Informazioni sul ritiro delle immagini dei nodi Docker

Standard

Questa pagina fornisce informazioni sul runtime dei container containerd, sul supporto per Docker in Google Kubernetes Engine (GKE) e una panoramica sui motivi per cui devi eseguire la migrazione alle immagini dei nodi che utilizzano containerd. Per istruzioni su come eseguire la migrazione a un'immagine dei nodi 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 ottenere questo risultato, 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 di container 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 ricco set di funzionalità come gVisor e Streaming di immagini per estendere le funzionalità di GKE. Inoltre, il runtime è considerato più sicuro e efficiente nell'uso delle risorse rispetto a 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 pool di nodi utilizza immagini dei nodi basate su Docker o se utilizza il provisioning automatico dei nodi con un tipo di immagine predefinito basato su Docker.

Prima del 31 luglio 2023, data di fine del 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 dei nodi che utilizza il runtime containerd.

Una volta raggiunta la fine del ciclo di vita della versione 1.23, 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 l'upgrade gradualmente 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 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 dalla 1.21 su Windows. Tuttavia, i cluster GKE Standard hanno continuato a supportare anche le immagini dei nodi che utilizzavano Docker come runtime. La seguente tabella descrive le immagini dei nodi basate su Docker che non saranno supportate in GKE 1.24 e versioni successive e gli 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 (`windows_sac`)	SAC di Windows Server con containerd (`windows_sac_containerd`)

Timeline e traguardi

In GKE versione 1.23, non puoi più effettuare le seguenti operazioni:

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.
Abilita il provisioning automatico dei nodi con il flag --autoprovisioning-image-type impostato su immagini dei nodi basate su Docker.

Se esegui 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.
Provisioning automatico dei nodi con il flag --autoprovisioning-image-type impostato 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 provisioning automatico dei nodi con il flag --autoprovisioning-image-type impostato 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 seguente tabella fornisce un riepilogo delle modifiche previste quando interagisci con le future versioni di GKE:

Azione	GKE versione 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
Esegui l'upgrade dalla versione precedente con la configurazione di provisioning automatico dei nodi Docker esistente	Sì	No
Utilizza 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 ed esegui la migrazione alle immagini dei nodi containerd prima che la versione 1.23 abbia raggiunto la fine del ciclo di vita il 31 luglio 2023, GKE esegui le seguenti operazioni nel tempo:

Se il cluster dispone del provisioning automatico dei nodi con un tipo di immagine dei nodi predefinito basato 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 di manutenzione. Per verificare che non vi siano effetti negativi sui carichi di lavoro, ti consigliamo di aggiornare manualmente il tipo di immagine predefinito per il provisioning automatico dei nodi a un'immagine basata su containerd prima che GKE aggiorni automaticamente la configurazione.
GKE esegue l'upgrade del piano di controllo del tuo cluster alla versione 1.24.
A partire dal 1° settembre 2023, GKE esegue la migrazione di tutti i pool di nodi che usano 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 richiedere che GKE avvii un'operazione per eseguire la migrazione del tuo cluster per 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 alla versione 1.24 o successiva e configura un'esclusione di manutenzione. Per ulteriori informazioni su questa esclusione dalla manutenzione, consulta Posticipare temporaneamente la migrazione automatica alle immagini dei nodi containerd.
GKE esegue l'upgrade dei pool di nodi dalla versione 1.23 alla versione 1.24, così come per qualsiasi versione non supportata, per garantire l'allineamento dell'integrità del cluster con il criterio per il disallineamento delle versioni open source. Per saperne di più, consulta il ciclo di vita della versione secondaria di GKE. Puoi bloccare temporaneamente questo upgrade con un'esclusione di 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 successiva, puoi configurare un'esclusione di manutenzione per impedire temporaneamente la migrazione dei nodi fino al 29 febbraio 2024, quando la versione 1.25 raggiungerà la fine del ciclo di vita. Per essere idoneo per questa esclusione di manutenzione, il cluster deve essere registrato in un canale di rilascio. Configura l'esclusione della manutenzione con l'ambito "Nessun upgrade dei nodi o secondari" e imposta il flag --add-maintenance-exclusion-end su 2024-02-29T00:00:00Z o su una data precedente. Ti consigliamo di sbloccare la migrazione il prima possibile e di consentire l'upgrade dei nodi alla versione 1.24. Le versioni secondarie che hanno raggiunto la fine del ciclo di vita non riceveranno più patch di sicurezza e correzioni di bug.

