In Google Kubernetes Engine (GKE)-Clustern werden Containerd-Knotenbilder mit allen Worker-Knoten verwendet, auf denen Version 1.24 oder höher ausgeführt wird. Die Worker-Knoten verwenden eine bestimmte Version von containerd, die auf der GKE-Version basiert:
- Knoten, auf denen GKE 1.32 oder niedriger mit containerd-Knoten-Images ausgeführt wird, verwenden containerd 1.7 oder niedriger.
- Auf Knoten, auf denen GKE 1.33 ausgeführt wird, wird containerd 2.0 verwendet.
Wenn GKE-Knoten von 1.32 auf 1.33 aktualisiert werden, migrieren die Knoten von containerd 1.7 zur neuen Hauptversion containerd 2.0. Sie können nicht ändern, welche containerd-Version von einer GKE-Version verwendet wird.
Sie können diese Seite überspringen, wenn Sie wissen, dass Ihre Arbeitslasten wie erwartet unter containerd 2 ausgeführt werden.
So erfolgt die Umstellung von GKE auf containerd 2
In der folgenden Zeitleiste sehen Sie, wie in GKE die Umstellung bestehender Cluster auf containerd 2 erfolgt:
- Mit der Nebenversion 1.32 verwendet GKE containerd 1.7. Mit containerd 1.7 wurden sowohl Docker-Schema 1-Images als auch die CRI (Container Runtime Interface) v1alpha2 API eingestellt. Weitere Informationen zu anderen in früheren Versionen eingestellten Funktionen finden Sie unter Eingestellte Konfigurationseigenschaften.
- In der Nebenversion 1.33 verwendet GKE containerd 2.0. Dadurch wird die Unterstützung für Docker-Schema 1-Images und die CRI v1alpha2 API entfernt.
- Die folgenden Containerd-Konfigurationseigenschaften im CRI-Plug-in werden nicht mehr unterstützt und in Containerd 2.1 entfernt. Die entsprechende GKE-Version wird noch bekannt gegeben:
registry.auths,registry.configs,registry.mirrors.
Einen ungefähren Zeitplan für automatische Upgrades auf spätere Nebenversionen wie 1.33 finden Sie im geschätzten Zeitplan für Release-Kanäle.
Auswirkungen der Umstellung auf containerd 2
Im folgenden Abschnitt erfahren Sie, welche Auswirkungen diese Umstellung auf containerd 2 hat.
Pausierte automatische Upgrades
GKE pausiert automatische Upgrades auf Version 1.33, wenn erkannt wird, dass in einem Cluster die verworfenen Funktionen verwendet werden. Wenn Ihre Clusterknoten jedoch diese Funktionen verwenden, empfehlen wir, einen Wartungsausschluss zu erstellen, um Knotenupgrades zu verhindern. Mit dem Wartungsausschluss wird sichergestellt, dass Ihre Knoten nicht aktualisiert werden, wenn GKE keine Nutzung erkennt.
Wenn 1.33 ein automatisches Upgradeziel für Ihre Clusterknoten ist und keine anderen Faktoren automatische Upgrades blockieren, werden nach der Migration von diesen Funktionen automatische Minor-Upgrades auf 1.33 in GKE fortgesetzt. Bei Standardcluster-Knotenpools können Sie den Knotenpool auch manuell aktualisieren.
Ende des Supports und Auswirkungen einer mangelhaften Vorbereitung auf die Migration
GKE pausiert automatische Upgrades bis zum Ende des Standardsupports. Wenn Ihr Cluster für den Extended Channel registriert ist, können Ihre Knoten bis zum Ende des erweiterten Supports bei einer Version bleiben. Weitere Informationen zu automatischen Knotenupgrades am Ende des Supports finden Sie unter Automatische Upgrades am Ende des Supports.
Wenn Sie nicht zu diesen Funktionen migrieren, wird Ihre Clusterversion nach dem Ende des Supports für 1.32 automatisch auf 1.33 aktualisiert. In diesem Fall können die folgenden Probleme auftreten:
- Arbeitslasten, die Docker-Schema 1-Images verwenden, schlagen fehl.
- Bei Anwendungen, die die CRI v1alpha2 API aufrufen, treten Fehler beim Aufruf der API auf.
Von eingestellten Funktionen migrieren
In den folgenden Abschnitten erfahren Sie, wie Sie von Funktionen migrieren, die mit containerd 2 eingestellt wurden.
Von Docker-Schema 1-Images migrieren
Identifizieren Sie Arbeitslasten mit Images, die migriert werden müssen, und migrieren Sie diese Arbeitslasten.
Zu migrierende Bilder finden
Es gibt verschiedene Tools, mit denen Sie nach Bildern suchen können, die migriert werden müssen.
Cloud Logging verwenden
Mit der folgenden Abfrage in Cloud Logging können Sie Containerd-Logs prüfen, um Docker-Schema 1-Images in Ihrem Cluster zu finden:
jsonPayload.SYSLOG_IDENTIFIER="containerd"
"conversion from schema 1 images is deprecated"
Wenn seit dem Abrufen des Bildes mehr als 30 Tage vergangen sind, werden möglicherweise keine Protokolle für das Bild angezeigt.
Befehl ctr direkt auf einem Knoten verwenden
Wenn Sie einen bestimmten Knoten abfragen möchten, um alle nicht gelöschten Images zurückzugeben, die als Schema 1 abgerufen wurden, führen Sie den folgenden Befehl auf einem Knoten aus:
ctr --namespace k8s.io images list 'labels."io.containerd.image/converted-docker-schema1"'
Dieser Befehl kann beispielsweise nützlich sein, wenn Sie die Fehlerbehebung für einen bestimmten Knoten durchführen und in Cloud Logging keine Logeinträge sehen, weil seit dem Abrufen des Images mehr als 30 Tage vergangen sind.
Open-Source-Tool crane verwenden
Sie können auch Open-Source-Tools wie crane verwenden, um nach Bildern zu suchen.
Führen Sie den folgenden crane-Befehl aus, um die Schemaversion für ein Bild zu prüfen:
crane manifest $tagged_image | jq .schemaVersion
Arbeitslasten vorbereiten
Wenn Sie Arbeitslasten vorbereiten möchten, die Docker-Schema 1-Images ausführen, müssen Sie diese Arbeitslasten zu Docker-Schema 2-Images oder OCI-Images (Open Container Initiative) migrieren. Sie haben folgende Möglichkeiten:
- Ersatzimage finden:Möglicherweise finden Sie ein öffentlich verfügbares Open-Source-Image oder ein vom Anbieter bereitgestelltes Image.
- Vorhandenes Image konvertieren:Wenn Sie kein Ersatzimage finden, können Sie vorhandene Docker-Schema 1-Images mit den folgenden Schritten in OCI-Images konvertieren:
- Ziehen Sie das Docker-Image in containerd, wo es automatisch in ein OCI-Image umgewandelt wird.
- Übertragen Sie das neue OCI-Image per Push in Ihre Registry.
Von der CRI v1alpha2 API migrieren
Die CRI v1alpha2 API wurde in Kubernetes 1.26 entfernt. Sie müssen die Arbeitslasten identifizieren, die auf den containerd-Socket zugreifen, und diese Anwendungen auf die v1 API aktualisieren.
Arbeitslasten identifizieren
Es gibt verschiedene Methoden, um Arbeitslasten zu identifizieren, die migriert werden müssen.
kubectl verwenden
Mit dem folgenden Befehl können Sie nach Arbeitslasten suchen, die auf den containerd-Socket zugreifen. Dieser Befehl gibt Arbeitslasten zurück, die hostPath-Verzeichnisse bereitstellen, die den Socket enthalten. Diese Abfrage kann zu Falschmeldungen führen, da einige Arbeitslasten diese Verzeichnisse oder andere untergeordnete Verzeichnisse bereitstellen, aber nicht auf den Containerd-Socket zugreifen.
Führen Sie dazu diesen Befehl aus:
kubectl get pods --all-namespaces -o json | jq -r '.items[] |
select(.spec.volumes[]? | select(.hostPath.path? and (.hostPath.path |
startswith("/run") or startswith("/var/run") or . == "/"))) |
.metadata.namespace + "/" + .metadata.name'
Anwendungscode prüfen
Sie können in Ihrem Anwendungscode prüfen, ob CRI v1alpha2 API-Clientbibliotheken importiert werden.
Beispiel: Golang-Code
package main
import (
...
runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"
)
func foo() {
...
client := runtimeapi.NewRuntimeServiceClient(conn)
version, err := client.Version(ctx, &runtimeapi.VersionRequest{})
...
}
Hier importiert die Anwendung die v1alpha2-Bibliothek und verwendet sie, um RPCs auszugeben. Wenn die RPCs die Verbindung zum containerd-Socket verwenden, führt diese Anwendung dazu, dass GKE automatische Upgrades für den Cluster pausiert.
So suchen und aktualisieren Sie Ihren Anwendungscode:
Sie können problematische Golang-Anwendungen ermitteln, indem Sie den folgenden Befehl ausführen, um nach dem Importpfad „v1alpha2“ zu suchen:
grep -r "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"Wenn die Ausgabe dieses Befehls anzeigt, dass die v1alpha2-Bibliothek in der Datei verwendet wird, müssen Sie die Datei aktualisieren.
Ersetzen Sie beispielsweise den folgenden Anwendungscode:
runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"Aktualisieren Sie den Code, um v1 zu verwenden:
runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1"