Cluster, Workerknoten und Clusterkomponenten aktualisieren

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ächsthöhere Version aktualisieren (n+1).

Können meine Worker-Knoten eine neuere Version als der Master ausführen?

Auf Ihren Workerknoten kann keine höhere major.minor Kubernetes-Version als auf dem Master ausgeführt werden. Darüber hinaus können Ihre Workerknoten nur eine Version hinter der Masterversion (n-1) liegen. Zuerst aktualisieren Sie Ihren Master auf die neueste Kubernetes-Version. 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 Red Hat OpenShift on IBM Cloud auf mögliche Auswirkungen überprüfen und den Befehl „ ibmcloud oc cluster master update “ selbst sicher ausführen, ohne abzuwarten, bis die automatische Aktualisierung wirksam wird.

Im Gegensatz zum Master müssen Sie die Worker für jede Patchversion aktualisieren.

Was passiert während des Master-Updates?

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.

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. Sie können den klassischen Workerknoten mit dem Befehl ibmcloud oc worker reload oder update aktualisieren. Beachten Sie, dass mit dem Befehl update der 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. Denken Sie daran, dass Ihre Workerknoten nur eine Version hinter der Masterversion (n-1) liegen dürfen. Sie können den klassischen Workerknoten mit dem Befehl ibmcloud oc worker update auf dasselbe 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 jeweils außer Betrieb gehen?

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 Konfigurationsmap „ Kubernetes “ erstellen, in der die maximale Anzahl von Worker-Knoten festgelegt wird, 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 Kubernetes Config-Map-Regeln 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 Konfigurationszuordnung 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.

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.

Wenn Sie OpenShift-Datenbasis in Ihrem Cluster bereitgestellt haben, befolgen Sie die Schritte unter VPC-Workerknoten mit OpenShift-Datenbasis aktualisieren.

• 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 oc worker reload “ installieren. Für Worker auf virtuellen VPC-Serverinstanzen verwenden Sie den Befehl „ ibmcloud oc 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 eine Version hinter der Master-Version zurückliegen dürfen (n-1). Sie können den VPC-Worker-Knoten auf denselben Patch aktualisieren, indem Sie den Befehl „ ibmcloud oc worker replace “ mit der Option „ --update “ verwenden.

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 zur Bewältigung der 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.minor ausgefü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.

Typen (Maschinentypen) aktualisieren

Vorbereitende Schritte:

• Rufen Sie Ihren Red Hat OpenShift-Cluster auf.
• 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:

1. Listen Sie verfügbare Workerknoten auf und notieren Sie deren private IP-Adressen.

   1. Listen Sie verfügbare Worker-Pools in Ihrem Cluster auf.

       ibmcloud oc 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 oc 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 oc worker get --cluster CLUSTER --worker WORKER-ID
       ```
   

2. Listen Sie die verfügbaren Typen in der Zone auf.

   ibmcloud oc flavors --zone <zone>
   

3. Erstellen Sie einen Workerknoten mit dem neuen Maschinentyp.

   1. Erstellen Sie einen Worker-Pool mit der Anzahl der Workerknoten, die Sie ersetzen möchten.
      • Klassische Cluster:

        ibmcloud oc 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 oc worker-pool create vpc-gen2 --name NAME --cluster CLUSTER --flavor FLAVOR --size-per-zone NUMBER-OF-WORKERS-PER-ZONE --label LABEL
        

   2. Stellen Sie sicher, dass der Worker-Pool erstellt wird.

       ibmcloud oc 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 Mehrzonenstandort](/docs/openshift?topic=openshift-regions-and-zones#zones-mz) oder [VPC](/docs/openshift?topic=openshift-regions-and-zones#zones-vpc)-Mehrzonenstandort aus.
       * Klassische Cluster:
           ```sh {: pre}
           ibmcloud oc 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 oc zone add vpc-gen2 --zone ZONE --cluster CLUSTER --worker-pool WORKER-POOL --subnet-id VPC-SUBNET-ID
           ```
   

4. Warten Sie, bis die Workerknoten bereitgestellt wurden. Wenn der Status des Workerknotens in Normal wechselt, ist die Bereitstellung abgeschlossen.

   ibmcloud oc worker ls --cluster CLUSTER
   

5. 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.

   1. 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 oc worker-pool rm --worker-pool WORKER-POOL --cluster CLUSTER
       ```
   2. Stellen Sie sicher, dass der Worker-Pool entfernt wird.
   ```sh {: pre}
       ibmcloud oc worker-pool ls --cluster CLUSTER
       ```
   

6. Stellen Sie sicher, dass die Workerknoten aus Ihrem Cluster entfernt werden.

   ibmcloud oc worker ls --cluster CLUSTER
   

7. 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 oc 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 oc worker ls ausführen, um alle in der Tabelle aufgelisteten Workerknoteneigenschaften anzuzeigen.

Clusterkomponenten aktualisieren

Ihr Red Hat OpenShift on IBM Cloud-Cluster wird mit Komponenten geliefert (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:

• Fluentd für Protokollierung
• Lastausgleichsfunktion für Ingress-Anwendungen (ALB)

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-ip
• ibm-file-plugin
• ibm-keepalived-watcher
• ibm-master-proxy
• ibm-storage-watcher
• Komponenten von kubernetes-dashboard
• metrics-server
• olm-operator- und catalog-Komponenten (1.16 und höher)
• vpn

Kann ich andere Plug-ins oder Add-ons als die Standardkomponenten installieren?

Ja. Unter Red Hat OpenShift on IBM Cloud finden Sie weitere Plug-ins und Add-ons, aus denen Sie auswählen können, um Ihren Cluster um zusätzliche Funktionen zu erweitern. Beispielsweise möchten Sie möglicherweise in Ihrem Cluster die von IBM verwalteten Add-ons aktivieren. Sie müssen diese Add-ons separat aktualisieren, indem Sie die Schritte zur Aktualisierung verwalteter Add-ons ausführen.

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 zu erweitern, wie beispielsweise Istio. 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.