Passi per aggiornare il master cluster

Prima di iniziare, assicurati di avere l'Operatore oppure il ruolo di accesso alla piattaforma IAM " Amministratore ". Se non sei sicuro del tuo ruolo di accesso, vai su Gestisci → Accesso (IAM) → Utenti nella console di IBM Cloud oppure chiedi all'amministratore del tuo account.

Se è in corso una rotazione dei certificati dell'autorità di certificazione (CA), l'aggiornamento principale viene bloccato fino al completamento della rotazione. Prima di iniziare, verifica lo stato di eventuali rotazioni in corso.

Per aggiornare la versione principale o secondaria del master “ Red Hat OpenShift ”:

1. Esamina le Red Hat OpenShift on IBM Cloud e apporta tutti gli aggiornamenti contrassegnati come Aggiorna prima del master.

2. Esaminare eventuali Kubernetes avvertenze utili, come ad esempio gli avvisi di obsolescenza.

3. Controllare i componenti aggiuntivi e i plug-in installati nel cluster per qualsiasi impatto che potrebbe essere causato dall'aggiornamento della versione del cluster.

   • Controllo dei componenti aggiuntivi

     1. Elenca i componenti aggiuntivi nel cluster.

        ibmcloud oc cluster addon ls --cluster CLUSTER
        

     2. Controlla la versione Red Hat OpenShift supportata per ogni componente aggiuntivo installato.

        ibmcloud oc addon-versions
        

     3. Se il componente aggiuntivo deve essere aggiornato per essere eseguito nella versione Red Hat OpenShift a cui vuoi aggiornare il tuo cluster, aggiorna il componente aggiuntivo.

   • Verifica dei plug-in

     1. Nel catalogoHelm, trova i plug-in che hai installato nel tuo cluster.
     2. Dal menu laterale, espandere la sezione SOURCES & TAR FILE.
     3. Scarica e apri il codice sorgente.
     4. Controllare i file README.md o RELEASENOTES.md per le versioni supportate.
     5. Se il plug-in deve essere aggiornato per essere eseguito nella versione Red Hat OpenShift a cui vuoi aggiornare il tuo cluster, aggiorna il plug-in seguendo le istruzioni del plug - in.

4. Aggiorna il tuo server API e i componenti master associati utilizzando la console IBM Cloud oppure eseguendo il comando CLI ibmcloud oc cluster master update .

5. Attendi alcuni minuti, quindi conferma che l'aggiornamento è stato completato. Controlla la versione del server API nel dashboard dei cluster IBM Cloud o esegui ibmcloud oc cluster ls.

6. Installa la versione della oc cli che corrisponde alla versione del server API Kubernetes eseguita nel master. Kubernetes non supporta le versioni client di oc che presentano una differenza di due o più versioni rispetto alla versione server (n ± 2). Per aggiornare la configurazione locale, esegui il comando ibmcloud oc cluster config -c CLUSTER_NAME_OR_ID, quindi verifica con ` `oc version --client.

Una volta completato l'aggiornamento del nodo master, aggiorna i nodi worker. Il metodo dipende dal tipo di infrastruttura in uso:

1. Aggiornamento dei nodi worker classici : utilizza un aggiornamento graduale gestito da un file di configurazione ( ConfigMap ) e dal comando worker update .
2. Aggiornamento dei nodi di lavoro VPC — I nodi di lavoro bare metal VPC vengono aggiornati in loco utilizzando worker reload; i nodi di lavoro VSI VPC devono utilizzare worker replace --update. La procedura di aggiornamento continuo “ ConfigMap ” non è ancora supportata per i nodi di lavoro VPC.

Prerequisiti

Prima di aggiornare i nodi di lavoro dell’infrastruttura classica, è necessario completare i seguenti passaggi preliminari.

Durante l'aggiornamento di un nodo di lavoro, il sistema operativo del nodo stesso viene reinstallato e tutti i dati non memorizzati su un supporto di archiviazione persistente vengono eliminati definitivamente. Prima di iniziare, assicurati che tutti i dati che devi conservare siano archiviati al di fuori del nodo di lavoro.

Se nel cluster è installato un Portworx, è necessario aggiornare la configurazione di Portworx prima di aggiornare i nodi di lavoro.

Aggiornamento dei nodi di lavoro classici nella CLI con una mappa di configurazione

Utilizza un file di aggiornamento " ConfigMap " per eseguire un aggiornamento progressivo dei tuoi nodi di lavoro classici. L' ConfigMap e consente di controllare il numero massimo di nodi che possono risultare non disponibili contemporaneamente, per zona o regione. Se la regola predefinita del 20% di indisponibilità è accettabile per il tuo cluster, puoi saltare i passaggi 3 e 4 (creazione di ConfigMap ) e passare direttamente al passaggio 5 per applicare l'aggiornamento utilizzando il comportamento predefinito.

1. Completa i passi prerequisiti.

2. Elenca i nodi di lavoro e prendi nota del loro indirizzo IP privato.

   ibmcloud oc worker ls --cluster CLUSTER
   

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.

   oc describe node PRIVATE-WORKER-IP
   

   Output di esempio

   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. Crea una mappa di configurazione e definisci le regole di non disponibilità per i tuoi nodi di lavoro. L' ConfigMap a supporta fino a 15 controlli con nome. Ogni controllo riguarda un insieme di nodi di lavoro in base all'etichetta e definisce la percentuale massima di tali nodi che possono risultare non disponibili contemporaneamente. L'esempio seguente mostra un controllo di zona (zonecheck.json), un controllo di regione (regioncheck.json), un controllo di fallback predefinito (defaultcheck.json) e un modello per i controlli personalizzati. Per ogni controllo, scegliere una delle etichette dei nodi di lavoro recuperate nel passaggio precedente per identificare i nodi di destinazione.

   Per ogni controllo, è possibile impostare un solo valore per NodeSelectorKey e NodeSelectorValue. Se vuoi impostare le regole per più di una regione, zona o altre etichette del nodo di lavoro, crea un nuovo controllo. È possibile definire fino a 15 controlli in una mappa di configurazione. Se aggiungi ulteriori controlli, solo un nodo di lavoro viene ricaricato alla volta finché non vengono aggiornati tutti i nodi di lavoro richiesti.

   Esempio

   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

   Opzionale: 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.

   zonecheck.json e regioncheck.json

   Due caselle di controllo che definiscono una regola per un insieme di nodi di lavoro identificabili tramite i valori specificati in “ NodeSelectorKey ” e “ NodeSelectorValue ”. L' zonecheck.json e identifica i nodi di lavoro in base alla loro etichetta di zona, mentre l' regioncheck.json e utilizza l'etichetta di regione aggiunta a ciascun nodo di lavoro durante il provisioning. Nell'esempio, il 30% di tutti i nodi di lavoro con etichetta di zona " dal13 " e il 20% di tutti i nodi di lavoro presenti in " us-south " potrebbero risultare non disponibili durante l'aggiornamento.

   defaultcheck.json

   Se non si crea una mappa di configurazione o se questa è configurata in modo errato, viene applicata l'impostazione predefinita di Kubernetes. Per impostazione predefinita, solo il 20% dei nodi di lavoro del cluster può essere non disponibile alla volta. Puoi sovrascrivere il valore predefinito aggiungendo il controllo predefinito alla tua mappa di configurazione. Nell'esempio, ogni nodo di lavoro non specificato nei controlli relativi alla zona e alla regione (dal13 o us-south) potrebbe risultare non disponibile durante l'aggiornamento.

   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. Se desideri aggiungere una regola per i nodi di lavoro appartenenti a un determinato pool di lavoro, puoi utilizzare l'etichetta " ibm-cloud.kubernetes.io/machine-type ".

   NodeSelectorValue

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

5. Crea la mappa di configurazione nel tuo cluster.

   oc apply -f <filepath/configmap.yaml>
   

6. Verifica che la mappa di configurazione sia stata creata.

   oc get configmap --namespace kube-system
   

7. Aggiorna i nodi di lavoro.

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

8. Facoltativo: verifica gli eventi che vengono attivati dalla mappa di configurazione e tutti gli errori di convalida che si verificano. Gli eventi possono essere esaminati nella sezione Events dell'output della tua CLI.

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

   oc get nodes
   

10. Assicurati che non ci siano nodi di lavoro duplicati. A volte, i cluster più vecchi riportano nodi di lavoro duplicati con uno NotReady stato dopo un aggiornamento. Per rimuovere i duplicati, consulta risoluzione dei problemi.

Aggiornamento dei nodi di lavoro classici nella console

Dopo aver configurato per la prima volta l' ConfigMap, è possibile aggiornare i nodi di lavoro utilizzando la console IBM Cloud. La console rispetta le regole di indisponibilità definite nell' ConfigMap.

1. Completa i passaggi preliminari e configura un’ ConfigMap per gestire l’aggiornamento dei nodi di lavoro.
2. Dal menu della console IBM Cloud , fare clic su Contenitori > Cluster.
3. Dalla pagina Cluster, fai clic sul tuo cluster.
4. Dalla scheda Nodi di lavoro, seleziona la casella di spunta per ciascun nodo di lavoro che desideri aggiornare. Viene visualizzata una barra delle azioni sulla riga dell'intestazione della tabella.
5. Dalla barra delle azioni, fai clic su Aggiorna.

Se nel cluster è installato un Portworx, è necessario riavviare i pod Portworx sui nodi worker aggiornati. Per ulteriori informazioni, consultare la sezione " Limitazioni di Portworx ".

