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. A questo scopo, Kubernetes sta rimuovendo un componente chiamato dockershim, che consente a Docker di che comunicano con i componenti di Kubernetes come il 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. Anche il runtime è considerato più risorse efficiente e sicuro rispetto al runtime 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 è interessati se uno qualsiasi dei suoi pool di nodi utilizza immagini dei nodi basate su Docker o node il provisioning automatico Immagine del nodo predefinita basata su Docker .
Prima del 31 luglio 2023, la fine del ciclo di vita di GKE 1.23 data, GKE mette in pausa automatico upgrade 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 dei nodi che utilizzi il runtime containerd.
Quando la versione 1.23 ha raggiunto la fine del ciclo di vita, GKE sblocca il controllo manuale degli upgrade dei piani alla versione 1.24 per i cluster la cui migrazione non è stata ancora completata, inizia gradualmente l'upgrade dei cluster per motivi di sicurezza e compatibilità. Per scoprire di più su come GKE dei cluster alla versione 1.24 e ti consigliamo di eseguire la migrazione cluster dalle immagini dei nodi Docker, vedi Migrazione automatica se 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, GKE I cluster standard continuavano inoltre a supportare le immagini dei nodi che utilizzavano Docker come runtime. La tabella seguente descrive le immagini dei nodi basate su Docker che non sarà supportato in GKE 1.24 e versioni successive. Inoltre, equivalenti 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 ( |
Tempistiche e traguardi
Nella versione 1.23 di GKE, non puoi più:
- Crea 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 creati prima dell'upgrade.
- Gestore della scalabilità automatica dei cluster sui 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.
In GKE versione 1.24, non puoi più effettuare le seguenti operazioni:
- Se il piano di controllo esegue la versione 1.24, non puoi utilizzare il nodo
provisioning automatico con il flag
--autoprovisioning-image-typeimpostato su di immagini dei nodi basate su Docker. - Se il pool di nodi esegue la versione 1.24, i nodi non possono utilizzare il nodo basato su Docker in formato 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 | GKE versione 1.24 |
|---|---|---|
| Crea nuovi cluster con Docker | No | No |
| Crea 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 |
| Usa 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 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 e un'esclusione dalla manutenzione. Per verificare che non ci siano effetti negativi sui tuoi carichi di lavoro, consigliamo di aggiornare manualmente il provisioning automatico dei nodi predefinito su un'immagine basata su containerd prima di GKE aggiorna automaticamente la configurazione.
GKE esegue l'upgrade del piano di controllo del cluster alla versione 1.24.
GKE esegue la migrazione di tutti i pool di nodi che utilizzano ancora Docker immagini dei nodi containerd a partire dal 1° settembre 2023. 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 da utilizzare le immagini containerd. Per effettuare questa richiesta, contatta l' assistenza clienti Google Cloud.
Per bloccare temporaneamente la migrazione automatica, esegui l'upgrade del cluster a versione 1.24 o successive e configurare una rete di un'esclusione. 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 al disallineamento delle versioni open source. Per saperne di più, vedi la durata della versione secondaria di GKE ciclo di lancio. Puoi bloccare temporaneamente questo upgrade con un'esclusione della manutenzione.
Ritarda temporaneamente la migrazione automatica alle immagini dei nodi containerd
Dopo l'upgrade del piano di controllo del cluster alla versione 1.24 o successive, puoi
configurare un'esclusione di manutenzione
per impedire temporaneamente la migrazione dei nodi fino al 29 febbraio 2024,
quando la versione 1.25 raggiunge
alla fine del supporto.
Per poter usufruire di questa esclusione dalla manutenzione, il cluster deve essere registrato a un canale di rilascio.
Configura l'esclusione dalla manutenzione con l'ambito "Nessun upgrade secondario o di 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
per consentire l'upgrade dei nodi alla versione 1.24. Versioni secondarie che hanno raggiunto
alla fine del supporto non riceverà più patch di sicurezza e correzioni di bug.
Esegui la migrazione dalle immagini dei nodi Docker a quelle containerd
Consulta Eseguire la migrazione da Docker a immagini dei nodi containerd per identificare cluster e pool di nodi utilizzando le immagini dei nodi basate su Docker ed eseguire la migrazione 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 della fine del supporto della versione 1.23, GKE impedisce upgrade alla versione 1.24 per i cluster che hanno pool di nodi che utilizzano nodi Docker in formato Docker. Dopo aver eseguito la migrazione del cluster per utilizzare solo immagini container, gli upgrade possono riprendere entro un giorno, in base al calendario delle release di GKE, oppure puoi eseguire manualmente l'upgrade del cluster.
Alla fine del supporto della versione 1.23, GKE sblocca lo sblocco automatico o manuale esegue l'upgrade alla versione 1.24 e segue la migrazione automatica e il processo di sviluppo.
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 Docker il runtime implementa anche containerd, quindi i carichi di lavoro si comportano in modo simile immagini dei nodi containerd.
Potresti essere interessato 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 da fornitori esterni nel tuo cluster GKE. Contatto questi fornitori per confermare l'impatto.
Le seguenti situazioni non ti riguardano:
- All'esterno del cluster GKE hai una pipeline di build che utilizza Docker per creare ed eseguire il push delle immagini container.
- Usi i comandi
docker buildedocker pushnel tuo cluster GKE in un cluster Kubernetes. Le immagini dei nodi Linux con containerd includono il file binario Docker supportano questi comandi.
Utilizzo di pod con privilegi per accedere a Docker
Se gli utenti accedono a Docker Engine su un nodo utilizzando un pod con privilegi, aggiornare i carichi di lavoro in modo da non fare affidamento diretto su Docker. Per Ad esempio, valuta la possibilità di eseguire la migrazione del processo di estrazione di logging e monitoraggio Componenti aggiuntivi di sistema da Docker Engine a 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 causare instabilità sul nodo.
Potresti svolgere queste attività utilizzando altri servizi che non rientrano nell'ambito del un singolo container, come Cloud Build, oppure utilizzare uno strumento come Kaniko per creare immagini come carico di lavoro Kubernetes.
Se nessuno di questi suggerimenti funziona e comprendi i rischi, puoi continuare a utilizzare Docker sul nodo locale per creare 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 con Docker.
Eseguire il debug dei container sui nodi containerd
Per eseguire il debug o la risoluzione dei problemi sui nodi Linux, puoi interagire
utilizzando lo strumento a riga di comando portatile creato per il container Kubernetes
runtime: crictl. crictl supporta funzionalità comuni per visualizzare i container
e le immagini, leggere i log ed eseguire comandi nei container. Consulta le
guida dell'utente crictl
per l'insieme completo delle funzionalità supportate e delle 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, consulta Risolvere i problemi relativi al runtime containerd.
Passaggi successivi
- Scopri di più sul ritiro di Dockershim.
- Verifica se il ritiro ti riguarda.
- Esegui la migrazione dalle immagini dei nodi Docker a quelle containerd.