Questa pagina fornisce informazioni sul runtime dei containerd, per Docker in Google Kubernetes Engine (GKE) e una panoramica dei motivi per cui è necessario 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 di 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 per comunicare con i componenti di Kubernetes come il kubelet.
Containerd, il nuovo runtime predefinito, è un il runtime dei container standard del settore, supportato da Kubernetes e utilizzato molti altri progetti. Il runtime containerd fornisce l'astrazione per livelli che consente l'implementazione di un ricco insieme di funzionalità come gVisor e Streaming di immagini per estendere 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 in GKE 1.24 e versioni successive. 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 controllo del cluster a GKE 1.24 e versioni successive prima di questa data, devi aggiornare la configurazione del provisioning automatico dei nodi e tutti i nodi al containerd runtime. 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 è stato il runtime predefinito per tutti i nuovi nodi GKE dalla 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) |
LTSC di Windows Server con Docker (windows_ltsc) |
LTSC Windows Server con containerd (windows_ltsc_containerd) |
SAC di Windows Server con Docker ( |
SAC di Windows Server con containerd ( |
Timeline e traguardi
In GKE versione 1.23, non puoi più effettuare le seguenti operazioni:
- 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.
- Abilita il provisioning automatico dei nodi con il flag
--autoprovisioning-image-typeper le immagini dei nodi basate su Docker.
Se stai eseguindo l'upgrade a GKE versione 1.23, 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-typeimpostato su Immagini dei nodi basate su Docker, se abilitate 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 tabella seguente fornisce un riepilogo delle modifiche previste quando interagisci con le prossime 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 |
| 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 ed esegui la migrazione alle immagini dei nodi containerd prima che la versione 1.23 raggiunga la fine del ciclo di vita il 31 luglio 2023, esegue le seguenti operazioni nel tempo:
Se nel cluster è disponibile il provisioning automatico dei nodi con un'immagine del nodo predefinita basata su Docker tipo, GKE aggiorna la configurazione in modo da utilizzare il nodo equivalente immagine 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 che GKE avvii un'operazione per la migrazione per utilizzare le immagini containerd. Per effettuare questa richiesta, contatta 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 l'articolo Posticipare temporaneamente il servizio la migrazione automatica alle immagini dei nodi containerd.
GKE esegue l'upgrade dei pool di nodi dalla versione 1.23 alla versione 1.24, come viene fatto con qualsiasi versione non supportata per garantire l'allineamento dell'integrità del cluster con 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.
Posticipa 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 avere l'idoneità per questa esclusione di manutenzione, il cluster deve essere registrato in
una release
di destinazione.
Configura l'esclusione di manutenzione con il pulsante "Nessun upgrade secondario o dei nodi"
ambito,
e imposta il flag --add-maintenance-exclusion-end su 2024-02-29T00:00:00Z o
in precedenza. Ti consigliamo di sbloccare la migrazione il prima possibile e
consente 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 da Docker alle immagini dei nodi 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 di GKE, Rientra nelle responsabilità del cliente per mantenere l'integrità dei carichi di lavoro ed è responsabilità di Google garantire che il cluster rimane funzionante, inclusa l'esecuzione di una versione supportata. Abbiamo consigliamo di testare i carichi di lavoro ed eseguire la migrazione del cluster prima GKE esegue automaticamente questa operazione.
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 gestire più a lungo il ciclo di vita dei container, ad esempio avviando e arrestando questi). Di conseguenza non puoi utilizzare i comandi Docker o l'API Docker per visualizzare o interagiscono con container GKE in esecuzione su nodi che utilizzano containerd in formato Docker.
La maggior parte dei carichi di lavoro degli utenti non ha una dipendenza dal runtime dei container. Il Docker il runtime implementa anche containerd, quindi i carichi di lavoro si comportano in modo simile immagini dei nodi containerd.
Potrebbero interessarti le seguenti situazioni:
- Esegui pod con privilegi che eseguono comandi Docker.
- Esegui script su nodi esterni all'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 monitoraggio di un sistema operativo completo.
- 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:
- Hai una pipeline di build esterna al cluster GKE 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 è possibile utilizzare containerd per creare immagini container. immagini Linux con containerd includono il file binario Docker per consentirti di usare Docker per creare eseguire il push delle immagini. Tuttavia, sconsigliamo di utilizzare container singoli e nodi per eseguire comandi e creare immagini.
Kubernetes non è a conoscenza delle risorse di sistema utilizzate dai processi locali al di fuori Kubernetes e il piano di controllo Kubernetes non può tenerne conto durante l'allocazione delle risorse. Questo può esaurire le risorse GKE carichi di lavoro di risorse 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 eseguire il push in un registro prima di poterle utilizzare in un cluster GKE. Kubernetes con containerd non è a conoscenza delle immagini create localmente con Docker.
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.
sotto 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.
- Eseguire la migrazione da Docker alle immagini dei nodi containerd.