Von Docker zu containerd-Knoten-Images migrieren


Auf dieser Seite erfahren Sie, wie Sie Ihren GKE-Standardcluster (Google Kubernetes Engine) und die Knotenpools zu Knoten-Images migrieren, die die containerd-Containerlaufzeit verwenden.

Übersicht

Kubernetes-Knoten verwenden die Containerlaufzeit, um Container zu starten, zu verwalten und zu beenden, die in Pods ausgeführt werden. Die Containerd-Laufzeit ist eine dem Branchenstandard entsprechende Containerlaufzeit, die von GKE unterstützt wird.

Die containerd-Laufzeit bietet die Schichtenabstraktion, die die Implementierung einer Vielzahl von Features wie gVisor und Image-Streaming ermöglicht, um die GKE-Funktionalität zu erweitern. Die containerd-Laufzeit gilt als ressourceneffizienter und sicherer als die Docker-Laufzeit.

So migrieren Sie Ihre Containerlaufzeit:

  • Knoten identifizieren, die die Docker-Laufzeit verwenden
  • Auswirkungen der Migration prüfen
  • Knoten-Image ändern

Hinweis

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
  • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.

Knoten identifizieren, die die Docker-Laufzeit verwenden

Mit den folgenden Methoden können Sie prüfen, welche Knoten Docker-basierte Knoten-Images verwenden:

  • Verwenden Sie ein Script, um alle Knoten in allen GKE-Clustern in Ihrem Google Cloud-Projekt zu iterieren.
  • Verwenden Sie die Google Cloud CLI, kubectl oder die Google Cloud Console, um Knoten-Images zu identifizieren.
  • Verwenden Sie Informationen und Empfehlungen zur Einstellung, um Cluster und Knoten in bestimmten Zonen oder Regionen in einem Google Cloud-Projekt zu identifizieren.

Wir empfehlen, mithilfe eines Skripts schnell alle Knoten zu identifizieren, die Sie migrieren müssen.

Script zum Identifizieren von Docker-Knoten verwenden

Das folgende Script testet jeden Knoten in jedem Cluster in den verfügbaren Projekten. Dadurch erhalten Sie umsetzbare Empfehlungen wie:

  • Ob die automatische Knotenbereitstellung für Docker-Images konfiguriert ist
  • Vorgeschlagene containerd-Knoten-Image-Entsprechungen für die Migration
  • Vorgeschlagene Knoten-Image-Versionen für die Migration
  • Vorgeschlagene Befehle, um die identifizierten Knoten und Einstellungen zu migrieren

Das Skript ignoriert GKE Autopilot-Cluster, die standardmäßig Container-Optimized OS mit containerd-Knoten-Image verwenden.

Führen Sie das folgende Skript aus:

