Einstellung des Docker-Knoten-Images

Standard

Diese Seite enthält Informationen zur containerd-Containerlaufzeit, zur Unterstützung für Docker in Google Kubernetes Engine (GKE) sowie einen Überblick darüber, warum Sie zu Knoten-Images migrieren müssen, die containerd verwenden. Eine Anleitung zum Migrieren zu einem containerd-Knoten-Image finden Sie unter Von Docker zu containerd-Knoten-Images migrieren.

Überblick

Kubernetes-Knoten verwenden die Containerlaufzeit, um Container zu starten, zu verwalten und zu beenden, die in Pods ausgeführt werden. Das Kubernetes-Projekt entfernt die integrierte Unterstützung für die Docker-Laufzeit in Kubernetes Version 1.24 und höher. Dazu entfernt Kubernetes eine Komponente namens dockershim, die Docker ermöglicht, mit Kubernetes-Komponenten wie kubelet zu kommunizieren.

Containerd, die neue Standardlaufzeit, 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 Laufzeit gilt auch als ressourceneffizienter und sicherer als die Docker-Laufzeit.

Aufgrund dieser Änderung unterstützt GKE keine Knoten-Images, die Docker als Laufzeit in der GKE-Version 1.24 und höher verwenden. Ein Cluster ist betroffen, wenn einer seiner Knotenpools Docker-basierte Knoten-Images oder die automatische Knotenbereitstellung mit einem Docker-basierten Knoten-Image-Standardtyp verwendet.

Vor dem 31. Juli 2023, dem Ende des Produktzyklus für die GKE-Version 1.23, pausiert GKE automatische Upgrades und verhindert manuelle Upgrades auf Version 1.24. Wenn Sie die Steuerungsebene Ihres Clusters vor diesem Datum auf GKE-Version 1.24 und höher upgraden möchten, müssen Sie die Konfiguration der automatischen Knotenbereitstellung und alle Knoten auf die containerd-Laufzeit aktualisieren. Zum Upgraden eines Knotenpools müssen Sie zu einem Knoten-Image migrieren, das die containerd-Laufzeit verwendet.

Nachdem 1.23 das Ende des Produktzyklus erreicht hat, hebt GKE die Blockierung von manuellen Upgrades der Steuerungsebene auf 1.24 für Cluster auf, die noch nicht migriert wurden. Die Upgrades der Cluster erfolgen aus Sicherheitsgründen und Kompatibilitätszwecken schrittweise. Weitere Informationen dazu, wie GKE Ihre Cluster auf 1.24 aktualisiert und wie Sie Ihre Cluster von Docker-Knoten-Images migrieren sollten, finden Sie unter Automatische Migration, wenn Version 1.23 das Ende des Produktzyklus erreicht.

Docker- und containerd-Knoten-Images

Containerd ist seit Version 1.19 unter Linux und Version 1.21 unter Windows die Standardlaufzeit für alle neuen GKE-Knoten. GKE-Standardcluster unterstützen jedoch weiterhin Knoten-Images, die Docker als Laufzeit verwendet haben. In der folgenden Tabelle werden die Docker-basierten Knoten-Images beschrieben, die in GKE-Version 1.24 und höher nicht unterstützt werden, sowie die Entsprechungen in containerd:

Docker-Laufzeit	containerd-Laufzeit
Container-Optimized OS mit Docker (`cos`)	Container-Optimized OS mit containerd (`cos_containerd`)
Ubuntu mit Docker (`ubuntu`)	Ubuntu mit containerd (`ubuntu_containerd`)
Windows Server LTSC mit Docker (`windows_ltsc`)	Windows Server LTSC mit containerd (`windows_ltsc_containerd`)
Windows Server SAC mit Docker (`windows_sac`)	Windows Server SAC mit containerd (`windows_sac_containerd`)

Zeitachse und Meilensteine

In GKE-Version 1.23 ist Folgendes nicht mehr möglich:

Neue Cluster erstellen, die Docker-basierte Knoten-Images verwenden
Neue Knotenpools mit Docker-basierten Knoten-Images zu einem vorhandenen Cluster hinzufügen
Automatische Knotenbereitstellung aktivieren, wobei das Flag --autoprovisioning-image-type auf Docker-basierte Knoten-Images festgelegt ist

