Bereitstellung einer Arm-Arbeitslast in einem Standardcluster vorbereiten

Auf dieser Seite wird erläutert, wie Sie eine Arbeitslast vorbereiten, die auf Arm-Knoten in einem GKE-Standardcluster geplant werden soll. Weitere Informationen zum Planen von Arm-Arbeitslasten mit Autopilot finden Sie unter Autopilot-Arbeitslasten in der Arm-Architektur bereitstellen.

Um eine Arbeitslast erfolgreich auf einem Arm-Knoten zu planen, benötigen Sie Folgendes:

Übersicht

Standardmäßig plant GKE Arbeitslasten nur für x86-basierte Knoten (Compute Engine-Maschinenreihen mit Intel oder AMD-Prozessoren) durch Einfügen einer Markierung (kubernetes.io/arch=arm64:NoSchedule) auf allen Arm-Knoten. Diese Markierung verhindert, dass x86-kompatible Arbeitslasten versehentlich auf Ihren Arm-Knoten geplant werden. Sie können diese Standardmarkierung optional entfernen, wenn x86-kompatible Arbeitslasten auf Arm-Knoten geplant werden sollen, ohne dass die entsprechende Toleranz erforderlich ist. Weitere Informationen finden Sie unter Standardmarkierung für die Arm-Architektur konfigurieren.

Wenn Sie eine Arbeitslast auf einem Arm-Knoten mit der Standardmarkierung bereitstellen möchten, verwenden Sie die in diesem Dokument beschriebenen Felder, um den Planer anzuweisen, die Arbeitslast an den angeforderten Knotentyp zu senden.

Verwenden Sie eines der folgenden Felder:

Wenn Sie eine Knotenauswahl oder eine Knotenaffinitätsregel verwenden, plant GKE Ihre Armor-kompatiblen Arbeitslasten nur, wenn Sie angegeben haben, dass das Container-Image der Arbeitslast in der Knotenarchitektur ausgeführt werden kann.

Wenn Sie eine Arm-kompatible Arbeitslast mit einer Knotenauswahl oder mit einer Knotenaffinitätsregel planen, wie in den folgenden Abschnitten beschrieben, fügt GKE automatisch eine Toleranz zur Arbeitslastkonfiguration hinzu, sodass die Pods auf den Armknoten ausgeführt werden können.

Diese Toleranz, die der Arbeitslast hinzugefügt wird, entspricht der Markierung (kubernetes.io/arch=arm64:NoSchedule), die standardmäßig allen Arm-Knoten hinzugefügt wird, damit Ihre Arbeitslast auf Arm-Knoten geplant werden kann.

In einigen Situationen, z. B. wenn Sie Images mit mehreren Architekturen haben, die auf jedem Knoten ausgeführt werden können, möchten Sie diese Toleranz möglicherweise manuell der Arbeitslastkonfiguration hinzufügen. Eine Anleitung finden Sie unter Toleranz zum Planen von Arbeitslasten mit mehreren Architekturen für mehrere Architekturen verwenden.

Knotenauswahl mit der Knotenauswahl planen

Fügen Sie der Spezifikation die folgende Knotenauswahl hinzu:

nodeSelector:
    kubernetes.io/arch: arm64

Die Knotenauswahl gibt an, dass diese Arbeitslast nur für Knoten mit dem Label arm64 geplant werden soll, die alle Arm-Knoten in GKE-Clustern haben.

Wenn diese Knotenauswahl in der Arbeitslastkonfiguration enthalten ist, fügt GKE eine Toleranz hinzu, die mit der Markierung übereinstimmt. Auf diese Weise wird die Arbeitslast, die auf Armor-Knoten geplant werden soll, zugelassen.

Mit einer Knotenaffinitätsregel eine Arm-Arbeitslast planen

Sie können die Arbeitslast auch mit der Knotenaffinität planen.

Arbeitslast für eine einzelne Architektur planen

Fügen Sie der Spezifikation die folgende Knotenaffinität hinzu:

  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/arch
            operator: In
            values:
            - arm64

Die Knotenaffinitätsregel gibt an, dass die Arbeitslast nur für Knoten mit dem Label arm64 geplant werden soll, die alle Arm-knoten in GKE-Clustern haben.

Wenn diese Knotenaffinitätsregel in der Arbeitslastkonfiguration enthalten ist, fügt GKE eine Toleranz hinzu, die mit der Markierung übereinstimmt. Auf diese Weise wird die Arbeitslast, die auf Armor-Knoten geplant werden soll, zugelassen.

Arbeitslast auf x86- und ARM-Architekturen planen

Wenn Sie eine Arbeitslast sowohl für x86- (Intel- und AMD-Prozessoren) als auch für Arm-Architekturen planen möchten und Ihre Arm-Knotenpools das Standardverhalten für Markierungen verwenden, können Sie dies auf verschiedene Arten angeben. Bei den folgenden Anweisungen wird davon ausgegangen, dass Ihre Arm-Knotenpools die Standardmarkierung verwenden.

