Wie kann ich die Kubelet- und Control-Plane-Konfiguration richtig mit Kubeadm ändern?

Question

Ich habe einen Kubernetes-Cluster (v1.20.0) mit 3 Mastern und 3 Knoten installiert kubeadm init, kubeadm joinalles auf Ubuntu 20.04. Jetzt muss ich die Konfiguration aktualisieren und

• Fügen Sie --cloud-provider=externaldas Kubelet-Startup-Flag auf allen Knoten hinzu, die ich verwenden werdevsphere-csi-treiber
• Ändern Sie die --service-cidraufgrund von Netzwerkanforderungen

Ich bin mir jedoch nicht ganz sicher, wie ich diese Änderungen richtig vornehme.

Kubelet

Es /etc/systemd/system/kubelet.service.d/10-kubeadm.confgibt dort einen Verweis darauf, /etc/default/kubeletaber das wird als letztes Mittel angesehen und es wird .NodeRegistration.KubeletExtraArgsstattdessen eine Aktualisierung empfohlen:

...
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/default/kubelet
...

Wo ist das .NodeRegistration.KubeletExtraArgsund wie ändere ich es für alle Knoten im Cluster?

Steuerebene

Soweit ich weiß, werden der API-Server und der Controller-Manager als statische Pods auf jedem Master ausgeführt und lesen ihre Konfiguration von /etc/kubernetes/manifests/kube-<type>.yaml. Mein erster Gedanke war, die notwendigen Änderungen an diesen Dateien vorzunehmen, aber laut den Kubernetes-Dokumenten aufUpgrade eines Kubeadm-Clusters, kubeadm wird:

* Fetches the kubeadm ClusterConfiguration from the cluster.
* Optionally backups the kube-apiserver certificate.
* Upgrades the static Pod manifests for the control plane components.

Da ich die Manifeste manuell geändert habe, werden sie in der ClusterConfiguration ( kubectl -n kube-system get cm kubeadm-config -o yaml) nicht aktualisiert. Würden meine Änderungen auf diese Weise ein Upgrade überstehen? Ich nehme an, ich könnte die ClusterConfiguration auch manuell bearbeiten, kubeadm edit cm ...aber das scheint fehleranfällig zu sein und man vergisst leicht jedes Mal, sie zu ändern.

Laut der Dokumentation gibt es eine Möglichkeit,Anpassen der Control-Plane-Konfigurationaber das scheint nur der Fall zu sein, wenn der Cluster zum ersten Mal installiert wird. kubeadm config print init-defaultsWie der Name schon sagt, werden mir beispielsweise nur die Standardwerte angezeigt, nicht das, was derzeit im Cluster ausgeführt wird. Der Versuch, die Clusterkonfiguration zu extrahieren kubectl -n kube-system get cm kubeadm-config -o yamlund auszuführen, kubeadm init --config <config>schlägt auf alle möglichen Arten fehl, da der Cluster bereits initialisiert ist.

Kubeadm kann laufenInitialisierungsphase Steuerebeneupload-configDadurch werden die statischen Pod-Manifeste aktualisiert, die Clusterkonfiguration bleibt jedoch unberührt, sodass ich diese Phase ebenfalls ausführen müsste .

Basierend auf dem oben Gesagten scheint der Workflow

• Extrahieren Sie die ClusterConfiguration kubeadm -n kube-system get cm kubeadm-configund speichern Sie sie in einer YAML-Datei
• Passen Sie die YAML-Datei mit den gewünschten Änderungen an
• Änderungen übernehmen mitkubeadm init phase control-plane all --config <yaml>
• Geänderte Konfiguration hochladenkubeadm init phase upload-config all --config <yaml>
• Verteilen Sie die geänderte YAML-Datei an alle Master
• Für jeden Master bewerben Sie sich mitkubeadm init phase control-plane all --config <yaml>

Was mir hier Sorgen bereitet, ist die offensichtliche Trennung zwischen den statischen Pod-Manifesten und der Clusterkonfiguration. Änderungen werden nicht besonders oft vorgenommen, daher vergisst man leicht, dass Änderungen an einer Stelle auch Änderungen an der anderen erfordern – manuell.

Gibt es keine Möglichkeit, die Kubelet- und Control-Plane-Einstellungen zu aktualisieren, die die Konsistenz zwischen den Kubernetes-Komponenten und Kubeadm sicherstellen? Ich bin noch recht neu bei Kubernetes und es gibteine Mengean Dokumentation dazu, also tut mir leid, wenn ich hier etwas Offensichtliches übersehen habe.

Answer 1

Ich werde versuchen, auf beide Ihrer Fragen einzugehen.

---

