Aggiornamento di cluster, nodi di lavoro e componenti del cluster

Aggiornamento del master

Come faccio a sapere quando aggiornare il master?

Ricevi una notifica nella console, negli annunci e nella CLI quando gli aggiornamenti sono disponibili. È inoltre possibile controllare periodicamente la pagina delle versioni supportate.

Di quante versioni rispetto all'ultima può essere in ritardo il master?

È possibile aggiornare il server API solo alla versione immediatamente successiva a quella attuale (n+1).

I miei nodi di lavoro possono utilizzare una versione più recente rispetto al master?

I nodi di lavoro non possono eseguire una versione di major.minor Kubernetes più recente rispetto a quella del master. Inoltre, i tuoi nodi di lavoro possono essere solo una versione dietro la versione master (n-1). Per prima cosa, aggiorna il tuo master all'ultima versione di Kubernetes. Poi, aggiorna i nodi di lavoro nel tuo cluster.

I nodi di lavoro possono eseguire versioni patch successive rispetto al master, ad esempio versioni patch specifiche per i nodi di lavoro per gli aggiornamenti di sicurezza.

Come vengono applicati gli aggiornamenti delle patch?

Per impostazione predefinita, gli aggiornamenti patch per il master vengono applicati automaticamente nel corso di diversi giorni, pertanto una versione della patch master potrebbe essere disponibile prima che venga applicata al tuo master. L'automazione degli aggiornamenti ignora anche i cluster che si trovano in uno stato non integro o che hanno operazioni attualmente in corso. Occasionalmente, IBM potrebbe disabilitare gli aggiornamenti automatici per uno specifico fix pack del master, ad esempio una patch che è necessaria solo se un master viene aggiornato da una versione secondaria a un'altra. In uno qualsiasi di questi casi, è possibile verificare le informazioni sulla versione disponibili all'indirizzo Red Hat OpenShift on IBM Cloud per valutare eventuali impatti e scegliere di utilizzare in tutta sicurezza il comando ibmcloud oc cluster master update autonomamente, senza attendere che venga applicato l'aggiornamento automatico.

A differenza del master, devi aggiornare i tuoi nodi di lavoro per ogni versione patch.

Cosa succede durante l'aggiornamento del master?

Il tuo master è altamente disponibile con tre pod master di replica. I pod master hanno un aggiornamento continuo, durante il quale solo un pod alla volta non è disponibile. Due istanze sono attive e in esecuzione in modo che tu possa accedere e modificare il cluster durante l'aggiornamento. I nodi di lavoro, le applicazioni e le risorse continuano ad essere in esecuzione.

Posso ripristinare la versione precedente dell'aggiornamento?

No, non è possibile ripristinare un cluster a una versione precedente una volta completato il processo di aggiornamento. Assicurati di utilizzare un cluster di test e segui le istruzioni per risolvere i problemi potenziali prima di aggiornare il tuo master di produzione.

Quale procedura devo seguire per aggiornare il master?

Il seguente diagramma illustra il processo che puoi seguire per aggiornare il tuo master.

Aggiornamento dei nodi di lavoro classici

Nota che è disponibile un aggiornamento per i tuoi nodi di lavoro in un cluster dell'infrastruttura classica. Cosa significa? Man mano che gli aggiornamenti e le patch di sicurezza vengono implementati per il server API e altri componenti master, devi assicurati che i nodi di lavoro rimangano sincronizzati. Puoi effettuare due tipi di aggiornamenti: aggiornare solo la versione patch o aggiornare la versione major.minor con la versione patch.

• Patch: un aggiornamento patch del nodo di lavoro include delle correzioni di sicurezza. È possibile aggiornare il nodo worker classico all'ultima patch utilizzando i comandi ibmcloud oc worker reload o update. Tieni presente che il comando update aggiorna anche il nodo di lavoro alla stessa versione major.minor del master e dell'ultima versione della patch, se è disponibile anche un aggiornamento della versione major.minor.
• Major.minor: un aggiornamento major.minor sposta la versione Kubernetes del nodo di lavoro alla stessa versione del master. Questo tipo di aggiornamento include spesso delle modifiche all'API Kubernetes o altri comportamenti per i quali devi preparare il tuo cluster. Ricorda che i tuoi nodi di lavoro possono essere solo una versione dietro la versione master (n-1). Puoi aggiornare il nodo di lavoro classico alla stessa patch utilizzando il comando ibmcloud oc worker update.

Per ulteriori informazioni, vedi Tipi di aggiornamento.

È buona norma ruotare i certificati CA ogni volta che si aggiornano i nodi worker, poiché la fase più lunga della rotazione dei certificati prevede la ricarica o la sostituzione dei nodi worker.

Cosa succede alle mie app durante un aggiornamento?

