Esegui l'upgrade dei cluster

Quando installi una nuova versione di bmctl, puoi eseguire l'upgrade dei cluster esistenti creati con una versione precedente. L'upgrade di un cluster alla versione più recente di Anthos clusters on bare metal offre funzionalità e correzioni aggiuntive per il tuo cluster. Inoltre, assicura che il cluster rimanga supportato. Puoi eseguire l'upgrade dei cluster di amministrazione, ibridi, autonomi o utente con il comando bmctl upgrade cluster.

Considerazioni sull'upgrade

Le seguenti sezioni descrivono le regole e le best practice da tenere presenti prima di eseguire l'upgrade di un cluster.

Funzionalità di anteprima

Le funzionalità di anteprima sono soggette a modifica e vengono fornite solo a scopo di test e valutazione. Non utilizzare le funzionalità di anteprima nei cluster di produzione. Non garantiamo che sia possibile eseguire l'upgrade dei cluster che utilizzano le funzionalità di anteprima. In alcuni casi, blocchiamo esplicitamente gli upgrade per i cluster che utilizzano le funzionalità di anteprima.

Per informazioni sull'interruzione delle modifiche relative all'upgrade, consulta le note di rilascio.

SELinux

Se vuoi abilitare SELinux per proteggere i tuoi container, devi assicurarti che SELinux sia abilitato in modalità Enforced su tutte le tue macchine host. A partire dalla versione 1.9.0 o successiva di Anthos clusters on bare metal, puoi abilitare o disabilitare SELinux prima o dopo la creazione del cluster o gli upgrade del cluster. SELinux è abilitato per impostazione predefinita su Red Hat Enterprise Linux (RHEL) e CentOS. Se SELinux è disabilitato sulle tue macchine host o hai dubbi, consulta Proteggere i tuoi container usando SELinux per istruzioni su come abilitarlo.

Anthos clusters on bare metal supporta SELinux solo nei sistemi RHEL e CentOS.

Regole di versione per gli upgrade

Quando scarichi e installi una nuova versione di bmctl, puoi eseguire l'upgrade dei tuoi cluster di amministrazione, ibridi, autonomi e creati o aggiornati con una versione precedente di bmctl. Non è possibile eseguire il downgrade dei cluster a una versione precedente.

Puoi eseguire l'upgrade di un cluster solo a una versione che corrisponde alla versione di bmctl in uso. In altre parole, se utilizzi la versione 1.13.10 di bmctl, puoi eseguire l'upgrade di un cluster solo alla versione 1.13.10.

Upgrade delle versioni delle patch

Per una determinata versione secondaria, puoi eseguire l'upgrade a qualsiasi versione patch più recente. In altre parole, puoi eseguire l'upgrade di un cluster di versione 1.13.X alla versione 1.13.Y purché Y sia maggiore di X. Ad esempio, puoi eseguire l'upgrade da 1.12.0 a 1.12.1 e da 1.12.1 a 1.12.3. Ti consigliamo di eseguire l'upgrade alla versione più recente della patch quando possibile per assicurarti che i cluster dispongano delle correzioni di sicurezza più recenti.

Upgrade della versione secondaria

Puoi eseguire l'upgrade dei cluster da una versione secondaria alla successiva, indipendentemente dalla versione della patch. In altre parole, puoi eseguire l'upgrade da 1.N.X a 1.N+1.Y, dove 1.N.X è la versione del tuo cluster e N+1 è la prossima versione secondaria disponibile. Le versioni della patch, X e Y, in questo caso non influiscono sulla logica di upgrade. Ad esempio, puoi eseguire l'upgrade da 1.12.3 a 1.13.10.

Non puoi ignorare le versioni secondarie durante l'upgrade dei cluster. Se tenti di eseguire l'upgrade a una versione secondaria con due o più versioni secondarie superiori alla versione del cluster, bmctl emette un errore. Ad esempio, non puoi eseguire l'upgrade di un cluster della versione 1.11.0 alla versione 1.13.0.

Un cluster di amministrazione può gestire cluster utente che si trovano nella stessa versione o in una versione secondaria precedente. I cluster utente gestiti non possono avere una versione secondaria inferiore rispetto al cluster di amministrazione, quindi prima di eseguire l'upgrade di un cluster di amministrazione a una nuova versione secondaria, assicurati che tutti i cluster utente gestiti siano nella stessa versione secondaria del cluster di amministrazione.

Gli esempi nelle seguenti istruzioni per l'upgrade mostrano il processo di upgrade dalla versione 1.12.2 ad Anthos clusters on bare metal 1.13.10.

Upgrade in loco per cluster autogestiti

A partire dalla versione 1.13.1 Anthos clusters on bare metal, puoi eseguire upgrade in loco su cluster di amministrazione, ibridi e autonomi. Un upgrade in loco elimina la necessità di un cluster bootstrap, che semplifica il processo e riduce i requisiti delle risorse per un upgrade. Per poter eseguire un upgrade in loco sul cluster autogestito, devi eseguire la versione 1.13.0 o successiva.

Per eseguire un upgrade in loco, puoi utilizzare bmctl o kubectl:

`bmctl`

Il processo di upgrade è identico al processo di upgrade standard, ad eccezione del comando bmctl upgrade cluster.

Per avviare l'upgrade in loco, utilizza il flag --use-bootstrap=false con il comando di upgrade:
```
bmctl upgrade cluster -c CLUSTER_NAME --use-bootstrap=false \
    --kubeconfig ADMIN_KUBECONFIG
```
Sostituisci quanto segue:
- CLUSTER_NAME: il nome del cluster di cui eseguire l'upgrade.
- ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.

Come per il processo di upgrade standard, i controlli preflight vengono eseguiti nell'ambito dell'upgrade del cluster per convalidare lo stato del cluster e l'integrità del nodo. Se i controlli preflight non vanno a buon fine, l'upgrade del cluster viene interrotto. Per risolvere eventuali errori, esamina il cluster e i log correlati, poiché non viene creato alcun cluster bootstrap.

`kubectl`

Per eseguire l'upgrade di un cluster autogestito con kubectl, segui questi passaggi:

Modifica il file di configurazione del cluster per impostare anthosBareMetalVersion sulla versione di destinazione dell'upgrade.
Per avviare l'upgrade, esegui il comando seguente:
```
kubectl apply -f CLUSTER_CONFIG_PATH
```
Sostituisci CLUSTER_CONFIG_PATH con il percorso del file di configurazione del cluster.

Come nel processo di upgrade standard, i controlli preflight vengono eseguiti come parte dell'upgrade del cluster per convalidare lo stato del cluster e l'integrità del nodo. Se i controlli preflight non vanno a buon fine, l'upgrade del cluster viene interrotto. Per risolvere eventuali errori, esamina il cluster e i relativi log, in quanto non viene creato alcun cluster di avvio.

Densità pod

Anthos clusters on bare metal supporta la configurazione di un massimo di 250 pod per nodo con nodeConfig.PodDensity.MaxPodsPerNode. Puoi configurare la densità dei pod solo durante la creazione del cluster. Non puoi aggiornare le impostazioni di densità dei pod per i cluster esistenti.

Problemi noti

Per informazioni sui potenziali problemi relativi agli upgrade dei cluster, consulta Upgrade dei cluster Anthos su Bare Metal nella pagina Problemi noti.

Eseguire l'upgrade dei cluster amministrativi, autonomi, ibridi o utente

Quando scarichi e installi una nuova versione di bmctl, puoi eseguire l'upgrade dei cluster amministrativi, ibridi, autonomi e creati con una versione precedente. Per una determinata versione di bmctl, è possibile eseguire l'upgrade del cluster solo alla stessa versione.

Scarica prima l'ultimo bmctl, quindi modifica i file di configurazione del cluster appropriati, quindi esegui il comando bmctl upgrade cluster per completare l'upgrade.

Scarica la versione più recente di bmctl dal bucket Cloud Storage e utilizza chmod per concedere a bmctl le autorizzazioni di esecuzione a tutti gli utenti:
```
gsutil cp gs://anthos-baremetal-release/bmctl/1.13.10/linux-amd64/bmctl bmctl
chmod a+x bmctl
```

Modifica il file di configurazione del cluster per modificare la versione del cluster Anthos clusters on bare metal da 1.12.2 a 1.13.10. Di seguito è riportato un esempio da una configurazione del cluster di amministrazione:

---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  # Cluster type. This can be:
  #   1) admin:  to create an admin cluster. This can later be used to create user clusters.
  #   2) user:   to create a user cluster. Requires an existing admin cluster.
  #   3) hybrid: to create a hybrid cluster that runs admin cluster components and user workloads.
  #   4) standalone: to create a cluster that manages itself, runs user workloads, but does not manage other clusters.
  type: admin
  # Anthos cluster version.
  # Change the following line from 1.12.2 to 1.13.10, shown below
  anthosBareMetalVersion: 1.13.10

Quando si eseguono l'upgrade dei cluster a 1.13.10, è necessario registrare i cluster con Connect nel tuo progetto,, parco risorse, se non sono già stati registrati.
1. Creare manualmente gli account di servizio e recuperare i file della chiave JSON come descritto in Configurare gli account di servizio da utilizzare con Connect nella pagina Abilitazione dei servizi e degli account di servizio Google.
2. Fai riferimento alle chiavi JSON scaricate nei campi gkeConnectAgentServiceAccountKeyPath e gkeConnectRegisterServiceAccountKeyPath associati del file di configurazione del cluster.
Utilizza il comando bmctl upgrade cluster per completare l'upgrade:
```
bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
Sostituisci quanto segue:
- CLUSTER_NAME: il nome del cluster di cui eseguire l'upgrade.
- ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
I controlli preflight vengono eseguiti come parte dell'upgrade del cluster per convalidare lo stato del cluster e l'integrità del nodo. L'upgrade del cluster non va a buon fine se i controlli preflight non vanno a buon fine.