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

Gehen Sie wie folgt vor, um die Haupt- oder _Neben_version des Kubernetes-Masters zu aktualisieren:

1. Überprüfen Sie die Kubernetes-Versionsinformationen und nehmen Sie alle mit Update before master gekennzeichneten Aktualisierungen vor.

2. Überprüfen Sie alle hilfreichen Warnungen zu Kubernetes, wie z. B. Hinweise auf veraltete Funktionen.

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 ks cluster addon ls --cluster CLUSTER
        

     2. Überprüfen Sie die installierte Kubernetes-Version für jedes installierte Add-on.

        ibmcloud ks addon-versions
        

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

   • 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, 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.

4. Aktualisieren Sie Ihren API-Server und die zugehörigen Master-Komponenten mithilfe der IBM Cloud-Konsole oder durch Ausführen des CLI -Befehlsibmcloud ks 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 ks cluster ls aus.

6. Installieren Sie die Version der kubectl cli, die mit dem API-Server Ihres Masters übereinstimmt. Kubernetes unterstützt keine kubectl 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 ks cluster config -c CLUSTER_NAME_OR_ID und überprüfen Sie anschließend mit kubectl version --client.

Sobald die Aktualisierung des Master-Knotens abgeschlossen ist, aktualisieren Sie Ihre Worker-Knoten. Die Vorgehensweise hängt von Ihrem Infrastrukturtyp 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-VSI-Worker und VPC-Bare-Metal-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 eine 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 von 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 ks 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).

   kubectl 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 Überprü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 Regionalprüfung (regioncheck.json), eine Standard-Fallback-Prüfung (defaultcheck.json) sowie eine Vorlage für benutzerdefinierte Prüfungen. Wählen Sie bei jedem Schritt 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.

   kubectl apply -f <filepath/configmap.yaml>
   

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

   kubectl get configmap --namespace kube-system
   

7. Aktualisieren Sie die Workerknoten.

   ibmcloud ks 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.

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

   kubectl get nodes
   

10. Stellen Sie sicher, dass keine Workerknoten doppelt vorhanden sind. Manchmal werden in älteren Clustern nach einer Aktualisierung 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 beachtet die Nichtverfügbarkeitsregeln, die Sie in der ConfigMap definiert haben.

1. Führen Sie die erforderlichen Schritte durch und richten Sie eine 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 zur Aktualisierung der VPC-Worker-Knoten mit Portworx-Volumes anstelle der Schritte auf dieser Seite.

Firmware-Updates während des Neustarts von VPC-Bare-Metal-Workern

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 – gegenüber der üblichen Neuladezeit verlängern. Planen Sie Ihre Wartungsfenster entsprechend.

Keine Vorab-Einblicke 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 die Daten auf den 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 dauerhaften Speichermedium 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 ks 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

• Melden Sie sich an Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest.
• Stellen Sie sicher, dass alle Daten, die Sie aufbewahren müssen, auf einem dauerhaften 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 Flavors

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 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
       ```
   

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

   ibmcloud ks 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 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
        

   2. 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
           ```
   

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

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-Worker, 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 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
       ```
   

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

   ibmcloud ks 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 Administrator IBM 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 ks logging autoupdate get --cluster CLUSTER ausführen.
• Deaktivieren Sie automatische Updates, indem Sie den Befehlibmcloud ks 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 ks 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 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.