Toleranz für die Planung von Arbeitslasten für mehrere Architekturen für alle Architekturen verwenden

Wenn Sie ein Image für mehrere Architekturen haben, das für jeden verfügbaren Architekturtyp in einem Standardcluster geplant werden soll, müssen Sie nur die Toleranz zur Arbeitslastspezifikation hinzufügen. Sie benötigen die auf dieser Seite beschriebenen Knotenauswahl- oder Knotenaffinitätsregeln nicht, wenn die Arbeitslast für alle Architekturtypen geplant werden kann.

Fügen Sie die Toleranz hinzu:

  tolerations:
    - key: kubernetes.io/arch
      operator: Equal
      value: arm64
      effect: NoSchedule

Mit dieser Toleranz kann GKE eine Arbeitslast für Knoten mit einem beliebigen Architekturtyp planen.

Beispiel: Sie haben einen Cluster mit den folgenden Knotenpools:

  • my-c4a-node-pool mit c4a-standard-16-VMs (arm64).
  • my-c2-node-pool mit c2-standard-8-VMs (amd64).
  • my-t2d-node-pool mit t2-standard-48-VMs (amd64).

Wenn Sie in diesem Cluster eine Arbeitslast bereitstellen, die ein Image für mehrere Architekturen und die Toleranz arm64 in der Arbeitslastkonfiguration verwendet, kann GKE die Arbeitslast für alle Knotenpools planen.

Knotenaffinitätsregel zur Planung von Arbeitslasten mit mehreren Architekturen für jede Architektur verwenden

Wenn eine Arbeitslast auf Knoten für verschiedene Architekturtypen wie x86 und Arm geplant werden soll, können Sie auch eine Knotenaffinitätsregel verwenden. Mit Knotenaffinitätsregeln können Sie genau angeben, für welche Architekturtypen die Arbeitslast geplant werden soll. Dieser Ansatz wird für die Planung von Arbeitslasten in Autopilot-Clustern empfohlen. Weitere Informationen finden Sie unter Autopilot-Arbeitslasten in der Arm-Architektur bereitstellen.

Bei x86-basierten Arbeitslasten benötigen Sie keine Knotenauswahlen, Knotenaffinitätsregeln oder Toleranzen für die Planung der Arbeitslast. Wenn Sie ein Image haben, das nur auf x86-basierten Knoten geplant werden soll, müssen Sie diese Felder nicht verwenden.

Wenn Sie Arbeitslasten für jeden Architekturtyp planen möchten, listen Sie arm64 und amd64 im Abschnitt values des Knotenaffinitätsfelds auf. Der Wert amd64 enthält alle Knoten, die x86-Prozessoren nutzen.

Das folgende Beispiel zeigt, wie diese Arbeitslast auf Knoten mit Arm-Prozessoren oder x86-Prozessoren geplant werden kann:

  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/arch
            operator: In
            values:
            - arm64
            - amd64

Die Labels für jeden Architekturtyp lauten:

Beispiel: Sie haben einen Cluster mit den folgenden Knotenpools und der angegebenen Knotenaffinitätsregel:

  • my-c4a-node-pool mit c4a-standard-16-VMs (arm64).
  • my-c2-node-pool mit c2-standard-8-VMs (amd64).
  • my-t2d-node-pool mit t2-standard-48-VMs (amd64).

Wenn Sie in diesem Cluster eine Arbeitslast bereitstellen, die ein Image für mehrere Architekturen verwendet und die Knotenaffinität mit arm64 in der Liste values enthält, fügt GKE die Toleranz in der Arbeitslastkonfiguration hinzu und die Arbeitslast ist für alle Knotenpools planbar.

Standardmarkierung für die Arm-Architektur konfigurieren

Standardmäßig markiert GKE alle Arm-Knoten mit der Markierung kubernetes.io/arch=arm64:NoSchedule. Diese Markierung verhindert, dass Arbeitslasten, die nur mit der x86-Architektur, nicht aber mit der Arm-Architektur kompatibel sind, auf Arm-Knoten geplant werden. Wenn Sie Arbeitslasten haben, die sowohl mit x86 als auch mit Arm kompatibel sind, können Sie diese Markierung deaktivieren, damit GKE diese Arbeitslasten auf Arm-Knoten planen kann, ohne dass eine Toleranz erforderlich ist, die der Markierung entspricht.

Sie können das Standardverhalten nur in Standardknotenpools in GKE-Clustern aktualisieren, in denen auf der Steuerungsebene Version 1.35.0-gke.2141000 oder höher ausgeführt wird, oder mit Knoten, die für benutzerdefinierte ComputeClasses erstellt wurden. Weitere Informationen finden Sie unter Standardmarkierung für die Arm-Architektur konfigurieren. Die Aktualisierung des Markierungsverhaltens gilt nicht für die Bereitstellung von Arm-Arbeitslasten mit Autopilot. Weitere Informationen finden Sie unter Autopilot Arbeitslasten in der Arm Architektur bereitstellen.

