Questa pagina fornisce informazioni sulle immagini dei nodi che utilizzano containerd come runtime dei container nei nodi Google Kubernetes Engine (GKE).
Informazioni su containerd
Il runtime del container è il software responsabile dell'esecuzione dei container e astrae la gestione dei container per Kubernetes. Esistono diversi runtime container.
Il runtime containerd è un runtime di container standard di settore supportato da Kubernetes e utilizzato da molti altri progetti. Il runtime containerd fornisce l'astrazione di livelli che consente l'implementazione di un ricco set di funzionalità come gVisor e streaming di immagini per estendere la funzionalità di GKE.
Il runtime containerd è considerato più sicuro e efficiente in termini di risorse rispetto al runtime Docker.
Utilizzo delle 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 container. I cluster GKE Autopilot usano sempre Container-Optimized OSr con containerd.
La seguente tabella descrive le immagini dei nodi containerd supportate in base alla tua 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 |
|
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 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 ci sia un affidamento diretto su Docker. Ad esempio, valuta la possibilità di eseguire la migrazione del processo di estrazione di logging e monitoraggio dai componenti aggiuntivi del sistema Docker Engine ai componenti aggiuntivi del sistema GKE.
Creazione di 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 da 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. Questo può esaurire i carichi di lavoro GKE o causare instabilità sul nodo.
Valuta la possibilità di eseguire queste attività utilizzando altri servizi al di fuori dell'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 di
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 Risolvere i problemi relativi al runtime dei container.
Passaggi successivi
- Scopri di più sull'integrazione di containerd nell'annuncio relativo a Kubernetes 1.11. Per ulteriori informazioni, consulta la documentazione relativa a containerd e ai plug-in CRI.
- Esamina le informazioni sulla migrazione da Dockershim su kubernetes.io.
- Scopri di più sul ritiro di Dockershim da parte di Kubernetes.
- Scopri come proteggere le tue app con gVisor su containerd.
- Scopri i vantaggi dell'utilizzo di Cloud Build per creare immagini in modo sicuro e affidabile su Google Cloud per sostituire una soluzione personalizzata che potrebbe richiedere Docker.