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

  • Arm-Knotenpools, auf denen Kubernetes-Versionen vor 1.24.8-gke.1300 ausgeführt werden, erhalten beim Erstellen des Knotenpools automatisch eine Markierung, um zu verhindern, dass Arm-Arbeitslasten auf Nicht-Arm-Knoten geplant werden. Arm-Knotenpools in Clustern mit Version 1.24.8-gke.1300 oder höher fügen diese Beschädigung nicht mehr hinzu. Wenn Sie von einem Cluster vor 1.24.8-gke.1300 auf eine neuere Version umstellen, müssen Sie diese Beschädigung selbst erstellen oder beim Upgrade anderweitig berücksichtigen.

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

  • Cluster mit der Kubernetes-Version 1.24 benötigen einen x86-Knotenpool, um den Connect-Agent auszuführen. Wenn in Ihrem Cluster die Kubernetes-Version 1.25 oder höher ausgeführt wird, ist kein x86-Knotenpool erforderlich.

Auf dieser Seite wird erläutert, wie Sie einen Arm-Knotenpool erstellen, warum Images mit mehreren Architekturen die empfohlene Methode zur Bereitstellung 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:

  • Einen vorhandenen 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 in Ihrem Cluster die Kubernetes-Version 1.24 ausgeführt wird, benötigen Sie einen x86-Knotenpool, um den Connect-Agenten auszuführen.

    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: einen der folgenden Instanztypen:

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

    • g5g

      Diese Instanztypen werden von Arm-basierten AWS Graviton-Prozessoren unterstützt. 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: 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: die Mindestanzahl von Knoten, die der Knotenpool enthalten kann

  • MAX_NODES: die maximale Anzahl von 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 aus 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 („multi-arch“) 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 es bereitgestellt wird. 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 mit einer einzelnen Architektur auf einem inkompatiblen Knoten planen, führt dies beim Laden zu einem Fehler.

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

Nächste Schritte