for project in $(gcloud projects list --format="value(projectId)")
do
  echo "ProjectId: $project"
  for clusters in $( \
    gcloud container clusters list \
      --project $project \
      --format="csv[no-heading](name,location,autopilot.enabled,currentMasterVersion,autoscaling.enableNodeAutoprovisioning,autoscaling.autoprovisioningNodePoolDefaults.imageType)")
  do
    IFS=',' read -r -a clustersArray <<< "$clusters"
    cluster_name="${clustersArray[0]}"
    cluster_zone="${clustersArray[1]}"
    cluster_isAutopilot="${clustersArray[2]}"
    cluster_version="${clustersArray[3]}"
    cluster_minorVersion=${cluster_version:0:4}
    cluster_autoprovisioning="${clustersArray[4]}"
    cluster_autoprovisioningImageType="${clustersArray[5]}"

    if [ "$cluster_isAutopilot" = "True" ]; then
      echo "  Cluster: $cluster_name (autopilot) (zone: $cluster_zone)"
      echo "    Autopilot clusters are running Containerd."
    else
      echo "  Cluster: $cluster_name (zone: $cluster_zone)"

      if [ "$cluster_autoprovisioning" = "True" ]; then
        if [ "$cluster_minorVersion"  \< "1.20" ]; then
          echo "    Node autoprovisioning is enabled, and new node pools will have image type 'COS'."
          echo "    This settings is not configurable on the current version of a cluster."
          echo "    Please upgrade you cluster and configure the default node autoprovisioning image type."
          echo "    "
        else
          if [ "$cluster_autoprovisioningImageType" = "COS" ]; then
            echo "    Node autoprovisioning is configured to create new node pools of type 'COS'."
            echo "    Run the following command to update:"
            echo "    gcloud container clusters update '$cluster_name' --project '$project' --zone '$cluster_zone' --enable-autoprovisioning --autoprovisioning-image-type='COS_CONTAINERD'"
            echo "    "
          fi

          if [ "$cluster_autoprovisioningImageType" = "UBUNTU" ]; then
            echo "    Node autoprovisioning is configured to create new node pools of type 'UBUNTU'."
            echo "    Run the following command to update:"
            echo "    gcloud container clusters update '$cluster_name' --project '$project' --zone '$cluster_zone' --enable-autoprovisioning --autoprovisioning-image-type='UBUNTU_CONTAINERD'"
            echo "    "
          fi
        fi
      fi

      for nodepools in $( \
        gcloud container node-pools list \
          --project $project \
          --cluster $cluster_name \
          --zone $cluster_zone \
          --format="csv[no-heading](name,version,config.imageType)")
      do
        IFS=',' read -r -a nodepoolsArray <<< "$nodepools"
        nodepool_name="${nodepoolsArray[0]}"
        nodepool_version="${nodepoolsArray[1]}"
        nodepool_imageType="${nodepoolsArray[2]}"

        nodepool_minorVersion=${nodepool_version:0:4}

        echo "    Nodepool: $nodepool_name, version: $nodepool_version ($nodepool_minorVersion), image: $nodepool_imageType"

        minorVersionWithRev="${nodepool_version/-gke./.}"
        linuxGkeMinVersion="1.14"
        windowsGkeMinVersion="1.21.1.2200"

        suggestedImageType="COS_CONTAINERD"

        if [ "$nodepool_imageType" = "UBUNTU" ]; then
          suggestedImageType="UBUNTU_CONTAINERD"
        elif [ "$nodepool_imageType" = "WINDOWS_LTSC" ]; then
          suggestedImageType="WINDOWS_LTSC_CONTAINERD"
        elif [ "$nodepool_imageType" = "WINDOWS_SAC" ]; then
          suggestedImageType="WINDOWS_SAC_CONTAINERD"
        fi

        tab=$'\n      ';
        nodepool_message="$tab Please update the nodepool to use Containerd."
        nodepool_message+="$tab Make sure to consult with the list of known issues https://cloud.google.com/kubernetes-engine/docs/concepts/using-containerd#known_issues."
        nodepool_message+="$tab Run the following command to upgrade:"
        nodepool_message+="$tab "
        nodepool_message+="$tab gcloud container clusters upgrade '$cluster_name' --project '$project' --zone '$cluster_zone' --image-type '$suggestedImageType' --node-pool '$nodepool_name'"
        nodepool_message+="$tab "

        # see https://cloud.google.com/kubernetes-engine/docs/concepts/node-images
        if [ "$nodepool_imageType" = "COS_CONTAINERD" ] || [ "$nodepool_imageType" = "UBUNTU_CONTAINERD" ] ||
           [ "$nodepool_imageType" = "WINDOWS_LTSC_CONTAINERD" ] || [ "$nodepool_imageType" = "WINDOWS_SAC_CONTAINERD" ]; then
          nodepool_message="$tab Nodepool is using Containerd already"
        elif ( [ "$nodepool_imageType" = "WINDOWS_LTSC" ] || [ "$nodepool_imageType" = "WINDOWS_SAC" ] ) &&
               [ "$(printf '%s\n' "$windowsGkeMinVersion" "$minorVersionWithRev" | sort -V | head -n1)" != "$windowsGkeMinVersion" ]; then
          nodepool_message="$tab Upgrade nodepool to the version that supports Containerd for Windows"
        elif [ "$(printf '%s\n' "$linuxGkeMinVersion" "$minorVersionWithRev" | sort -V | head -n1)" != "$linuxGkeMinVersion" ]; then
          nodepool_message="$tab Upgrade nodepool to the version that supports Containerd"
        fi
        echo "$nodepool_message"
      done
    fi # not autopilot
  done
