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 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 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 Migration von diesen Funktionen abgeschlossen haben, setzt GKE die automatischen Nebenversions-Upgrades auf Version 1.33 fort, wenn die folgenden Bedingungen erfüllt sind:

  • 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 automatisches Upgradeziel für Ihre Clusterknoten.
  • Es gibt keine anderen blockierenden Faktoren. Weitere Informationen finden Sie unter Zeitpunkt automatischer Upgrades.

Bei Knotenpools für Standardcluster 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 Google 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
  • 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, 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 die 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 Google Cloud -Konsole 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:

  • Die Liste der zu überprüfenden Arbeitslasten kann falsch positive Ergebnisse enthalten. Verwenden Sie sie nur zur Untersuchung. Wenn eine Arbeitslast in dieser Liste aufgeführt wird, bedeutet das nicht, dass sie definitiv 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 Nutzung der eingestellten 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 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 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 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 der letzte Aufruf der CRIv1alpha2 API protokolliert.

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 in Beziehung zu setzen.

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 über die 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 müssen Sie den Importpfad ändern und die Art und Weise 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 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, um v1 zu verwenden:

      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.2 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 mit Insights und Empfehlungen Cluster finden, in denen die eingestellten containerd-Konfigurationseigenschaften verwendet werden. Dafür ist eine Mindestversion von GKE erforderlich. Weitere Informationen zu diesem Ansatz finden Sie unter Betroffene Cluster identifizieren.

Wenn Sie sich die Statistiken in der Google Cloud Konsole ansehen, finden Sie in der Seitenleiste die Informationen 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 prü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 mit einem hostPath-Volume, das die containerd-Konfiguration enthält
  • 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 der Workload 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 gängige 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 für Ihre Arbeitslasten die Eigenschaften auths oder configs.auth in der containerd-Konfiguration verwendet werden, um sich bei einer privaten Registry zu authentifizieren, um Container-Images abzurufen, müssen Sie die Arbeitslasten, für die diese Images verwendet werden, stattdessen zum Feld imagePullSecrets migrieren. Weitere Informationen finden Sie unter Image aus einer privaten Registry abrufen.

Wenn Sie Arbeitslasten ermitteln und migrieren möchten, die die eingestellten Attribute auths oder configs.auth verwenden, folgen Sie der Anleitung unten.

Authentifizierungsdetails für Ihre Registry finden

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"

Erheben 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 Registry-Domain 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, so aktualisieren, dass keine Registry-Authentifizierungen mehr festgelegt werden. Ändern Sie alle Arbeitslasten, die die Konfiguration ändern, so, dass die Registry-Authentifizierungen nicht mehr festgelegt werden.

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 Ihre verbleibenden Arbeitslasten zum 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 Registrys 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. Wenn Sie die Konfiguration auf den vorhandenen Cluster anwenden, kann dies möglicherweise andere vorhandene Arbeitslasten beeinträchtigen. Weitere Informationen zu diesen beiden Ansätzen finden Sie unter Laufzeitkonfigurationsdatei 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 eingestellten API-Aufrufe immer noch nicht ermitteln können und die Empfehlungen weiterhin aktiv sind, sollten Sie Folgendes in Betracht ziehen:

  • Wenn Sie in der Dokumentation keine Lösung für Ihr Problem finden, lesen Sie den Abschnitt Support erhalten. Dort finden Sie weitere Informationen, unter anderem zu den folgenden Themen: