Diese Seite wurde von der Cloud Translation API übersetzt.

Führen Sie fehlertolerante Arbeitslasten zu geringeren Kosten in Spot-Pods aus

Autopilot

Auf dieser Seite erfahren Sie, wie Sie fehlertolerante Arbeitslasten zu geringeren Kosten ausführen können, indem Sie Spot Pods in Ihren Google Kubernetes Engine (GKE) Autopilot-Clustern verwenden.

Übersicht

In GKE Autopilot-Clustern sind Spot-Pods Pods, die auf Knoten ausgeführt werden, die von Compute Engine Spot-VMs unterstützt werden. Spot-Pods sind preislich günstiger als Standard-Autopilot-Pods, können aber von GKE entfernt werden, wenn Rechenressourcen benötigt werden, um Standard-Pods auszuführen.

Spot-Pods sind ideal für die Ausführung zustandsloser, Batch- oder fehlertoleranter Arbeitslasten zu geringeren Kosten im Vergleich zu einer Ausführung dieser Arbeitslasten auf Standard-Pods. Wenn Sie Spot-Pods in Autopilot-Clustern verwenden möchten, ändern Sie das Manifest mit Ihrer Pod-Spezifikation, um Spot-Pods anzufordern.

Sie können Spot-Pods mit der Standard-Compute-Klasse für Autopilot sowie mit speziellen Compute-Klassen ausführen, die bestimmte Hardwareanforderungen erfüllen. Informationen zu diesen Compute-Klassen finden Sie unter Compute-Klassen in Autopilot.

Weitere Informationen zu den Preisen für Spot-Pods in Autopilot-Clustern finden Sie unter Preise für Google Kubernetes Engine.

Spot-Pods sind vom Autopilot-Service Level Agreement ausgeschlossen.

Vorteile

Die Verwendung von Spot-Pods in Ihren Autopilot-Clustern bietet folgende Vorteile:

Niedrigere Preise als die Ausführung derselben Arbeitslasten auf standardmäßigen Autopilot-Pods.
GKE verwaltet automatisch Autoscaling und Planung.
GKE markiert Knoten automatisch, die Spot-Pods ausführen, damit Standard-Pods wie Ihre kritischen Arbeitslasten nicht auf diesen Knoten geplant werden. Ihre Bereitstellungen, die Spot-Pods verwenden, werden automatisch mit einer entsprechenden Toleranz aktualisiert.

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 diesen Task 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 dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.
Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI das compute/region-Attribut fest. Wenn Sie hauptsächlich zonale Cluster verwenden, legen Sie stattdessen compute/zone fest. Wenn Sie einen standardmäßigen Speicherort festlegen, können Sie in der gcloud CLI Fehler wie diesen vermeiden: One of [--zone, --region] must be supplied: Please specify location. Bei bestimmten Befehlen müssen Sie möglicherweise den Speicherort angeben, wenn er sich von dem von Ihnen festgelegten Standard unterscheidet.

Spot-Pods in Ihren Autopilot-Arbeitslasten anfordern

Wenn Sie anfordern möchten, dass Ihre Pods als Spot-Pods ausgeführt werden, verwenden Sie das Label cloud.google.com/gke-spot=true in einem nodeSelector oder Knotenaffinität in der Pod-Spezifikation. GKE stellt automatisch Knoten bereit, die Spot-Pods ausführen können.

Spot-Pods können jederzeit entfernt und beendet werden, z. B. wenn die Rechenressourcen an anderer Stelle in Google Clouderforderlich sind. Wenn eine Beendigung auftritt, können Spot-Pods auf dem beendenden Knoten einen Kulanzzeitraum von bis zu 15 Sekunden vor der Beendigung anfordern. Dies wird auf Best-Effort-Basis durch Festlegen des Feldes terminationGracePeriodSeconds gewährt.

Der maximale Kulanzzeitraum für Spot-Pods während des vorzeitigen Beendens beträgt 15 Sekunden. Wenn Sie in terminationGracePeriodSeconds mehr als 15 Sekunden anfordern, werden während des vorzeitigen Beendens nicht mehr als 15 Sekunden gewährt. Bei der Bereinigung wird Ihrem Pod das SIGTERM-Signal gesendet, was die Schritte zum Herunterfahren während des Kulanzzeitraums einleitet.

Für Autopilot markiert GKE auch automatisch die Knoten, die zum Ausführen von Spot-Pods erstellt wurden, und ändert diese Arbeitslasten mit der entsprechenden Toleranz. Die Markierung verhindert, dass Standard-Pods auf Knoten geplant werden, die Spot-Pods ausführen.

Mit nodeSelector die Spot-Pods erforderlich machen

