Was hat es damit auf sich?
Kürzlich sind wir auf einen Fehler gestoßen, der uns daran hinderte, Dienste in unserem Cluster bereitzustellen und zu testen.
Dies wurde durch containerd v.1.4.6 ausgelöst. Die neuen Pods waren in der Warteschleife und hatten den Fehler „Failed to create pod sandbox: rpc error: code = DeadlineExceeded desc = context deadline exceeded“.
Bei der Fehlersuche stießen wir auf die Lösung in der Weave-Dokumentation. (https://www.weave.works/docs/net/latest/kubernetes/kube-addon/#-things-to-watch-out-for).
Wir sind jedoch zusätzlich auf einen alternativen Lösungsansatz gestoßen, der darin besteht, den CIDR-Bereich von Service und Pod Network zu erweitern. Das Problem ist jedoch, dass dies nicht vorgesehen ist, nachdem ein Cluster erstellt wurde. Die CIDR-Einträge sind im Steuerebenen-Knoten schreibgeschützt. Wie das Ganze funktioniert, wird im Folgenden näher erläutert.
Wie funktioniert das?
Um den Schreibschutz des Steuerebenen-Knotens außer Kraft zu setzen, wird ein weiterer Steuerebenen-Knoten hinzugefügt und bearbeitet. Da dieser keine Einträge hat, dies aber in Zukunft noch geändert werden könnte, besteht für ihn kein Schreibschutz. Somit kann dort der Eintrag podCIDR zum Spec-Eintrag hinzugefügt werden. Auf diesem Steuerebenen-Knoten müssen dann die CIDR-Einträge in den Manifestdateien aktualisiert werden. Darüber hinaus müssen die CIDR und die Adresse des zweiten Masters in den ConfigMaps kube-proxy, kubeadm-config und cluster-info aktualisiert werden.
Beispiel:
Voraussetzungen
Es wird ein Cluster mit zwei Control-Plane-Knoten und mehreren Worker-Knoten benötigt. Verwendet wird Kubernetes Version 1.23.14 mit der Container-Runtime containerd und CNI Weave (https://www.weave.works/docs/net/latest/kubernetes/kube-addon/#-installation).
Der Cluster wird mit --service-cidr=„192.168.128.0/24“ und --pod-network-cidr=„192.168.129.0/24“ erstellt.
Testen
Nachdem der Cluster erstellt wurde, wird `kubectl edit` verwendet, um den zweiten Steuerebenen-Knoten zu bearbeiten.
Der Abschnitt „Spezifikationen“ wird wie folgt angepasst:
spec:
podCIDR: 192.168.130.0/23
podCIDRs:
- 192.168.130.0/23
taints:
- effect: NoSchedule
key: node-role.kubernetes.io/master
Anschließend werden die Manifestdateien auf dem zweiten Control-Plane-Knoten mit der neuen CIDR aktualisiert. Dazu kann der Befehl `kubeadm init phase control-plane all --service-cidr "192.168.128.0/23“ --pod-network-cidr "192.168.130.0/23“` verwendet werden.
Im Cluster müssen nun die ConfigMaps für kube-proxy, kubeadm-config und cluster-info konfiguriert werden.
Zunächst wird die ConfigMap von kube-proxy mit dem Befehl `kubectl edit cm kube-proxy -n kube-system` bearbeitet.
Der `clusterCIDR` Eintrag muss den Wert des neuen pod-network-cid`rs haben und der `server`-Eintrag muss die IP-Adresse des neuen Control-Plane-Knotens haben.
Dann wird die ConfigMap von kubeadm-config mit dem Befehl `kubectl edit cm kubeadm-config -n kube-system` bearbeitet.
Der Eintrag `podSubnet` muss den Wert der neuen pod-network-cid`rs haben, der Eintrag `serviceSubnet` muss den Wert der neuen service-cid`rs haben und der Eintrag `controlPlaneEndpoint` muss die IP-Adresse des neuen Steuerebenen-Knotens haben.
Schließlich wird die ConfigMap von kube-proxy mit dem Befehl `kubectl edit cm cluster-info -n kube-public` bearbeitet.
Der Eintrag `server` muss die IP-Adresse des neuen Steuerelementknotens enthalten.
Nun wird das Kubelet auf dem zweiten Steuerebenen-Knoten neu gestartet. Dazu wird der Befehl `systemctl restart kubelet` verwendet.
Nun wird der erste Control-Plane-Knoten mit dem Befehl `kubectl delete node Control-Plane-Node1` aus dem Cluster entfernt.
Wenn ein Admin-Knoten verwendet wird, muss die Datei ./kube/config im Benutzerverzeichnis geändert werden. Der Eintrag `server` muss die IP-Adresse des neuen Kontrollplanknotens enthalten. Der CIDR-Bereich des Clusters ist nun aktualisiert worden.
Author: Tobias Altmann
