Knoten zu containerd 2 migrieren

In Google Kubernetes Engine-Clustern (GKE) werden containerd Knoten Images mit allen Worker-Knoten verwendet, auf denen Version 1.24 und höher ausgeführt wird. Die Worker-Knoten verwenden eine bestimmte Version von containerd, basierend auf dem Betriebssystem und der GKE-Nebenversion:

  • Container-Optimized OS- und Ubuntu-Knoten (Linux):
    • Linux-Knoten, auf denen GKE 1.32 oder eine frühere Version mit containerd-Knoten-Images ausgeführt wird, verwenden containerd 1.7 oder frühere Versionen.
    • Linux-Knoten, auf denen GKE 1.33 ausgeführt wird, verwenden containerd 2.0.
  • Windows Server-Knoten:
    • Windows Server-Knoten, auf denen GKE 1.34 oder eine frühere Version mit containerd-Knoten-Images ausgeführt wird, verwenden containerd 1.7 oder frühere Versionen.
    • Windows Server-Knoten, auf denen GKE 1.35 ausgeführt wird, verwenden containerd 2.0.

Wenn GKE-Knoten auf die entsprechende GKE-Nebenversion 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 auf containerd 2 ausgeführt werden.

Umstellung von GKE auf containerd 2

In der folgenden Zeitachse wird erläutert, wie GKE vorhandene Cluster auf containerd 2 umstellt:

  • Für Linux-Knoten mit 1.32 und Windows Server-Knoten mit 1.34 verwendet GKE containerd 1.7. In containerd 1.7 wurden sowohl Docker Schema 1-Images als auch die Container Runtime Interface (CRI) v1alpha2 API verworfen. Informationen zu anderen Funktionen, die in früheren Versionen verworfen wurden, finden Sie unter Verworfene Konfigurationseigenschaften.
  • Für Linux-Knoten mit 1.33 und Windows Server-Knoten mit 1.35 verwendet GKE containerd 2.0, das die Unterstützung für Docker Schema 1-Images und die CRI v1alpha2 API entfernt.
  • Die folgenden containerd-Konfigurationseigenschaften im CRI-Plug‑in sind verworfen und werden in containerd 2.4 oder höher entfernt. Eine GKE-Version wird noch bekannt gegeben: registry.auths, registry.configs, registry.mirrors. registry.configs.tls wurde jedoch bereits in containerd 2.0 entfernt.

Einen ungefähren Zeitplan für automatische Upgrades auf spätere Nebenversionen finden Sie im geschätzten Zeitplan für Release Kanäle.

Auswirkungen der Umstellung auf containerd 2

Im folgenden Abschnitt werden die Auswirkungen dieser Umstellung auf containerd 2 erläutert.

Pausierte automatische Upgrades

GKE pausiert automatische Upgrades auf folgende Weise, je nach aktueller Nebenversion des Clusters und je nachdem, ob die Knoten im Cluster Linux-Knoten oder Windows Server-Knoten sind.

Pausierte automatische Upgrades für Linux-Knoten

GKE pausiert automatische Upgrades auf 1.33 für Cluster mit Linux-Knoten, wenn erkannt wird, dass der Cluster die verworfenen Funktionen verwendet. Wenn Ihre Clusterknoten diese Funktionen verwenden, empfehlen wir jedoch, einen Wartungs ausschluss zu erstellen, um Clusterupgrades zu verhindern. Der Wartungsausschluss sorgt dafür, dass Ihr Cluster nicht aktualisiert wird, wenn GKE die Verwendung nicht erkennt.

Nachdem Sie die Verwendung dieser Funktionen eingestellt haben, setzt GKE automatische Nebenversionsupgrades auf 1.33 fort, wenn Folgendes zutrifft:

  • GKE hat die Verwendung verworfener Funktionen seit 14 Tagen nicht erkannt oder seit 3 Tagen für verworfene CRI-Eigenschaften von registry.configs.
  • 1.33 ist ein automatisches Upgradeziel für Ihren Cluster.
  • Es gibt keine anderen blockierenden Faktoren. Weitere Informationen finden Sie unter Zeitpunkt automatischer Upgrades.

Sie können den Cluster auch manuell aktualisieren.

Pausierte automatische Upgrades für Windows Server-Knoten

GKE pausiert automatische Upgrades auf 1.35 für alle Cluster mit Windows Server-Knoten, unabhängig davon, ob der Cluster die verworfenen Funktionen verwendet. GKE kann nicht erkennen, ob Windows Server-Knoten die verworfenen Funktionen verwenden.