Sie können dieses Verhalten in den folgenden Situationen mit Standardknotenpools konfigurieren:

  • Bei der Clustererstellung für den Standardknotenpool
  • Wenn Sie einen Standardknotenpool erstellen oder aktualisieren

Wenn im Cluster Arbeitslasten ausgeführt werden, die nicht mit Arm kompatibel sind, entfernen Sie die Standardmarkierung nicht, da inkompatible Arbeitslasten auf den nicht markierten Arm-Knoten geplant werden könnten.

Wählen Sie eine der folgenden Optionen aus, um die Standardmarkierung für Arm-Knoten zu konfigurieren:

gcloud CLI

Verwenden Sie das Flag --node-architecture-taint-behavior, um das Markierungsverhalten mit der gcloud CLI festzulegen, wenn Sie eine der folgenden Aktionen ausführen:

  • Erstellen Sie einen Standardcluster mit einem bestimmten Markierungsverhalten für den Standardknotenpool mit dem gcloud container cluster create Befehl:

    gcloud container cluster create CLUSTER_NAME
    --location=CONTROL_PLANE_LOCATION \
    --node-architecture-taint-behavior=BEHAVIOR

  • Erstellen Sie einen Standardknotenpool mit dem gcloud container node-pools create Befehl:

    gcloud container node-pools create POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --node-architecture-taint-behavior=BEHAVIOR

  • Aktualisieren Sie einen Standardknotenpool mit dem gcloud container node-pools update Befehl:

    gcloud container node-pools update POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --node-architecture-taint-behavior=BEHAVIOR

Ersetzen Sie in diesen Befehlen Folgendes:

  • CLUSTER_NAME: Der Name Ihres Clusters.
  • CONTROL_PLANE_LOCATION: Der Compute Engine Standort der Steuerungsebene Ihres Clusters. Geben Sie für regionale Cluster eine Region oder für zonale Cluster eine Zone an.
  • POOL_NAME: Der Name des Knotenpools.

  • BEHAVIOR: Eine der folgenden Einstellungen:

    • none: GKE lässt die Standardmarkierung kubernetes.io/arch=arm64:NoSchedule weg.
    • arm: Legt das Standardverhalten explizit fest, wodurch die Markierungen kubernetes.io/arch=arm64:NoSchedule für alle Knoten im Arm-Knotenpool hinzugefügt werden.

Wenn Sie das Markierungsverhalten für die Knotenarchitektur für einen Standardknotenpool ändern, aktualisiert GKE die Markierungen sofort, ohne dass die Knoten neu erstellt werden müssen.

Terraform

Fügen Sie den folgenden Block taint_config in node_config hinzu, um das Markierungsverhalten für die Architektur zu konfigurieren:

taint_config {
  architecture_taint_behavior = "BEHAVIOR"
}

Ersetzen Sie BEHAVIOR durch eine der folgenden Einstellungen:

  • NONE: GKE lässt die Standardmarkierung kubernetes.io/arch=arm64:NoSchedule weg.
  • ARM: Legt das Standardverhalten explizit fest, wodurch die Markierungen kubernetes.io/arch=arm64:NoSchedule für alle Knoten im Arm-Knotenpool hinzugefügt werden.

Eine vollständige node_config für einen Standardknotenpool, der diesen Block enthält, sieht so aus:

resource "google_container_node_pool" "primary_preemptible_nodes" {
  name       = "NODE_POOL_NAME"
  location   = "NODE_POOL_LOCATION"
  cluster    = google_container_cluster.primary.name
  node_count = 1

  node_config {
    preemptible  = true
    machine_type = "ARM_MACHINE_TYPE"

    # Google recommends custom service accounts that have cloud-platform scope and permissions granted via IAM Roles.
    service_account = google_service_account.default.email
    oauth_scopes    = [
      "https://www.googleapis.com/auth/cloud-platform"
    ]
    taint_config {
      architecture_taint_behavior = "BEHAVIOR"
    }
  }
}

In diesem Beispiel steht NODE_POOL_NAME für den Namen des Knotenpools und NODE_POOL_LOCATION für den Standort der Steuerungsebene des Clusters.

Arbeitslast bereitstellen

Nachdem Sie nun festgelegt haben, wo Ihre Arm-kompatiblen Arbeitslasten geplant werden sollen, können Sie Ihre Arbeitslast bereitstellen.

Wenn Sie eine Arbeitslast in einem GKE-Cluster bereitstellen, sind die Anweisungen für alle Architekturtypen identisch. Sie können eine Arm-kompatible Arbeitslast wie jede andere Arbeitslast bereitstellen, solange Sie die erforderlichen Schritte ausgeführt haben. Beispiele für die Bereitstellung von Arbeitslasten finden Sie auf den folgenden Seiten:

Fehlerbehebung

Allgemeine Fehler und Informationen zur Fehlerbehebung finden Sie unter Fehlerbehebung bei Arm-Arbeitslasten.

Nächste Schritte