Knoten zu containerd 2 migrieren

In Google Kubernetes Engine-Clustern (GKE) werden Knoten-Images von containerd 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, die vom Betriebssystem und der GKE-Nebenversion abhängt:

  • Container-Optimized OS- und Ubuntu-Knoten (Linux):
    • Auf Linux-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 Linux-Knoten, auf denen GKE 1.33 ausgeführt wird, wird containerd 2.0 verwendet.
  • Windows Server-Knoten:
    • Auf Windows Server-Knoten, auf denen GKE 1.34 oder niedriger mit containerd-Knoten-Images ausgeführt wird, wird containerd 1.7 oder eine frühere Version verwendet.
    • Auf Windows Server-Knoten, auf denen GKE 1.35 ausgeführt wird, wird containerd 2.0 verwendet.

Wenn GKE-Knoten auf die entsprechende GKE-Nebenversion aktualisiert werden, wird die containerd-Version von 1.7 auf die neue Hauptversion 2.0 migriert. 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 sehen Sie, wie GKE vorhandene Cluster auf containerd 2 umstellt:

  • Für Linux-Knoten mit Version 1.32 und Windows Server-Knoten mit Version 1.34 verwendet GKE containerd 1.7. 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.
  • Für Linux-Knoten mit Version 1.33 und Windows Server-Knoten mit Version 1.35 verwendet GKE containerd 2.0, wodurch die Unterstützung für Docker-Schema 1-Images und die CRI v1alpha2-API entfällt.
  • Die folgenden containerd-Konfigurationseigenschaften im CRI-Plug-in sind veraltet 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 erfahren Sie, welche Auswirkungen diese Umstellung auf containerd 2 hat.

Pausierte automatische Upgrades

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

Pausierung automatischer Upgrades für Linux-Knoten

GKE pausiert automatische Upgrades auf Version 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, einen Wartungsausschluss zu erstellen, um Clusterupgrades zu verhindern. Der Wartungsausschluss sorgt dafür, dass Ihr Cluster nicht aktualisiert wird, wenn GKE keine Nutzung erkennt.

Nachdem Sie die Verwendung dieser Funktionen migriert haben, setzt GKE die automatischen 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-registry.configs-Eigenschaften.
  • 1.33 ist ein Ziel für automatische Upgrades 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 upgraden.

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 auf Windows Server-Knoten die eingestellten Funktionen verwendet werden.

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

Ende des Supports und Auswirkungen einer fehlenden 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 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 identifizieren

GKE überwacht Ihre Cluster und verwendet den Recommender-Dienst, um über Statistiken und Empfehlungen die Identifizierung von Linux-Knoten in Ihrem Cluster zu ermöglichen, die diese eingestellten Funktionen verwenden. GKE erkennt keine Nutzung von Windows Server-Knoten.

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, um Statistiken und Empfehlungen aufzurufen. 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: Eingestellte CRI-registry.configs-Properties, einschließlich registry.configs.auth und registry.configs.tls

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 und migriert werden müssen, und migrieren Sie diese Arbeitslasten.

Ein von Google bereitgestelltes Bild, das von diesem Problem betroffen ist, ist gcr.io/google-containers/startup-script.

  • gcr.io/google-containers/startup-script:v1: Verwendet das eingestellte 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: Das unterstützte Schema 2-Format wird verwendet und die Daten können abgerufen werden.

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

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 Informationen und Empfehlungen verwenden, um Cluster mit Linux-Knoten zu finden, die Docker-Schema 1-Images verwenden, wenn in Ihrem Cluster eine Mindestversion oder höher ausgeführt wird. Außerdem können Sie die folgende Abfrage in Cloud Logging verwenden, um in containerd-Logs nach Docker Schema 1-Images in Ihrem Cluster zu suchen:

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

Führen Sie den folgenden Befehl auf einem Knoten aus, um alle nicht gelöschten Bilder abzufragen, die als Schema 1 abgerufen wurden:

  ctr --namespace k8s.io images list 'labels."io.containerd.image/converted-docker-schema1"'

Dieser Befehl kann beispielsweise hilfreich sein, wenn Sie Probleme mit 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 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 für die Migration:

  • Ersatzbild suchen:Möglicherweise finden Sie ein öffentlich verfügbares Open-Source-Bild oder ein Bild, das vom Anbieter bereitgestellt wird.
  • 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. Das Docker-Image in containerd abrufen, wodurch es automatisch in ein OCI-Image konvertiert wird.
    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 identifizieren

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, ob Maßnahmen erforderlich sind.

Statistiken und Empfehlungen nutzen

Mithilfe von Statistiken und Empfehlungen können Sie Cluster mit Linux-Knoten finden, die die v1alpha2-API verwenden, wenn in Ihrem Cluster eine Mindestversion oder höher ausgeführt wird. Weitere Informationen finden Sie unter Betroffene Cluster ermitteln.

Wenn Sie sich die Statistiken in der Google Cloud -Konsole ansehen, 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).