Prerequisiti

Prima di aggiornare i nodi di lavoro dell’infrastruttura VPC, completare i seguenti passaggi preliminari.

Per i worker VPC VSI, il nodo worker viene eliminato e sostituito con un nuovo nodo. Per gli utenti che utilizzano macchine bare metal in VPC, il nodo viene ricaricato in loco. In entrambi i casi, i dati che non vengono salvati su un supporto di archiviazione permanente vengono eliminati definitivamente. Prima di iniziare, assicurati che tutti i dati che devi conservare siano archiviati al di fuori del nodo di lavoro.

Se nel proprio cluster è presente un Portworx, seguire la procedura per aggiornare i nodi di lavoro VPC con i volumi " Portworx ", anziché seguire la procedura descritta in questa pagina.

Aggiornamenti del firmware durante il ricaricamento del worker bare metal di VPC

Quando si riavvia un nodo worker bare metal di una VPC, l’infrastruttur IBM Cloud a verifica automaticamente se è disponibile un aggiornamento del firmware per quel server e lo applica nell’ambito del processo di riavvio. Non è necessaria alcuna operazione aggiuntiva per avviare l'aggiornamento del firmware.

Quando si esegue il riavvio di un nodo di lavoro bare metal VPC, tenere presenti le seguenti considerazioni:

Tempo di ricarica prolungato

Se durante il ricaricamento viene eseguito un aggiornamento del firmware, la durata complessiva del ricaricamento può aumentare in modo significativo — di 30 minuti o più — rispetto alla durata standard del ricaricamento. Pianificate di conseguenza le finestre di manutenzione.

Nessuna visibilità anticipata sugli aggiornamenti in sospeso

Prima di eseguire il comando di ricaricamento, non è possibile sapere se sia in sospeso un aggiornamento del firmware per un nodo di lavoro.

Rischio di perdita dei dati

Come per tutte le operazioni di reload dei worker bare metal su VPC, i dati presenti sui dischi locali vengono cancellati durante il reload, indipendentemente dal fatto che venga applicato o meno un aggiornamento del firmware. Prima di eseguire il ricaricamento, esegui il backup di tutti i dati che non sono memorizzati su un supporto di archiviazione permanente.

Errore di ricarica dovuto all'aggiornamento del firmware

In alcuni casi, l'aggiornamento del firmware può non andare a buon fine, causando l'entrata del nodo worker in uno stato di " reload_failed " (Failed to reload worker) con i dettagli dello stato riportati all'indirizzo The infrastructure firmware update has failed. (P4056). Se dovesse verificarsi quanto segue:

1. Attendi qualche minuto, quindi riprova a ricaricare il sito eseguendo nuovamente il comando ibmcloud oc worker reload --cluster CLUSTER --worker WORKER-NODE-ID .
2. Se l'errore persiste dopo 2-3 tentativi, apri una richiesta di assistenza su IBM Cloud.

Prima di iniziare

• Accedi al tuo cluster Red Hat OpenShift.
• Verifica che tutti i dati che devi conservare siano archiviati su un supporto di memorizzazione permanente esterno al nodo di lavoro. I dati memorizzati esclusivamente sul nodo di lavoro vanno persi e non possono essere recuperati.
• Assicurati di disporre del ruolo di accesso alla piattaforma IAM "Operatore" o "Amministratore". Se non sei sicuro del tuo ruolo di accesso, vai su Gestisci → Accesso (IAM) → Utenti nella console di IBM Cloud oppure chiedi all'amministratore del tuo account.

Per aggiornare i gusti

