Kubernetes auf Hetzner Cloud: Warum ich das Netzwerk-Plugin gewechselt habe

Beim Deployen von Anwendungen in meinen Cluster fiel mir eine Störung auf – ich nutzte PVC, um Volumes zu provisionieren. Manche Volumes liessen sich nicht erstellen oder mounten. Der Container hcloud-csi-driver im hcloud-csi-node-xxxx loggte folgende Fehler:

Get https://api.hetzner.cloud/v1/volumes/5127341: dial tcp: i/o timeout"

Warum sollte eine Verbindung zu api.hetzner.cloud timeouten? Ich untersuchte beide Nodes, und nicht jeder Node hatte diesen Timeout. Warum verhalten sie sich unterschiedlich, obwohl sie exakt gleich konfiguriert sind? Tiefer im Kaninchenbau fand ich diese Art von Fehlermeldungen:

Get https://api.hetzner.cloud/v1/volumes/5127341: dial tcp: lookup api.hetzner.cloud on 10.96.0.10:53: read udp 10.244.2.70:55772->10.96.0.10:53: i/o timeout

Es sieht so aus, als könne dieser Pod den coredns-Service im Cluster nicht erreichen, api.hetzner.cloud nicht auflösen und daher die Hetzner-API nicht aufrufen, um das Volume zu erstellen und anzuhängen. Als ich diese Pods und sogar Nodes neu startete (vorher kubectl drain <node>), fiel mir auf: Wenn nur ein Node läuft, tritt der Fehler nicht so oft auf. Und nachdem ich die Master-Toleration für coredns vorübergehend entfernt hatte – wodurch alles in der obigen Aufrufkette auf worker-1 lief – war der Fehler komplett weg. Das führte zum Schluss, dass das Netzwerk nicht wie erwartet funktioniert.

Der erste Satz auf https://github.com/coreos/flannel/blob/master/Documentation/troubleshooting.md:

In Docker v1.13 and later, the default iptables forwarding policy was changed to DROP This problem manifests itself as connectivity problems between containers running on different hosts. To resolve it upgrade to the latest version of flannel.

fiel mir ins Auge. Aber selbst nach dem Upgrade von flannel auf die neueste verfügbare Version half es nicht. Und der Issue-Tracker von flannel zeigt, dass ich mit dem Problem nicht allein bin: https://github.com/coreos/flannel/issues?q=is%3Aissue+is%3Aopen+FORWARD

Angesichts der MetalLB Network Addon Compatibility musste ich ein Netzwerk-Addon finden, das “einfach” funktioniert. Mit Calico, Cilium und Weave als grossartigen Alternativen, die nicht auf flannel setzen, gibt es reichlich Auswahl.

Ich entschied mich für Cilium, weil es eine aktive Community und volle MetalLB-Kompatibilität hat. Ich hätte aber auch Calico oder Weave nehmen können – irgendwas musste es sein.

Der Austausch eines CNI-Plugins/-Addons verursacht eine Downtime für alle Pods im Cluster.

# delete the flannel network from the cluster
kubectl delete -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

# on each node and master
rm /etc/cni/net.d/10-flannel.conf

# now restart
reboot

# now deploy Cilium
kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/v1.7.1/install/kubernetes/quick-install.yaml

# after waiting a few seconds (up to a minute or two) the network and all pods come up again.

Ich habe sowohl Cilium als auch WeaveNet getestet, und beide Addons funktionieren, soweit ich das aktuell beurteilen kann.