Wenn Sie Ihren Cluster mit Windows Server-Knoten auf 1.35 aktualisieren möchten, folgen Sie zuerst der Anleitung unter Von verworfenen Funktionen migrieren. Nachdem Sie diese Anleitung befolgt haben, können Sie den Cluster manuell auf 1.35 aktualisieren.

Ende des Supports und Auswirkungen, wenn die Migration nicht vorbereitet wird

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 auf einer Version bleiben. 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, wenn 1.32 (für Linux-Knoten) oder 1.34 (für Windows Server-Knoten) das Ende des Supports erreicht und Ihre Clusterknoten automatisch auf 1.33 oder 1.35 aktualisiert werden, können die folgenden Probleme mit Ihren Clustern auftreten:

  • 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 ermitteln

GKE überwacht Ihre Cluster und verwendet den Recommender Dienst, um Ihnen mit Statistiken und Empfehlungen zu helfen, Linux-Knoten in Ihrem Cluster zu identifizieren, die diese verworfenen Funktionen verwenden. GKE erkennt die Verwendung von Windows Server-Knoten nicht.

Versionsanforderungen

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

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

Statistiken und Empfehlungen abrufen

Folgen Sie der Anleitung zum Aufrufen von Statistiken und Empfehlungen. Sie können Statistiken über die Google Cloud Console 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
  • DEPRECATION_CONTAINERD_V2_CONFIG_REGISTRY_CONFIGS: Verworfene CRI registry.configs Eigenschaften, einschließlich registry.configs.auth und registry.configs.tls

Von verworfenen Funktionen migrieren

In den folgenden Abschnitten wird erläutert, wie Sie von Funktionen migrieren, die mit containerd 2 verworfen wurden.

Von Docker Schema 1-Images migrieren

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

Ein von diesem Problem betroffenes von Google bereitgestelltes Image ist gcr.io/google-containers/startup-script.

  • gcr.io/google-containers/startup-script:v1: verwendet das verworfene Schema 1-Format und kann in GKE 1.33 und höher für Linux-Knoten nicht abgerufen werden.
  • gcr.io/google-containers/startup-script:v2: verwendet das unterstützte Schema 2-Format und kann erfolgreich abgerufen werden.

Wenn Sie gcr.io/google-containers/startup-script:v1 in einer Ihrer Arbeitslasten (z. B. DaemonSets oder Bereitstellungen) verwenden, müssen Sie die Image-Referenz auf gcr.io/google-containers/startup-script:v2 aktualisieren.

Zu migrierende Images finden

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

Statistiken und Empfehlungen oder Cloud Logging verwenden

Wie im Abschnitt Betroffene Cluster ermitteln erläutert, können Sie Statistiken und Empfehlungen verwenden, um Cluster mit Linux-Knoten 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 Images mehr als 30 Tage vergangen sind, werden möglicherweise keine Logs für ein Image 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 nützlich sein, wenn Sie beispielsweise Fehler auf einem bestimmten Knoten beheben und in Cloud Logging keine Logeinträge sehen, da 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 Images zu suchen.

Führen Sie den folgenden crane-Befehl aus, um die Schemaversion für ein Image 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 Schema 2-Docker-Images oder OCI-Images (Open Container Initiative) migrieren. Folgende Optionen stehen für die Migration zur Verfügung:

  • Ersatz-Image suchen:Möglicherweise finden Sie ein öffentlich verfügbares Open-Source-Image oder ein Image, das von einem Anbieter bereitgestellt wird.
  • Vorhandenes Image konvertieren:Wenn Sie kein Ersatz-Image finden, können Sie vorhandene Docker Schema 1-Images mit den folgenden Schritten in OCI-Images konvertieren:
    1. Docker-Image in containerd abrufen, das es automatisch in ein OCI-Image konvertiert.
    2. Neues OCI-Image in Ihre Registry übertragen.

Von der CRI v1alpha2 API migrieren

Die CRI v1alpha2 API wurde in Kubernetes entfernt 1.26. Sie müssen Arbeitslasten identifizieren, die auf den containerd-Socket zugreifen, und diese Anwendungen auf die v1 API aktualisieren.

Potenziell betroffene Arbeitslasten identifizieren

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

Statistiken und Empfehlungen verwenden

Sie können Statistiken und Empfehlungen verwenden, um Cluster mit Linux-Knoten 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 ermitteln.

Wenn Sie Statistiken in der Google Cloud Console aufrufen, sehen Sie in der Seitenleiste Migrieren Sie Ihre Arbeitslasten aus der verworfenen CRI v1alpha2 API. In der Tabelle Zu überprüfende Arbeitslasten in diesem Bereich sind 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).

Beachten Sie Folgendes:

  • Die Liste der zu überprüfenden Arbeitslasten kann falsch positive Ergebnisse enthalten. Verwenden Sie sie nur zur Untersuchung. Wenn eine Arbeitslast in dieser Liste angezeigt wird, bedeutet das nicht unbedingt, dass sie die verworfene API verwendet. Das Vorhandensein eines falsch positiven Ergebnisses führt nicht dazu, dass automatische Upgrades pausiert werden. Das Pausieren basiert nur auf der tatsächlich beobachteten Verwendung der verworfenen API.
  • Diese Liste ist möglicherweise leer oder unvollständig. Eine leere oder unvollständige Liste kann auftreten, wenn Arbeitslasten, die die verworfene 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. Automatische Upgrades werden fortgesetzt, nachdem die Verwendung der verworfenen API seit 14 Tagen nicht mehr erkannt wurde.

Daher empfehlen wir, weitere Untersuchungen durchzuführen und die folgenden Methoden zu verwenden, um die tatsächliche API-Nutzung zu bestätigen.

Auf betroffene Arbeitslasten von Drittanbietern prüfen

Prüfen Sie für 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 verwendet wie für die Tabelle Zu überprüfende Arbeitslasten in der Google Cloud Console Empfehlung. Es werden Arbeitslasten zurückgegeben, die nicht von GKE verwaltet werden und hostPath-Volumes mit dem Pfad des Sockets enthalten. Wie bei der Empfehlung kann diese Abfrage falsch positive Ergebnisse liefern oder kurzlebige Arbeitslasten übersehen.

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

Eine genauere Möglichkeit, um zu ermitteln, welche Arbeitslasten, die auf Linux-Knoten ausgeführt werden, die CRI v1alpha2 API aufrufen, besteht darin, zwei spezielle DaemonSets bereitzustellen:

  • The containerd-socket-tracer protokolliert jeden Prozess, der eine Verbindung zum containerd Socket öffnet, zusammen mit den Pod- und Containerdetails.
  • cri-v1alpha2-api-deprecation-reporter protokolliert den Zeitpunkt des letzten Aufrufs der CRI v1alpha2 API.

Diese Tools verwenden eBPF (Extended Berkeley Packet Filter) um Verbindungen zum containerd Socket zu verfolgen und die Verbindungen mit tatsächlichen verworfenen API Aufrufen zu korrelieren.

Sie können diese DaemonSets nicht auf Windows Server-Knoten bereitstellen.

Durch Korrelieren der Zeitstempel aus diesen beiden Tools können Sie die genaue Arbeitslast ermitteln, die den verworfenen API-Aufruf ausführt. Diese Methode ist zuverlässiger als die alleinige Prüfung auf hostPath-Volumes, da sie tatsächliche Socketverbindungen und die API-Nutzung beobachtet.

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

Wenn Sie die Quelle der verworfenen API-Aufrufe nach Verwendung dieser Tools immer noch nicht ermitteln können, die Empfehlung aber weiterhin aktiv ist, finden Sie unter Support anfordernweitere Informationen.

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

Anwendungscode aktualisieren

Wenn Sie Ihre Anwendung aktualisieren möchten, 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 v1Version der API verwendet wird. Dazu müssen Sie den Importpfad ändern und die Art und Weise aktualisieren, wie Ihr Code die API aufruft.

Hier ist beispielsweise der folgende Golang-Code, der die verworfene Bibliothek verwendet:

  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.

Führen Sie die folgenden Schritte aus, um Ihren Anwendungscode zu suchen und zu aktualisieren:

  1. Identifizieren Sie problematische Golang-Anwendungen, indem Sie mit dem folgenden Befehl nach dem v1alpha2-Importpfad 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"

Von verworfenen containerd-Konfigurationseigenschaften migrieren

Die containerd-Konfigurationseigenschaften registry.auths, registry.configs und registry.mirrors im CRI-Plug‑in sind verworfen und werden in containerd 2.4 oder höher entfernt. Eine GKE-Version wird noch bekannt gegeben. registry.configs.tls wurde jedoch bereits in containerd 2.0 entfernt.

Arbeitslasten identifizieren

Sie können verschiedene Methoden verwenden, um Arbeitslasten zu identifizieren, die migriert werden müssen.

Statistiken und Empfehlungen verwenden

Als ersten Schritt können Sie Statistiken und Empfehlungen verwenden, um Cluster mit Linux-Knoten zu finden, die die verworfenen containerd-Konfigurationseigenschaften verwenden. Dafür ist eine Mindestversion von GKE erforderlich. Weitere Informationen zu dieser Methode finden Sie unter Betroffene Cluster ermitteln.

Wenn Sie Statistiken in der Google Cloud Console aufrufen, sehen Sie in der Seitenleiste containerd-Konfiguration aus dem veralteten Feld „auths“ der CRI-Registry migrieren field oder containerd-Konfiguration aus dem veralteten Feld „mirrors“ der CRI-Registry migrieren field. Im Abschnitt Zu überprüfende Arbeitslasten finden Sie Arbeitslasten, die möglicherweise auf die containerd-Konfiguration zugreifen.

kubectl verwenden

Alternativ können Sie kubectl verwenden, um Arbeitslasten zu identifizieren.

Suchen Sie nach Arbeitslasten, die die containerd-Konfiguration ändern, indem Sie nach Arbeitslasten mit den folgenden Attributen suchen:

  • Arbeitslasten, die ein hostPath-Volume enthalten, das die containerd-Konfiguration enthält
  • Arbeitslasten mit einem Container mit privilegiertem Zugriff (spec.containers.securityContext.privileged: true) und dem Hostprozess-ID-Namespace (PID) (spec.hostPID: true)

Dieser Befehl kann falsch positive Ergebnisse liefern, da die Arbeitslast möglicherweise auf andere Dateien in diesen Verzeichnissen zugreift, die nicht die containerd-Konfiguration sind. Außerdem werden mit diesem Befehl möglicherweise keine Arbeitslasten zurückgegeben, die auf andere, weniger übliche Weise auf die containerd-Konfigurationsdatei zugreifen.

Führen Sie den folgenden Befehl aus, um nach den DaemonSets zu suchen:

kubectl get daemonsets --all-namespaces -o json | \
jq -r '
  [
    "/", "/etc", "/etc/",
    "/etc/containerd", "/etc/containerd/",
    "/etc/containerd/config.toml"
  ] as $host_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(
    ([.metadata.namespace] | inside($excluded_namespaces) | not)
    and
    (
      (any(.spec.template.spec.volumes[]?.hostPath.path; IN($host_paths[])))
      or
      (
        .spec.template.spec.hostPID == true and
        any(.spec.template.spec.containers[]; .securityContext?.privileged == true)
      )
    )
  ) |
  .metadata.namespace + "/" + .metadata.name
'

Von den CRI-Registry-Eigenschaften auths oder configs.auth migrieren

Wenn Ihre Arbeitslasten die Eigenschaften auths oder configs.auth in der containerd-Konfiguration verwenden, um sich bei einer privaten Registry zu authentifizieren, um Container-Images abzurufen, müssen Sie die Arbeitslasten, die diese Images verwenden, stattdessen zum Feld imagePullSecrets migrieren. Weitere Informationen finden Sie unter Image aus einer privaten Registry abrufen.

Folgen Sie der Anleitung, um Arbeitslasten zu identifizieren und zu migrieren, die die verworfenen Eigenschaften auths oder configs.auth verwenden.

Authentifizierungsdetails für Ihre Registry suchen

Sie haben folgende Möglichkeiten, die Authentifizierungsdetails für Ihre Registry zu finden:

  • Prüfen Sie die Abschnitte auths und configs.auth der CRI-Registry in der Datei /etc/containerd/config.toml, indem Sie eine Verbindung zu einem GKE-Knoten herstellen.
  • Suchen Sie mit den zuvor beschriebenen Methoden zum Identifizieren von Arbeitslasten nach der Arbeitslast, die Ihre containerd-Konfigurationsdatei ändert, und prüfen Sie, welche Authentifizierungsdetails enthalten sind. GKE verwendet diese Einstellungen nicht für seine Systemarbeitslasten.

Wenn Sie die Eigenschaft registry.configs.auth verwenden, sehen die Authentifizierungsdetails möglicherweise so aus:

  [plugins."io.containerd.grpc.v1.cri".registry.configs."$REGISTRY_DOMAIN".auth]
    username = "example-user"
    password = "example-password"