Sie können einen nodeSelector verwenden, um Spot-Pods in einem Deployment erforderlich zu machen. Fügen Sie dem Deployment das Label cloud.google.com/gke-spot=true hinzu, wie im folgenden Beispiel gezeigt:

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    metadata:
      labels:
        app: pi
    spec:
      nodeSelector:
        cloud.google.com/gke-spot: "true"
      terminationGracePeriodSeconds: 15
      containers:
      - name: pi
        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

Mit Knotenaffinität die Spot-Pods anfordern

Alternativ können Sie Spot-Pods mit Knotenaffinität anfordern. Die Knotenaffinität bietet Ihnen eine umfangreichere Möglichkeit, Knoten zum Ausführen Ihrer Arbeitslasten auszuwählen. Sie können beispielsweise mehrere Auswahlkriterien kombinieren, um eine genauere Kontrolle darüber zu erhalten, wo Ihre Pods ausgeführt werden. Wenn Sie Spot-Pods zur Knotenaffinität verwenden, können Sie die Art der zu verwendenden Knotenaffinität so angeben:

requiredDuringSchedulingIgnoredDuringExecution: Spot-Pods müssen verwendet werden.
preferredDuringSchedulingIgnoredDuringExecution: Spot-Pods auf Best-Effort-Basis verwenden.

Wenn Sie Spot-Pods in einem Deployment anfordern möchten, fügen Sie Ihrem Deployment-Manifest die folgende nodeAffinity-Regel hinzu:

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    metadata:
      labels:
        app: pi
    spec:
      terminationGracePeriodSeconds: 15
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: cloud.google.com/gke-spot
                operator: In
                values:
                - "true"
      containers:
      - name: pi
        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

Spot-Pods auf Best-Effort-Basis anfordern

Verwenden Sie preferredDuringSchedulingIgnoredDuringExecution, um Spot-Pods auf Best-Effort-Basis anzufordern. Wenn Sie Spot-Pods auf bevorzugte Weise anfordern, plant GKE Ihre Pods in folgender Reihenfolge:

Vorhandene Knoten, die Spot-Pods ausführen können, die eine zuweisbare Kapazität haben.
Vorhandene Standardknoten mit verfügbaren zuweisbaren Kapazitäten.
Neue Knoten, die Spot-Pods ausführen können, sofern die Rechenressourcen verfügbar sind.
Neue Standardknoten.

Da GKE vorhandene Standardknoten mit zuweisbarer Kapazität gegenüber der Erstellung neuer Knoten für Spot-Pods bevorzugt, werden möglicherweise mehr Pods als Standard-Pods ausgeführt als als Spot-Pods. Dadurch können Sie die Vorteile der niedrigeren Preise für Spot-Pods eventuell nicht voll ausschöpfen.

Anfragen für Pods auf Abruf

Autopilot-Cluster unterstützen Anfragen für Pods auf Abruf. Dazu wird die Auswahl cloud.google.com/gke-preemptible verwendet. Pods, die diesen Selektor verwenden, werden automatisch zu Spot-Pods migriert und der Selektor wird in cloud.google.com/gke-spot geändert.

Beendete Pods suchen und löschen

Während der ordnungsgemäßen Pod-Beendigung weist das Kubelet den beendeten Pods den Status Failed und den Grund Shutdown zu. Wenn die Anzahl der beendeten Pods einen Schwellenwert von 1.000 erreicht, bereinigt die automatische Speicherbereinigung die Pods. Sie können Shutdown-Pods mit dem folgenden Befehl auch manuell löschen:

kubectl get pods --all-namespaces | grep -i shutdown | awk '{print $1, $2}' | xargs -n2 kubectl delete pod -n

Verhindern, dass Arbeitslasten Spot-Pods verwenden

Wenn Sie vorhandene Spot-Pods aktualisieren möchten, damit sie als Standard-Pods ausgeführt werden, können Sie eine der folgenden Methoden verwenden:

Arbeitslast neu erstellen: Löschen Sie das Deployment, entfernen Sie die Zeilen im Manifest, die Spot-Pods auswählen, und wenden Sie dann das aktualisierte Deployment-Manifest auf den Cluster an.
Arbeitslast bearbeiten: Bearbeiten Sie die Deployment-Spezifikation, während die Pods im Cluster ausgeführt werden.

Bei beiden Methoden kann es zu geringfügigen Unterbrechungen der Arbeitslast kommen.

Arbeitslast neu erstellen

In den folgenden Schritten wird beschrieben, wie Sie die vorhandene Bereitstellung löschen und ein aktualisiertes Manifest auf den Cluster anwenden. Sie können diese Schritte auch für andere Arten von Kubernetes-Arbeitslasten wie Jobs verwenden.

Damit GKE die aktualisierten Pods auf dem richtigen Knotentyp platziert, müssen Sie den vorhandenen Status der Arbeitslast vom Kubernetes API-Server in eine Datei exportieren und diese Datei bearbeiten.

