Arm-Arbeitslasten in GKE on AWS ausführen

Mit GKE on AWS können Sie Arm-Arbeitslasten ausführen, die für Arm-basierte AWS Graviton-Prozessoren entwickelt wurden.

Beschränkungen

  • Bei Arm-Knotenpools, auf denen Kubernetes-Versionen vor 1.24.8-gke.1300 ausgeführt werden, wird beim Erstellen des Knotenpools automatisch eine Markierung hinzugefügt, um zu verhindern, dass Arm-Arbeitslasten auf Nicht-Arm-Knoten geplant werden. Bei Arm-Knotenpools in Clustern mit Version 1.24.8-gke.1300 oder höher wird dieser Taint nicht mehr hinzugefügt. Wenn Sie ein Upgrade von einem Cluster vor 1.24.8-gke.1300 ausführen, müssen Sie diesen Taint selbst erstellen oder ihn anderweitig beim Upgrade berücksichtigen.

  • Arm-Knotenpools in GKE on AWS unterstützen Cloud Service Mesh, Config Sync oder Policy Controller nicht. Sie müssen diese Produkte in einem x86-Knotenpool ausführen.

  • Für Cluster mit Kubernetes-Version 1.24 ist ein x86-Knotenpool erforderlich, um den Connect Agent auszuführen. Wenn auf Ihrem Cluster Kubernetes-Version 1.25 oder höher ausgeführt wird, benötigen Sie keinen x86-Knotenpool.

Auf dieser Seite wird erläutert, wie Sie einen Arm-Knotenpool erstellen, warum Images mit mehreren Architekturen die empfohlene Methode zum Bereitstellen von Arm-Arbeitslasten sind und wie Sie Arm-Arbeitslasten planen.

Hinweise

Bevor Sie Knotenpools für Ihre Arm-Arbeitslasten erstellen, benötigen Sie die folgenden Ressourcen:

  • Ein vorhandener AWS-Cluster, in dem der Knotenpool erstellt werden soll. Auf diesem Cluster muss Kubernetes-Version 1.24 oder höher ausgeführt werden.
  • Ein IAM-Instanzprofil für die Knotenpool-VMs.
  • Ein Subnetz, in dem die Knotenpool-VMs ausgeführt werden.

  • Wenn auf Ihrem Cluster Kubernetes-Version 1.24 ausgeführt wird, benötigen Sie einen x86-Knotenpool zum Ausführen des Connect-Agents.

    Weitere Informationen zum Erstellen eines Knotenpools in GKE on AWS finden Sie unter Knotenpool erstellen.

Arm-Knotenpool erstellen

GKE on AWS unterstützt Knotenpools, die auf dem minimalen Knoten-Image von Canonical Ubuntu arm64 und der containerd-Laufzeit basieren.

Führen Sie den folgenden Befehl aus, um einen Arm-Knotenpool zu erstellen und einem vorhandenen Cluster hinzuzufügen:

gcloud container aws node-pools create NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --instance-type INSTANCE_TYPE \
    --root-volume-size ROOT_VOLUME_SIZE \
    --iam-instance-profile NODEPOOL_PROFILE \
    --node-version NODE_VERSION \
    --min-nodes MIN_NODES \
    --max-nodes MAX_NODES \
    --max-pods-per-node MAX_PODS_PER_NODE \
    --location GOOGLE_CLOUD_LOCATION \
    --subnet-id NODEPOOL_SUBNET \
    --ssh-ec2-key-pair SSH_KEY_PAIR_NAME \
    --config-encryption-kms-key-arn CONFIG_KMS_KEY_ARN

Ersetzen Sie Folgendes:

  • NODE_POOL_NAME: der Name, den Sie für Ihren Knotenpool auswählen
  • CLUSTER_NAME: der Name des Clusters, an den der Knotenpool angehängt werden soll.

  • INSTANCE_TYPE: einer der folgenden Instanztypen:

    • m6g
    • m6gd
    • t4g
    • r6g
    • r6gd
    • c6g
    • c6gd
    • c6gn
    • x2gd
    • c7g
    • im4gn

    • g5g

      Diese Instanztypen basieren auf Arm-basierten AWS Graviton-Prozessoren. Sie müssen auch die gewünschte Instanzgröße angeben. Beispiel: m6g.medium Eine vollständige Liste finden Sie unter Unterstützte AWS-Instanztypen.

  • ROOT_VOLUME_SIZE: ist die gewünschte Größe für das Root-Volume jedes Knotens in Gb

  • NODEPOOL_PROFILE: ist das IAM-Instanzprofil für Knotenpool-VMs

  • NODE_VERSION: die Kubernetes-Version, die auf jedem Knoten im Knotenpool installiert werden soll. Sie muss Version 1.24 oder höher sein. Beispiel: 1.24.3-gke.200

  • MIN_NODES: ist die Mindestanzahl von Knoten, die der Knotenpool enthalten kann.

  • MAX_NODES: ist die maximale Anzahl an Knoten, die der Knotenpool enthalten darf.

  • MAX_PODS_PER_NODE: die maximale Anzahl von Pods, die auf einem einzelnen Knoten im Pool erstellt werden können

  • GOOGLE_CLOUD_LOCATION: der Name des Google Cloud

    Standort, von dem dieser Knotenpool verwaltet wird

  • NODEPOOL_SUBNET ist die ID des Subnetzes, in dem der Knotenpool ausgeführt wird. Wenn sich dieses Subnetz außerhalb des primären CIDR-Blocks der VPC befindet, sind zusätzliche Schritte erforderlich. Weitere Informationen finden Sie unter Sicherheitsgruppen.

  • SSH_KEY_PAIR_NAME ist der Name des AWS-SSH-Schlüsselpaars, das für den SSH-Zugriff erstellt wurde (optional).

  • CONFIG_KMS_KEY_ARN: ist der Amazon-Ressourcenname (ARN) des AWS KMS-Schlüssels, der Nutzerdaten verschlüsselt

Images mit mehreren Architekturen

Container-Images müssen mit der Architektur des Knotens kompatibel sein, auf dem Sie die Arm-Arbeitslasten ausführen möchten. Damit Ihr Container-Image Arm-kompatibel ist, empfehlen wir, Images mit mehreren Architekturen zu verwenden.

Ein Image für mehrere Architekturen ist ein Image, das mehrere Architekturen unterstützen kann. Es sieht wie ein einzelnes Image mit einem einzelnen Tag aus, enthält aber eine Reihe von Images, die auf verschiedenen Maschinenarchitekturen ausgeführt werden können. Images für mehrere Architekturen sind mit den Spezifikationen für Docker Image Manifest V2 Scheme 2 oder OCI Image Index kompatibel.

Wenn Sie ein Image für mehrere Architekturen in einem Cluster bereitstellen, wählt die Containerlaufzeit automatisch das Image aus, das mit der Architektur des Knotens kompatibel ist, auf dem Sie die Bereitstellung vornehmen. Sobald Sie ein Image für mehrere Architekturen für eine Arbeitslast haben, können Sie diese Arbeitslast über mehrere Architekturen hinweg bereitstellen. Wenn Sie ein Image für eine einzelne Architektur auf einem inkompatiblen Knoten planen, tritt beim Laden ein Fehler auf.

Weitere Informationen zur Verwendung von Images mit mehreren Architekturen mit Arm-Arbeitslasten finden Sie in der Google Kubernetes Engine-Dokumentation (GKE) unter Images mit mehreren Architekturen für Arm-Arbeitslasten erstellen.

Nächste Schritte