Verifica se è disponibile un aggiornamento della versione con la CLI IBM Cloud

1. Accedi a IBM Cloud. Se disponi di un account federato, seleziona l'opzione " --sso ".

   ibmcloud login [--sso]
   

2. Elenca i cluster Satellite nel tuo account.

   ibmcloud ks cluster ls --provider satellite
   

3. Elenca i nodi di lavoro nel cluster per cui vuoi aggiornare la versione. Nell'output, ricercare un asterisco * con un messaggio che indica che è disponibile un aggiornamento della versione.

   ibmcloud ks worker ls -c CLUSTER_NAME_OR_ID
   

   Output di esempio

   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'
   

Verifica se un aggiornamento della versione è disponibile dalla console IBM Cloud

1. Accedi alla consoleSatellite.
2. Fare clic sull'ubicazione con gli host che si desidera aggiornare.
3. Fai clic sulla scheda Hosts.
4. Dall'elenco di host, fare clic sul collegamento al Cluster per l'host che si desidera aggiornare. Viene visualizzata una nuova scheda per i dettagli del cluster Red Hat OpenShift on IBM Cloud.
5. Fai clic sulla scheda " Nodi di lavoro ".
6. Nella colonna Versione, verificare la presenza di un'icona informativa che indichi Update available quando si fa clic sull'icona. Se non è disponibile alcun aggiornamento, non è presente alcuna icona.
7. Determinare se l'aggiornamento della versione è un aggiornamento principale, secondario o patch.

Applicare gli aggiornamenti della versione agli host del nodo di lavoro uno alla volta

1. Facoltativo: Collega e assegna gli host aggiuntivi al cluster di servizi per gestire la capacità di elaborazione mentre i tuoi host esistenti sono in fase di aggiornamento.

2. Identifica i tuoi host del nodo di lavoro. Gli host dei nodi di lavoro non hanno infrastructure elencati nella colonna Cluster dell'output, ma hanno invece il nome del cluster.

3. Aggiorna i tuoi nodi di lavoro singolarmente eseguendo il comando ibmcloud ks worker update.

   ibmcloud ks worker update -c CLUSTER_NAME_OR_ID --worker WORKER_ID
   

4. Conferma che l'aggiornamento è stato completato controllando la versione Kubernetes dei tuoi nodi di lavoro.

   kubectl get nodes
   

   Se l'aggiornamento non è riuscito, è necessario applicare gli aggiornamenti della versione sostituendo gli host.

Applicare gli aggiornamenti della versione agli host del nodo di lavoro con una ConfigMap

Puoi eseguire il rollout degli aggiornamenti a tutti gli host del nodo di lavoro con una ConfigMap. Specificare quali nodi aggiornare utilizzando le etichette. È anche possibile specificare

1. Facoltativo: Collega e assegna gli host aggiuntivi al cluster di servizi per gestire la capacità di elaborazione mentre i tuoi host esistenti sono in fase di aggiornamento.

2. Identifica i tuoi host del nodo di lavoro. I tuoi host del nodo di lavoro non sono elencati come Infrastructure.

3. Visualizza le etichette di un nodo di lavoro. Puoi trovare le etichette del nodo di lavoro nella sezione Labels del tuo output della CLI. Ogni etichetta è formata da un NodeSelectorKey e da un NodeSelectorValue. È possibile utilizzare le etichette per specificare quali nodi di lavoro aggiornare.

   kubectl get nodes -o yaml
   

   Output di esempio

   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. Crea un gruppo di disponibilità ( ConfigMap ) e definisci le regole di indisponibilità per i tuoi nodi di lavoro. L'esempio seguente mostra due assegni: l' defaultcheck.json e un modello di assegno. È possibile utilizzare questo controllo di esempio per definire le regole per tutti i nodi di lavoro che non corrispondono a nessuno dei controlli definiti in ConfigMap (defaultcheck.json). Utilizzare il modello di controllo per creare il proprio controllo. Per ogni controllo, per identificare un nodo di lavoro, devi scegliere una delle etichette del nodo di lavoro che hai richiamato nel passo precedente.

   Per ogni controllo, è possibile impostare un solo valore per NodeSelectorKey e NodeSelectorValue. È possibile definire fino a 10 controlli in un file “ ConfigMap ”. Se aggiungi altri controlli, verranno ignorati.

   Esempio

   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

   Facoltativo: il timeout, espresso in secondi, da attendere affinché il drenaggio venga completato. Lo svuotamento in sicurezza di un nodo di lavoro rimuove tutti i pod esistenti dal nodo di lavoro e ripianifica i pod su altri nodi di lavoro nel cluster. I valori accettati sono numeri interi compresi tra 1 e 180. Il valore predefinito è 30.

   defaultcheck.json

   Quando si aggiornano i nodi di lavoro negli host Satellite, solo il 20% dei nodi di lavoro nel cluster può non essere disponibile alla volta.

   MaxUnavailablePercentage

   Il numero massimo di nodi che possono essere non disponibili per un valore e una chiave etichetta specificati, espresso come percentuale. Un nodo di lavoro è non disponibile durante il processo di distribuzione, ricaricamento o provisioning. I nodi di lavoro in coda sono bloccati dall'essere aggiornati se superano le percentuali di non disponibilità massime definite.

   NodeSelectorKey

   La chiave di etichetta del nodo di lavoro per il quale vuoi impostare una regola. Puoi impostare regole per le etichette predefinite fornite da IBM, così come per le etichette del nodo di lavoro che hai creato.

   NodeSelectorValue

   Il valore dell'etichetta che deve essere tenuto in considerazione dal nodo di lavoro per la regola che hai definito.

5. Crea l' ConfigMap e nel tuo cluster.

   kubectl apply -f <filepath/configmap.yaml>
   

6. Verificare che sia stato creato il file “ ConfigMap ”.

   kubectl get configmap --namespace kube-system
   

7. Aggiorna i nodi di lavoro elencandoli per ID.

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

8. Facoltativo: verificare gli eventi generati dall' ConfigMap e e gli eventuali errori di convalida che si verificano. Gli eventi possono essere esaminati nella sezione Events dell'output della tua CLI.

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

9. Conferma che l'aggiornamento è stato completato controllando la versione Kubernetes dei tuoi nodi di lavoro.

   kubectl get nodes
   

   Se l'aggiornamento non è riuscito, è necessario applicare gli aggiornamenti della versione sostituendo gli host.

10. Verifica di non avere nodi di lavoro duplicati. A volte, nei cluster più datati potrebbero essere presenti nodi di lavoro duplicati con uno NotReady stato dopo un aggiornamento. Per rimuovere i duplicati, consulta risoluzione dei problemi.