In meinem aktuellen Test-Setup habe ich mehrere VMs, auf denen Debian-11 läuft. Alle Knoten haben eine private IP und eine zweite Wireguard-Schnittstelle. In Zukunft werden sich die Knoten an verschiedenen Standorten mit unterschiedlichen Netzwerken befinden und Wireguard wird verwendet, um alle unterschiedlichen Netzwerkumgebungen zu „überlagern“. Ich möchte auf allen Knoten ein Kubernetes installieren.
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
...
Ich habe also Docker und kubeadm/kubelet/kubectl in Version 1.23.5 auf allen Knoten installiert. Außerdem habe ich auf allen Knoten einen Haproxy installiert. Er fungiert als Lastenausgleich, indem er localhost:443 auflistet und die Anfragen an eine der Online-Kontrollebenen weiterleitet.
Dann habe ich den Cluster mit kubeadm gestartet
vm01> kubeadm init --apiserver-advertise-address=10.11.12.10 --pod-network-cidr=10.20.0.0/16
Danach habe ich getestet, ob ich Flanell oder Kaliko integrieren kann. Entweder durch Hinzufügen --iface=<wireguard-interface>oder durch Festlegen des benutzerdefinierten Manifests ...nodeAddressAutodetectionV4.interface: <wireguard-interface>.
Wenn ich einen normalen Knoten hinzufüge, ist alles in Ordnung. Der Knoten wird hinzugefügt, Pods werden erstellt und die Kommunikation erfolgt über die definierte Netzwerkschnittstelle.
Wenn ich eine Steuerebene ohne Wireguard-Schnittstelle hinzufüge, kann ich auch verschiedene Steuerebenen hinzufügen mit
vm2> kubeadm join 127.0.0.1:443 --token ... --discovery-token-ca-cert-hash sha256:... --control-plane
Natürlich habe ich vorher mehrere Dateien von vm01 nach vm02 kopiert, wie /etc/kubernetes/pkietwa die ca.*, sa.*, front-proxy-ca.*, apiserver-kubelet-client.*und etcd/ca.*.
Aber wenn ich das Flannel- oder Calico-Netzwerk zusammen mit der Wireguard-Schnittstelle verwende, passiert nach dem Join-Befehl etwas Seltsames.
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
Und nach diesem Timeout funktioniert der API-Server sogar auf vm01 nicht mehr, ich kann keine kubeadm- oder kubectl-Befehle mehr ausführen. Der HTTPS-Dienst auf 6443 ist tot. Aber ich verstehe weder, warum der API-Server auf vm01 nicht mehr funktioniert, wenn ich einen zweiten API-Server hinzufüge, noch kann ich einen Grund finden, wenn die Ausgabe von den 192.168.... IPs spricht, weil der Cluster nur über das Wireguard-Netzwerk 10.11.12.0/24 kommunizieren sollte.
Antwort1
Nach der Feststellung eines ähnlichen Problems inhttps://stackoverflow.com/questions/64227042/setting-up-a-kubernetes-master-on-a-different-ipIch denke, das ist auch hier die Lösung. Wenn ich hinzufüge --apiserver-advertise-address=<this-wireguard-ip>, ändert sich die Ausgabe (keine 192.168.. IP) und es wird verbunden. Was ich nicht verstehe, ist, warum der VM01-API-Server nicht mehr funktioniert.
Was auch immer der Join-Befehl im Hintergrund tut, er muss einen etcd-Dienst auf der zweiten Kontrollebene erstellen und dieser Dienst muss auch auf derselben IP laufen wie die Flannel/Calico-Netzwerkschnittstelle. Bei Verwendung der primären Netzwerkschnittstelle ist dieser Parameter auf der zweiten/dritten Kontrollebene nicht erforderlich.