Schritte zum Aktualisieren des Cluster-Masters

Bevor Sie beginnen, stellen Sie sicher, dass Sie über die IAM-Plattformzugriffsrolle Operator oder Administrator verfügen. Wenn Sie sich bezüglich Ihrer Zugriffsrolle unsicher sind, gehen Sie in der IBM Cloud-Konsole zu Verwalten → Zugriff (IAM) → Benutzer oder wenden Sie sich an Ihren Kontoadministrator.

Wenn gerade eine Zertifikatsrotation einer Zertifizierungsstelle (CA) stattfindet, wird das Master-Update blockiert, bis die Rotation abgeschlossen ist. Überprüfen Sie den Status einer eventuell laufenden Rotation, bevor Sie beginnen.

So aktualisieren Sie die übergeordnete oder untergeordnete Red Hat OpenShift-Master-Version:

1. Überprüfen Sie die Red Hat OpenShift on IBM Cloud-Versionsinformationen und nehmen Sie alle Aktualisierungen vor, die mit _Vor Master aktualisieren_markiert sind.

2. Überprüfen Sie alle hilfreichen Hinweise auf Kubernetes, wie z. B. Verwendungshinweise.

3. Ü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

     1. Listen Sie die Add-ons im Cluster auf.

        ibmcloud oc cluster addon ls --cluster CLUSTER
        

     2. Überprüfen Sie die unterstützte Red Hat OpenShift-Version für jedes installierte Add-on.

        ibmcloud oc addon-versions
        

     3. Wenn das Add-on aktualisiert werden muss, damit es in der Red Hat OpenShift-Version ausgeführt werden kann, auf die der Cluster aktualisiert werden soll, aktualisieren Sie das Add-on.

   • Plug-ins überprüfen

     1. Suchen Sie im Helm-Katalog nach den Plug-ins, die Sie in Ihrem Cluster installiert haben.
     2. Erweitern Sie im seitlichen Menü den Abschnitt QUELLEN & TAR-DATEI.
     3. Laden Sie den Quellcode herunter und öffnen Sie ihn.
     4. Überprüfen Sie die Dateien README.md oder RELEASENOTES.md auf unterstützte Versionen.
     5. Wenn das Plug-in aktualisiert werden muss, damit es in der Red Hat OpenShift-Version ausgeführt werden kann, auf die Ihr Cluster aktualisiert werden soll, aktualisieren Sie das Plug-in, indem Sie die entsprechenden Anweisungen befolgen.

4. Aktualisieren Sie Ihren API-Server und die zugehörigen Master-Komponenten mithilfe der IBM Cloud-Konsole oder durch Ausführen des CLI -Befehlsibmcloud oc cluster master update.

5. 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 oc cluster ls aus.

6. Installieren Sie die Version der oc cli, die mit der Version des API-Servers übereinstimmt, die auf dem Master ausgeführt wird. Kubernetes Unterstützt keine oc Client-Versionen, die zwei oder mehr Versionen von der Server-Version abweichen (n ± 2). Um Ihre lokale Konfiguration zu aktualisieren, führen Sie aus ibmcloud oc cluster config -c CLUSTER_NAME_OR_ID und überprüfen Sie anschließend mit oc version --client.

Sobald die Aktualisierung des Master-Knotens abgeschlossen ist, aktualisieren Sie Ihre Worker-Knoten. Die Vorgehensweise hängt von Ihrer Infrastrukturart ab:

1. Aktualisierung klassischer Worker-Knoten – erfolgt über ein rollierendes Update, das über eine ConfigMap und den worker update Befehl gesteuert wird.
2. Aktualisierung von VPC-Worker-Knoten — VPC-Bare-Metal-Worker werden vor Ort mit aktualisiert worker reload; VPC-VSI-Worker müssen verwenden worker replace --update. Das Verfahren für rollierende Updates von ConfigMap wird für VPC-Worker-Knoten noch nicht unterstützt.

Voraussetzungen

Bevor Sie Ihre Worker-Knoten der klassischen Infrastruktur aktualisieren, führen Sie die folgenden vorbereitenden Schritte durch.

Während einer Aktualisierung des Worker-Knotens wird der Rechner des Worker-Knotens neu aufgesetzt, und alle Daten, die nicht auf einem persistenten Speicher gespeichert sind, werden dauerhaft gelöscht. Stellen Sie sicher, dass alle Daten, die Sie aufbewahren müssen, außerhalb des Worker-Knotens gespeichert sind, bevor Sie beginnen.

Wenn Sie Portworx in Ihrem Cluster installiert haben, müssen Sie Ihre Portworx-Konfiguration aktualisieren, bevor Sie die Worker-Knoten aktualisieren.

Klassische Workerknoten über die Befehlszeilenschnittstelle (CLI) mit einer Konfigurationszuordnung aktualisieren