done

# Sample output:
#
# ProjectId:  my-project-id
#  Cluster: autopilot-cluster-1 (autopilot) (zone: us-central1)
#    Autopilot clusters are running Containerd.
#  Cluster: cluster-1 (zone: us-central1-c)
#    Nodepool: default-pool, version: 1.18.12-gke.1210 (1.18), image: COS
#
#       Please update the nodepool to use Containerd.
#       Make sure to consult with the list of known issues https://cloud.google.com/kubernetes-engine/docs/concepts/using-containerd#known_issues.
#       Run the following command to upgrade:
#
#       gcloud container clusters upgrade 'cluster-1' --project 'my-project-id' --zone 'us-central1-c' --image-type 'COS_CONTAINERD' --node-pool 'default-pool'
#
#    Nodepool: pool-1, version: 1.18.12-gke.1210 (1.18), image: COS
#
#       Please update the nodepool to use Containerd.
#       Make sure to consult with the list of known issues https://cloud.google.com/kubernetes-engine/docs/concepts/using-containerd#known_issues.
#       Run the following command to upgrade:
#
#       gcloud container clusters upgrade 'cluster-1' --project 'my-project-id' --zone 'us-central1-c' --image-type 'COS_CONTAINERD' --node-pool 'pool-1'
#
#    Nodepool: winpool, version: 1.18.12-gke.1210 (1.18), image: WINDOWS_SAC
#
#       Upgrade nodepool to the version that supports Containerd for Windows
#
#  Cluster: another-test-cluster (zone: us-central1-c)
#    Nodepool: default-pool, version: 1.20.4-gke.400 (1.20), image: COS_CONTAINERD
#
#      Nodepool is using Containerd already
#

Knoten-Images mit Google Cloud identifizieren

Sie können die Knoten-Images mit der Google Cloud CLI, kubectl oder der Google Cloud Console auf vorhandene Knoten prüfen.

gcloud

Führen Sie dazu folgenden Befehl aus:

gcloud container node-pools list \
    --cluster=CLUSTER_NAME \
    --format="table(name,version,config.imageType)"

Ersetzen Sie CLUSTER_NAME durch den Namen Ihres Clusters.

Die Ausgabe sieht in etwa so aus:

NAME          NODE_VERSION    IMAGE_TYPE
default-pool  1.19.6-gke.600  UBUNTU

Console

  1. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

    Zur Seite "Google Kubernetes Engine"

  2. Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie ändern möchten.

  3. Wählen Sie den Tab Knoten aus.

  4. Prüfen Sie im Abschnitt Knotenpools den Wert in der Spalte Image-Typ.

kubectl

Führen Sie dazu folgenden Befehl aus:

kubectl get nodes -o wide

Die Ausgabe sieht in etwa so aus:

# For Docker runtime
NAME         STATUS   VERSION             OS-IMAGE                             CONTAINER-RUNTIME
gke-node-1   Ready    v1.16.15-gke.6000   Container-Optimized OS from Google   docker://19.3.1
gke-node-2   Ready    v1.16.15-gke.6000   Container-Optimized OS from Google   docker://19.3.1
gke-node-3   Ready    v1.16.15-gke.6000   Container-Optimized OS from Google   docker://19.3.1

Der Wert in der Spalte CONTAINER-RUNTIME gibt die Laufzeit und Version an.

Cluster mithilfe von Informationen und Empfehlungen zur Einstellung ermitteln

GKE erkennt die Verwendung einiger verworfener Features und APIs, einschließlich Docker-basierter Knoten-Images. Weitere Informationen finden Sie unter Verworfene Komponenten von GKE.

Zur Erkennung der Nutzung verworfener Features generiert GKE Informationen und Empfehlungen, die die Nutzung von Docker-basierten Knoten-Images mit dem Statistikuntertyp DEPRECATION_K8S_1_24_DOCKERSHIM identifizieren.

Eine Kombination aus Information und Empfehlung identifiziert einen Cluster mit solchen Knoten, die Docker-basierte Knoten-Images verwenden. Jedes Information/Empfehlung-Paar enthält eine Liste der spezifischen Knotenpools in einem Cluster, die Docker-basierte Knoten-Images verwenden und zu containerd-Knoten-Images migriert werden müssen.

Folgen Sie der Anleitung zum Aufrufen von Informationen und Empfehlungen zur Einstellung. Verwenden Sie für die gcloud CLI--Befehle das folgende Flag, um nur Informationen zu dieser Einstellung anzusehen:

--filter="insightSubtype:DEPRECATION_K8S_1_24_DOCKERSHIM"

Nachdem Sie ermittelt haben, welche Knotenpools von Clustern Docker-basierte Knoten-Images verwenden, folgen Sie der Anleitung Knoten-Image in ein containerd-Knoten-Image ändern.

Auswirkungen einer Migration prüfen

Bevor Sie Ihre Produktionscluster und Knotenpools zu Knoten-Images migrieren, die containerd verwenden, empfehlen wir Ihnen dringend, die Auswirkungen der Migration in einer Staging-Umgebung zu testen, um das Risiko zu minimieren.

Wir empfehlen, die Knoten unabhängig von der Knotenaktualisierung zu migrieren, damit Sie Variablen beim Überprüfen der Arbeitslasten mit der neuen Konfiguration isolieren können. Wenn Sie außerdem gleichzeitig den Knotenpool auf Version 1.24 aktualisieren, können Sie die Änderung nicht rückgängig machen, da Docker-Knoten von 1.24 nicht unterstützt werden und Sie keine Downgrades von Nebenversionen ausführen können.

Knoten-Image in ein containerd-Image ändern

Wenn Sie das Script zum Identifizieren Ihrer Docker-Knoten verwendet haben, können Sie die vom Script zurückgegebenen vorgeschlagenen Befehle verwenden, um die Einstellungen für die automatische Knotenbereitstellung und Ihre Knoten-Images in die containerd-Entsprechungen zu ändern.

Sie können Knoten auch von einem Docker-Image-Typ zu einem containerd-Image-Typ migrieren. Aktualisieren Sie dazu den Knotenpool und legen Sie über die gcloud CLI oder die Google Cloud Console ein anderes Image fest.

GKE verwendet die ausgewählte Upgradestrategie und Konfiguration für den Knoten, um das Image eines Knotens zu migrieren. Für diese Migration empfehlen wir die Verwendung derBlau/Grün-Upgradestrategie. Wenn bei Ihren Arbeitslasten während des Upgrades Probleme mit dem neuen Knoten-Image auftreten, können Sie ein Rollback auf die vorherige Umgebung mit der ursprünglichen Knoten-Image-Konfiguration durchführen.

gcloud

Führen Sie dazu diesen Befehl aus:

gcloud container clusters upgrade CLUSTER_NAME \
    --image-type=NODE_IMAGE \
    --node-pool=POOL_NAME \
    --cluster-version=NODE_VERSION

Dabei gilt:

  • NODE_IMAGE: das Knoten-Image, das von den Knoten verwendet werden soll
  • POOL_NAME: der Name des zu migrierenden Knotenpools
  • NODE_VERSION: Vorhandene Version des Knotenpools. Wir empfehlen, dieses Flag festzulegen, da GKE andernfalls versucht, die Version des Knotenpools auf die Version der Steuerungsebene umzustellen und das Knoten-Image im selben Vorgang zu aktualisieren. Wenn auf der Steuerebene Version 1.24 ausgeführt wird, schlägt der Befehl fehl. Wird auf der Steuerungsebene 1.23 ausführt, ist der Befehl erfolgreich, sodass Sie die beiden Änderungen (Versionsupgrade und Image-Update) nicht isoliert testen können.

Die Ausgabe sieht in etwa so aus:

NAME          NODE_VERSION    IMAGE_TYPE
default-pool  1.23.6-gke.600  UBUNTU_CONTAINERD

Console

  1. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

    Zu „Google Kubernetes Engine“

  2. Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie ändern möchten.

  3. Klicken Sie auf den Tab Knoten.

  4. Klicken Sie im Bereich Knotenpools auf den Namen des Knotenpools, dessen Größe Sie anpassen möchten.

  5. Klicken Sie auf der Seite Knotenpooldetails auf Bearbeiten.

  6. Klicken Sie im Abschnitt Knoten unter Image-Typ auf Ändern.

  7. Wählen Sie einen der containerd-Image-Typen aus.

  8. Klicken Sie auf Ändern.

