Na minha configuração de teste atual, tenho várias VMs executando o Debian-11. Todos os nós possuem um IP privado e uma segunda interface wireguard. No futuro, os nós estarão em locais diferentes com redes diferentes e o Wireguard será usado para "sobrepor" todos os diferentes ambientes de rede. Quero instalar um Kubernetes em todos os nós.
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
...
Portanto, instalei o docker e o kubeadm/kubelet/kubectl na versão 1.23.5 em todos os nós. Também instalei um haproxy em todos os nós. Ele funciona como um balanceador de carga listando localhost:443 e encaminhando as solicitações para um dos planos de controle online.
Então iniciei o cluster com kubeadm
vm01> kubeadm init --apiserver-advertise-address=10.11.12.10 --pod-network-cidr=10.20.0.0/16
Depois disso testei integrar flanela ou chita. Adicionando --iface=<wireguard-interface>ou definindo o manifesto personalizado ...nodeAddressAutodetectionV4.interface: <wireguard-interface>.
Quando adiciono um nó normal, está tudo bem. O nó é adicionado, os pods são criados e a comunicação é feita através da interface de rede definida.
Quando adiciono um plano de controle sem a interface wireguard, também posso adicionar diferentes planos de controle com
vm2> kubeadm join 127.0.0.1:443 --token ... --discovery-token-ca-cert-hash sha256:... --control-plane
É claro que antes disso , copiei vários arquivos de vm01 para vm02 /etc/kubernetes/pkicomo ca.*, sa.*, front-proxy-ca.*e .apiserver-kubelet-client.*etcd/ca.*
Mas quando utilizo a rede flanela ou chita junto com a interface wireguard, algo estranho acontece após o comando join.
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
E depois desse tempo limite, mesmo no vm01, o servidor API para de funcionar, não consigo mais executar nenhum comando kubeadm ou kubectl. O serviço HTTPS em 6443 está inativo. Mas também não entendo porque o servidor API no vm01 para de funcionar ao adicionar um segundo servidor API nem consigo encontrar um motivo, quando a saída está falando sobre 192.168.... IPs, porque o cluster deve se comunicar apenas através do 10.11.12.0 /24 rede wireguard.
Responder1
Depois de encontrar um problema semelhante emhttps://stackoverflow.com/questions/64227042/setting-up-a-kubernetes-master-on-a- Different-IPEu acho que essa também é a solução aqui. Quando adiciono --apiserver-advertise-address=<this-wireguard-ip>, a saída muda (sem 192.168.. IP) e ela se junta. O que não entendo é por que o servidor API VM01 para de funcionar.
O que quer que o comando join esteja fazendo nos bastidores, ele precisa criar um serviço etcd no segundo plano de controle e esse serviço também deve ser executado no mesmo IP da interface de rede flanela/calico. No caso de utilizar a interface de rede primária este parâmetro não é necessário no segundo/terceiro plano de controle.