Immagini dei nodi containerd


Questa pagina fornisce informazioni sulle immagini dei nodi che utilizzano containerd come runtime del container nei nodi Google Kubernetes Engine (GKE).

Informazioni su containerd

Il runtime del container è un software responsabile dell'esecuzione dei container, mentre la gestione dei container per Kubernetes. Esistono diversi tipi di runtime dei contenitori.

Il runtime containerd è uno standard di settore il runtime del container supportato da Kubernetes e usato da molte 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 containerd è considerato più sicuro ed efficiente in termini di risorse rispetto il runtime Docker.

Utilizzo di immagini containerd nei cluster GKE

Quando crei un nuovo cluster GKE, viene creato un nuovo pool di nodi in o quando esegui l'upgrade di un cluster esistente, puoi scegliere di utilizzare l'immagine del nodo containerd. I cluster GKE Autopilot utilizzano sempre Container-Optimized OS con containerd.

La tabella seguente descrive le immagini dei nodi containerd supportate in base alla modalità cluster e al sistema operativo del pool di nodi:

Modalità cluster Sistema operativo del pool di nodi Immagine del nodo
Pilota automatico Linux cos_containerd
Standard Linux
  • cos_containerd
  • ubuntu_containerd
Standard Windows Server

Queste immagini richiedono GKE versione 1.21.1-gke.2200 o successiva.

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. 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 è possibile 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 dai processi locali al di fuori Kubernetes e il piano di controllo Kubernetes non può tenerne conto durante l'allocazione delle risorse. Ciò può causare una carenza di risorse per i carichi di lavoro GKE o causare 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 eseguire il push in un registro 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 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 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".

Problemi noti e risoluzione dei problemi

Per la risoluzione dei problemi e per i problemi noti relativi alle soluzioni alternative, consulta Risoluzione dei problemi relativi al runtime del container.

Passaggi successivi