Wenn Sie ein Upgrade auf GKE-Version 1.23 durchführen, können Sie mit Folgendem fortfahren:

Vorhandene Knotenpools mit Docker-basierten Knoten-Images, die vor dem Upgrade erstellt wurden
Cluster-Autoscaler in Knotenpools mit Docker-Knoten-Images
Automatische Knotenbereitstellung mit dem Flag --autoprovisioning-image-type, das auf Docker-basierte Knoten-Images festgelegt ist, falls vor dem Upgrade aktiviert

In GKE-Version 1.24 ist Folgendes nicht mehr möglich:

Wenn auf der Steuerungsebene Version 1.24 ausgeführt wird, können Sie die automatisierte Knotenbereitstellung nicht verwenden, wenn das Flag --autoprovisioning-image-type auf Docker-basierte Knoten-Images festgelegt ist.
Wenn der Knotenpool Version 1.24 ausführt, können die Knoten keine Docker-basierten Knoten-Images verwenden.

Die folgende Tabelle enthält eine Zusammenfassung der Änderungen, die bei der Interaktion mit geplanten GKE-Versionen zu erwarten sind:

Aktion	GKE-Version 1.23	GKE-Version 1.24
Neue Cluster mit Docker erstellen	Nein	Nein
Neue Knotenpools mit Docker erstellen	Nein	Nein
Automatische Knotenbereitstellung mit Docker aktivieren	Nein	Nein
Upgrade von vorheriger Version mit vorhandener Konfiguration für die automatische Bereitstellung von Docker-Knoten	Ja	Nein
Docker-basierte Knoten-Images verwenden	Ja	Nein

Automatische Migration, wenn Version 1.23 das Ende ihres Lebenszyklus erreicht

Wenn Sie kein Upgrade auf Version 1.24 durchführen und zu containerd-Knoten-Images migrieren, bevor Version 1.23 am 31. Juli 2023 das Ende ihres Lebenszyklus erreicht, führt GKE im Laufe der Zeit Folgendes aus:

Wenn Ihr Cluster eine automatisierte Knotenbereitstellung mit einem Docker-basierten Knoten-Image-Standardtyp hat, aktualisiert GKE die Konfiguration zur Verwendung des äquivalenten Knoten-Image, das die containerd-Laufzeit verwendet. Sie können diesen Vorgang nicht mit einem Wartungsausschluss blockieren. Damit Sie prüfen, dass sich die Arbeitslasten nicht negativ auf Ihre Arbeitslasten auswirken, empfehlen wir, dass Sie den Standard-Image-Typ der automatischen Knotenbereitstellung manuell auf ein containerd-basiertes Image aktualisieren, bevor GKE die Konfiguration automatisch aktualisiert.
GKE aktualisiert die Steuerungsebene Ihres Clusters auf Version 1.24.
GKE migriert alle Knotenpools, die noch Docker verwenden, zu containerd-Knoten-Images ab dem 1. September 2023. Wir empfehlen, die Knoten-Images vor diesem Datum manuell zu migrieren. Alternativ können Sie festlegen, dass GKE einen Vorgang zur Migration Ihres Clusters initiiert, um containerd-Images zu verwenden. Wenden Sie sich an Cloud Customer Care, um diese Anfrage zu stellen.

Wenn Sie die automatische Migration vorübergehend blockieren möchten, aktualisieren Sie den Cluster auf Version 1.24 oder höher und konfigurieren Sie einen Wartungsausschluss. Weitere Informationen zu diesem Wartungsausschluss finden Sie unter Automatische Migration zu containerd-Knoten-Images vorübergehend verzögern.
GKE aktualisiert Knotenpools der Version 1.23 auf 1.24 wie bei jeder nicht unterstützten Version, um dafür zu sorgen, dass der Clusterzustand mit der Open-Source-Versionskompatibilitätsrichtlinie konform ist. Weitere Informationen finden Sie unter Lebenszyklus der GKE-Nebenversion. Sie können dieses Upgrade vorübergehend mit einem Wartungsausschluss blockieren.

Automatische Migration zu containerd-Knoten-Images vorübergehend verzögern