Zu Docker-Knoten-Images zurückkehren

Wenn Ihre Knoten automatisch oder manuell zu containerd-Knoten migriert wurden und ein Problem mit Ihren Arbeitslasten aufgetreten ist, führen Sie die folgenden Schritte aus, um zu Docker-Knoten-Images zurückzukehren:

  1. Wählen Sie je nach Status des Vorgangs den folgenden Schritt aus:
  2. Konfigurieren Sie einen Wartungsausschluss, um zu verhindern, dass GKE die Migration vorübergehend wiederholt.
  3. Prüfen Sie die Ursache des Problems, damit Sie von Docker migrieren können, und prüfen Sie, ob auf Ihrem Cluster eine unterstützte Version von GKE ausgeführt wird.
  4. Versuchen Sie noch einmal, das Knoten-Image in ein containerd-Image zu ändern. Wenn Sie den Wartungsausschluss entfernen, löst GKE den Vorgang noch einmal aus.

Konfigurationen von IaC-Tools (Infrastructure as Code) aktualisieren

Wenn Sie IaC-Tools wie Terraform, Ansible oder Pulumi zum Verwalten von GKE-Clustern verwenden, müssen Sie Ihre Konfigurationen so aktualisieren, dass containerd-Knoten-Images verwendet werden, um zu verhindern, dass die Tools den zuvor gewünschten Status mit dem neuen tatsächlichen Status abgleichen. Der GKE Terraform-Anbieter unterstützt beispielsweise konfigurierbare Bildtypen.

Aktualisieren Sie alle Konfigurationen, damit das Tool das Knoten-Image nach der Migration zu containerd-Knoten-Images nicht wieder auf ein Docker-basiertes Knoten-Image aktualisiert.

Standardknoten-Image für die automatische Knotenbereitstellung ändern

Wenn Sie die automatische Knotenbereitstellung in Ihrem Cluster verwenden, ändern Sie den Standard-Image-Typ in ein containerd-Knoten-Image. Das Ändern des Standard-Image-Typs gilt nur für neue automatisch bereitgestellte Knotenpools. Sie müssen das Knoten-Image für vorhandene automatisch bereitgestellte Knotenpools manuell ändern.

Sie können den Standard-Image-Typ der automatischen Knotenbereitstellung über die gcloud CLI oder eine Konfigurationsdatei ändern.

gcloud

Führen Sie dazu diesen Befehl aus:

gcloud container clusters update CLUSTER_NAME \
    --enable-autoprovisioning \
    --autoprovisioning-image-type=IMAGE_TYPE

Dabei gilt:

  • CLUSTER_NAME: der Name des Clusters, der aktualisiert werden soll.
  • IMAGE_TYPE: der Knoten-Image-Typ. Dies kann einer der folgenden sein:

    • cos_containerd
    • ubuntu_containerd

Datei

Mit einer YAML-Konfigurationsdatei können Sie den Standard-Knoten-Image-Typ für die automatische Knotenbereitstellung ändern. Wenn Sie eine Datei verwenden, müssen Sie auch Maximalwerte für CPU- und Arbeitsspeicherressourcen angeben.

  1. Speichern Sie die folgende YAML-Datei:

    resourceLimits:
      - resourceType: 'cpu'
          minimum: 4
          maximum: 10
      - resourceType: 'memory'
          maximum: 64
    autoprovisioningNodePoolDefaults:
      imageType: 'IMAGE_TYPE'
    

    Ersetzen Sie IMAGE_TYPE durch den containerd-Image-Typ.

  2. Wenden Sie die Konfiguration an:

    gcloud container clusters update CLUSTER_NAME \
        --enable-autoprovisioning \
        --autoprovisioning-config-file=FILE_NAME
    

    Ersetzen Sie FILE_NAME durch den Pfad zur Konfigurationsdatei.

Fehlerbehebung

Informationen zur Fehlerbehebung und zu bekannten Problemen bei Problemumgehungen finden Sie unter Fehlerbehebung für die Containerlaufzeit.

Nächste Schritte