Folgendes ist wichtig:

  • Die Liste der zu überprüfenden Arbeitslasten kann falsch positive Ergebnisse enthalten. Verwenden Sie sie nur für Untersuchungen. Wenn eine Arbeitslast in dieser Liste aufgeführt wird, bedeutet das nicht unbedingt, dass sie die verworfene API verwendet. Das Vorhandensein eines fälschlicherweise positiven Ergebnisses führt nicht dazu, dass automatische Upgrades pausiert werden. Das Pausieren basiert nur auf der tatsächlich beobachteten Nutzung der verworfenen API.
  • 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. Automatische Upgrades werden fortgesetzt, nachdem die Verwendung der verworfenen API 14 Tage lang nicht erkannt wurde.

Wir empfehlen daher, die tatsächliche API-Nutzung mit den folgenden Methoden zu überprüfen.

Betroffene Drittanbieter-Arbeitslasten prüfen

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 Google 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

Um genauer zu ermitteln, welche Arbeitslasten, die auf Linux-Knoten ausgeführt werden, die CRI v1alpha2 API aufrufen, können Sie zwei spezielle DaemonSets bereitstellen:

  • 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 protokolliert, wann die CRIv1alpha2 API zuletzt aufgerufen wurde.

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

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

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

Eine detaillierte Anleitung zur Bereitstellung und Verwendung dieser Tools sowie zur Interpretation 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 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 k8s.io/cri-api/pkg/apis/runtime/v1alpha2-Clientbibliothek importiert wird, 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, 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:

  1. Ermitteln Sie problematische Go-Anwendungen, 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 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 für die Verwendung von Version 1:

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

Von verworfenen containerd-Konfigurationsattributen migrieren

Die containerd-Konfigurationseigenschaften registry.auths, registry.configs und registry.mirrors im CRI-Plug-in sind veraltet 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 Techniken verwenden, um Arbeitslasten zu identifizieren, die migriert werden müssen.

Statistiken und Empfehlungen nutzen

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

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

kubectl verwenden

Alternativ können Sie Arbeitslasten mit kubectl identifizieren.

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

  • Arbeitslasten, die ein hostPath-Volume mit der containerd-Konfiguration enthalten
  • Arbeitslasten mit einem Container mit privilegiertem Zugriff (spec.containers.securityContext.privileged: true), die den Host-PID-Namespace (spec.hostPID: true) verwenden

Dieser Befehl kann fälschlicherweise positive Ergebnisse zurückgeben, 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-Properties 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.

In der folgenden Anleitung erfahren Sie, wie Sie Arbeitslasten ermitteln und migrieren, die die eingestellten Attribute auths oder configs.auth verwenden.

Authentifizierungsdetails für Ihre Registry suchen

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

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

Wenn Sie die Property registry.configs.auth verwenden, können die Authentifizierungsdetails so aussehen:

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

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

Arbeitslast für die Verwendung des Felds imagePullSecrets aktualisieren
  1. Erstellen Sie ein Secret mit Ihren Authentifizierungsdetails aus dem vorherigen Abschnitt, indem Sie der Anleitung zum Abrufen eines Images aus einer privaten Registry folgen.

  2. Ermitteln Sie mit dem folgenden Befehl, welche Arbeitslasten in das 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 Bildern aus dieser Registrierungsdomain verwendet wird, ein Secret erstellen.

  3. Aktualisieren Sie Ihre Arbeitslasten, damit das Feld imagePullSecrets mit den Secrets verwendet wird, 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 Feld imagePullSecrets 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, aktualisieren, damit keine Registry-Authentifizierungen mehr festgelegt werden. Ändern Sie alle Arbeitslasten, die die Konfiguration ändern, sodass keine Registry-Authentifizierungen mehr festgelegt werden.

Mit einem neuen Knotenpool testen und Arbeitslasten in den 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 verbleibenden Arbeitslasten in den neuen Knotenpool. Folgen Sie dazu der Anleitung zum Migrieren von Arbeitslasten zwischen Knotenpools.

Von der CRI-Registry-Property 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 zur Migration von Konfigurations-DaemonSets. Dazu gehen Sie so vor:

  1. Aktualisieren Sie Ihre Arbeitslasten, die die containerd-Konfiguration ändern, sodass keine TLS-Details mehr festgelegt werden.
  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 testen Sie, ob Ihre Arbeitslasten, die in der privaten Registry gehostete Images verwenden, wie erwartet funktionieren.
  5. Wenden Sie die Konfiguration auf einen neuen Cluster an und führen Sie die Arbeitslasten in diesem Cluster aus oder wenden Sie die Konfiguration auf den vorhandenen Cluster an. Das Anwenden der Konfiguration auf den vorhandenen Cluster kann möglicherweise andere vorhandene Arbeitslasten beeinträchtigen. Weitere Informationen zu diesen beiden Ansätzen finden Sie unter Laufzeitkonfigurationsdatei erstellen.

Nach der Migration sollten Sie keine Änderungen mehr am Feld registry.configs vornehmen, da sonst Probleme mit containerd auftreten können.

Support anfordern

Wenn Sie die Quelle der eingestellten API-Aufrufe immer noch nicht ermitteln können und die Empfehlungen weiterhin aktiv sind, sollten Sie Folgendes in Betracht ziehen: