Knoten zu containerd 2 migrieren

In Google Kubernetes Engine-Clustern (GKE) werden Knoten-Images mit containerd für alle Worker-Knoten verwendet, auf denen Version 1.24 und höher ausgeführt wird. Die Worker-Knoten verwenden eine bestimmte Version von containerd, die auf der GKE-Version basiert:

  • Auf Knoten, auf denen GKE 1.32 oder früher mit containerd-Knoten-Images ausgeführt wird, wird containerd 1.7 oder eine frühere Version verwendet.
  • Auf Knoten, auf denen GKE 1.33 ausgeführt wird, wird containerd 2.0 verwendet.

Wenn GKE-Knoten von Version 1.32 auf Version 1.33 aktualisiert werden, wird auf den Knoten von containerd 1.7 auf die neue Hauptversion containerd 2.0 migriert. Sie können nicht ändern, welche containerd-Version in einer GKE-Version verwendet wird.

Sie können diese Seite überspringen, wenn Sie wissen, dass Ihre Arbeitslasten wie erwartet auf containerd 2 ausgeführt werden.

Umstellung von GKE auf containerd 2

In der folgenden Zeitachse sehen Sie, wie vorhandene Cluster in GKE auf containerd 2 umgestellt werden:

  • In der Nebenversion 1.32 wird in GKE containerd 1.7 verwendet. In containerd 1.7 wurden sowohl Docker-Schema 1-Images als auch die CRI (Container Runtime Interface) v1alpha2 API eingestellt. Informationen zu anderen Funktionen, die in früheren Versionen eingestellt wurden, finden Sie unter Eingestellte Konfigurationseigenschaften.
  • Mit der Nebenversion 1.33 verwendet GKE containerd 2.0, wodurch die Unterstützung für Schema 1-Docker-Images und die CRI v1alpha2-API entfernt wird.
  • Die folgenden containerd-Konfigurationseigenschaften im CRI-Plug-in sind veraltet und werden in containerd 2.2 entfernt. Eine GKE-Version wird noch angekündigt: 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 mehr über die Auswirkungen dieser Umstellung auf containerd 2.

Pausierte automatische Upgrades

GKE pausiert automatische Upgrades auf Version 1.33, wenn erkannt wird, dass ein Cluster die verworfenen Funktionen verwendet. Wenn Ihre Clusterknoten diese Funktionen jedoch verwenden, empfehlen wir, einen Wartungsausschluss zu erstellen, um Knotenupgrades zu verhindern. Der Wartungsausschluss sorgt dafür, dass Ihre Knoten nicht aktualisiert werden, wenn GKE keine Nutzung erkennt.

Nachdem Sie die Verwendung dieser Funktionen migriert haben, werden automatische Nebenversionsupgrades auf 1.33 von GKE fortgesetzt, wenn 1.33 ein automatisches Upgradeziel für Ihre Clusterknoten ist und keine anderen Faktoren automatische Upgrades blockieren. Bei Knotenpools von Standardclustern können Sie den Knotenpool auch manuell upgraden.

Ende des Supports und Auswirkungen, wenn Sie sich nicht auf die Migration vorbereiten

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 in einer Version verbleiben. Weitere Informationen zu automatischen Knotenupgrades am Ende des Supports finden Sie unter Automatische Upgrades am Ende des Supports.

Wenn Sie nicht von diesen Funktionen migrieren, können die folgenden Probleme mit Ihren Clustern auftreten, wenn 1.32 das End of Support erreicht und Ihre Clusterknoten automatisch auf 1.33 aktualisiert werden:

  • Arbeitslasten, die Docker-Schema 1-Images verwenden, schlagen fehl.
  • Bei Anwendungen, die die CRI v1alpha2 API aufrufen, treten Fehler beim Aufrufen der API auf.

Betroffene Cluster identifizieren

GKE überwacht Ihre Cluster und verwendet den Recommender-Dienst, um über Statistiken und Empfehlungen Clusterknoten zu identifizieren, die diese eingestellten Funktionen verwenden.

Versionsanforderungen

Cluster erhalten diese Statistiken und Empfehlungen, wenn sie die folgenden Versionen oder höher ausführen:

  • 1.28.15-gke.1159000
  • 1.29.9-gke.1541000
  • 1.30.5-gke.1355000
  • 1.31.1-gke.1621000

Statistiken und Empfehlungen erhalten

Folgen Sie der Anleitung zum Aufrufen von Informationen und Empfehlungen. In der Trusted Cloud -Konsole können Sie Statistiken abrufen. Sie können auch die Google Cloud CLI oder die Recommender API verwenden und mit den folgenden Untertypen filtern:

  • DEPRECATION_CONTAINERD_V1_SCHEMA_IMAGES: Docker-Schema 1-Images
  • DEPRECATION_CONTAINERD_V1ALPHA2_CRI_API: CRI v1alpha2 API

Von eingestellten Funktionen migrieren

In den folgenden Abschnitten erfahren Sie, wie Sie von Funktionen migrieren, die mit containerd 2 eingestellt wurden.

Aus Schema 1-Docker-Images migrieren

Identifizieren Sie Arbeitslasten, die Bilder verwenden, die migriert werden müssen, und migrieren Sie diese Arbeitslasten.

Zu migrierende Bilder finden

Sie können verschiedene Tools verwenden, um Bilder zu finden, die migriert werden müssen.

Statistiken und Empfehlungen oder Cloud Logging verwenden

Wie im Abschnitt Betroffene Cluster identifizieren beschrieben, können Sie Statistiken und Empfehlungen verwenden, um Cluster zu finden, die Docker Schema 1-Images verwenden, wenn auf Ihrem Cluster eine Mindestversion oder höher ausgeführt wird. Außerdem können Sie die folgende Abfrage in Cloud Logging verwenden, um containerd-Logs zu prüfen und 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 Logs für das Bild angezeigt.

Den Befehl ctr direkt auf einem Knoten verwenden

Wenn Sie einen bestimmten Knoten abfragen möchten, um alle nicht gelöschten Bilder 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 nützlich sein, wenn Sie beispielsweise Fehler bei einem bestimmten Knoten beheben und keine Logeinträge in Cloud Logging sehen, weil das Image vor mehr als 30 Tagen abgerufen wurde.

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

Um Arbeitslasten vorzubereiten, die Schema 1-Docker-Images ausführen, müssen Sie diese Arbeitslasten zu Schema 2-Docker-Images oder OCI-Images (Open Container Initiative) migrieren. Sie haben folgende Möglichkeiten für die Migration:

  • Ersatzbild suchen:Möglicherweise finden Sie ein öffentlich verfügbares Open-Source-Bild oder ein vom Anbieter bereitgestelltes Bild.
  • Vorhandenes Bild konvertieren:Wenn Sie kein Ersatzbild finden, können Sie vorhandene Docker-Schema 1-Images mit den folgenden Schritten in OCI-Images konvertieren:
    1. Laden Sie das Docker-Image in containerd herunter. Es wird automatisch in ein OCI-Image konvertiert.
    2. Ü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 Arbeitslasten identifizieren, die auf den containerd-Socket zugreifen, und diese Anwendungen auf die v1 API aktualisieren.

Potenziell betroffene Arbeitslasten ermitteln

Sie können verschiedene Techniken verwenden, um Arbeitslasten zu identifizieren, die möglicherweise migriert werden müssen. Diese Techniken können falsch positive Ergebnisse liefern, die Sie weiter untersuchen müssen, um festzustellen, dass keine Maßnahmen erforderlich sind.

Statistiken und Empfehlungen nutzen

Sie können Statistiken und Empfehlungen verwenden, um Cluster zu finden, die die v1alpha2-API verwenden, wenn auf Ihrem Cluster eine Mindestversion oder höher ausgeführt wird. Weitere Informationen finden Sie unter Betroffene Cluster identifizieren.

Wenn Sie Statistiken in der Trusted Cloud Console aufrufen, sehen Sie in der Seitenleiste den Bereich Arbeitslasten aus der verworfenen CRI v1alpha2 API migrieren. In der Tabelle Zu überprüfende Arbeitslasten in diesem Bereich werden Arbeitslasten aufgeführt, die möglicherweise betroffen sind. Diese Liste enthält alle Arbeitslasten, die nicht von GKE verwaltet werden und hostPath-Volumes mit dem containerd-Socketpfad enthalten (z. B. /var/run/containerd/containerd.sock oder /run/containerd/containerd.sock).

Wichtig:

  • Diese Liste kann fälschlicherweise markierte Einträge enthalten. Wenn eine Arbeitslast in dieser Liste aufgeführt ist, bedeutet das nicht zwangsläufig, dass sie die eingestellte API verwendet. Es gibt nur an, dass die Arbeitslast auf ein hostPath-Volume verweist, das den containerd-Socket enthält. Ein Monitoring-Agent kann beispielsweise das Stammdateisystem des Knotens (/) einbeziehen, um Messwerte zu erfassen. Wenn Sie das Stammdateisystem des Knotens einbeziehen, wird technisch gesehen auch der Pfad des Sockets einbezogen. Der Messwerte-Agent ruft die CRI v1alpha2-API jedoch möglicherweise nicht auf.
  • Diese Liste ist möglicherweise leer oder unvollständig. Eine leere oder unvollständige Liste kann auftreten, wenn Arbeitslasten, die die eingestellte API verwenden, nur kurzlebig waren und nicht ausgeführt wurden, als GKE die regelmäßige Prüfung durchgeführt hat. Das Vorhandensein der Empfehlung selbst bedeutet, dass die Verwendung der CRI v1alpha2-API auf mindestens einem Knoten in Ihrem Cluster erkannt wurde.

Wir empfehlen daher, die tatsächliche API-Nutzung mit den folgenden Methoden zu bestätigen.

Prüfen, ob Arbeitslasten von Drittanbietern betroffen sind

Prüfen Sie bei Drittanbietersoftware, die in Ihren Clustern bereitgestellt wird, ob diese Arbeitslasten die CRI v1alpha2 API verwenden. Möglicherweise müssen Sie sich an die jeweiligen Anbieter wenden, um zu prüfen, welche Versionen ihrer Software kompatibel sind.

kubectl verwenden

Mit dem folgenden Befehl können Sie potenziell betroffene Arbeitslasten finden, indem Sie nach Arbeitslasten suchen, die auf den containerd-Socket zugreifen. Dabei wird eine ähnliche Logik wie für die Tabelle Zu überprüfende Arbeitslasten in der Empfehlung der Trusted Cloud -Konsole verwendet. Es werden Arbeitslasten zurückgegeben, die nicht von GKE verwaltet werden und hostPath-Volumes enthalten, einschließlich des Pfads des Sockets. Wie bei der Empfehlung kann es auch bei dieser Abfrage zu falsch positiven Ergebnissen kommen oder kurzlebige Arbeitslasten werden nicht berücksichtigt.

Führen Sie dazu diesen Befehl aus:

kubectl get pods --all-namespaces -o json | \
jq -r '
  [
    "/", "/var", "/var/","/var/run", "/var/run/",
    "/var/run/containerd", "/var/run/containerd/", "/var/run/containerd/containerd.sock",
    "/run", "/run/", "/run/containerd", "/run/containerd/",
    "/run/containerd/containerd.sock"
  ] as $socket_paths |
  [
    "kube-system", "kube-node-lease", "istio-system", "asm-system",
    "gatekeeper-system", "config-management-system", "config-management-monitoring",
    "cnrm-system", "hnc-system", "gke-managed-system", "gke-gmp-system",
    "gmp-system", "gke-managed-cim"
  ] as $excluded_namespaces |
  .items[] |
  select(
    (.spec.volumes[]?.hostPath.path as $p | $socket_paths | index($p))
    and
    ([.metadata.namespace] | inside($excluded_namespaces) | not)
  ) |
  .metadata.namespace + "/" + .metadata.name
'
eBPF-Tracing verwenden, um API-Aufrufer zu identifizieren

Wenn Sie genauer wissen möchten, welche Arbeitslasten die CRI v1alpha2 API aufrufen, können Sie zwei spezielle DaemonSets bereitstellen: containerd-socket-tracer und cri-v1alpha2-api-deprecation-reporter. Diese Tools verwenden den Extended Berkeley Packet Filter (eBPF), um Verbindungen zum containerd-Socket zu verfolgen und die Verbindungen mit tatsächlichen verworfenen API-Aufrufen zu korrelieren:

  • Im containerd-socket-tracer werden alle Prozesse protokolliert, die eine Verbindung zum containerd-Socket öffnen, zusammen mit den Pod- und Containerdetails.
  • Im cri-v1alpha2-api-deprecation-reporter wird der letzte Aufruf der CRIv1alpha2 API protokolliert.

Wenn Sie die Zeitstempel dieser beiden Tools in Beziehung setzen, können Sie die genaue Arbeitslast ermitteln, die den verworfenen API-Aufruf ausführt. Diese Methode bietet eine höhere Zuverlässigkeit als die alleinige Prüfung der hostPath-Volumina, da sie tatsächliche Socket-Verbindungen und die API-Nutzung beobachtet.

Eine detaillierte Anleitung zum Bereitstellen und Verwenden dieser Tools sowie zum Interpretieren ihrer Logs finden Sie unter containerd-Socketverbindungen verfolgen.

Wenn Sie nach der Verwendung dieser Tools die Quelle der verworfenen API-Aufrufe immer noch nicht ermitteln können, die Empfehlung aber weiterhin aktiv ist, lesen Sie den Abschnitt Support erhalten.

Nachdem Sie eine Arbeitslast identifiziert haben, die die CRI v1alpha2 API verwendet, entweder mit den oben genannten Methoden oder durch Überprüfen Ihres Codes, müssen Sie den Code aktualisieren, damit die v1 API verwendet wird.

Anwendungscode aktualisieren

Um Ihre Anwendung zu aktualisieren, entfernen Sie die Stelle, an der die Anwendung die k8s.io/cri-api/pkg/apis/runtime/v1alpha2-Clientbibliothek importiert, und ändern Sie den Code so, dass die v1-Version der API verwendet wird. In diesem Schritt ändern Sie den Importpfad und aktualisieren, wie Ihr Code die API aufruft.

Hier ein Beispiel für Golang-Code, in dem die eingestellte Bibliothek verwendet wird:

  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 zum Ausgeben von RPCs. 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:

  1. Ermitteln Sie problematische Go-Anwendungen, indem Sie mit dem folgenden Befehl nach dem Importpfad v1alpha2 suchen:

      grep -r "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"

    Wenn die Ausgabe dieses Befehls zeigt, 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"

  2. Aktualisieren Sie den Code, um v1 zu verwenden:

      runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1"

Support anfordern

Wenn Sie der Anleitung zum Verwenden von eBPF-Tracing zur Identifizierung von API-Aufrufern gefolgt sind, die Quelle der eingestellten API-Aufrufe aber weiterhin nicht ermitteln können und die Empfehlungen aktiv bleiben, sollten Sie Folgendes in Betracht ziehen: