Questa pagina è stata tradotta dall'API Cloud Translation.

Esegui la migrazione dei nodi a containerd 2

Autopilot Standard

I cluster Google Kubernetes Engine (GKE) utilizzano immagini del nodo containerd con tutti i nodi worker che eseguono la versione 1.24 e successive. I nodi worker utilizzano una versione specifica di containerd, in base alla versione di GKE:

I nodi che eseguono GKE 1.32 o versioni precedenti, con immagini dei nodi containerd, utilizzano containerd 1.7 o versioni precedenti.
I nodi che eseguono GKE 1.33 utilizzano containerd 2.0.

Quando i nodi GKE vengono sottoposti ad upgrade da 1.32 a 1.33, viene eseguita la migrazione dall'utilizzo di containerd 1.7 alla nuova versione principale, containerd 2.0. Non puoi modificare la versione di Containerd utilizzata da una versione di GKE.

Puoi saltare la lettura di questa pagina se sai che i tuoi carichi di lavoro vengono eseguiti come previsto su containerd 2.

Come GKE esegue la transizione a containerd 2

Esamina la seguente sequenza temporale per capire in che modo GKE sta effettuando la transizione dei cluster esistenti all'utilizzo di containerd 2:

Con la versione minore 1.32, GKE utilizza containerd 1.7. containerd 1.7 ha ritirato sia le immagini Docker schema 1 sia l'API Container Runtime Interface (CRI) v1alpha2. Per scoprire di più sulle altre funzionalità ritirate nelle versioni precedenti, consulta Proprietà di configurazione ritirate.
Con la versione minore 1.33, GKE utilizza containerd 2.0, cherimuove il supporto per le immagini Docker Schema 1 e l'API CRI v1alpha2.
Le seguenti proprietà di configurazione di containerd nel plug-in CRI sono deprecate e verranno rimosse in containerd 2.1, con una versione GKE ancora da annunci.registry.auths, registry.configs, registry.mirrors.

Per le tempistiche approssimative degli upgrade automatici alle versioni secondarie successive, come la 1.33, consulta la Pianificazione stimata per i canali di rilascio.

Impatto della transizione a containerd 2

Leggi la sezione seguente per comprendere l'impatto di questa transizione a containerd 2.

Upgrade automatici in pausa

GKE mette in pausa gli upgrade automatici alla versione 1.33 quando rileva che un cluster utilizza le funzionalità ritirate. Tuttavia, se i nodi del cluster utilizzano queste funzionalità, ti consigliamo di creare un'esclusione per la manutenzione per impedire gli upgrade dei nodi. L'esclusione per la manutenzione garantisce che non venga eseguito l'upgrade dei tuoi nodi se GKE non rileva l'utilizzo.

Dopo la migrazione dall'utilizzo di queste funzionalità, se 1.33 è un obiettivo di upgrade automatico per i nodi del cluster e non sono presenti altri fattori che bloccano gli upgrade automatici, GKE riprende gli upgrade minori automatici a 1.33. Per i pool di nodi dei cluster standard, puoi anche eseguire l'upgrade manuale del pool di nodi.

Termine del supporto e impatto della mancata preparazione alla migrazione

GKE mette in pausa gli upgrade automatici fino alla fine del supporto standard. Se il tuo cluster è registrato nel canale esteso, i tuoi nodi possono rimanere su una versione fino al termine del supporto esteso. Per maggiori dettagli sugli upgrade automatici dei nodi al termine del supporto, consulta Upgrade automatici al termine del supporto.

Se non esegui la migrazione da queste funzionalità, quando la versione 1.32 raggiunge la fine del ciclo di vita e viene eseguito l'upgrade automatico dei nodi del cluster alla versione 1.33, potresti riscontrare i seguenti problemi con i cluster:

I workload che utilizzano immagini Docker schema 1 non vanno a buon fine.
Le applicazioni che chiamano l'API CRI v1alpha2 riscontrano errori durante la chiamata all'API.

Eseguire la migrazione dalle funzionalità ritirate

Esamina i seguenti contenuti per capire come eseguire la migrazione dalle funzionalità ritirate con containerd 2.

Esegui la migrazione dalle immagini Docker schema 1

Identifica i carichi di lavoro che utilizzano le immagini di cui deve essere eseguita la migrazione, quindi esegui la migrazione di questi carichi di lavoro.

Trovare le immagini di cui eseguire la migrazione

Puoi utilizzare diversi strumenti per trovare le immagini di cui è necessaria la migrazione.

Utilizzare Cloud Logging

Puoi utilizzare la seguente query in Cloud Logging per controllare i log di containerd e trovare le immagini Docker Schema 1 nel tuo cluster:

jsonPayload.SYSLOG_IDENTIFIER="containerd"
"conversion from schema 1 images is deprecated"

Se sono trascorsi più di 30 giorni dal recupero dell'immagine, potresti non vedere i log relativi a un'immagine.

Utilizza il comando `ctr` direttamente su un nodo

Per eseguire una query su un nodo specifico in modo da restituire tutte le immagini non eliminate che sono state estratte come Schema 1, esegui il seguente comando su un nodo:

  ctr --namespace k8s.io images list 'labels."io.containerd.image/converted-docker-schema1"'

Questo comando può essere utile se, ad esempio, stai risolvendo i problemi di un determinato nodo e non visualizzi le voci di log in Cloud Logging perché sono trascorsi più di 30 giorni dal recupero dell'immagine.

Utilizza lo strumento open source `crane`

Puoi anche utilizzare strumenti open source come crane per controllare la presenza di immagini.

Esegui il seguente comando crane per controllare la versione dello schema di un'immagine:

crane manifest $tagged_image | jq .schemaVersion

Prepara i workload

Per preparare i workload che eseguono immagini Docker schema 1, devi eseguirne la migrazione alle immagini Docker schema 2 o alle immagini Open Container Initiative (OCI). Valuta le seguenti opzioni per la migrazione:

Trova un'immagine sostitutiva:potresti riuscire a trovare un'immagine open source o fornita dal fornitore disponibile pubblicamente.
Converti l'immagine esistente:se non riesci a trovare un'immagine sostitutiva, puoi convertire le immagini Docker schema 1 esistenti in immagini OCI con i seguenti passaggi:
1. Estrai l'immagine Docker in containerd, che la converte automaticamente in un'immagine OCI.
2. Esegui il push della nuova immagine OCI nel tuo registry.

Esegui la migrazione dall'API CRI v1alpha2

L'API CRI v1alpha2 è stata rimessa in Kubernetes 1.26. Devi identificare i workload che accedono al socket containerd e aggiornare queste applicazioni per utilizzare l'API v1.

Identificare i carichi di lavoro

Puoi utilizzare tecniche diverse per identificare i carichi di lavoro di cui deve essere eseguita la migrazione.

Utilizza kubectl

Il seguente comando ti aiuta a trovare i carichi di lavoro che accedono alla socket di containerd. Questo comando restituisce i carichi di lavoro che montano directory hostPath che includono la presa. Questa query potrebbe generare falsi positivi perché alcuni carichi di lavoro montano queste directory o altre directory secondarie, ma non accedono alla socket containerd.

Esegui questo comando:

kubectl get pods --all-namespaces -o json | jq -r '.items[] |
select(.spec.volumes[]? | select(.hostPath.path? and (.hostPath.path |
startswith("/run") or startswith("/var/run") or . == "/"))) |
.metadata.namespace + "/" + .metadata.name'

Controlla il codice dell'applicazione

Puoi controllare il codice dell'applicazione per verificare se importa le librerie client dell'API CRI v1alpha2.

Ad esempio, vedi il seguente codice Golang:

  package main

  import (
    ...

    runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"
  )

  func foo() {
    ...

    client := runtimeapi.NewRuntimeServiceClient(conn)
    version, err := client.Version(ctx, &runtimeapi.VersionRequest{})

    ...
  }

Qui l'applicazione importa la libreria v1alpha2 e la utilizza per emettere RPC. Se le RPC utilizzano la connessione alla porta del socket containerd, questa applicazione causerà la messa in pausa degli upgrade automatici per il cluster da parte di GKE.

Per cercare e aggiornare il codice dell'applicazione:

Identifica le applicazioni golang problematiche eseguendo il seguente comando per cercare il percorso di importazione v1alpha2:
```
  grep -r "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"
```
Se l'output di questo comando indica che nel file viene utilizzata la libreria v1alpha2, devi aggiornare il file.

Ad esempio, sostituisci il seguente codice dell'applicazione:
```
  runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"
```
Aggiorna il codice in modo da utilizzare la versione 1:
```
  runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1"
```