Questa pagina fornisce informazioni sul runtime del container containerd, sul supporto per Docker in Google Kubernetes Engine (GKE) e una panoramica del motivo per cui devi eseguire la migrazione alle immagini dei nodi che utilizzano containerd. Per istruzioni su come eseguire la migrazione a un'immagine del nodo containerd, consulta Eseguire la migrazione da Docker alle immagini dei nodi containerd.
Panoramica
I nodi Kubernetes utilizzano il runtime del container per avviare, gestire e arrestare i container in esecuzione nei pod. Il progetto Kubernetes sta rimuovendo il supporto integrato per il runtime Docker in Kubernetes versione 1.24 e successive. Per raggiungere questo obiettivo, Kubernetes sta rimuovendo un componente chiamato dockershim, che consente a Docker di comunicare con i componenti di Kubernetes come kubelet.
Containerd, il nuovo runtime predefinito, è un runtime del container standard del settore supportato da Kubernetes e utilizzato da molti altri progetti. Il runtime containerd fornisce l'astrazione di layering che consente l'implementazione di un ricco set di funzionalità come gVisor e Image streaming per estendere la funzionalità GKE. Il runtime è anche considerato più efficiente e sicuro del runtime Docker.
A causa di questa modifica, GKE non supporta le immagini dei nodi che utilizzano Docker come runtime in GKE 1.24 e versioni successive. Un cluster è interessato se uno qualsiasi dei suoi node pool utilizza immagini dei nodi basate su Docker o utilizza il provisioning automatico dei nodi con un tipo di immagine dei nodi predefinita basata su Docker.
Prima del 31 luglio 2023, la data di fine ciclo di vita della versione 1.23 di GKE, GKE mette in pausa gli upgrade automatici e impedisce gli upgrade manuali alla versione 1.24. Per eseguire l'upgrade del piano di controllo del cluster alla versione GKE 1.24 e successive prima di questa data, devi aggiornare la configurazione del provisioning automatico dei nodi e tutti i nodi al runtime containerd. Per eseguire l'upgrade di un pool di nodi, devi eseguire la migrazione a un'immagine del nodo che utilizza il runtime containerd.
Una volta raggiunta la fine del ciclo di vita della versione 1.23, GKE sblocca gli upgrade manuali del control plane alla versione 1.24 per i cluster che non hanno ancora completato la migrazione e inizia a eseguire l'upgrade graduale dei cluster per motivi di sicurezza e compatibilità. Per scoprire di più su come GKE esegue l'upgrade dei cluster alla versione 1.24 e su cosa ti consigliamo di fare per eseguire la migrazione dei cluster dalle immagini dei nodi Docker, consulta la pagina Migrazione automatica quando la versione 1.23 raggiunge la fine del ciclo di vita.
Immagini dei nodi Docker e containerd
Containerd è il runtime predefinito per tutti i nuovi nodi GKE dalla versione 1.19 su Linux e 1.21 su Windows. Tuttavia, i cluster GKE Standard hanno continuato a supportare anche le immagini dei nodi che utilizzavano Docker come runtime. La tabella seguente descrive le immagini dei nodi basate su Docker che non saranno supportate in GKE 1.24 e versioni successive e gli equivalenti di containerd:
| Runtime Docker | Runtime containerd |
|---|---|
Container-Optimized OS con Docker (cos) |
Container-Optimized OS con containerd (cos_containerd) |
Ubuntu con Docker (ubuntu) |
Ubuntu con containerd (ubuntu_containerd) |
Windows Server LTSC con Docker (windows_ltsc) |
Windows Server LTSC con containerd (windows_ltsc_containerd) |
SAC di Windows Server con Docker ( |
SAC di Windows Server con containerd ( |
Timeline e traguardi
Nella versione 1.23 di GKE, non puoi più:
- Crea nuovi cluster che utilizzano immagini dei nodi basate su Docker.
- Aggiungi nuovi node pool con immagini dei nodi basate su Docker a un cluster esistente.
- Abilita il provisioning automatico dei nodi con il flag
--autoprovisioning-image-typeimpostato su immagini dei nodi basate su Docker.
Se esegui l'upgrade alla versione 1.23 di GKE, puoi continuare a utilizzare quanto segue:
- Pool di nodi esistenti con immagini dei nodi basate su Docker create prima dell'upgrade.
- Gestore della scalabilità automatica dei cluster sui pool di nodi con immagini dei nodi Docker.
- Provisioning automatico dei nodi con il flag
--autoprovisioning-image-typeimpostato su immagini dei nodi basate su Docker, se abilitato prima dell'upgrade.
Nella versione 1.24 di GKE, non puoi più eseguire le seguenti operazioni:
- Se il control plane esegue la versione 1.24, non puoi utilizzare il provisioning automatico dei nodi con il flag
--autoprovisioning-image-typeimpostato su immagini dei nodi basate su Docker. - Se il pool di nodi esegue la versione 1.24, i nodi non possono utilizzare immagini dei nodi basate su Docker.
La tabella seguente fornisce un riepilogo delle modifiche da aspettarsi quando interagisci con le prossime versioni di GKE:
| Azione | GKE versione 1.23 | Versione 1.24 di GKE |
|---|---|---|
| Crea nuovi cluster con Docker | No | No |
| Crea nuovi node pool con Docker | No | No |
| Abilita il provisioning automatico dei nodi con Docker | No | No |
| Esegui l'upgrade dalla versione precedente con la configurazione del provisioning automatico dei nodi Docker esistente | Sì | No |
| Utilizzare immagini dei nodi basate su Docker | Sì | No |
Migrazione automatica quando la versione 1.23 raggiunge la fine del ciclo di vita
Se non esegui l'upgrade alla versione 1.24 e la migrazione alle immagini dei nodi containerd prima che la versione 1.23 raggiunga la fine del ciclo di vita il 31 luglio 2023, GKE esegue le seguenti operazioni nel tempo:
Se il cluster dispone del provisioning automatico dei nodi con un tipo di immagine dei nodi predefinita basata su Docker, GKE aggiorna la configurazione in modo da utilizzare l'immagine dei nodi equivalente che utilizza il runtime containerd. Non puoi bloccare questa operazione con un'esclusione della manutenzione. Per verificare che non ci siano effetti negativi sui tuoi carichi di lavoro, ti consigliamo di aggiornare manualmente il tipo di immagine predefinito del provisioning automatico dei nodi a un'immagine basata su containerd prima che GKE aggiorni automaticamente la configurazione.
GKE esegue l'upgrade del control plane del cluster alla versione 1.24.
A partire dal 1° settembre 2023, GKE esegue la migrazione di tutti i pool di nodi che utilizzano ancora Docker alle immagini dei nodi containerd. Ti consigliamo di eseguire la migrazione manuale delle immagini dei nodi prima di questa data. In alternativa, puoi richiedere a GKE di avviare un'operazione per eseguire la migrazione del cluster in modo che utilizzi le immagini containerd. Per effettuare questa richiesta, contatta l' assistenza clienti Google Cloud.
Per bloccare temporaneamente la migrazione automatica, esegui l'upgrade del cluster alla versione 1.24 o successive e configura un'esclusione della manutenzione. Per ulteriori informazioni su questa esclusione dalla manutenzione, vedi Ritardare temporaneamente la migrazione automatica alle immagini dei nodi Containerd.
GKE esegue l'upgrade dei pool di nodi nella versione 1.23 alla 1.24, come avviene con qualsiasi versione non supportata per garantire l'allineamento dell'integrità del cluster con le norme sul disallineamento delle versioni open source. Per saperne di più, consulta il ciclo di vita delle versioni secondarie di GKE. Puoi bloccare temporaneamente questo upgrade con un'esclusione dalla manutenzione.
Ritardare temporaneamente la migrazione automatica alle immagini dei nodi containerd
Dopo l'upgrade del control plane del cluster alla versione 1.24 o successive, puoi
configurare un'esclusione della manutenzione
per impedire temporaneamente la migrazione dei nodi fino al 29 febbraio 2024, data in cui la versione 1.25 raggiungerà
la fine del supporto.
Per essere idoneo a questa esclusione dalla manutenzione, il tuo cluster deve essere registrato a
un canale
di rilascio.
Configura l'esclusione dalla manutenzione con l'ambito "Nessun upgrade secondario o dei nodi" e imposta il flag --add-maintenance-exclusion-end su 2024-02-29T00:00:00Z o versioni precedenti. Ti consigliamo di sbloccare la migrazione il prima possibile e
consentire l'upgrade dei nodi alla versione 1.24. Le versioni secondarie che hanno raggiunto
la fine del supporto non riceveranno più patch di sicurezza e correzioni di bug.
Esegui la migrazione dalle immagini dei nodi Docker a containerd
Consulta Eseguire la migrazione dalle immagini dei nodi Docker a quelle basate su containerd per identificare i cluster e i pool di nodi che utilizzano immagini dei nodi basate su Docker ed eseguire la migrazione di questi pool di nodi alle immagini dei nodi basate su containerd.
Nell'ambito del modello di responsabilità condivisa GKE, il mantenimento dell'integrità dei carichi di lavoro rientra nelle responsabilità del cliente, mentre garantire che il cluster rimanga funzionale, inclusa l'esecuzione di una versione supportata, rientra nelle responsabilità di Google. Ti consigliamo vivamente di testare i tuoi carichi di lavoro ed eseguire la migrazione del cluster prima che GKE lo faccia automaticamente.
Prima che la versione 1.23 non sia più supportata, GKE impedisce gli upgrade automatici o manuali alla versione 1.24 per i cluster con pool di nodi che utilizzano immagini dei nodi Docker. Dopo aver eseguito la migrazione del cluster in modo che utilizzi solo immagini containerd, gli upgrade automatici possono riprendere entro un giorno, in base al programma di rilascio di GKE, oppure puoi eseguire l'upgrade manuale del cluster.
Al termine del supporto di 1.23, GKE sblocca gli upgrade automatici o manuali alla versione 1.24 e segue la procedura di migrazione automatica.
Impatto della migrazione
La modifica principale quando esegui la migrazione alle immagini dei nodi containerd è che Docker non gestisce più il ciclo di vita dei container (ad esempio l'avvio e l'arresto). Pertanto, non puoi utilizzare i comandi Docker o l'API Docker per visualizzare o interagire con i container GKE in esecuzione su nodi che utilizzano immagini containerd.
La maggior parte dei carichi di lavoro degli utenti non dipende dal runtime del container. Il runtime Docker implementa anche containerd, quindi i tuoi carichi di lavoro si comportano in modo simile sulle immagini dei nodi containerd.
Potresti essere interessato se si verificano le seguenti situazioni:
- Esegui pod con privilegi che eseguono comandi Docker.
- Esegui script sui nodi dall'esterno dell'infrastruttura Kubernetes (ad esempio, per utilizzare SSH per risolvere i problemi).
- Esegui strumenti di terze parti che eseguono operazioni con privilegi simili.
- Alcuni dei tuoi strumenti rispondono a log specifici di Docker nel tuo sistema di monitoraggio.
- Esegui il deployment di strumenti di logging, monitoraggio, sicurezza o integrazione continua forniti da fornitori esterni nel tuo cluster GKE. Contatta questi fornitori per confermare l'impatto.
Non sei interessato nelle seguenti situazioni:
- Hai una pipeline di build al di fuori del cluster GKE che utilizza Docker per creare ed eseguire il push delle immagini container.
- Utilizzi i comandi
docker buildedocker pushnel cluster GKE. Le immagini dei nodi Linux con containerd includono il binario Docker e supportano questi comandi.
Utilizzo di pod con privilegi per accedere a Docker
Se i tuoi utenti accedono a Docker Engine su un nodo utilizzando un pod privilegiato, devi aggiornare questi carichi di lavoro in modo che non dipendano direttamente da Docker. Ad esempio, valuta la migrazione del processo di estrazione di logging e monitoraggio da Docker Engine ai componenti aggiuntivi di sistema GKE.
Creazione di immagini container con Containerd
Non puoi utilizzare Containerd per creare immagini container. Le immagini Linux con containerd includono il binario Docker, in modo da poter utilizzare Docker per creare e trasferire immagini. Tuttavia, non consigliamo di utilizzare singoli container e nodi locali per eseguire comandi per creare immagini.
Kubernetes non è a conoscenza delle risorse di sistema utilizzate dai processi locali al di fuori dell'ambito di Kubernetes e il piano di controllo Kubernetes non può tenere conto di questi processi durante l'allocazione delle risorse. Ciò può privare i carichi di lavoro GKE di risorse o causare instabilità sul nodo.
Valuta la possibilità di eseguire queste attività utilizzando altri servizi al di fuori dell'ambito del singolo container, ad esempio Cloud Build, oppure utilizza uno strumento come kaniko per creare immagini come carico di lavoro Kubernetes.
Se nessuno di questi suggerimenti funziona per te e comprendi i rischi, puoi continuare a utilizzare Docker sul nodo locale per creare immagini. Devi eseguire il push delle immagini in un registro prima di poterle utilizzare in un cluster GKE. Kubernetes con containerd non riconosce le immagini create localmente utilizzando Docker.
Debug dei container sui nodi containerd
Per il debug o la risoluzione dei problemi sui nodi Linux, puoi interagire con
containerd utilizzando lo strumento a riga di comando portatile creato per i runtime dei container Kubernetes: crictl. crictl supporta funzionalità comuni per visualizzare container e immagini, leggere i log ed eseguire comandi nei container. Consulta la
guida dell'utente di crictl
per l'insieme completo di funzionalità supportate e informazioni sull'utilizzo.
Per i nodi Windows Server, il daemon containerd viene eseguito come servizio Windows
denominato containerd.
I log sono disponibili come segue:
- Windows:
C:\etc\kubernetes\logs\containerd.log - Linux: esegui
journalctl -u containerd
Puoi anche visualizzare i log per i nodi Windows e Linux in Esplora log
in LOG NAME: "container-runtime".
Risoluzione dei problemi
Per la risoluzione dei problemi, vai a Risolvere i problemi relativi al runtime containerd.
Passaggi successivi
- Scopri di più sul ritiro di dockershim.
- Controlla se il ritiro ti riguarda.
- Esegui la migrazione da Docker a immagini dei nodi containerd.