Erfassen Sie diese Authentifizierungsdetails für jede Registry-Domain, die in Ihrer Konfiguration angegeben ist.

Arbeitslast aktualisieren, um das Feld imagePullSecrets zu verwenden
  1. Erstellen Sie ein Secret mit Ihren Authentifizierungsdetails aus dem vorherigen Abschnitt . Folgen Sie dazu der Anleitung unter Image aus einer privaten Registry abrufen.

  2. Ermitteln Sie mit dem folgenden Befehl, welche Arbeitslasten zum Feld imagePullSecrets migriert werden müssen:

    kubectl get pods -A -o json |
jq -r ".items[] |
  select(.spec.containers[] |
        .image | startswith(\"$REGISTRY_DOMAIN\")) |
  .metadata.namespace + \"/\" + .metadata.name"

    Sie müssen für jeden Namespace, der von Arbeitslasten mit Images aus dieser Registry-Domain verwendet wird, ein Secret erstellen.

  3. Aktualisieren Sie Ihre Arbeitslasten, um das Feld imagePullSecrets mit den Secrets zu verwenden, die Sie im vorherigen Schritt erstellt haben.

    Wenn Sie eine große Anzahl von Arbeitslasten migrieren müssen, können Sie alternativ einen MutatingAdmissionWebhook implementieren, um das imagePullSecrets Feld hinzuzufügen.

containerd-Konfiguration aktualisieren, um die Festlegung von Registry-Authentifizierungen zu beenden

Nachdem Sie Ihre Arbeitslasten migriert haben, um das Feld imagePullSecrets zu verwenden, müssen Sie Ihre Arbeitslasten, die Ihre containerd-Konfiguration ändern, so aktualisieren, dass die Festlegung von Registry-Authentifizierungen beendet wird. Ändern Sie alle Arbeitslasten, die Sie als Änderung der Konfiguration identifiziert haben, so, dass die Festlegung von Registry-Authentifizierungen beendet wird.

Mit einem neuen Knotenpool testen und Arbeitslasten zum neuen Knotenpool migrieren

So verringern Sie das Risiko von Problemen mit Ihren Arbeitslasten:

  1. Einen neuen Knotenpool erstellen.
  2. Planen Sie die aktualisierte Arbeitslast, die Ihre containerd-Konfiguration ändert, für Knoten im neuen Knotenpool.
  3. Migrieren Sie die restlichen Arbeitslasten zum neuen Knotenpool. Folgen Sie dazu der Anleitung unter Arbeitslasten zwischen Knoten pools migrieren.

Von der CRI-Registry-Eigenschaft configs.tls migrieren

Wenn Ihre Arbeitslasten die Eigenschaft registry.configs.tls verwenden, müssen Sie diese Arbeitslasten migrieren, um mit privaten CA-Zertifikaten auf private Registries zuzugreifen.

Folgen Sie der Anleitung unter Von Konfigurations-DaemonSets migrieren. Dieser Vorgang umfasst folgende Schritte:

  1. Aktualisieren Sie Ihre Arbeitslasten, die die containerd-Konfiguration ändern, um die Festlegung von TLS-Details zu beenden.
  2. Speichern Sie die Zertifikate in Secret Manager.
  3. Erstellen Sie eine Laufzeit-Konfigurationsdatei, die auf Ihre Zertifikate verweist.
  4. Erstellen Sie einen neuen Knotenpool und prüfen Sie, ob Ihre Arbeitslasten, die Images aus der privaten Registry verwenden, wie erwartet funktionieren.
  5. Wenden Sie die Konfiguration auf einen neuen Cluster an und führen Sie die Arbeitslasten auf diesem Cluster aus oder wenden Sie die Konfiguration auf den vorhandenen Cluster an. Wenn Sie die Konfiguration auf den vorhandenen Cluster anwenden, können möglicherweise andere vorhandene Arbeitslasten unterbrochen werden. Weitere Informationen zu diesen beiden Ansätzen finden Sie unter Laufzeit-Konfigurationsdatei erstellen.

Nach der Migration müssen Sie alle Änderungen am Feld registry.configs beenden, da sonst Probleme mit containerd auftreten können.

Support anfordern

Wenn Sie die Quelle der verworfenen API-Aufrufe immer noch nicht ermitteln können und die Empfehlungen weiterhin aktiv sind, sollten Sie den folgenden Schritt ausführen: