Questa pagina fornisce informazioni sulle immagini dei nodi che utilizzano containerd come runtime dei container nei nodi di 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. Ci sono vari tipi di container runtime.
Il runtime containerd è uno standard di settore il runtime del container, supportato da Kubernetes e utilizzato da molte altri progetti. Il runtime containerd fornisce l'astrazione per livelli consente l'implementazione di un ricco insieme di funzionalità come gVisor e Streaming di immagini per estendere le funzionalità di GKE.
Il runtime containerd è considerato più sicuro ed efficiente in termini di risorse rispetto il runtime Docker.
Utilizzo delle 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 usano sempre Container-Optimized OS con containerd.
La tabella seguente descrive le immagini dei nodi containerd supportate in base modalità cluster e nodo sistema operativo pool:
| Modalità cluster | Sistema operativo 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 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".
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
- Scopri di più sull'integrazione containerd nell'annuncio di Kubernetes 1.11. Per ulteriori informazioni, consulta la documentazione per containerd e i plug-in CRI.
- Esamina la migrazione dalle informazioni di 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 la creazione di immagini in modo sicuro e affidabile su Google Cloud per sostituire una soluzione personalizzata che potrebbero richiedere Docker.