Schreiben Sie die Arbeitslastspezifikation in eine YAML-Datei:
```
kubectl get deployment DEPLOYMENT_NAME -o yaml > DEPLOYMENT_NAME-on-demand.yaml
```
Ersetzen Sie DEPLOYMENT_NAME durch den Namen Ihres Deployments. Verwenden Sie für andere Arten von Arbeitslasten wie Jobs oder Pods den entsprechenden Ressourcennamen in Ihrem kubectl get-Befehl, z. B. kubectl get pod.
Öffnen Sie die YAML-Datei in einem Texteditor:
```
vi DEPLOYMENT_NAME-on-demand.yaml
```

Entfernen Sie den nodeSelector für Spot-Pods und die Toleranz, die GKE für Spot-Pods hinzugefügt hat, aus der Datei:

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
  # lines omitted for clarity
spec:
  progressDeadlineSeconds: 600
  replicas: 6
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      pod: nginx-pod
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
    # lines omitted for clarity
    spec:
      containers:
      - image: nginx
        imagePullPolicy: Always
        name: web-server
        resources:
          limits:
            ephemeral-storage: 1Gi
          requests:
            cpu: 500m
            ephemeral-storage: 1Gi
            memory: 2Gi
        securityContext:
          capabilities:
            drop:
            - NET_RAW
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      nodeSelector:
        cloud.google.com/gke-spot: "true"
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext:
        seccompProfile:
          type: RuntimeDefault
      terminationGracePeriodSeconds: 15
      tolerations:
      - effect: NoSchedule
        key: kubernetes.io/arch
        operator: Equal
        value: amd64
      - effect: NoSchedule
        key: cloud.google.com/gke-spot
        operator: Equal
        value: "true"
status:
  #lines omitted for clarity

Sie müssen sowohl die Toleranz als auch den nodeSelector entfernen, um GKE mitzuteilen, dass die Pods auf On-Demand-Knoten und nicht auf Spot-Knoten ausgeführt werden müssen.

Speichern Sie das aktualisierte Manifest.
Löschen Sie das Bereitstellungsmanifest und wenden Sie es noch einmal auf den Cluster an:
```
kubectl replace -f DEPLOYMENT_NAME-on-demand.yaml
```
Die Dauer dieses Vorgangs hängt von der Anzahl der Pods ab, die GKE beenden und bereinigen muss.

Arbeitslast direkt bearbeiten

In den folgenden Schritten wird gezeigt, wie Sie ein laufendes Deployment direkt bearbeiten, um GKE mitzuteilen, dass die Pods auf On-Demand-Knoten ausgeführt werden müssen. Sie können diese Schritte auch für andere Arten von Kubernetes-Arbeitslasten wie Jobs verwenden.

Sie müssen das Arbeitslastobjekt in der Kubernetes API bearbeiten, da GKE der Arbeitslastspezifikation während der Arbeitslastzulassung automatisch eine Toleranz für Spot-Pods hinzufügt.

Öffnen Sie das Arbeitslastmanifest zum Bearbeiten in einem Texteditor:
```
kubectl edit deployment/DEPLOYMENT_NAME
```
Ersetzen Sie DEPLOYMENT_NAME durch den Namen des Deployments. Verwenden Sie für andere Arten von Arbeitslasten wie Jobs oder Pods den entsprechenden Ressourcennamen in Ihrem kubectl edit-Befehl, z. B. kubectl edit pod/POD_NAME.

Löschen Sie im Texteditor den Knotenselektor oder die Knotenaffinitätsregel für Spot-Pods und die Toleranz, die GKE dem Manifest hinzugefügt hat, wie im folgenden Beispiel:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      type: dev
  template:
    metadata:
      labels:
        type: dev
    spec:
      nodeSelector:
        cloud.google.com/gke-spot: "true"
      tolerations:
      - effect: NoSchedule
        key: cloud.google.com/gke-spot
        operator: Equal
        value: "true"
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

Speichern Sie das aktualisierte Manifest und schließen Sie den Texteditor. Die aktualisierte Objektkonfiguration weist GKE darauf hin, dass die Pods auf On-Demand-Knoten ausgeführt werden müssen. GKE erstellt die Pods neu, um sie auf neuen On-Demand-Knoten zu platzieren.

Prüfen, ob Arbeitslasten auf On-Demand-Knoten ausgeführt werden

So prüfen Sie, ob Ihre aktualisierten Arbeitslasten nicht mehr auf Spot-Pods ausgeführt werden:

Arbeitslast prüfen:

kubectl describe deployment DEPLOYMENT_NAME

Die Ausgabe enthält keinen Eintrag für cloud.google.com/gke-spot im Feld spec.tolerations.