1. Elenca i nodi di lavoro e prendi nota del loro indirizzo IP privato.

   1. Elenca i pool di nodi di lavoro disponibili nel tuo cluster.

       ibmcloud oc worker-pool ls --cluster CLUSTER
       ```
   2. Elenca i nodi di lavoro nel pool di nodi di lavoro. Prendi nota di **ID** e **IP privato**.
   ```sh {: pre}
       ibmcloud oc worker ls --cluster CLUSTER --worker-pool WORKER-POOL
       ```
   3. Ottieni i dettagli per un nodo di lavoro. Nell'output, prendi nota della zona e dell'ID della VLAN pubblica e privata per i cluster classici o dell'ID della sottorete per i cluster VPC.
   ```sh {: pre}
       ibmcloud oc worker get --cluster CLUSTER --worker WORKER-ID
       ```
   

2. Elenca i profili disponibili nella zona.

   ibmcloud oc flavors --zone <zone>
   

3. Crea un nodo di lavoro con il nuovo tipo di macchina.

   1. Crea un pool di nodi di lavoro con il numero di nodi di lavoro che vuoi sostituire.
      • Cluster classici:

        ibmcloud oc worker-pool create classic --name WORKER-POOL --cluster CLUSTER --flavor FLAVOR --size-per-zone NUMBER-OF-WORKERS-PER-ZONE
        

      • Cluster VPC di generazione 2:

        ibmcloud oc worker-pool create vpc-gen2 --name NAME --cluster CLUSTER --flavor FLAVOR --size-per-zone NUMBER-OF-WORKERS-PER-ZONE --label LABEL
        

   2. Verifica che il pool di nodi di lavoro sia stato creato.

       ibmcloud oc worker-pool ls --cluster CLUSTER
       ```
   3. Aggiungi la zona al pool di nodi di lavoro che hai richiamato in precedenza. Quando aggiungi una zona, viene eseguito il provisioning dei nodi di lavoro definiti nel tuo pool di nodi di lavoro nella zona e vengono considerati per una pianificazione futura del carico di lavoro. Se vuoi distribuire i tuoi nodi di lavoro tra più zone, scegli un'ubicazione multizona [classica](/docs/openshift?topic=openshift-regions-and-zones#zones-mz) o [VPC](/docs/openshift?topic=openshift-regions-and-zones#zones-vpc).
       * Cluster classici:
           ```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
           ```
       * Cluster VPC:
           ```sh {: pre}
           ibmcloud oc zone add vpc-gen2 --zone ZONE --cluster CLUSTER --worker-pool WORKER-POOL --subnet-id VPC-SUBNET-ID
           ```
   

4. Attendi che i nodi di lavoro vengano distribuiti. Quando lo stato del nodo di lavoro diventa Normal, la distribuzione è terminata.

   ibmcloud oc worker ls --cluster CLUSTER
   

5. Eliminare il vecchio pool di lavoratori. Se si disattiva un’istanza Classic bare metal (che viene fatturata mensilmente), verrà addebitato l’intero importo mensile anche se la disattivazione avviene a metà mese. I servizi VPC, compresi quelli bare metal, vengono fatturati su base oraria.

   1. Rimuovi il pool di nodi di lavoro con il tipo di macchina obsoleto. La rimozione di un pool di nodi di lavoro rimuove tutti i nodi di lavoro nel pool in tutte le zone. Il completamento di questo processo potrebbe impiegare alcuni minuti.

       ibmcloud oc worker-pool rm --worker-pool WORKER-POOL --cluster CLUSTER
       ```
   2. Verifica che il pool di nodi di lavoro sia stato rimosso.
   ```sh {: pre}
       ibmcloud oc worker-pool ls --cluster CLUSTER
       ```
   

6. Verifica che i nodi di lavoro siano stati rimossi dal tuo cluster.

   ibmcloud oc worker ls --cluster CLUSTER
   

7. Ripeti questa procedura per aggiornare altri pool di nodi di lavoro o nodi di lavoro autonomi a profili differenti

Gestione degli aggiornamenti automatici per Fluentd

Quando crei una configurazione di registrazione per un'origine nel tuo cluster da inoltrare a un server esterno, nel tuo cluster viene creato un componente Fluentd. Per modificare le configurazioni relative alla registrazione o ai filtri, è necessario che il componente Fluentd sia aggiornato all'ultima versione. Per impostazione predefinita, gli aggiornamenti automatici per il componente sono abilitati.

Per eseguire i comandi riportati di seguito, è necessario disporre del ruolo di accesso alla piattaforma IAM " IBM Cloud "(Amministratore ) per il cluster.

Puoi gestire gli aggiornamenti automatici del componente Fluentd nei seguenti modi.

• Verifica se gli aggiornamenti automatici sono abilitati eseguendo il comando ibmcloud oc logging autoupdate get --cluster CLUSTER .
• Disattiva gli aggiornamenti automatici eseguendo il comando ibmcloud oc logging autoupdate disable.
• Se gli aggiornamenti automatici sono disabilitati, ma hai bisogno di cambiare la tua configurazione, hai due opzioni:
  • Attiva gli aggiornamenti automatici per i tuoi pod Fluentd.

      ibmcloud oc logging autoupdate enable --cluster CLUSTER
      ```
  * Forza un aggiornamento una tantum quando usi un comando di registrazione che include l'opzione `--force-update`. I tuoi pod vengono aggiornati all'ultima versione del componente Fluentd, ma d'ora in poi Fluentd non verrà più aggiornato automaticamente.
          Comando di esempio
  
  ```sh {: pre}
      ibmcloud oc logging config update --cluster CLUSTER --id LOG-CONFIG-ID --type LOG-TYPE --force-update
      ```
  

Gestione degli aggiornamenti automatici per gli ALB Ingress

Controlla quando viene aggiornato il componente ALB (application load balancer) Ingress. Per informazioni su come mantenere gli ALB aggiornati, vedi Gestione del ciclo di vita di ALB Ingress.