Se esegui le applicazioni come parte di una distribuzione su nodi di lavoro che hai aggiornato, le applicazioni verranno ripianificate su altri nodi di lavoro nel cluster. Questi nodi di lavoro potrebbero trovarsi in un pool di nodi di lavoro diverso oppure, se hai nodi di lavoro autonomi, le applicazioni potrebbero essere pianificate su nodi di lavoro autonomi. Per evitare un periodo di inattività per la tua applicazione, devi assicurarti di disporre di capacità sufficiente nel cluster per sostenere il carico di lavoro.

Come posso controllare il numero di nodi di lavoro che vengono disattivati contemporaneamente durante un aggiornamento o un ricaricamento?

Se tutti i tuoi nodi di lavoro devono essere attivi e in esecuzione, prendi in considerazione il ridimensionamento del tuo pool di nodi di lavoro oppure l'aggiunta di nodi di lavoro autonomi per aggiungere altri nodi di lavoro. Puoi rimuovere i nodi di lavoro aggiuntivi una volta completato l'aggiornamento.

Inoltre, è possibile creare una mappa di configurazione " Kubernetes " che specifichi il numero massimo di nodi di lavoro che possono risultare non disponibili contemporaneamente, ad esempio durante un aggiornamento. I nodi di lavoro vengono identificati dalle etichette del nodo di lavoro. Puoi utilizzare le etichette fornite da IBM oppure le etichette personalizzate che hai aggiunto al nodo di lavoro.

Le regole della mappa di Kubernetes configurazione vengono utilizzate solo per l'aggiornamento dei nodi di lavoro. Queste regole non influiscono sui ricaricamenti del nodo di lavoro, il che significa che il ricaricamento avviene immediatamente quando richiesto.

Cosa succede se decido di non definire una mappa di configurazione?

Quando la mappa di configurazione non è definita, viene utilizzato il valore predefinito. Per impostazione predefinita, durante il processo di aggiornamento può risultare indisponibile al massimo il 20% di tutti i nodi di lavoro presenti in ciascun cluster.

Aggiornamento dei nodi di lavoro VPC

Noti che è disponibile un aggiornamento per i tuoi nodi di lavoro in un cluster VPC. Cosa significa? Man mano che gli aggiornamenti e le patch di sicurezza vengono implementati per il server API e altri componenti master, devi assicurati che i nodi di lavoro rimangano sincronizzati. Puoi effettuare due tipi di aggiornamenti: aggiornare solo la versione patch o aggiornare la versione major.minor con la versione patch.

Se hai Portworx distribuito nel tuo cluster, segui i passaggi per aggiornare i nodi worker VPC con Portworx volumi.

È buona norma ruotare i certificati CA ogni volta che si aggiornano i nodi worker, poiché la fase più lunga della rotazione dei certificati prevede la ricarica o la sostituzione dei nodi worker.

Se hai OpenShift Data Foundation distribuito nel tuo cluster, segui i passaggi per aggiornare i nodi worker VPC con OpenShift Data Foundation.

• Patch: un aggiornamento patch del nodo di lavoro include delle correzioni di sicurezza. Per chi lavora con macchine bare metal su VPC, è possibile applicare l'ultima patch utilizzando il comando ibmcloud oc worker reload . Per i worker delle istanze di server virtuali VPC, utilizzare il comando ibmcloud oc worker replace .
• Major.minor: un aggiornamento major.minor sposta la versione Kubernetes del nodo di lavoro alla stessa versione del master. Questo tipo di aggiornamento include spesso delle modifiche all'API Kubernetes o altri comportamenti per i quali devi preparare il tuo cluster. Ricorda che i tuoi nodi di lavoro possono essere solo una versione dietro la versione master (n-1). Puoi aggiornare il nodo di lavoro VPC alla stessa patch utilizzando il comando ibmcloud oc worker replace con l'opzione --update.

Cosa succede alle mie app durante un aggiornamento?

Se esegui le applicazioni come parte di una distribuzione su nodi di lavoro che hai aggiornato, le applicazioni verranno ripianificate su altri nodi di lavoro nel cluster. Questi nodi di lavoro potrebbero trovarsi in un pool di nodi di lavoro diverso. Per evitare tempi di inattività della tua app, devi assicurarti che il cluster disponga di capacità sufficiente per gestire il carico di lavoro, ad esempio ridimensionando i pool di worker. Per ulteriori informazioni, vedi Aggiunta di nodi di lavoro ai cluster Classic o Aggiunta di nodi di lavoro ai cluster VPC.

Cosa succede al mio nodo di lavoro durante un aggiornamento?

Il nodo di lavoro del VPC viene sostituito rimuovendo il vecchio nodo di lavoro e configurandone uno nuovo che esegue la patch aggiornata o la versione major.minor. Il nodo di lavoro sostitutivo viene creato nella stessa zona, nello stesso pool di nodi di lavoro e con lo stesso profilo del nodo di lavoro eliminato. Tuttavia, al nodo worker sostitutivo viene assegnato un nuovo indirizzo IP privato e vengono perse tutte le etichette o i taint personalizzati applicati al vecchio nodo worker (le etichette e i taint del pool di worker rimangono comunque applicati al nodo worker sostitutivo).

