Diese Seite enthält Informationen zu Knoten-Images, die containerd als Containerlaufzeit in Ihren GKE-Knoten (Google Kubernetes Engine) verwenden.
containerd
Als Software ist die Containerlaufzeit dafür zuständig, Container auszuführen und die Containerverwaltung für Kubernetes auszuführen. Es gibt verschiedene Containerlaufzeiten.
Die containerd-Laufzeit ist eine dem Branchenstandard entsprechende Containerlaufzeit, die von Kubernetes unterstützt und von vielen anderen Projekten verwendet wird. Die containerd-Laufzeit bietet die Schichtenabstraktion, die die Implementierung einer Vielzahl von Features wie gVisor und Image-Streaming ermöglicht, um die GKE-Funktionalität zu erweitern.
Die containerd-Laufzeit gilt als ressourceneffizienter und sicherer als die Docker-Laufzeit.
containerd-Images in GKE-Clustern verwenden
Wenn Sie einen neuen GKE-Cluster, einen neuen Knotenpool in einem vorhandenen Cluster erstellen oder einen vorhandenen Cluster aktualisieren, können Sie ein containerd-Knoten-Image verwenden. GKE Autopilot-Cluster verwenden immer Container-Optimized OS mit containerd.
In der folgenden Tabelle werden die unterstützten containerd-Knoten-Images anhand des Clustermodus und des Betriebssystems des Knotenpools dargestellt:
Clustermodus | Betriebssystem des Knotenpools | Knotenimage |
---|---|---|
Autopilot | Linux | cos_containerd |
Standard | Linux |
|
Standard | Windows Server |
Diese Images erfordern die GKE-Version 1.21.1-gke.2200 oder höher. |
Privilegierte Pods für den Zugriff auf Docker verwenden
Wenn Ihre Nutzer über einen privilegierten Pod auf die Docker Engine auf einem Knoten zugreifen, sollten Sie diese Arbeitslasten aktualisieren, damit keine direkte Abhängigkeit von Docker besteht. Beispielsweise können Sie den Logging- und Monitoring-Extraktionsprozess von Docker Engine zu GKE-System-Add-ons migrieren.
Container-Images mit containerd erstellen
Sie können containerd nicht verwenden, um Container-Images zu erstellen. Linux-Images mit containerd enthalten die Docker-Binärdatei, sodass Sie Docker zum Erstellen und Übertragen von Images verwenden können. Es wird jedoch nicht empfohlen, einzelne Container und lokale Knoten zum Ausführen von Befehlen zum Erstellen von Images zu verwenden.
Kubernetes kennt keine Systemressourcen, die von lokalen Prozessen außerhalb des Bereichs von Kubernetes verwendet werden. Die Steuerungsebene von Kubernetes kann diese Prozesse bei der Ressourcenzuteilung ebenfalls nicht berücksichtigen. Das kann zu einem Mangel an Ressourcen für Ihre GKE-Arbeitslasten führen oder Instabilitäten auf dem Knoten verursachen.
Erwägen Sie, diese Aufgaben mit anderen Diensten außerhalb des Bereichs des einzelnen Containers auszuführen, z. B. mit Cloud Build. Sie können auch ein Tool wie Kaniko verwenden, um Images als Kubernetes-Arbeitslast zu erstellen.
Wenn keiner dieser Vorschläge für Sie geeignet ist und Sie die Risiken verstehen, können Sie Docker weiterhin auf dem lokalen Knoten verwenden, um Images zu erstellen. Sie müssen die Images in eine Registry verschieben, bevor Sie sie in einem GKE-Cluster verwenden können. Kubernetes mit containerd nimmt keine Images wahr, die lokal mit Docker erstellt wurden.
Container auf containerd-Knoten debuggen
Zum Debugging und zur Problembehebung auf Linux-Knoten können Sie mithilfe des speziell für Kubernetes-Containerlaufzeiten erstellten portablen Befehlszeilentools mit containerd interagieren: crictl
crictl
unterstützt allgemeine Funktionen, mit denen Sie Container und Images aufrufen, Logs lesen und Befehle in den Containern ausführen können. Im Nutzerhandbuch für crictl finden Sie alle unterstützten Funktionen und Informationen zu deren Nutzung.
Bei Windows Server-Knoten wird der Containerd-Daemon als Windows-Dienst mit dem Namen containerd
ausgeführt.
Logs sind so verfügbar:
- Windows:
C:\etc\kubernetes\logs\containerd.log
- Linux:
journalctl -u containerd
ausführen
Sie können auch Logs für Windows- und Linux-Knoten im Log-Explorer unter LOG NAME: "container-runtime"
aufrufen.
Bekannte Probleme und Fehlerbehebung
Informationen zur Fehlerbehebung und zu bekannten Problemen bei Problemumgehungen finden Sie unter Fehlerbehebung für die Containerlaufzeit.
Nächste Schritte
- Mehr zur containerd-Integration erfahren Sie in der Ankündigung zu Kubernetes 1.11. Noch mehr Informationen finden Sie in der Dokumentation zu containerd und zu den CRI-Plug-ins.
- Prüfen Sie die Migration von dockershim auf kubernetes.io.
- Hier erfahren Sie mehr über die Einstellung von Dockershim durch Kubernetes.
- Hier finden Sie Informationen zum Schützen Ihrer Anwendungen mit gVisor in containerd.
- Hier erfahren Sie mehr über die Vorteile von Cloud Build, wenn Sie in Google Cloud sicher und zuverlässig Images erstellen möchten, um eine benutzerdefinierte Lösung zu ersetzen, die möglicherweise Docker erfordert.