Mit der IBM Cloud-CLI prüfen, ob eine Versionsaktualisierung verfügbar ist

1. Melden Sie sich bei IBM Cloud an. Fügen Sie die Option --sso hinzu, wenn Sie ein eingebundenes Konto haben.

   ibmcloud login [--sso]
   

2. Listen Sie die Satellite-Cluster in Ihrem Konto auf.

   ibmcloud ks cluster ls --provider satellite
   

3. Listen Sie die Workerknoten im Cluster auf, für die Sie die Version aktualisieren möchten. Suchen Sie in der Ausgabe nach einem * mit einer Meldung, die anzeigt, dass eine Versionsaktualisierung verfügbar ist.

   ibmcloud ks worker ls -c CLUSTER_NAME_OR_ID
   

   Beispielausgabe

   ID                Primary IP       Flavor   State    Status   Zone     Version   
   sat-worker-<ID>   <IP_address>     upi      normal   Ready    zone-1   4.5.35_1534_openshift*   
   * To update to 4.5.37_1537_openshift version, run 'ibmcloud ks worker replace'. Review and make any required version changes before you update: 'https://ibm.biz/upworker'
   

Mit der IBM Cloud-Konsole prüfen, ob eine Versionsaktualisierung verfügbar ist

1. Melden Sie sich an der Satellite-Konsolean.
2. Klicken Sie auf die Position mit den Hosts, die Sie aktualisieren möchten.
3. Klicken Sie auf die Registerkarte für Hosts.
4. Klicken Sie in der Hostliste auf den Link zum Cluster des Hosts, den Sie aktualisieren möchten. Für die Red Hat OpenShift on IBM Cloud Clusterdetails wird ein neues Tab geöffnet.
5. Klicken Sie auf das Tab Workerknoten .
6. Achten Sie in der Spalte Version auf ein Informationssymbol, das anzeigt, wenn Update available Sie auf das Symbol klicken. Wenn keine Aktualisierung verfügbar ist, ist kein Symbol vorhanden.
7. Ermitteln Sie, ob es sich bei der Versionsaktualisierung um die Aktualisierung einer Haupt-, Neben- oder Patchversion handelt.

Versionsaktualisierungen nacheinander auf Workerknotenhosts anwenden

1. Optional: Ordnen Sie dem Service-Cluster und assign zusätzliche Hosts zu, um die Rechenkapazität zu verarbeiten, während Ihre vorhandenen Hosts aktualisiert werden.

2. Ermitteln Sie Ihre Workerknotenhosts. Auf den Workerknotenhosts ist infrastructure nicht in der Spalte Cluster der Ausgabe aufgelistet, sondern der Name des Clusters.

3. Aktualisieren Sie Ihre Workerknoten einzeln, indem Sie den Befehl ibmcloud ks worker update ausführen.

   ibmcloud ks worker update -c CLUSTER_NAME_OR_ID --worker WORKER_ID
   

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

   kubectl get nodes
   

   Wenn die Aktualisierung fehlgeschlagen ist, müssen Sie Versionsaktualisierungen anwenden, indem Sie Hosts ersetzen.

Wenden Sie Versionsaktualisierungen auf Ihre Workerknotenhosts mit einer ConfigMap an

Sie können Aktualisierungen für alle Workerknotenhosts mit einer ConfigMaptemporär auslagern. Geben Sie mithilfe von Bezeichnungen an, welche Knoten aktualisiert werden sollen. Sie können auch Folgendes angeben:

1. Optional: Ordnen Sie dem Service-Cluster und assign zusätzliche Hosts zu, um die Rechenkapazität zu verarbeiten, während Ihre vorhandenen Hosts aktualisiert werden.

2. Ermitteln Sie Ihre Workerknotenhosts. Ihre Workerknotenhosts werden nicht als Infrastructure aufgelistet.

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). Sie können die Bezeichnungen verwenden, um anzugeben, welche Workerknoten aktualisiert werden sollen.

   kubectl get nodes -o yaml
   

   Beispielausgabe

   labels:
     arch: amd64
     beta.kubernetes.io/arch: amd64
     beta.kubernetes.io/instance-type: upi
     beta.kubernetes.io/os: linux
     failure-domain.beta.kubernetes.io/region: us-east
     failure-domain.beta.kubernetes.io/zone: us-east-2
     ibm-cloud.kubernetes.io/iaas-provider: upi
     ibm-cloud.kubernetes.io/internal-ip: 10.241.0.4
     ibm-cloud.kubernetes.io/machine-type: upi
     ibm-cloud.kubernetes.io/os: REDHAT_8_64
     ibm-cloud.kubernetes.io/region: us-east
     ibm-cloud.kubernetes.io/worker-id: sat-satellitei-5bd83963cdfedc7668c9040879c88113a134c4e7
     ibm-cloud.kubernetes.io/worker-pool-id: cbtljodw089nltg8k210-9a3f763
     ibm-cloud.kubernetes.io/worker-pool-name: default
     ibm-cloud.kubernetes.io/worker-version: 4.7.59_1583_openshift
     ibm-cloud.kubernetes.io/zone: us-east-2
     kubernetes.io/arch: amd64
     kubernetes.io/hostname: satellite-ibm-host-3
     kubernetes.io/os: linux
     node-role.kubernetes.io/master: ""
     node-role.kubernetes.io/worker: ""
     node.kubernetes.io/instance-type: upi
     node.openshift.io/os_id: rhel
     privateVLAN: "1"
     topology.kubernetes.io/region: us-east
     topology.kubernetes.io/zone: us-east-2
   

4. Erstellen Sie eine ConfigMap und legen Sie die Regeln für die Nichtverfügbarkeit Ihrer Worker-Knoten fest. Das folgende Beispiel zeigt zwei Schecks, den defaultcheck.json und eine Scheckvorlage. Mit dieser Beispielprüfung können Sie Regeln für alle Workerknoten definieren, die keiner der Prüfungen entsprechen, die Sie in der ConfigMap (defaultcheck.json) definiert haben. Verwenden Sie die Prüfschablone, um Ihre eigene Prüfung zu 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 NodeSelectorKey und NodeSelectorValue festlegen. Definieren Sie bis zu 10 Prüfungen in einem ConfigMap. Wenn Sie weitere Prüfungen hinzufügen, werden sie ignoriert.

   Beispiel

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: ibm-cluster-update-configuration
     namespace: kube-system
   data:
     drain_timeout_seconds: "120"
     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.

   defaultcheck.json

   Wenn Sie Workerknoten in Satellite-Hosts aktualisieren, sind möglicherweise nur 20 Prozent der Workerknoten im Cluster nicht verfügbar.

   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.

   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 ConfigMap erstellt wurde.

   kubectl get configmap --namespace kube-system
   

7. Aktualisieren Sie die Workerknoten, indem Sie sie nach ID auflisten.

   ibmcloud ks worker update --cluster <cluster_name_or_ID> --worker <worker_node1_ID> --worker <worker_node2_ID>
   

8. Optional: Überprüfen Sie die von der ConfigMap ausgelösten Ereignisse sowie eventuell auftretende Validierungsfehler. 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
   

   Wenn die Aktualisierung fehlgeschlagen ist, müssen Sie Versionsaktualisierungen anwenden, indem Sie Hosts ersetzen.

10. 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 NotReady aufgelistet. Informationen zum Entfernen doppelter Workerknoten finden Sie im Abschnitt zur Fehlerbehebung.