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 e astrae la gestione dei container per Kubernetes. Esistono diversi runtime dei container.

Il runtime containerd è un runtime del container standard di settore supportato da Kubernetes e utilizzato da molti altri progetti. Il runtime containerd fornisce l'astrazione di layering che consente l'implementazione di un ricco insieme di funzionalità come gVisor e Image streaming per estendere la funzionalità di GKE.

Il runtime containerd è considerato più efficiente in termini di risorse e più sicuro del runtime Docker.

Utilizzo di immagini containerd nei cluster GKE

Quando crei un nuovo cluster GKE, un nuovo pool di nodi in un cluster esistente o quando esegui l'upgrade di un cluster esistente, puoi scegliere di utilizzare un'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 node pool Immagine del nodo
Autopilot Linux cos_containerd
Standard Linux
  • cos_containerd
  • ubuntu_containerd
Standard Windows Server

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

Utilizzo di pod con privilegi per accedere a Docker

Se i tuoi utenti accedono a Docker Engine su un nodo utilizzando un pod privilegiato, devi aggiornare questi carichi di lavoro in modo che non dipendano direttamente da Docker. Ad esempio, valuta 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 Docker, in modo da poter utilizzare Docker per creare e trasferire immagini. Tuttavia, non consigliamo di utilizzare singoli container e nodi locali per eseguire comandi per 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ò tenere conto di questi processi durante l'allocazione delle risorse. Ciò può privare i carichi di lavoro GKE di risorse o causare instabilità sul nodo.

Valuta la possibilità di eseguire queste attività utilizzando altri servizi al di fuori dell'ambito del singolo container, ad esempio 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 comprendi i 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 riconosce le 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 di funzionalità supportate e 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".

Problemi noti e risoluzione dei problemi

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

Passaggi successivi