Verwenden Sie einen ConfigMap, um ein rollierendes Update Ihrer klassischen Worker-Knoten durchzuführen. Mit dem ConfigMap können Sie festlegen, wie viele Knoten pro Zone oder Region gleichzeitig nicht verfügbar sein dürfen. Wenn die standardmäßige 20-Prozent-Ausfallregel für Ihren Cluster akzeptabel ist, können Sie die Schritte 3 und 4 (Erstellung des ConfigMap ) überspringen und direkt mit Schritt 5 fortfahren, um das Update mit dem Standardverhalten anzuwenden.

1. Führen Sie die vorausgesetzten Schritte aus.

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

   ibmcloud oc worker ls --cluster CLUSTER
   

3. 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).

   oc describe node PRIVATE-WORKER-IP
   

   Beispielausgabe

   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
   

4. Erstellen Sie eine Konfigurationszuordnung und definieren Sie die Nichtverfügbarkeitsregeln für Ihre Workerknoten. Der ConfigMap unterstützt bis zu 15 benannte Prüfungen. Jede Überprüfung zielt auf eine Gruppe von Worker-Knoten anhand ihrer Kennzeichnung ab und legt den maximalen Prozentsatz dieser Knoten fest, die gleichzeitig nicht verfügbar sein dürfen. Das folgende Beispiel zeigt eine Zonenprüfung (zonecheck.json), eine Regionsprüfung (regioncheck.json), eine Standard-Fallback-Prüfung (defaultcheck.json) sowie eine Vorlage für benutzerdefinierte Prüfungen. Wählen Sie bei jedem Check eine der Worker-Node-Bezeichnungen aus, die Sie im vorherigen Schritt abgerufen haben, um die Zielknoten zu identifizieren.

   Für jede Prüfung können Sie nur einen Wert für NodeSelectorKey und NodeSelectorValue festlegen. 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 einer Konfigurationskarte. 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überschreitung in Sekunden, die abgewartet wird, 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.json und regioncheck.json

   Zwei Prüfungen, die eine Regel für eine Gruppe von Workerknoten definieren, die mit den angegebenen Merkmalen NodeSelectorKey und NodeSelectorValue identifiziert werden können. zonecheck.json identifiziert Workerknoten anhand ihrer Zonenbezeichnung und regioncheck.json verwendet die Bezeichnung der Region, die jedem Workerknoten während der Bereitstellung zugeordnet wird. Im vorliegenden Beispiel dürfen 30 % aller Workerknoten mit der Zonenbezeichnung dal13 und 20 % aller Workerknoten in us-south wä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 (dal13 oder us-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-type verwenden.

   NodeSelectorValue

   Der Bezeichnungswert, den der Workerknoten für die von Ihnen definierte Regel berücksichtigen muss.

5. Erstellen Sie die Konfigurationszuordnung in Ihrem Cluster.

   oc apply -f <filepath/configmap.yaml>
   

6. Stellen Sie sicher, dass die Konfigurationszuordnung erstellt wurde.

   oc get configmap --namespace kube-system
   

7. Aktualisieren Sie die Workerknoten.

   ibmcloud oc worker update --cluster CLUSTER --worker WORKER-NODE-1-ID --worker WORKER-NODE-2-ID
   

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

   oc describe -n kube-system cm ibm-cluster-update-configuration
   

9. Vergewissern Sie sich, dass die Aktualisierung abgeschlossen wurde, indem Sie die Kubernetes-Version der Workerknoten überprüfen.

   oc get nodes
   

10. Stellen Sie sicher, dass keine Workerknoten doppelt vorhanden sind. Manchmal werden in älteren Clustern nach einem Update doppelte Worker-Knoten mit einem Status NotReady aufgeführt. Informationen zum Entfernen doppelter Workerknoten finden Sie im Abschnitt zur Fehlerbehebung.

Klassische Workerknoten in der Konsole aktualisieren

Nachdem Sie die ConfigMap zum ersten Mal eingerichtet haben, können Sie die Worker-Knoten über die IBM Cloud-Konsole aktualisieren. Die Konsole hält sich an die Nichtverfügbarkeitsregeln, die Sie im ConfigMap definiert haben.

1. Führen Sie die erforderlichen Schritte durch und richten Sie ein ConfigMap ein, um zu steuern, wie Ihre Worker-Knoten aktualisiert werden.
2. Über das IBM Cloud-Konsolenmenü , klicken Sie auf Container > Cluster.
3. Klicken Sie auf der Seite Cluster auf Ihren Cluster.
4. 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.
5. Klicken Sie in der Aktionsleiste auf Aktualisieren.

Wenn Sie Portworx in Ihrem Cluster installiert haben, müssen Sie die Portworx-Pods auf den aktualisierten Worker-Knoten neu starten. Weitere Informationen finden Sie im Abschnitt zu den Portworx-Einschränkungen.

Voraussetzungen

Bevor Sie die Worker-Knoten Ihrer VPC-Infrastruktur aktualisieren, führen Sie die folgenden vorbereitenden Schritte durch.

Bei VPC-VSI-Workern wird der Worker-Knoten gelöscht und durch einen neuen Knoten ersetzt. Bei VPC-Bare-Metal-Workern wird der Knoten an Ort und Stelle neu geladen. In beiden Fällen werden Daten, die nicht auf einem persistenten Speicher gespeichert sind, dauerhaft gelöscht. Stellen Sie sicher, dass alle Daten, die Sie aufbewahren müssen, außerhalb des Worker-Knotens gespeichert sind, bevor Sie beginnen.

Wenn Sie Portworx in Ihrem Cluster bereitgestellt haben, befolgen Sie die Schritte zum Aktualisieren der VPC-Worker-Knoten mit Portworx-Volumes anstelle der Schritte auf dieser Seite.

Firmware-Updates während des Neustarts eines VPC-Bare-Metal-Workers

Wenn Sie einen VPC-Bare-Metal-Worker-Knoten neu starten, prüft die IBM Cloud-Infrastruktur automatisch, ob für diesen Server ein Firmware-Update ansteht, und führt dieses im Rahmen des Neustartvorgangs durch. Es sind keine weiteren Maßnahmen erforderlich, um das Firmware-Update auszulösen.

Beachten Sie die folgenden Punkte, wenn Sie einen VPC-Bare-Metal-Worker-Knoten neu laden:

Verlängerte Ladezeit

Wenn während des Neuladens ein Firmware-Update durchgeführt wird, kann sich die Gesamtdauer des Neuladens erheblich – um 30 Minuten oder mehr – über die übliche Neuladedauer hinaus verlängern. Planen Sie Ihre Wartungsfenster entsprechend.

Keine Vorab-Einblick in anstehende Aktualisierungen

Es ist nicht ersichtlich, ob für einen Worker-Knoten ein Firmware-Update ansteht, bevor Sie den Befehl reload ausführen.

Risiko eines Datenverlusts

Wie bei allen VPC-Bare-Metal-Worker-Neuinstallationen werden Daten auf lokalen Festplatten während der Neuinstallation gelöscht, unabhängig davon, ob ein Firmware-Update durchgeführt wird. Sichern Sie alle Daten, die nicht auf einem persistenten Speicher gespeichert sind, bevor Sie den Ladevorgang erneut starten.

Fehler beim Neuladen aufgrund eines Firmware-Updates

In einigen Fällen kann ein Firmware-Update fehlschlagen, was dazu führt, dass der Worker-Knoten in einen Zustand reload_failed (Failed to reload worker) mit dem Statusdetail wechselt The infrastructure firmware update has failed. (P4056). Falls Folgendes auftritt:

1. Warten Sie einige Minuten und versuchen Sie dann erneut, die Seite neu zu laden, indem Sie den Befehl erneut ibmcloud oc worker reload --cluster CLUSTER --worker WORKER-NODE-ID ausführen.
2. Sollte der Fehler nach 2–3 Versuchen weiterhin bestehen, eröffnen Sie bitte einen Support-Fall unter IBM Cloud.

Vorbereitende Schritte

• Rufen Sie Ihren Red Hat OpenShift-Cluster auf.
• Stellen Sie sicher, dass alle Daten, die Sie aufbewahren müssen, auf einem persistenten Speicher außerhalb des Worker-Knotens gespeichert sind. Daten, die ausschließlich auf dem Worker-Knoten gespeichert sind, gehen verloren und können nicht wiederhergestellt werden.
• Stellen Sie sicher, dass Sie über die IAM-Plattformzugriffsrolle Operator oder Administrator verfügen. Wenn Sie sich bezüglich Ihrer Zugriffsrolle unsicher sind, gehen Sie in der IBM Cloud-Konsole zu Verwalten → Zugriff (IAM) → Benutzer oder wenden Sie sich an Ihren Kontoadministrator.

So aktualisieren Sie Varianten

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 Worker-Pool. Wenn Sie eine Classic-Bare-Metal-Variante (die monatlich abgerechnet wird) entfernen, wird Ihnen der gesamte Monat in Rechnung gestellt, auch wenn Sie sie mitten im Monat entfernen. VPC-Worker, einschließlich Bare-Metal-Instanzen, werden stundenweise abgerechnet.

   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.

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.

Um die folgenden Befehle auszuführen, benötigen Sie die IAM-Plattformzugriffsrolle AdministratorIBM Cloud für den Cluster.

Sie können die automatischen Aktualisierungen der Fluentd-Komponente auf folgende Arten verwalten.

• Überprüfen Sie, ob automatische Aktualisierungen aktiviert sind, indem Sie den Befehl ibmcloud oc logging autoupdate get --cluster CLUSTER ausführen.
• Deaktivieren Sie automatische Updates, indem Sie den Befehlibmcloud oc logging autoupdate disable ausfü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 oc logging autoupdate enable --cluster CLUSTER
      ```
  * Erzwingen Sie eine einmalige Aktualisierung, wenn Sie einen Protokollierungsbefehl verwenden, der die Option `--force-update` enthält. Ihre Pods werden auf die neueste Version der Fluentd-Komponente aktualisiert, Fluentd wird jedoch künftig nicht mehr automatisch aktualisiert.
          Beispielbefehl
  
  ```sh {: pre}
      ibmcloud oc 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.