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.
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 Ihremkubectl 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 Ihremkubectl 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
.
Nächste Schritte
- Weitere Informationen zur Autopilot-Clusterarchitektur
- Lebenszyklus von Pods
- Spot-VMs in GKE-Standardclustern