1. Fügen Sie auf allen Knoten das Startflag --cloud-provider=external kubelet hinzu

Wo ist dieses .NodeRegistration.KubeletExtraArgs und wie ändere ich es für alle Knoten im Cluster?

KubeletExtraArgssind alle von Kubelet unterstützten Argumente und Parameter. Sie sind dokumentiertHier. Sie müssen den Befehl mit den entsprechenden Flags verwenden kubelet, um ihn zu ändern. Beachten Sie auch, dass das Flag, das Sie verwenden möchten, in k8s v1.23 entfernt wird:

--cloud-provider stringDer Anbieter für Cloud-Dienste. Wird auf eine leere Zeichenfolge gesetzt, wenn ohne Cloud-Anbieter ausgeführt wird. Wenn festgelegt, bestimmt der Cloud-Anbieter den Namen des Knotens (lesen Sie in der Dokumentation des Cloud-Anbieters nach, ob und wie der Hostname verwendet wird). (VERALTET: wird in 1.23 entfernt, um den Code des Cloud-Anbieters aus Kubelet zu entfernen.)

BEARBEITEN:

Um Ihre Frage bezüglich Folgendem besser zu beantworten:.NodeRegistration.KubeletExtraArgs

Dies sind auch Elemente derkubeadm-Init-Konfigurationsdatei:

Es ist möglich, die Konfiguration kubeadm initmit einer Konfigurationsdatei statt mit Befehlszeilenflags durchzuführen, und einige erweiterte Funktionen sind möglicherweise nur als Optionen der Konfigurationsdatei verfügbar. Diese Datei wird mithilfe des --configFlags übergeben und muss eine ClusterConfiguration Struktur und optional mehrere Strukturen enthalten, die durch getrennt sind . ---\nDas Mischen --configmit anderen Flags ist in einigen Fällen möglicherweise nicht zulässig.

Weitere Einzelheiten finden Sie auch über dieKnotenregistrierungsoptionensowie weitere Informationen zu den Feldern und der Verwendung der Konfiguration.

Beachten Sie außerdem Folgendes:

KubeletExtraArgsübergibt zusätzliche Argumente an den Kubelet. Die Argumente hier werden über die Umgebungsdatei an die Kubelet-Befehlszeile übergeben.

kubeadm schreibt zur Laufzeit für das Kubelet in die Quelle. Dies überschreibt die generische Basiskonfiguration in kubelet-config-1.X ConfigMap

Flags haben beim Parsen eine höhere Priorität. Diese Werte sind lokal und spezifisch für den Knoten, auf dem kubeadm ausgeführt wird.

EDIT2:

kubeadm initsoll nur einmal beim Erstellen eines Clusters verwendet werden, wenn Sie es mit Flags oder einer Konfigurationsdatei verwenden. Sie können die Konfigurationen nicht ändern, indem Sie es erneut mit anderen Werten ausführen.HierSie finden Informationen zu kubeadm und seiner Verwendung. Sobald der Cluster eingerichtet ist, sollte kubeadm gelöscht und Änderungen direkt an den statischen Pod-Manifesten vorgenommen werden.

---

2. Ändern Sie --service-cidr entsprechend den Netzwerkanforderungen

Das ist komplizierter. Sie könnten es ähnlich machen wieHieroderHierDieser Ansatz ist jedoch fehleranfällig und eher nicht zu empfehlen.

Der praktikablere und sicherere Weg wäre, den Cluster einfach mit kubeadm resetund neu zu erstellen kubeadm init --service-cidr. Die Option, die CIDRs automatisch zu ändern, war aus der Kubernetes-Perspektive nicht einmal zu erwarten. Kurz gesagt, diekubeadm zurücksetzenist hier der richtige Weg.

Answer 2

In Bezug auf

Ich verstehe, dass sich KubletExtraArgs auf die Befehlszeilenargumente von Kublet bezieht. Was ich nicht verstehe, ist, wo dieses Attribut ist und wie ich es ändern kann.

mehrere Quellen wieDieses hierzeigen auf das Hinzufügen zu

/etc/systemd/system/kubelet.service.d/10-kubeadm.conf

Zeilen wie zB

Environment="KUBELET_EXTRA_ARGS=--pod-manifest-path=/etc/kubelet.d/"

um die Umgebung für ein benutzerdefiniertes Verzeichnis für statische Pods hier beispielsweise festzulegen, anstatt die CLI mit

kubelet --pod-manifest-path=/etc/kubelet.d

wie in den Dokumenten vorgeschlagen.

Wenn Sie danach googeln, $KUBELET_EXTRA_ARGSwerden Sie zahlreiche Beispiele zu der oben genannten 10-kubeadm.confDatei finden.