Autopilot-Arbeitslasten in der Arm-Architektur bereitstellen

Auf dieser Seite erfahren Sie, wie Sie Ihre GKE-Autopilot-Bereitstellungen (Google Kubernetes Engine) konfigurieren, um Knoten anzufordern, die von Arm-Architektur unterstützt werden.

Über Arm-Architektur in Autopilot

Autopilot-Cluster bieten Compute-Klassen für Arbeitslasten, die bestimmte Hardwareanforderungen haben. Einige dieser Rechenklassen unterstützen mehrere CPU-Architekturen wie amd64 und arm64.

Anwendungsfälle für Arm-Knoten

Knoten mit der Arm-Architektur bieten eine kostengünstigere Leistung als ähnliche x86-Knoten. Sie sollten Arm für Ihre Autopilot-Arbeitslasten in Situationen wie der folgenden auswählen:

  • Ihre Umgebung basiert auf der Arm-Architektur zum Erstellen und Testen.
  • Sie entwickeln Anwendungen für Android-Geräte, die auf Arm-CPUs ausgeführt werden.
  • Sie verwenden Images für mehrere Architekturen und möchten die Kosten optimieren, während Sie Ihre Arbeitslasten ausführen.

Hinweise

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.

Arm-Knoten im Autopilot anfordern

Damit Autopilot Ihre Pods auf Arm-Knoten ausführt, geben Sie eines der folgenden Labels in einer nodeSelector- oder Knotenaffinitätsregel an:

  • kubernetes.io/arch: arm64. GKE platziert Pods standardmäßig auf T2A-Maschinentypen. Wenn keine T2A-Maschinen verfügbar sind, platziert GKE Pods auf C4A-Maschinentypen.
  • cloud.google.com/machine-family: ARM_MACHINE_SERIES: Replace ARM_MACHINE_SERIES with an Arm machine series like C4A or T2A. GKE platziert Pods in der angegebenen Reihe.

Wenn Sie eines der Labels verwenden, kann GKE standardmäßig andere Pods auf demselben Knoten platzieren, wenn dort Kapazität verfügbar ist. Wenn Sie einen dedizierten Knoten für jeden Pod anfordern möchten, fügen Sie Ihrem Manifest das Label cloud.google.com/compute-class: Performance hinzu. Weitere Informationen finden Sie unter Autopilot-Pod-Leistung durch Auswahl einer Maschinenreihe optimieren.

Alternativ können Sie das Label Scale-Out mit dem Label arm64 verwenden, um T2A anzufordern. Sie können auch die Arm-Architektur für Spot-Pods anfordern.

Zum Bereitstellen Ihrer Arbeitslast führt Autopilot Folgendes aus:

  1. Stellt automatisch Arm-Knoten bereit, um Ihre Pods auszuführen.
  2. Die neuen Knoten werden automatisch markiert, damit keine Nicht-Arm-Pods auf diesen Knoten geplant werden.
  3. Fügt Ihren Arm-Pods automatisch eine Toleranz hinzu, um die Planung auf den neuen Knoten zu ermöglichen.

Beispielanfrage für die Arm-Architektur

Die folgenden Beispielspezifikationen zeigen, wie Sie einen Knotenselektor oder eine Knotenaffinitätsregel verwenden, um die Arm-Architektur in Autopilot anzufordern.

nodeSelector

Das folgende Beispielmanifest zeigt, wie Sie Arm-Knoten in einem nodeSelector anfordern:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-arm
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-arm
  template:
    metadata:
      labels:
        app: nginx-arm
    spec:
      nodeSelector:
        cloud.google.com/compute-class: Performance
        kubernetes.io/arch: arm64
      containers:
      - name: nginx-arm
        image: nginx
        resources:
          requests:
            cpu: 2000m
            memory: 2Gi

nodeAffinity

Sie können Arm-Knoten mithilfe der Knotenaffinität anfordern. Sie können auch den Typ der zu verwendenden Knotenaffinität angeben:

  • requiredDuringSchedulingIgnoredDuringExecution muss die angegebene Compute-Klasse und Architektur verwenden.
  • preferredDuringSchedulingIgnoredDuringExecution: Verwenden Sie die angegebene Computing-Klasse und -Architektur auf Best-Effort-Basis. Wenn beispielsweise ein vorhandener x86-Knoten zuweisbar ist, platziert GKE Ihren Pod auf dem x86-Knoten, anstatt einen neuen Arm-Knoten bereitzustellen. Wenn Sie kein Image-Manifest für mehrere Architekturen verwenden, stürzt Ihr Pod ab. Wir empfehlen dringend, die gewünschte Architektur explizit anzufordern.

Das folgende Beispielmanifest erfordert die Klasse Performance und die Arm-Knoten:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-arm
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-arm
  template:
    metadata:
      labels:
        app: nginx-arm
    spec:
      terminationGracePeriodSeconds: 25
      containers:
      - name: nginx-arm
        image: nginx
        resources:
          requests:
            cpu: 2000m
            memory: 2Gi
            ephemeral-storage: 1Gi
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: cloud.google.com/compute-class
                operator: In
                values:
                - Performance
              - key: kubernetes.io/arch
                operator: In
                values:
                - arm64

Empfehlungen

  • Images für mehrere Architekturen als Teil Ihrer Pipeline erstellen und verwenden. Images für mehrere Architekturen sorgen dafür, dass Ihre Pods auch dann ausgeführt werden, wenn sie auf x86-Knoten platziert werden.
  • Fordern Sie explizit Architektur und Compute-Klassen in Ihren Arbeitslastmanifesten an. Wenn nicht, verwendet Autopilot die Standardarchitektur der ausgewählten Compute-Klasse, die möglicherweise nicht "Arm" ist.

Verfügbarkeit

Sie können Autopilot-Arbeitslasten in der Arm-Architektur an Google Cloud-Standorten bereitstellen, die die Arm-Architektur unterstützen. Weitere Informationen finden Sie unter verfügbare Regionen und Zonen.

Fehlerbehebung

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

Nächste Schritte