Esegui la migrazione da Docker alle immagini dei nodi containerd

Consulta Eseguire la migrazione da Docker alle immagini dei nodi containerd per identificare i cluster e i pool di nodi utilizzando le 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 di GKE, fa parte delle responsabilità del cliente mantenere l'integrità dei carichi di lavoro; inoltre, fa parte delle responsabilità di Google per garantire che il cluster rimanga funzionante, inclusa l'esecuzione di una versione supportata. Ti consigliamo vivamente di testare i carichi di lavoro e di eseguire la migrazione del cluster prima che GKE lo faccia automaticamente.

Prima della fine del ciclo di vita della versione 1.23, GKE impedisce gli upgrade automatici o manuali alla versione 1.24 per i cluster che hanno pool di nodi che utilizzano immagini dei nodi Docker. Dopo aver eseguito la migrazione del cluster per utilizzare solo immagini containerd, gli upgrade automatici possono riprendere entro un giorno, in base alla pianificazione delle release di GKE, oppure puoi eseguire manualmente l'upgrade del cluster.

Dopo la fine del ciclo di vita della versione 1.23, GKE sblocca gli upgrade automatici o manuali alla versione 1.24 e segue il processo 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). Di conseguenza, non puoi utilizzare i comandi Docker o l'API Docker per visualizzare o interagire con i container GKE in esecuzione sui nodi che utilizzano immagini containerd.

La maggior parte dei carichi di lavoro degli utenti non ha una dipendenza dal runtime del container. Il runtime Docker implementa anche containerd, in modo che i carichi di lavoro si comportino in modo simile sulle immagini dei nodi containerd.

Potrebbero essere interessati se si verificano le seguenti situazioni:

Esegui pod con privilegi che eseguono comandi Docker.
Gli script vengono eseguiti 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 per Docker nel tuo sistema di monitoraggio.
Esegui il deployment nel tuo cluster GKE di strumenti di logging, monitoraggio, sicurezza o integrazione continua forniti da fornitori esterni. Contatta questi fornitori per confermarne l'impatto.

Non ti riguarda nelle seguenti situazioni:

Disponi di una pipeline di build esterna al cluster GKE che utilizza Docker per creare ed eseguire il push delle immagini container.
Puoi utilizzare i comandi docker build e docker push nel cluster GKE. Le immagini dei nodi Linux con containerd includono il programma 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 carichi di lavoro in modo che non facciano affidamento diretto 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.

crea immagini container con containerd

Non puoi utilizzare containerd per creare immagini container. Le immagini Linux con containerd includono il programma binario Docker, in modo da poter utilizzare Docker per creare ed eseguire il push delle immagini. Tuttavia, sconsigliamo di utilizzare container singoli e nodi locali per eseguire comandi al fine di 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ò tenerne conto durante l'allocazione delle risorse. Questo può esaurire i carichi di lavoro di risorse GKE o causare instabilità sul nodo.

Valuta la possibilità di eseguire queste attività utilizzando altri servizi esterni all'ambito del singolo container, come 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 sei consapevole dei 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 è a conoscenza delle 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 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: esecuzione journalctl -u containerd

Puoi visualizzare i log per i nodi Windows e Linux anche in Esplora log in LOG NAME: "container-runtime".

Risoluzione dei problemi

Per la risoluzione dei problemi, vedi Risolvere i problemi relativi al runtime containerd.