Creé un clúster integrado multimaestro de K3s como este:
nombre de host: k3s01
curl -sfL https://get.k3s.io | K3S_TOKEN=xxx INSTALL_K3S_EXEC="server --disable servicelb --disable traefik --bind-address=10.0.0.4 --tls-san 10.0.0.4 --node-external-ip=168.119.x.x --node-ip=10.0.0.4 --flannel-iface=enp7s0 --advertise-address=PUBIP-OF-LB --cluster-init" sh -
nombre de host: k8s02
curl -sfL https://get.k3s.io | K3S_TOKEN=xxx INSTALL_K3S_EXEC="server --disable servicelb --disable traefik --bind-address=10.0.0.2 --tls-san 10.0.0.2 --node-ip 10.0.0.2 --node-external-ip=168.119.x.x --flannel-iface=enp7s0 --server=https://10.0.0.4:6443" sh -
nombre de host: k8s03
curl -sfL https://get.k3s.io | K3S_TOKEN=xxx INSTALL_K3S_EXEC="server --disable servicelb --disable traefik --bind-address=10.0.0.3 --tls-san 10.0.0.3 --node-ip 10.0.0.3 --node-external-ip=168.119.x.x --flannel-iface=enp7s0 --server=https://10.0.0.4:6443" sh -
¡Puedo conectarme desde mi máquina local con kubectl a través de LB-IP! LB: tcp 6443 -> 6443
También puedo usar kubectl desde cualquiera de los nodos anteriores. Implementé CSI para Hetzner, eso también funciona bien. ¡Probado con su implementación de prueba!
Sin embargo, después de todo eso (funcionando bien hasta ahora), intenté instalar ingress-nginx. La implementación comenzó sin ningún problema. Pero descubrí que hay un problema al comunicarse con el apiserver desde dentro del clúster, como muestra el siguiente registro del controlador ingress-nginx:
E1204 11:42:25.216392 8 leaderelection.go:321] error retrieving resource lock ingress-nginx/ingress-controller-leader-nginx: Get "https://10.43.0.1:443/api/v1/namespaces/ingress-nginx/configmaps/ingress-controller-leader-nginx": dial tcp 10.43.0.1:443: connect: connection refused
Mmmm, ¡qué extraño! Bien, hagamos algunas comprobaciones:
kubectl get svc kubernetes -o yaml
apiVersion: v1
kind: Service
metadata:
creationTimestamp: "2020-12-04T11:22:25Z"
labels:
component: apiserver
provider: kubernetes
managedFields:
- apiVersion: v1
fieldsType: FieldsV1
fieldsV1:
f:metadata:
f:labels:
.: {}
f:component: {}
f:provider: {}
f:spec:
f:clusterIP: {}
f:ports:
.: {}
k:{"port":443,"protocol":"TCP"}:
.: {}
f:name: {}
f:port: {}
f:protocol: {}
f:targetPort: {}
f:sessionAffinity: {}
f:type: {}
manager: k3s
operation: Update
time: "2020-12-04T11:22:25Z"
name: kubernetes
namespace: default
resourceVersion: "10434"
selfLink: /api/v1/namespaces/default/services/kubernetes
uid: f0993556-3b7f-40aa-a293-45170cb03002
spec:
clusterIP: 10.43.0.1
ports:
- name: https
port: 443
protocol: TCP
targetPort: 6443
sessionAffinity: None
type: ClusterIP
status:
loadBalancer: {}
Parece gtm.
kubectl get endpoints -o yaml
apiVersion: v1
items:
- apiVersion: v1
kind: Endpoints
metadata:
creationTimestamp: "2020-12-04T11:22:25Z"
labels:
endpointslice.kubernetes.io/skip-mirror: "true"
managedFields:
- apiVersion: v1
fieldsType: FieldsV1
fieldsV1:
f:metadata:
f:labels:
.: {}
f:endpointslice.kubernetes.io/skip-mirror: {}
f:subsets: {}
manager: k3s
operation: Update
time: "2020-12-04T11:23:39Z"
name: kubernetes
namespace: default
resourceVersion: "808"
selfLink: /api/v1/namespaces/default/endpoints/kubernetes
uid: cb450392-b4c9-4c2f-bfde-1a3b20ac4b5d
subsets:
- addresses:
- ip: 167.233.x.x
- ip: 168.119.x.x
- ip: 168.119.x.x
ports:
- name: https
port: 6443
protocol: TCP
kind: List
metadata:
resourceVersion: ""
selfLink: ""
Bien, ¿por qué están aquí las IP de pub? Comprobémoslo desde un pod para llamar a una de las IP directamente:
kubectl exec -it ingress-controler-pod-xxxx -- bash
bash-5.0$ curl https://167.233.x.x:6443 --insecure
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {
},
"status": "Failure",
"message": "Unauthorized",
"reason": "Unauthorized",
"code": 401
}bash-5.0$ curl https://10.43.0.1:443
curl: (7) Failed to connect to 10.43.0.1 port 443: Connection refused
Ok... ¡eso es extraño!
También a veces algunos errores como:
Error from server: error dialing backend: dial tcp: lookup k8s02: Try again
Aparece cuando intento top exex en un pod o muestro registros. Eso solo sucede cuando intento hacer esto en un pod de destino que se ejecuta en otro host.
¿Hay algún problema con el DNS?
cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
No puedo resolver mis hosts por su nombre. Sin embargo, acabo de especificar IP en la configuración de K3s. ¿Necesito DNS que funcione entre mis hosts? ¿Hay algún problema con los parámetros de instalación de mi K3s?
Respuesta1
Tuve un problema similar, causado por una resolución de DNS mal configurada. Verifique si puede resolver los nombres de host de los nodos entre sí.