Questa pagina fornisce informazioni sul runtime del contenitore containerd, sul supporto di Docker in Google Kubernetes Engine (GKE) e una panoramica del motivo per cui devi eseguire la migrazione alle immagini di nodo 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 1.24 e versioni successive. Per farlo, 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 contenitore standard di settore supportato da Kubernetes e utilizzato da molti altri progetti. Il runtime containerd fornisce l'astrazione a livelli che consente l'implementazione di un ampio insieme di funzionalità come gVisor e Image streaming per estendere la funzionalità di GKE. Il runtime è inoltre considerato più efficiente in termini di risorse e più sicuro rispetto al runtime di Docker.
A causa di questa modifica, GKE non supporta le immagini dei nodi che utilizzano Docker come runtime nella versione 1.24 e successive di GKE. Un cluster è interessato se uno dei suoi pool di nodi utilizza immagini dei nodi basate su Docker o utilizza il provisioning automatico dei nodi con un tipo di immagine del nodo predefinito basato su Docker.
Prima del 31 luglio 2023, data di ritiro 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 tuo 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 utilizzi il runtime containerd.
Una volta che la versione 1.23 ha raggiunto la fine del ciclo di vita, GKE sblocca gli upgrade manuali del piano di controllo alla versione 1.24 per i cluster che non hanno ancora completato la migrazione e inizia gradualmente a eseguire l'upgrade 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 consigliamo di fare per eseguire la migrazione dei cluster dalle immagini dei nodi Docker, consulta 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 dall'inizio della 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 nella versione 1.24 e successive di GKE 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ù:
- Creare nuovi cluster che utilizzano immagini dei nodi basate su Docker.
- Aggiungi nuovi pool di nodi con immagini dei nodi basate su Docker a un cluster esistente.
- Attiva il provisioning automatico dei nodi con il flag
--autoprovisioning-image-typeimpostato su immagini dei nodi basate su Docker.
Se stai eseguendo l'upgrade alla versione 1.23 di GKE, puoi continuare utilizzando quanto segue:
- Pool di nodi esistenti con immagini dei nodi basate su Docker create prima dell'upgrade.
- Scalabilità automatica dei cluster nei pool di nodi con immagini dei nodi Docker.
- Il 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ù:
- Se il piano di controllo 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 node pool esegue la versione 1.24, i nodi non possono utilizzare immagini dei nodi basate su Docker.
La seguente tabella fornisce un riepilogo delle modifiche che puoi aspettarti quando interagisci con le prossime versioni di GKE:
| Azione | Versione GKE 1.23 | Versione GKE 1.24 |
|---|---|---|
| Creare nuovi cluster con Docker | No | No |
| Creare nuovi pool di nodi con Docker | No | No |
| Abilita il provisioning automatico dei nodi con Docker | No | No |
| Eseguire l'upgrade dalla versione precedente con la configurazione esistente del provisioning automatico dei nodi Docker | Sì | No |
| Utilizzare immagini dei nodi basate su Docker | Sì | No |
Migrazione automatica al termine del ciclo di vita della versione 1.23
Se non esegui l'upgrade alla versione 1.24 e non esegui la migrazione alle immagini dei nodi containerd prima del ritiro della versione 1.23 il 31 luglio 2023, GKE eseguirà quanto segue nel tempo:
Se il tuo cluster dispone del provisioning automatico dei nodi con un tipo di immagine del nodo predefinito basato su Docker, GKE aggiorna la configurazione in modo da utilizzare l'immagine del nodo equivalente che utilizza il runtime containerd. Non puoi bloccare questa operazione con un'esclusione per la manutenzione. Per verificare che non ci siano effetti negativi sui carichi di lavoro, ti consigliamo di aggiornare manualmente il tipo di immagine predefinito per il provisioning automatico dei nodi su un'immagine basata su containerd prima che GKE aggiorni automaticamente la configurazione.
GKE esegue l'upgrade del piano di controllo 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 manualmente la migrazione delle immagini dei nodi prima di questa data. In alternativa, puoi chiedere a GKE di avviare un'operazione per eseguire la migrazione del tuo 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 successiva e configura un'esclusione della manutenzione. Per ulteriori informazioni su questa esclusione di manutenzione, consulta Ritarda temporaneamente la migrazione automatica alle immagini dei nodi containerd.
GKE esegue l'upgrade dei pool di nodi dalla versione 1.23 alla 1.24, come avviene con qualsiasi versione non supportata, per garantire l'allineamento dell'integrità del cluster alla policy di disallineamento delle versioni open source. Per saperne di più, consulta il ciclo di vita delle versioni minori di GKE. Puoi bloccare temporaneamente questo upgrade con un'esclusione dalla manutenzione.
Ritarda temporaneamente la migrazione automatica alle immagini dei nodi containerd
Dopo aver eseguito l'upgrade del piano di controllo del cluster alla versione 1.24 o successiva, puoi
configurare un'esclusione della manutenzione
per impedire temporaneamente la migrazione dei nodi fino al 29 febbraio 2024,
quando la versione 1.25 raggiunge il termine del supporto.
Per essere idoneo a questa esclusione per manutenzione, il cluster deve essere registrato a un canale di release.
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 su una versione precedente. Ti consigliamo di sbloccare la migrazione il prima possibile e di eseguire l'upgrade dei nodi alla versione 1.24. Le versioni minori che hanno raggiunto la fine del supporto non riceveranno più patch di sicurezza e correzioni di bug.
Esegui la migrazione da Docker alle immagini dei nodi containerd
Consulta la sezione Eseguire la migrazione da Docker a immagini dei nodi 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 containerd.
Nell'ambito del modello di responsabilità condivisa GKE, rientra nelle responsabilità del cliente mantenere l'integrità dei carichi di lavoro e nelle responsabilità di Google garantire che il cluster rimanga funzionale, il che include l'esecuzione di una versione supportata. Ti consigliamo vivamente di testare i carichi di lavoro ed eseguire la migrazione del cluster prima che GKE lo faccia automaticamente.
Prima del termine del supporto della versione 1.23, 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 da utilizzare solo immagini containerd, gli upgrade automatici possono riprendere entro un giorno, in base alla pianificazione dei rilasci di GKE, oppure puoi eseguire l'upgrade manuale del cluster.
Dopo la fine del supporto della versione 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 ha dipendenze dal runtime del contenitore. Il runtime Docker implementa anche containerd, pertanto i tuoi carichi di lavoro si comportano in modo simile sulle immagini dei nodi containerd.
La situazione potrebbe interessarti se si applicano 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 ai log specifici di Docker nel sistema di monitoraggio.
- Esegui il deployment di strumenti di logging, monitoraggio, sicurezza o integrazione continua fornito da fornitori esterni nel tuo cluster GKE. Contatta questi fornitori per confermare l'impatto.
La modifica non ti interessa nelle seguenti situazioni:
- Hai una pipeline di compilazione al di fuori del cluster GKE che utilizza Docker per creare e spingere le immagini container.
- Utilizzi i comandi
docker buildedocker pushnel tuo 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 con privilegi, devi aggiornare questi workload in modo che non si basino direttamente su Docker. Ad esempio, valuta la possibilità di eseguire 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 di Docker in modo da poter utilizzare Docker per creare e spingere le immagini. Tuttavia, non consigliamo di utilizzare singoli contenitori e nodi locali per eseguire comandi per la creazione di immagini.
Kubernetes non è a conoscenza delle risorse di sistema utilizzate da processi locali al di fuori dell'ambito di Kubernetes e il piano di controllo di Kubernetes non può tener conto di queste operazioni durante l'allocazione delle risorse. Ciò può causare una carenza di risorse per i carichi di lavoro GKE o instabilità sul nodo.
Valuta la possibilità di svolgere queste attività utilizzando altri servizi esterni all'ambito del singolo contenitore, come Cloud Build, oppure uno strumento come kaniko per creare immagini come carico di lavoro Kubernetes.
Se nessuno di questi suggerimenti funziona e conosci i rischi, puoi continuare a utilizzare Docker sul nodo locale per creare le immagini. Devi spingere le immagini in un registry prima di poterle utilizzare in un cluster GKE. Kubernetes con containerd non è a conoscenza delle immagini create localmente utilizzando Docker.
Eseguire il 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 i container
e le immagini, leggere i log ed eseguire comandi nei container. Consulta la guida dell'utente di crictl per l'insieme completo delle funzionalità supportate e le informazioni sull'utilizzo.
Per i nodi Windows Server, il daemon containerd viene eseguito come servizio Windows chiamato 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 alle immagini dei nodi containerd.