Cosa succede se sostituisco più nodi di lavoro contemporaneamente?

Se sostituisci più nodi di lavoro contemporaneamente, vengono eliminati e sostituiti contemporaneamente, non uno per uno. Assicurati di disporre di capacità sufficiente nel tuo cluster per ripianificare i tuoi carichi di lavoro prima di sostituire i nodi di lavoro.

Cosa succede se non viene creato un nodo di lavoro sostitutivo?

Un nodo di lavoro sostitutivo non viene creato se il pool di nodi di lavoro non ha il ribilanciamento automatico abilitato.

Aggiornamento dei profili (tipi di macchina)

Prima di cominciare:

• Accedi al tuo cluster Red Hat OpenShift.
• I dati sul nodo di lavoro vengono eliminati. Prendi in considerazione l'archiviazione dei tuoi dati sull'archiviazione persistente all'esterno del nodo di lavoro.
• Assicurati di disporre del ruolo di accesso alla piattaforma IAM "Operatore" o "Amministratore".

Per aggiornare i profili:

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. Rimuovi il nodo di lavoro obsoleto. Nota: se stati rimuovendo un profilo con fatturazione mensile (ad esempio, bare metal), ti viene addebitato l'intero mese.

   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

Come vengono ridotti i pool di nodi di lavoro?

Quando il numero di nodi di lavoro in un pool di nodi di lavoro viene ridotto, ad esempio durante l'aggiornamento di un nodo di lavoro o con il comando ibmcloud oc worker-pool resize, ai nodi di lavoro viene assegnata una priorità per l'eliminazione in base a diverse proprietà, inclusi lo stato, l'integrità e la versione.

Questa logica di priorità non è rilevante per il componente aggiuntivo autoscaler.

La seguente tabella mostra l'ordine in cui ai nodi di lavoro viene assegnata la priorità per l'eliminazione.

È possibile eseguire il comando ibmcloud oc worker ls per visualizzare tutte le proprietà del nodo di lavoro elencate nella tabella.

Aggiornamento dei componenti del cluster

Il tuo cluster Red Hat OpenShift on IBM Cloud viene fornito con dei componenti, come Ingress, che vengono installati automaticamente quando esegui il provisioning del cluster. Per impostazione predefinita, questi componenti vengono aggiornati automaticamente da IBM. Tuttavia, puoi disabilitare gli aggiornamenti per alcuni componenti aggiuntivi e aggiornarli manualmente e separatamente dai nodi master e di lavoro.

Quali componenti predefiniti posso aggiornare separatamente dal cluster?

Puoi disabilitare facoltativamente gli aggiornamenti automatici per i seguenti componenti:

• Fluentd per la registrazione
• ALB (application load balancer) Ingress

Ci sono componenti che non posso aggiornare separatamente dal cluster?

Sì. Il cluster è stato implementato con i seguenti componenti gestiti e le risorse associate, che non possono essere modificati, salvo che per ridimensionare i pod o modificare le configmap al fine di ottenere determinati vantaggi in termini di prestazioni. Se provi a modificare uno di questi componenti di distribuzione, le loro impostazioni originali vengono ripristinate a intervalli regolari quando vengono aggiornate con il master cluster. Tuttavia, tieni presente che le risorse che crei che vengono associate a questi componenti, come ad esempio le politiche di rete Calico che crei per essere implementate dai componenti di distribuzione Calico, non vengono aggiornate.

• calico componenti
• coredns componenti
• ibm-cloud-provider-ip
• ibm-file-plugin
• ibm-keepalived-watcher
• ibm-master-proxy
• ibm-storage-watcher
• kubernetes-dashboard componenti
• metrics-server
• Componenti olm-operator e catalog (1.16 e successive)
• vpn

Posso installare plug-in o componenti aggiuntivi diversi da quelli predefiniti?

Sì. Red Hat OpenShift on IBM Cloud mette a disposizione altri plug-in e componenti aggiuntivi tra cui puoi scegliere per ampliare le funzionalità del tuo cluster. Ad esempio, potresti voler abilitare i componenti aggiuntivi gestiti d IBM nel tuo cluster. È necessario aggiornare questi componenti aggiuntivi separatamente, seguendo la procedura di aggiornamento dei componenti aggiuntivi gestiti.

Aggiornamento di componenti aggiuntivi gestiti

I componenti aggiuntivi per i cluster gestiti di IBM Cloud Kubernetes Service rappresentano un modo semplice per potenziare il proprio cluster con funzionalità open source, come ad esempio Istio. La versione dello strumento open-source che aggiungi al tuo cluster è verificata da IBM e approvata per l'utilizzo in IBM Cloud Kubernetes Service. Per aggiornare alle ultime versioni i componenti aggiuntivi gestiti che hai abilitato nel tuo cluster, vedi Aggiornamento di componenti aggiuntivi gestiti.