En mi configuración de prueba actual tengo varias máquinas virtuales que ejecutan Debian-11. Todos los nodos tienen una IP privada y una segunda interfaz Wireguard. En el futuro, los nodos estarán en diferentes ubicaciones con diferentes redes y Wireguard se utiliza para "superponer" todos los diferentes entornos de red. Quiero instalar Kubernetes en todos los nodos.
node public ip wireguard ip
vm1 192.168.10.10 10.11.12.10
vm2 192.168.10.11 10.11.12.11
vm3 192.168.10.12 10.11.12.12
...
Así que instalé Docker y kubeadm/kubelet/kubectl en la versión 1.23.5 en todos los nodos. También instalé un haproxy en todos los nodos. Funciona como un equilibrador de carga al incluirse en localhost:443 y reenviar las solicitudes a uno de los planos de control en línea.
Luego inicié el clúster con kubeadm.
vm01> kubeadm init --apiserver-advertise-address=10.11.12.10 --pod-network-cidr=10.20.0.0/16
Después de eso probé para integrar franela o percal. Ya sea agregando --iface=<wireguard-interface>o configurando el manifiesto personalizado ...nodeAddressAutodetectionV4.interface: <wireguard-interface>.
Cuando agrego un nodo normal, todo está bien. Se agrega el nodo, se crean pods y la comunicación se realiza a través de la interfaz de red definida.
Cuando agrego un plano de control sin la interfaz Wireguard, también puedo agregar diferentes planos de control con
vm2> kubeadm join 127.0.0.1:443 --token ... --discovery-token-ca-cert-hash sha256:... --control-plane
Por supuesto , antes de eso, copié varios archivos de vm01 a vm02 /etc/kubernetes/pkicomo ca.*, sa.*, front-proxy-ca.*y .apiserver-kubelet-client.*etcd/ca.*
Pero cuando uso la red de franela o calico junto con la interfaz Wireguard, sucede algo extraño después del comando de unión.
root@vm02:~# kubeadm join 127.0.0.1:443 --token nwevkx.tzm37tb4qx3wg2jz --discovery-token-ca-cert-hash sha256:9a97a5846ad823647ccb1892971c5f0004043d88f62328d051a31ce8b697ad4a --control-plane
[preflight] Running pre-flight checks
[preflight] Reading configuration from the cluster...
[preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
[preflight] Running pre-flight checks before initializing the new control plane instance
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [localhost mimas] and IPs [192.168.10.11 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [localhost mimas] and IPs [192.168.10.11 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local mimas] and IPs [10.96.0.1 192.168.10.11 127.0.0.1]
[certs] Using the existing "apiserver-kubelet-client" certificate and key
[certs] Valid certificates and keys now exist in "/etc/kubernetes/pki"
[certs] Using the existing "sa" key
[kubeconfig] Generating kubeconfig files
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[kubeconfig] Writing "admin.conf" kubeconfig file
[endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[check-etcd] Checking that the etcd cluster is healthy
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Starting the kubelet
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...
[etcd] Announced new etcd member joining to the existing etcd cluster
[etcd] Creating static Pod manifest for "etcd"
[etcd] Waiting for the new etcd member to join the cluster. This can take up to 40s
[kubelet-check] Initial timeout of 40s passed.
error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: timeout waiting for etcd cluster to be available
To see the stack trace of this error execute with --v=5 or higher
Y después de ese tiempo de espera, incluso en vm01, el servidor API deja de funcionar, ya no puedo ejecutar ningún comando kubeadm o kubectl. El servicio HTTPS en 6443 está inactivo. Pero ni entiendo por qué el servidor API en vm01 deja de funcionar al agregar un segundo servidor API ni puedo encontrar una razón, cuando el resultado habla de las IP 192.168...., porque el clúster debe comunicarse solo a través de 10.11.12.0 /24 red de protección de cables.
Respuesta1
Después de encontrar un problema similar enhttps://stackoverflow.com/questions/64227042/setting-up-a-kubernetes-master-on-a-diferente-ipCreo que esta también es la solución aquí. Cuando agrego --apiserver-advertise-address=<this-wireguard-ip>, la salida cambia (no 192.168.. IP) y se une. Lo que no entiendo es por qué el servidor API VM01 deja de funcionar.
Cualquiera que sea el comando de unión que esté haciendo internamente, necesita crear un servicio etcd en el segundo plano de control y ese servicio también debe ejecutarse en la misma IP que en la interfaz de red de franela/calicó. En caso de utilizar la interfaz de red primaria, este parámetro no es necesario en el segundo/tercer plano de control.