Cluster, Workerknoten und Clusterkomponenten aktualisieren
In den folgenden Abschnitten finden Sie Schritte, um Ihre Cluster-Master-und Workerknoten auf dem neuesten Stand zu halten.
Master aktualisieren
- Woran erkenne ich, wann ich den Master aktualisieren muss?
- Sie werden in der Konsole, in Ankündigungen und in der Befehlszeilenschnittstelle benachrichtigt, wenn Aktualisierungen verfügbar sind. Sie können auch in regelmäßigen Abständen die Seite Unterstützte Versionen überprüfen.
- Um wie viele Versionen darf der Master hinter der neuesten Version zurückliegen?
- Sie können den API-Server nur auf die nächste Version aktualisieren, die auf die aktuelle Version folgt (
n+1). - Können meine Worker-Knoten eine neuere Version als der Master ausführen?
- Auf Ihren Workerknoten kann keine höhere
major.minorKubernetes-Version als auf dem Master ausgeführt werden. Außerdem dürfen Ihre Worker-Knoten höchstens zwei Nebenversionen hinter der Master-Version zurückliegen (n-2). Aktualisieren Sie zunächst Ihren Master auf die neueste Version von Kubernetes. Anschließend aktualisieren Sie die Workerknoten in Ihrem Cluster.
Workerknoten können eine spätere Patchversion als der Master ausführen, zum Beispiel Patchversionen, die für Workerknoten aufgrund von Sicherheitsaktualisierungen spezifisch sind.
- Wie werden Patch-Updates installiert?
- Patchaktualisierungen für den Master werden automatisch über mehrere Tage hinweg angewendet, sodass eine Master-Patch-Version möglicherweise als verfügbar angezeigt wird, bevor sie auf Ihren Master angewendet wird. Die Aktualisierungsautomatisierung
überspringt auch Cluster, die sich in einem nicht einwandfreien Zustand befinden oder in denen derzeit Operationen ausgeführt werden. Es kann vorkommen, dass IBM gelegentlich die automatischen Aktualisierungen für ein bestimmtes Master-Fixpack
inaktiviert, zum Beispiel ein Patch, das nur benötigt wird, wenn ein Master von einer Nebenversion auf eine andere Version aktualisiert wird. In jedem dieser Fälle können Sie die Versionsinformationen unter Kubernetes auf mögliche Auswirkungen überprüfen und den Befehl
ibmcloud ks cluster master updateselbst sicher ausführen, ohne abzuwarten, bis die automatische Aktualisierung erfolgt ist.
Im Gegensatz zum Master müssen Sie die Worker für jede Patchversion aktualisieren.
- Was geschieht während der Master-Aktualisierung?
- Ihr Master ist mit drei Replikat-Master-Pods hoch verfügbar. Die Master-Pods haben eine rollierende Aktualisierung, während der immer nur ein Pod nicht verfügbar ist. Zwei Instanzen sind aktiv, sodass Sie während der Aktualisierung auf den Cluster zugreifen und ihn ändern können. Ihre Workerknoten, Apps und Ressourcen werden weiterhin ausgeführt.
- Kann ich das Update rückgängig machen?
- Nein, nachdem eine Aktualisierung durchgeführt wurde, können Sie den Cluster nicht auf eine frühere Version zurücksetzen. Achten Sie darauf, zunächst einen Testcluster zu verwenden und die Anweisungen für den Umgang mit potenziellen Problemen zu befolgen, bevor Sie Ihren Produktionsmaster aktualisieren.
- Wie kann ich den Master aktualisieren?
- Das folgende Diagramm zeigt den Prozess, den Sie zum Aktualisieren des Masters ausführen können.
Schritte zum Aktualisieren des Cluster-Masters
Bevor Sie beginnen, stellen Sie sicher, dass Sie über die IAM-Plattformzugriffsrolle Operator oder Administrator verfügen.
Aktualisierungen des Clustermasters werden blockiert, wenn eine Zertifikatsrotation der Zertifizierungsstelle (CA) im Gange ist. Warten Sie den Abschluss einer Rotation ab, bevor Sie den Cluster-Master aktualisieren.
Gehen Sie wie folgt vor, um die Haupt- oder _Neben_version des Kubernetes-Masters zu aktualisieren:
-
Überprüfen Sie die Versionsinformationen unter Kubernetes und nehmen Sie alle Aktualisierungen vor, die mit Update before master gekennzeichnet sind.
-
Überprüfen Sie alle hilfreichen Warnhinweise unter Kubernetes, wie z. B. Hinweise auf veraltete Funktionen.
-
Überprüfen Sie die in Ihrem Cluster installierten Add-ons und Plug-ins hinsichtlich aller möglichen Auswirkungen, die auf die Aktualisierung der Clusterversion zurückzuführen sein können.
-
Add-ons überprüfen
- Listen Sie die Add-ons im Cluster auf.
ibmcloud ks cluster addon ls --cluster CLUSTER - Überprüfen Sie die installierte Kubernetes-Version für jedes installierte Add-on.
ibmcloud ks addon-versions - Wenn Ihr Add-on aktualisiert werden muss, um in der Kubernetes-Version ausgeführt werden zu können, auf die Ihr Cluster aktualisiert werden soll, aktualisieren Sie das Add-on.
- Listen Sie die Add-ons im Cluster auf.
-
Plug-ins überprüfen
- Suchen Sie im Helm-Katalog nach den Plug-ins, die Sie in Ihrem Cluster installiert haben.
- Erweitern Sie im seitlichen Menü den Abschnitt QUELLEN & TAR-DATEI.
- Laden Sie den Quellcode herunter und öffnen Sie ihn.
- Überprüfen Sie die Dateien
README.mdoderRELEASENOTES.mdauf unterstützte Versionen. - Wenn das Plug-in aktualisiert werden muss, um in der Kubernetes-Version ausgeführt zu werden, auf die Sie Ihren Cluster aktualisieren möchten, aktualisieren Sie das Plug-in, indem Sie die Plug-in-Anweisungen befolgen.
-
-
Aktualisieren Sie Ihren API-Server und die zugehörigen Master-Komponenten mithilfe der IBM Cloud-Konsole oder durch Ausführen des CLI -Befehls
ibmcloud ks cluster master update. -
Warten Sie ein paar Minuten und vergewissern Sie sich dann, dass die Aktualisierung abgeschlossen ist. Überprüfen Sie die Version des API-Servers im Dashboard für IBM Cloud-Cluster oder führen Sie den Befehl
ibmcloud ks cluster lsaus. -
Installieren Sie die Version der
kubectl cli, die mit dem API-Server Ihres Masters übereinstimmt. Kubernetes Unterstützt keinekubectlClient-Versionen, die zwei oder mehr Versionen von der Server-Version abweichen (n +/- 2).
Wenn das Master-Update abgeschlossen ist, können Sie je nach dem Typ des verwendeten Clusterinfrastrukturproviders Ihre Workerknoten aktualisieren.
Klassische Workerknoten aktualisieren
Sie sehen, dass für Ihre Workerknoten in einem Cluster in der klassischen Infrastruktur ein Update verfügbar ist. Was bedeutet das? Bei der Einrichtung von
Sicherheitsupdates und -patches für den API-Server und anderen Komponenten des Masters müssen Sie darauf achten, dass Ihre Workerknoten synchronisiert bleiben. Sie können zwei Typen von Aktualisierung durchführen: Eine Aktualisierung nur der
Patchversion oder eine Aktualisierung der Version (major.minor) mit der Patchversion.
- Patch: Eine Patchaktualisierung eines Workerknotens umfasst Korrekturen (Fixes) für die Sicherheit. Mit dem Befehl
ibmcloud ks worker reloadoderupdatekönnen Sie den klassischen Workerknoten auf den neuesten Patch aktualisieren. Beachten Sie, dass mit dem Befehlupdateder Workerknoten auch auf dieselbe Version (major.minor) wie die Master- und neueste Patchversion aktualisiert wird, wenn auch ein Update für die Version (major.minor) verfügbar ist. - Hauptversion.Nebenversion: Eine Aktualisierung der Version (
major.minor) stuft die Kubernetes-Version des Workerknotens auf dieselbe Version wie die des Masters hoch. Diese Art von Aktualisierung geht oft mit Änderungen an der Kubernetes-API oder anderen Verhaltensmustern einher, auf die Sie Ihren Cluster vorbereiten müssen. Beachten Sie, dass Ihre Worker-Knoten höchstens zwei Nebenversionen hinter der Master-Version zurückliegen dürfen (n-2). Sie können den klassischen Worker-Knoten mit dem Befehlibmcloud ks worker updateauf denselben Patch aktualisieren.
Weitere Informationen finden Sie in Aktualisierungstypen.
Es empfiehlt sich, bei jeder Aktualisierung der Arbeitsknoten rotieren Sie Ihre CA-Zertifikate zu verwenden, da der längste Schritt der Zertifikatsrotation das Neuladen oder Ersetzen der Arbeitsknoten beinhaltet.
- Was passiert mit meinen Apps während eines Updates?
- Wenn Sie Apps als Teil einer Bereitstellung auf Workerknoten ausführen, die Sie aktualisieren, werden die Apps auf anderen Workerknoten im Cluster neu geplant. Diese Workerknoten können sich in einem anderen Worker-Pool befinden. Wenn Sie eigenständige Workerknoten haben, können Apps auch auf eigenständigen Workerknoten geplant werden. Um Ausfallzeiten für Ihre App zu vermeiden, müssen Sie sicherstellen, dass genügend Kapazität im Cluster vorhanden ist, um die Workload zu übernehmen.
- Wie kann ich steuern, wie viele Worker-Knoten während eines Updates oder Reloads gleichzeitig heruntergefahren werden?
- Wenn alle Workerknoten betriebsbereit sein müssen, sollten Sie in Betracht ziehen, die Größe des Worker-Pools zu ändern oder eigenständige Workerknoten hinzufügen, um weitere Workerknoten hinzuzufügen. Sie können die zusätzlichen Workerknoten entfernen, nachdem die Aktualisierung abgeschlossen ist.
Darüber hinaus können Sie eine Konfigurationszuordnung Kubernetes erstellen, die die maximale Anzahl an Worker-Knoten festlegt, die gleichzeitig nicht verfügbar sein dürfen, beispielsweise während eines Updates. Workerknoten werden durch eine entsprechende Bezeichnung identifiziert. Sie können von IBM bereitgestellte Bezeichnungen oder angepasste Bezeichnungen verwenden, die Sie dem Workerknoten hinzugefügt haben.
Die Regeln der Konfigurationszuordnung „ Kubernetes “ werden nur für die Aktualisierung von Worker-Knoten verwendet. Diese Regeln wirken sich nicht auf das erneute Laden von Workerknoten aus. Dies bedeutet, dass das erneute Laden sofort nach der Anforderung erfolgt.
- Was passiert, wenn ich keine Konfigurationskarte definiere?
- Wenn die Konfigurationszuordnung nicht definiert wurde, wird die Standardeinstellung verwendet. Standardmäßig können maximal 20 % aller Workerknoten in jedem Cluster während des Aktualisierungsprozesses nicht verfügbar sein.
Voraussetzungen
Lesen Sie die Informationen zu den vorausgesetzten Schritten, bevor Sie Ihre Workerknoten der klassischen Infrastruktur aktualisieren.
Die Aktualisierung von Workerknoten kann zu Ausfallzeiten bei Ihren Apps und Services führen. Von Ihrer Workerknotenmaschine wird ein neues Image erstellt und dabei werden Daten gelöscht, die nicht außerhalb des Pods gespeichert sind.
- Stellen Sie im Hinblick auf die neuesten Sicherheitspatches und -korrekturen sicher, dass Ihre Workerknoten so bald wie möglich nach Veröffentlichung des neuesten Patches aktualisiert werden. Weitere Informationen zu den neuesten Updates finden Sie unter Kubernetes-Versionsinformationen.
- Melden Sie sich an Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest.
- Aktualisieren Sie den Master. Die Version des Workerknotens darf nicht höher als die Version des API-Servers sein, die in Ihrem Kubernetes-Master ausgeführt wird.
- Nehmen Sie alle Änderungen vor, die im Leitfaden zur Vorbereitung der Kubernetes-Version mit Nach Master aktualisieren gekennzeichnet sind.
- Wenn Sie ein Patch-Update anwenden möchten, lesen Sie die Versionsinformationen zu Kubernetes.
- Erwägen Sie, weitere Worker-Knoten hinzuzufügen, damit Ihr Cluster über genügend Kapazität verfügt, um Ihre Workloads während des Updates neu zu planen. Weitere Informationen finden Sie unter Workerknoten zu klassischen Clustern hinzufügen oder Workerknoten zu VPC-Clustern hinzufügen.
- Stellen Sie sicher, dass Sie über die IAM-Plattformzugriffsrolle Operator oder Administrator verfügen.
Klassische Workerknoten über die Befehlszeilenschnittstelle (CLI) mit einer Konfigurationszuordnung aktualisieren
Richten Sie eine Konfigurationszuordnung ein, um eine rollierende Aktualisierung Ihrer klassischen Arbeiterknoten durchzuführen.
-
Führen Sie die vorausgesetzten Schritte aus.
-
Listen Sie verfügbare Workerknoten auf und notieren Sie deren private IP-Adressen.
ibmcloud ks worker ls --cluster CLUSTER -
Zeigen Sie die Bezeichnungen eines Workerknotens an. Die Bezeichnungen der Workerknoten finden Sie im Abschnitt Labels der CLI-Ausgabe. Jede Bezeichnung besteht aus einem Selektorschlüssel (
NodeSelectorKey) und einem Selektorwert (NodeSelectorValue).kubectl describe node PRIVATE-WORKER-IPBeispielausgabe
NAME: 10.184.58.3 Roles: <none> Labels: arch=amd64 beta.kubernetes.io/arch=amd64 beta.kubernetes.io/os=linux failure-domain.beta.kubernetes.io/region=us-south failure-domain.beta.kubernetes.io/zone=dal12 ibm-cloud.kubernetes.io/encrypted-docker-data=true ibm-cloud.kubernetes.io/iaas-provider=softlayer ibm-cloud.kubernetes.io/machine-type=u3c.2x4.encrypted kubernetes.io/hostname=10.123.45.3 privateVLAN=2299001 publicVLAN=2299012 Annotations: node.alpha.kubernetes.io/ttl=0 volumes.kubernetes.io/controller-managed-attach-detach=true CreationTimestamp: Tue, 03 Apr 2022 15:26:17 -0400 Taints: <none> Unschedulable: false -
Erstellen Sie eine Konfigurationszuordnung und definieren Sie die Nichtverfügbarkeitsregeln für Ihre Workerknoten. Das folgende Beispiel zeigt vier Prüfungen:
zonecheck.json,regioncheck.json,defaultcheck.jsonund eine Prüfungsvorlage. Sie können diese Beispielprüfungen verwenden, um Regeln für Workerknoten in einer bestimmten Zone (zonecheck.json), Region (regioncheck.json) oder für alle Workerknoten zu definieren, die mit keiner der in der Konfigurationszuordnung (defaultcheck.json) definierten Prüfungen übereinstimmen. Mithilfe der Prüfvorlage können Sie eine eigene Prüfung erstellen. Für jede Prüfung müssen Sie zum Identifizieren eines Workerknotens eine der Workerknotenbezeichnungen auswählen, die Sie im vorherigen Schritt abgerufen haben.Für jede Prüfung können Sie nur einen Wert für
NodeSelectorKeyundNodeSelectorValuefestlegen. Wenn Sie Regeln für mehrere Regionen, Zonen oder andere Workerknotenbezeichnungen festlegen möchten, müssen Sie eine neue Prüfung erstellen. Definieren Sie bis zu 15 Prüfungen in einem Konfigurations-Map. Wenn Sie weitere Prüfungen hinzufügen, wird jeweils nur ein Workerknoten erneut geladen, bis alle angeforderten Worker aktualisiert wurden.Beispiel
apiVersion: v1 kind: ConfigMap metadata: name: ibm-cluster-update-configuration namespace: kube-system data: drain_timeout_seconds: "120" zonecheck.json: | { "MaxUnavailablePercentage": 30, "NodeSelectorKey": "failure-domain.beta.kubernetes.io/zone", "NodeSelectorValue": "dal13" } regioncheck.json: | { "MaxUnavailablePercentage": 20, "NodeSelectorKey": "failure-domain.beta.kubernetes.io/region", "NodeSelectorValue": "us-south" } defaultcheck.json: | { "MaxUnavailablePercentage": 20 } <check_name>: | { "MaxUnavailablePercentage": <value_in_percentage>, "NodeSelectorKey": "<node_selector_key>", "NodeSelectorValue": "<node_selector_value>" }drain_timeout_seconds- Optional: Die Zeit in Sekunden, die gewartet werden soll, bis der Drain-Vorgang abgeschlossen ist. Durch das Entleeren eines Workerknotens werden alle vorhandenen Pods sicher vom Workerknoten entfernt und die Pods auf anderen Workerknoten im Cluster neu geplant. Zulässige Werte liegen zwischen 1 und 180. Der Standardwert ist 30.
zonecheck.jsonundregioncheck.json- Zwei Prüfungen, die eine Regel für eine Gruppe von Workerknoten definieren, die mit den angegebenen Merkmalen
NodeSelectorKeyundNodeSelectorValueidentifiziert werden können.zonecheck.jsonidentifiziert Workerknoten anhand ihrer Zonenbezeichnung undregioncheck.jsonverwendet die Bezeichnung der Region, die jedem Workerknoten während der Bereitstellung zugeordnet wird. Im vorliegenden Beispiel dürfen 30 % aller Workerknoten mit der Zonenbezeichnungdal13und 20 % aller Workerknoten inus-southwährend der Aktualisierung nicht verfügbar sein. defaultcheck.json- Wenn Sie keine Konfigurationszuordnung erstellen oder die Zuordnung nicht ordnungsgemäß konfiguriert ist, wird der Standardwert von Kubernetes angewendet. Standardmäßig können nur 20 % der Workerknoten im Cluster zu einem bestimmten
Zeitpunkt nicht verfügbar sein. Sie können den Standardwert überschreiben, indem Sie die Standardprüfung zur Konfigurationszuordnung hinzufügen. Im vorliegenden Beispiel darf jeder Workerknoten, der nicht in den Prüfungen für Zone
und Region (
dal13oderus-south) angegeben ist, während der Aktualisierung nicht verfügbar sein. MaxUnavailablePercentage- Dies ist für einen angegebenen Bezeichnungsschlüssel und -wert die maximale Anzahl nicht verfügbarer Knoten. Der Wert wird als Prozentsatz angegeben. Ein Workerknoten ist während des Bereitstellungs-, Neulade- oder Einrichtungsprozesses nicht verfügbar. Bei Überschreitung eines beliebigen definierten maximalen Prozentsatzes für Nichtverfügbarkeit werden die in der Warteschlange befindlichen Workerknoten blockiert und so von der Aktualisierung ausgeschlossen.
NodeSelectorKey- Dies ist der Bezeichnungsschlüssel des Workerknotens, für den eine Regel festgelegt werden soll. Sie können Regeln sowohl für die von IBM bereitgestellten Standardbezeichnungen als auch für die von Ihnen erstellten Workerknotenbezeichnungen
festlegen. Wenn Sie eine Regel für Workerknoten hinzufügen möchten, die zu einem Workerpool gehören, können Sie die Bezeichnung
ibm-cloud.kubernetes.io/machine-typeverwenden. NodeSelectorValue- Der Bezeichnungswert, den der Workerknoten für die von Ihnen definierte Regel berücksichtigen muss.
-
Erstellen Sie die Konfigurationszuordnung in Ihrem Cluster.
kubectl apply -f <filepath/configmap.yaml> -
Stellen Sie sicher, dass die Konfigurationszuordnung erstellt wurde.
kubectl get configmap --namespace kube-system -
Aktualisieren Sie die Workerknoten.
ibmcloud ks worker update --cluster CLUSTER --worker WORKER-NODE-1-ID --worker WORKER-NODE-2-ID -
Optional: Überprüfen Sie die Ereignisse, die von der Konfigurationszuordnung möglicherweise ausgelöst werden, sowie alle eventuell auftretenden Gültigkeitsfehler. Die Ereignisse können im Abschnitt Events Ihrer CLI-Ausgabe überprüft werden.
kubectl describe -n kube-system cm ibm-cluster-update-configuration -
Vergewissern Sie sich, dass die Aktualisierung abgeschlossen wurde, indem Sie die Kubernetes-Version der Workerknoten überprüfen.
kubectl get nodes -
Stellen Sie sicher, dass keine Workerknoten doppelt vorhanden sind. In manchen Fällen werden für ältere Cluster nach einer Aktualisierung doppelte Workerknoten mit dem Status
NotReadyaufgelistet. Informationen zum Entfernen doppelter Workerknoten finden Sie im Abschnitt zur Fehlerbehebung.
Nächste Schritte
- Wiederholen Sie den Aktualisierungsprozess mit anderen Worker-Pools.
- Informieren Sie die Entwickler, die im Cluster arbeiten, damit diese ihre
kubectl-CLI auf die Version des Kubernetes-Masters aktualisieren können. - Wenn das Kubernetes-Dashboard keine Auslastungsdiagramme anzeigt, löschen Sie den
kube-dashboard.
Klassische Workerknoten in der Konsole aktualisieren
Wenn Sie die Konfigurationszuordnung (Configmap) erstmals eingerichtet haben, können Sie anschließend Workerknoten über die IBM Cloud-Konsole aktualisieren.
Gehen Sie wie folgt vor, um Workerknoten über die Konsole zu aktualisieren:
- Führen Sie die vorausgesetzten Schritte aus und richten Sie eine Konfigurationszuordnung ein, um zu steuern, wie Ihre Workerknoten aktualisiert werden.
- Über das IBM Cloud-Konsolenmenü
, klicken Sie auf Container > Cluster.
- Klicken Sie auf der Seite Cluster auf Ihren Cluster.
- Wählen Sie auf der Registerkarte Workerknoten das Kontrollkästchen für jeden Workerknoten aus, den Sie aktualisieren wollen. Über der Zeile der Tabellenüberschrift wird eine Aktionsleiste angezeigt.
- Klicken Sie in der Aktionsleiste auf Aktualisieren.
Wenn Sie Portworx in Ihrem Cluster installiert haben, müssen Sie die Portworx-Pods auf aktualisierten Workerknoten neu starten. Weitere Informationen finden Sie im Abschnitt zu den Portworx-Einschränkungen.
VPC-Workerknoten aktualisieren
Sie stellen fest, dass für Ihre Worker-Knoten in einem VPC-Cluster ein Update verfügbar ist. Was bedeutet das? Bei der Einrichtung von Sicherheitsupdates und -patches für den API-Server und anderen Komponenten des Masters müssen Sie darauf achten,
dass Ihre Workerknoten synchronisiert bleiben. Sie können zwei Typen von Aktualisierung durchführen: Eine Aktualisierung nur der Patchversion oder eine Aktualisierung der Version (major.minor) mit der Patchversion.
Wenn Portworx in Ihrem Cluster bereitgestellt ist, führen Sie die Schritte unter VPC-Workerknoten mit Portworx-Datenträgern aktualisieren aus.
Es empfiehlt sich, bei jeder Aktualisierung der Arbeitsknoten rotieren Sie Ihre CA-Zertifikate zu verwenden, da der längste Schritt der Zertifikatsrotation das Neuladen oder Ersetzen der Arbeitsknoten beinhaltet.
- Patch: Eine Patchaktualisierung eines Workerknotens umfasst Korrekturen (Fixes) für die Sicherheit. Für Benutzer von VPC-Bare-Metal-Systemen können Sie den neuesten Patch mit dem Befehl „
ibmcloud ks worker reload“ installieren. Für Worker auf virtuellen VPC-Serverinstanzen verwenden Sie den Befehl „ibmcloud ks worker replace“. - Hauptversion.Nebenversion: Eine Aktualisierung der Version (
major.minor) stuft die Kubernetes-Version des Workerknotens auf dieselbe Version wie die des Masters hoch. Diese Art von Aktualisierung geht oft mit Änderungen an der Kubernetes-API oder anderen Verhaltensmustern einher, auf die Sie Ihren Cluster vorbereiten müssen. Beachten Sie, dass Ihre Worker-Knoten höchstens zwei Nebenversionen hinter der Master-Version zurückliegen dürfen (n-2). Sie können den VPC-Worker-Knoten auf denselben Patch aktualisieren, indem Sie den Befehlibmcloud ks worker replacemit der Option--updateverwenden.
- Was passiert mit meinen Apps während eines Updates?
- Wenn Sie Apps als Teil einer Bereitstellung auf Workerknoten ausführen, die Sie aktualisieren, werden die Apps auf anderen Workerknoten im Cluster neu geplant. Diese Workerknoten könnten sich in einem anderen Worker-Pool befinden. Um Ausfallzeiten Ihrer App zu vermeiden, müssen Sie sicherstellen, dass im Cluster genügend Kapazität für die Arbeitslast vorhanden ist, beispielsweise durch eine Anpassung der Größe Ihrer Worker-Pools. Weitere Informationen finden Sie unter Workerknoten zu klassischen Clustern hinzufügen oder Workerknoten zu VPC-Clustern hinzufügen.
- Was passiert mit meinem Worker-Knoten während eines Updates?
- Der VPC-Worker-Knoten wird ersetzt, indem der alte Worker-Knoten entfernt und ein neuer Worker-Knoten bereitgestellt wird, der mit der aktualisierten Version oder der Version
major.minorausgeführt wird. Der Ersatzworkerknoten wird in derselben Zone, in demselben Worker-Pool und mit demselben Typ wie der gelöschte Workerknoten erstellt. Dem Ersatzworkerknoten wird jedoch eine neue private IP-Adresse zugewiesen. Alle angepassten Bezeichnungen oder Taints, die Sie auf den alten Workerknoten angewendet haben, gehen verloren (die Workerpoolbezeichnungen und -Taints werden jedoch auf den Ersatzworkerknoten angewendet). - Was passiert, wenn ich mehrere Worker-Knoten gleichzeitig austausche?
- Wenn Sie mehrere Workerknoten gleichzeitig ersetzen, werden diese gleichzeitig (und nicht nacheinander) gelöscht und ersetzt. Stellen Sie sicher, dass Sie in Ihrem Cluster über ausreichend Kapazität verfügen, um Ihre Workloads neu planen zu können, bevor Sie die Workerknoten ersetzen.
- Was passiert, wenn kein Ersatz-Worker-Knoten erstellt wird?
- Ein Ersatzworkerknoten wird nur dann erstellt, wenn für den Workerpool die Automatische Neuverteilung aktiviert ist.
Voraussetzungen
Lesen Sie die Informationen zu den vorausgesetzten Schritten, bevor Sie Ihre Workerknoten der VPC-Infrastruktur aktualisieren.
Die Aktualisierung von Workerknoten kann zu Ausfallzeiten bei Ihren Apps und Services führen. Ihre Workerknotenmaschine wird entfernt und Daten werden gelöscht, sofern sie nicht außerhalb des Pods gespeichert sind.
- Stellen Sie im Hinblick auf die neuesten Sicherheitspatches und -korrekturen sicher, dass Ihre Workerknoten so bald wie möglich nach Veröffentlichung des neuesten Patches aktualisiert werden. Weitere Informationen zu den neuesten Updates finden Sie unter Kubernetes-Versionsinformationen.
- Melden Sie sich an Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest.
- Aktualisieren Sie den Master. Die Version des Workerknotens darf nicht höher als die Version des API-Servers sein, die in Ihrem Kubernetes-Master ausgeführt wird.
- Nehmen Sie alle Änderungen vor, die im Leitfaden zur Vorbereitung der Kubernetes-Version mit Nach Master aktualisieren gekennzeichnet sind.
- Wenn Sie ein Patch-Update anwenden möchten, lesen Sie die Versionsinformationen zu Kubernetes.
- Stellen Sie sicher, dass Sie über die IAM-Plattformzugriffsrolle Operator oder Administrator verfügen.
VPC-Workerknoten über die Befehlszeilenschnittstelle (CLI) aktualisieren
Führen Sie die folgenden Schritte aus, um Ihre Worker-Knoten mithilfe der CLI zu aktualisieren.
- Führen Sie die vorausgesetzten Schritte aus.
- Optional: Erhöhen Sie die Kapazität Ihres Clusters, indem Sie die Größe des Worker-Pools anpassen. Die Pods auf dem Workerknoten können neu geplant werden und während der Aktualisierung auf den hinzugefügten Workerknoten weiterhin ausgeführt werden. Weitere Informationen finden Sie unter Workerknoten zu klassischen Clustern hinzufügen oder Workerknoten zu VPC-Clustern hinzufügen.
- Listen Sie die Workerknoten in Ihrem Cluster auf und notieren Sie die ID und die Primäre IP-Adresse des Workerknotens, den Sie aktualisieren möchten.
ibmcloud ks worker ls --cluster CLUSTER - Ersetzen Sie den Workerknoten, um entweder die Patchversion oder die Version (
major.minor), die der Masterversion entspricht, zu aktualisieren.- Um den Worker-Knoten auf dieselbe
major.minorVersion wie den Master zu aktualisieren, beispielsweise von 1.34 auf 1.35, fügen Sie die Option--updatehinzu.
ibmcloud ks worker replace --cluster CLUSTER --worker WORKER-NODE-ID --update ``` * Um den Worker-Knoten auf die neueste Patch-Version derselben `major.minor` Version zu aktualisieren, beispielsweise von 1.34.8_1530 auf 1.34.9_1533, lassen Sie die Option `--update` weg. ```sh {: pre} ibmcloud ks worker replace --cluster CLUSTER --worker WORKER-NODE-ID ``` - Um den Worker-Knoten auf dieselbe
- Wiederholen Sie diese Schritte für jeden Workerknoten, der aktualisiert werden soll.
- Optional: Sobald die ersetzten Worker-Knoten den Status Bereit haben, passen Sie die Größe des Worker-Pools an die gewünschte Clusterkapazität an. Weitere Informationen finden Sie unter Workerknoten zu VPC-Clustern hinzufügen.
Wenn Portworx in Ihrem VPC-Cluster ausgeführt wird, müssen Sie Ihren Block Storage for VPC-Datenträger manuell dem neuen Workerknoten zuordnen.
VPC-Workerknoten in der Konsole aktualisieren
Sie können Ihre VPC-Workerknoten in der Konsole aktualisieren. Bevor Sie beginnen, sollten Sie erwägen, dem Cluster Worker-Knoten hinzuzufügen, um Ausfallzeiten Ihrer Anwendungen zu vermeiden.
- Führen Sie die vorausgesetzten Schritte aus.
- Über das IBM Cloud-Konsolenmenü
, klicken Sie auf Container > Cluster.
- Klicken Sie auf der Seite Cluster auf Ihren Cluster.
- Wählen Sie auf der Registerkarte Workerknoten das Kontrollkästchen für jeden Workerknoten aus, den Sie aktualisieren wollen. Über der Zeile der Tabellenüberschrift wird eine Aktionsleiste angezeigt.
- Klicken Sie in der Aktionsleiste auf Aktualisieren.
Typen (Maschinentypen) aktualisieren
Vorbereitende Schritte:
- Melden Sie sich an Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest.
- Die Daten auf dem Workerknoten werden gelöscht. Speichern Sie Ihre Daten im persistenten Speicher außerhalb des Workerknotens.
- Stellen Sie sicher, dass Sie über die IAM-Plattformzugriffsrolle Operator oder Administrator verfügen.
Gehen Sie wie folgt vor, um Typen zu aktualisieren:
-
Listen Sie verfügbare Workerknoten auf und notieren Sie deren private IP-Adressen.
- Listen Sie verfügbare Worker-Pools in Ihrem Cluster auf.
ibmcloud ks worker-pool ls --cluster CLUSTER ``` 2. Listen Sie die Workerknoten im Worker-Pool auf. Notieren Sie sich die **ID** und den Wert für **Private IP**. ```sh {: pre} ibmcloud ks worker ls --cluster CLUSTER --worker-pool WORKER-POOL ``` 3. Rufen Sie die Details für einen Workerknoten ab. Notieren Sie in der Ausgabe die Zone und entweder die private und die öffentliche VLAN-ID für klassische Cluster oder die Teilnetz-ID für VPC-Cluster. ```sh {: pre} ibmcloud ks worker get --cluster CLUSTER --worker WORKER-ID ``` -
Listen Sie die verfügbaren Typen in der Zone auf.
ibmcloud ks flavors --zone <zone> -
Erstellen Sie einen Workerknoten mit dem neuen Maschinentyp.
- Erstellen Sie einen Worker-Pool mit der Anzahl der Workerknoten, die Sie ersetzen möchten.
- Klassische Cluster:
ibmcloud ks worker-pool create classic --name WORKER-POOL --cluster CLUSTER --flavor FLAVOR --size-per-zone NUMBER-OF-WORKERS-PER-ZONE - VPC-Cluster der 2. Generation:
ibmcloud ks worker-pool create vpc-gen2 --name NAME --cluster CLUSTER --flavor FLAVOR --size-per-zone NUMBER-OF-WORKERS-PER-ZONE --label LABEL
- Klassische Cluster:
- Stellen Sie sicher, dass der Worker-Pool erstellt wird.
ibmcloud ks worker-pool ls --cluster CLUSTER ``` 3. Fügen Sie die Zone zu Ihrem Worker-Pool hinzu, die Sie zuvor abgerufen haben. Beim Hinzufügen einer Zone werden die Workerknoten, die im Worker-Pool definiert sind, in der Zone bereitgestellt und für die zukünftige Planung von Workloads berücksichtigt. Wenn Sie die Workerknoten auf mehrere Zonen verteilen möchten, wählen Sie einen [klassischen](/docs/containers?topic=containers-regions-and-zones#zones-mz) oder [VPC](/docs/containers?topic=containers-regions-and-zones#zones-vpc)-Mehrzonenstandort. * Klassische Cluster: ```sh {: pre} ibmcloud ks zone add classic --zone ZONE --cluster CLUSTER --worker-pool WORKER-POOL --private-vlan PRIVATE-VLAN-ID --public-vlan PUBLIC-VLAN-ID ``` * VPC-Cluster: ```sh {: pre} ibmcloud ks zone add vpc-gen2 --zone ZONE --cluster CLUSTER --worker-pool WORKER-POOL --subnet-id VPC-SUBNET-ID ``` - Erstellen Sie einen Worker-Pool mit der Anzahl der Workerknoten, die Sie ersetzen möchten.
-
Warten Sie, bis die Workerknoten bereitgestellt wurden. Wenn der Status des Workerknotens in Normal wechselt, ist die Bereitstellung abgeschlossen.
ibmcloud ks worker ls --cluster CLUSTER -
Entfernen Sie den alten Workerknoten. Hinweis: Wenn Sie einen Typ entfernen, der monatlich abgerechnet wird (zum Beispiel Bare-Metal), dann wird Ihnen der gesamte Monat noch berechnet.
- Entfernen Sie den Worker-Pool mit dem alten Maschinentyp. Durch das Entfernen eines Worker-Pools werden alle Workerknoten im Pool in allen Zonen entfernt. Dieser Prozess kann einige Minuten dauern.
ibmcloud ks worker-pool rm --worker-pool WORKER-POOL --cluster CLUSTER ``` 2. Stellen Sie sicher, dass der Worker-Pool entfernt wird. ```sh {: pre} ibmcloud ks worker-pool ls --cluster CLUSTER ``` -
Stellen Sie sicher, dass die Workerknoten aus Ihrem Cluster entfernt werden.
ibmcloud ks worker ls --cluster CLUSTER -
Wiederholen Sie diese Schritte, um andere Worker-Pools oder eigenständige Workerknoten auf verschiedene Typen zu aktualisieren.
Wie wird für Worker-Pools ein Scale-down durchgeführt?
Wenn die Anzahl der Workerknoten in einem Worker-Pool verringert wird, z. B. während einer Aktualisierung des Workerknotens oder mit dem Befehl ibmcloud ks worker-pool resize,
werden die Workerknoten basierend auf mehreren Eigenschaften, einschließlich Status, Zustand und Version, zum Löschen priorisiert.
Diese Prioritätslogik ist für das Autoscaler-Add-on nicht relevant.
Die folgende Tabelle zeigt die Reihenfolge, in der Workerknoten zum Löschen priorisiert werden.
Sie können den Befehl ibmcloud ks worker ls ausführen, um alle in der Tabelle aufgelisteten Workerknoteneigenschaften anzuzeigen.
| Priorität | Eigenschaft | Beschreibung |
|---|---|---|
| 1 | Status des Workerknotens | Workerknoten mit dem Status 'Nicht funktionsfähig' oder 'Niedrig' werden für das Entfernen priorisiert. Diese Liste zeigt die Status sortiert von der höchsten zur niedrigsten Priorität an: provision_failed, deploy_failed,
deleting, provision_pending, provisioning, deploying, provisioned, reloading_failed, reloading, deployed. |
| 2 | Gesundheit der Arbeiterknoten | Nicht einwandfreie Workerknoten werden vor Workerknoten in einwandfreiem Zustand priorisiert. Diese Liste zeigt die Statuszustände mit der höchsten bis niedrigsten Priorität an: critical, warning, pending,
unsupported, normal. |
| 3 | Workerknotenversion | Workerknoten, die in älteren Versionen ausgeführt werden, haben eine höhere Löschpriorität. |
| 4 | Gewählte Einstellung für die Platzierung | Nur für Worker, die auf einem dedizierten Host ausgeführt werden Workerknoten, die auf einem dedizierten Host ausgeführt werden, für den die Option DesiredPlacementDisabled auf true gesetzt ist,
haben eine höhere Löschpriorität. |
| 5 | alphabetische Reihenfolge | Nachdem Workerknoten anhand der oben aufgeführten Faktoren priorisiert wurden, werden sie in alphabetischer Reihenfolge gelöscht. Beachten Sie, dass IDs für Worker in klassischen und VPC-Clustern basierend auf den Konventionen für Workerknoten-IDs mit dem Alter korrelieren, sodass ältere Workerknoten zuerst entfernt werden. |
Clusterkomponenten aktualisieren
Ihr IBM Cloud Kubernetes Service-Cluster wird mit Komponenten geliefert, wie z. B. Ingress, die automatisch installiert werden, wenn Sie den Cluster bereitstellen. Diese Komponenten werden standardmäßig automatisch von IBM aktualisiert. Sie können jedoch automatische Aktualisierungen für manche Komponenten inaktivieren und sie separat über die Master- und Workerknoten aktualisieren.
- Welche Standardkomponenten kann ich unabhängig vom Cluster aktualisieren?
- Optional können Sie automatische Aktualisierungen für die folgenden Komponenten inaktivieren:
- Gibt es Komponenten, die ich nicht unabhängig vom Cluster aktualisieren kann?
- Ja. Ihr Cluster wird mit den folgenden verwalteten Komponenten und zugehörigen Ressourcen bereitgestellt, die nicht geändert werden können, außer zum Skalieren von Pods oder zum Bearbeiten von Konfigurationszuordnungen, um die Leistung zu steigern. Wenn Sie versuchen, eine dieser Komponenten für die Bereitstellung zu ändern, werden ihre ursprünglichen Einstellungen in einem regelmäßigen Intervall wiederhergestellt, wenn sie mit dem Cluster-Master aktualisiert werden. Beachten Sie jedoch, dass Ressourcen, die Sie erstellen und die zu diesen Komponenten gehören (wie z. B. die Calico-Netzrichtlinien, die Sie für die Implementierung durch die Calico-Bereitstellungskomponenten erstellen), nicht aktualisiert werden.
- Komponenten von
calico - Komponenten von
coredns ibm-cloud-provider-ipibm-file-pluginibm-keepalived-watcheribm-master-proxyibm-storage-watcher- Komponenten von
kubernetes-dashboard metrics-serverolm-operator- undcatalog-Komponenten (1.16 und höher)vpn
- Kann ich andere Plug-ins oder Add-ons als die Standardkomponenten installieren?
- Ja. IBM Cloud Kubernetes Service bietet weitere Plug-ins und Add-ons, aus denen Sie auswählen können, um Ihren Cluster um zusätzliche Funktionen zu erweitern. Beispielsweise können Sie Helm-Diagramme verwenden, um das Block-Speicher-Plugin zu installieren. Oder Sie möchten vielleicht von IBM verwaltete Add-ons in Ihrem Cluster aktivieren. Sie müssen diese Helm-Charts und Add-ons separat aktualisieren, indem Sie die Anweisungen in den Readme-Dateien zu den Helm-Charts befolgen oder die Schritte zum Aktualisieren verwalteter Add-ons ausführen.
Automatische Aktualisierungen für Fluentd verwalten
Wenn Sie eine Protokollierungskonfiguration für eine Quelle in Ihrem Cluster erstellen, die an einen externen Server weitergeleitet werden soll, wird eine Fluentd-Komponente in Ihrem Cluster erstellt. Zum Ändern Ihrer Protokollierungs- oder Filterkonfigurationen muss die Fluentd-Komponente auf dem neuesten Versionsstand sein. Standardmäßig sind automatische Aktualisierungen für die Komponente aktiviert.
Sie können die automatischen Aktualisierungen der Fluentd-Komponente auf folgende Arten verwalten. Hinweis: Um die folgenden Befehle auszuführen, benötigen Sie die IAM-Plattformzugriffsrolle AdministratorIBM Cloud für den Cluster.
- Überprüfen Sie, ob automatische Aktualisierungen aktiviert sind, indem Sie den Befehl
ibmcloud ks logging autoupdate get --cluster CLUSTERausführen. - Deaktivieren Sie automatische Updates, indem Sie den Befehl
ibmcloud ks logging autoupdate disableausführen. - Wenn automatische Aktualisierungen inaktiviert sind, Sie die Konfiguration jedoch ändern müssen, stehen Ihnen zwei Optionen zur Auswahl:
- Aktivieren Sie automatische Aktualisierungen für Ihre Fluentd-Pods.
ibmcloud ks logging autoupdate enable --cluster CLUSTER ``` * Erzwingen Sie eine einmalige Aktualisierung, wenn Sie einen Protokollierungsbefehl verwenden, der die Option `--force-update` enthält. **Hinweis**: Die Pods werden auf die aktuelle Version der Fluentd-Komponente aktualisiert, Fluentd wird jedoch zukünftig nicht automatisch aktualisiert. Beispielbefehl ```sh {: pre} ibmcloud ks logging config update --cluster CLUSTER --id LOG-CONFIG-ID --type LOG-TYPE --force-update ```
Automatische Aktualisierungen für Ingress-ALBs verwalten
Steuern Sie, wann die Komponente für die Lastausgleichsfunktion für Ingress-Anwendungen (ALB) aktualisiert wird. Informationen zur Sicherstellung der Aktualität von ALBs finden Sie im Abschnitt Ingress-ALB-Lebenszyklus verwalten.
Verwaltete Add-ons aktualisieren
Die Add-ons für Managed- IBM Cloud Kubernetes Service-Cluster bieten eine einfache Möglichkeit, Ihren Cluster um Open-Source-Funktionen wie Istio zu erweitern. Die Version des Open-Source-Tools, das Sie zu Ihrem Cluster hinzufügen, wurde von IBM getestet und für die Verwendung in IBM Cloud Kubernetes Service genehmigt. Informationen zur Vorgehensweise beim Aktualisieren von verwalteten Add-ons, die Sie in Ihrem Cluster aktiviert haben, auf die neuesten Versionen finden Sie unter Verwaltete Add-ons aktualisieren.