Nachdem die Steuerungsebene Ihres Clusters auf 1.24 oder höher aktualisiert wurde, können Sie Wartungsausschluss konfigurieren um vorübergehend zu verhindern, dass die Knoten bis zum 29.02.2024 migriert werden, wenn Version 1.25 das Ende des Produktzyklus erreicht hat. Für diesen Wartungsausschluss muss Ihr Cluster in einer Release-Version registriert sein. Konfigurieren Sie den Wartungsausschluss mit dem Bereich Keine Nebenversions- oder Knotenupgrades und setzen Sie das Flag --add-maintenance-exclusion-end auf 2024-02-29T00:00:00Z oder früher. Wir empfehlen, die Blockierung Ihrer Migration so schnell wie möglich aufzuheben und die Knoten auf Version 1.24 zu aktualisieren. Nebenversionen, die das End of Life erreicht haben, erhalten keine Sicherheitspatches und Fehlerkorrekturen mehr.

Von Docker zu containerd-Knoten-Images migrieren

Unter Von Docker zu containerd-Knoten-Images migrieren erfahren Sie, wie Sie Cluster und Knotenpools mit Docker-basierten Knoten-Images identifizieren und diese Knotenpools zu containerd-Knoten-Images migrieren.

Entsprechend dem GKE-Modell der geteilten Verantwortung liegt es im Verantwortungsbereich des Kunden, die Integrität der Arbeitslasten aufrechtzuerhalten, und im Verantwortungsbereich von Google, für die Funktionsfähigkeit des Clusters zu sorgen. Dazu gehört auch die Ausführung einer unterstützten Version. Wir empfehlen dringend, Ihre Arbeitslasten zu testen und Ihren Cluster zu migrieren, bevor dies durch GKE automatisch erfolgt.

Bevor das Ende des Produktzyklus von 1.23 erreicht ist, verhindert GKE automatische oder manuelle Upgrades auf 1.24 für Cluster mit Knotenpools, die Docker-Knoten-Images verwenden. Nachdem Sie Ihren Cluster so migriert haben, dass nur containerd-Images verwendet werden, können automatische Upgrades innerhalb eines Tages nach dem GKE-Releasezeitplan fortgesetzt werden. Sie können den Cluster auch manuell upgraden.

Nach dem Ende des Produktzyklus von 1.23 hebt GKE die Blockierung von automatischen oder manuellen Upgrades auf 1.24 auf und folgt dem Prozess der automatischen Migration.

Auswirkungen der Migration

Die Hauptänderung bei der Migration zu containerd-Knoten-Images besteht darin, dass Docker den Lebenszyklus Ihrer Container (z. B. das Starten und Beenden) nicht mehr verwaltet. Daher können Sie Docker-Befehle oder die Docker API nicht verwenden, um sich GKE-Container anzusehen oder mit ihnen zu interagieren, wenn sie auf Knoten ausgeführt werden, die containerd-Images verwenden.

Die meisten Nutzerarbeitslasten haben keine Abhängigkeit von der Containerlaufzeit. Die Docker-Laufzeit implementiert auch containerd, sodass sich Ihre Arbeitslasten auf containerd-Knoten-Images ähnlich verhalten.

Sie sind möglicherweise betroffen, wenn Folgendes zutrifft:

Sie führen privilegierte Pods aus, die Docker-Befehle ausführen.
Sie führen Skripts auf Knoten von außerhalb der Kubernetes-Infrastruktur aus, um beispielsweise SSH zur Fehlerbehebung zu verwenden.
Sie führen Tools von Drittanbietern aus, die ähnlich privilegierte Vorgänge ausführen.
Einige Ihrer Tools reagieren auf Docker-spezifische Logs in Ihrem Monitoringsystem.
Sie stellen Logging-, Monitoring-, Sicherheits- oder Continuous-Integration-Tools bereit, die von externen Anbietern in Ihrem GKE-Cluster bereitgestellt werden. Wenden Sie sich an diese Anbieter, um die Auswirkungen zu bestätigen.

In den folgenden Situationen sind Sie nicht betroffen:

Sie haben eine Build-Pipeline außerhalb des GKE-Clusters, die Docker verwendet, um Container-Images zu erstellen und per Push zu übertragen.
Sie verwenden die Befehle docker build und docker push in Ihrem GKE-Cluster. Linux-Knoten-Images mit containerd enthalten die Docker-Binärdatei und unterstützen diese Befehle.

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.

Fehlerbehebung

Informationen zur Fehlerbehebung finden Sie unter Probleme mit der containerd-Laufzeit beheben.