VMs auf Abruf ausführen


Auf dieser Seite finden Sie einen Überblick über die Unterstützung von VMs auf Abruf in Google Kubernetes Engine (GKE).

Übersicht

VMs auf Abruf sind Compute Engine-VM-Instanzen, im Allgemeinen mit einer maximalen Gültigkeit von 24 Stunden, jedoch ohne Verfügbarkeitsgarantien. Sie sind preisgünstiger als standardmäßige Compute Engine-VMs und bieten die gleichen Maschinentypen und Optionen.

Sie können mithilfe von präemptiven VMs in GKE-Clustern oder Knotenpools Batch- oder fehlertolerante Jobs ausführen, die hinsichtlich der schwankenden Verfügbarkeit präemptiver VMs unempfindlicher sind.

Weitere Informationen zu VMs auf Abruf finden Sie unter VMs auf Abruf in der Compute Engine-Dokumentation.

Funktionsweise präemptiver VMs

In GKE-Clustern oder -Knotenpools erstellte Compute Engine-VMs verhalten sich wie eine verwaltete Instanzgruppe. VMs auf Abruf in GKE unterliegen den gleichen Einschränkungen wie Instanzen auf Abruf in einer verwalteten Instanzgruppe. Instanzen auf Abruf werden 30 Sekunden nach Erhalt eines Hinweises auf vorzeitiges Beenden beendet.

Zusätzlich erhalten die VMs auf Abruf das Kubernetes-Label cloud.google.com/gke-preemptible=true. Kubernetes-Labels können im Feld nodeSelector für die Planung von Pods für bestimmte Knoten verwendet werden.

Beispielselektor zum Filtern präemptiver VMs:

apiVersion: v1
kind: Pod
spec:
  nodeSelector:
    cloud.google.com/gke-preemptible: "true"

Kubernetes-Knoten auf Abruf

Bei GKE-Knoten auf Abruf mit Version 1.20 oder höher ist die Kubelet-Funktion zum ordnungsgemäßen Herunterfahren von Knoten standardmäßig aktiviert. Infolgedessen erkennt Kubelet ein vorzeitiges Beenden und beendet Pods ordnungsgemäß.

Auf Best-Effort-Basis werden Nutzer-Pods 25 Sekunden für eine ordnungsgemäße Beendigung (mit terminationGracePeriodSeconds angefordert) und dann für System-Pods (die mit system-cluster-critical oder system-node-critical Prioritäts-Klassen) werden für ihre ordnungsgemäße Beendigung fünf Sekunden gewährt.

Geben Sie für Pods auf präemptiven Knoten nicht mehr als 25 Sekunden für terminationGracePeriodSeconds an, da diese Pods während des vorzeitigen Beendens nur 25 Sekunden erhalten.

Wenn das Kubelet Pods während des Herunterfahrens von Knoten auf Abruf beendet, wird den Pods der Status Failed und der Grund Shutdown zugewiesen. Diese Pods werden bei der nächsten automatischen Speicherbereinigung bereinigt. 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

Verstöße gegen Kubernetes-Einschränkungen

Die Verwendung von VMs auf Abruf auf der GKE macht einige Kubernetes-Garantien ungültig. Die folgenden Einschränkungen werden von VMs auf Abruf geändert:

  • Das vorzeitige Beenden von Knoten fährt Pods ohne vorherigen Hinweis herunter und ignoriert den konfigurierten Pod-Kulanzzeitraum, wenn das ordnungsgemäße Knoten herunterfahren nicht aktiviert ist (vor Version 1.20).
  • In der Dokumentation "Budget zur Pod-Unterbrechung" heißt es: "Das Budget kann nur vor freiwilligen Bereinigungen schützen, nicht aber vor sämtlichen Gründen, die zu einer Nichtverfügbarkeit führen." Vorzeitiges Beenden ist nicht freiwillig. Daher kann es zu einer höheren Nichtverfügbarkeit kommen, als im Budget für die Pod-Unterbrechung angegeben ist.

Best Practices

Da präemptive VMs keine Verfügbarkeitsgarantien haben, sollten Sie Ihr System unter der Annahme erstellen, dass eine oder alle Compute Engine-Instanzen präemptiv sein könnten und nicht verfügbar werden. Außerdem gibt es keine Garantien dafür, wann neue Instanzen verfügbar werden.

Darüber hinaus ist nicht gewährleistet, dass auf VMs auf Abruf ausgeführte Pods immer ordnungsgemäß heruntergefahren werden können. Es kann einige Minuten dauern, bis GKE erkennt, dass der Knoten zuvor gesperrt wurde und die Pods nicht mehr ausgeführt werden, was die Neuplanung der Pods auf einen neuen Knoten verzögert.

Wenn Sie möchten, dass Ihre Jobs oder Arbeitslasten verarbeitet werden, auch wenn keine VMs auf Abruf verfügbar sind, können Sie in einem Cluster auf Abruf und nicht auf Abruf verfügbare Knotenpools erstellen.

Obwohl Knotennamen im Allgemeinen gleich bleiben, falls und wenn sie nach dem vorzeitigen Beenden ersetzt werden, können sich die internen und externen IPs von VMs auf Abruf bei einer vorzeitigen Beendigung ändern.

Verwenden Sie keine VMs auf Abruf mit zustandsorientierten Pods, da diese die in StatefulSets enthaltene Semantik von höchstens eins verletzen und zu Datenverlust führen können.

Planung von VM-Knoten auf Abruf durch Einsatz von Knotenmarkierungen vermeiden

Verwenden Sie eine Knotenmarkierung, damit keine kritischen Pods auf einem VM-Knoten auf Abruf geplant und somit Systemunterbrechungen vermieden werden.

Wenn Sie Knotenmarkierungen anwenden, achten Sie darauf, dass Ihr Cluster auch Knoten ohne Markierungen enthält, die nicht auf Abruf verfügbar sind, damit es immer einen Knotenpool von Standard-VMs gibt, auf denen Systemkomponenten wie DNS ausgeführt werden können.

Knoten für VMs auf Abruf markieren

Führen Sie den folgenden Befehl aus, um einem Knoten mit VMs auf Abruf eine Knotenmarkierung hinzuzufügen:

kubectl taint nodes node-name cloud.google.com/gke-preemptible="true":NoSchedule

Dabei ist node-name der Name des Knotens.

Jetzt werden für den Knoten nur Pods geplant, die die Knotenmarkierung tolerieren.

Toleranz von Pods erweitern

Fügen Sie der Spezifikation des Pods oder der Pod-Vorlagenspezifikation des Objekts die folgende Anweisung hinzu, um den Pods die relevante Toleranz hinzuzufügen:

tolerations:
- key: cloud.google.com/gke-preemptible
  operator: Equal
  value: "true"
  effect: NoSchedule

GPU-Knotenmarkierungen auf Abruf

Sie sollten den Cluster mit Knoten erstellen, die nicht auf Abruf sind, bevor Sie einen GPU-Knotenpool auf Abruf hinzufügen. Dadurch wird gewährleistet, dass immer ein Knotenpool mit Standard-VMs vorhanden ist, auf dem Systemkomponenten wie DNS ausgeführt werden können, bevor GPU-Knotenpools auf Abruf hinzugefügt werden.

Befinden sich keine anderen Knotenpools im Cluster, wenn dem Cluster ein Knotenpool auf Abruf mit GPUs hinzugefügt wird, wird ihm nicht die normale Markierung nvidia.com/gpu=present:NoSchedule zugewiesen. Das gilt auch, wenn ein Cluster direkt mit einem GPU-Knotenpool auf Abruf erstellt wird. System-Pods werden also auf den Knoten auf Abruf geplant, was bei einem vorzeitigen Beenden störend sein kann. Diese Pods verbrauchen auch Ressourcen auf GPU-Knoten. Das vergeudet nicht nur Kapazität, sondern auch Geld, da GPU-Knoten teurer sind als Nicht-GPU-Knoten.

Cluster oder Knotenpool mit VMs auf Abruf erstellen

Mit dem gcloud-Befehlszeilentool oder der Cloud Console können Sie einen Cluster oder Knotenpool mit VMs auf Abruf erstellen.

gcloud

Sie können einen Cluster oder Knotenpool mit VMs auf Abruf erstellen, indem Sie das Flag --preemptible angeben.

Führen Sie den folgenden Befehl aus, um einen Cluster mit VMs auf Abruf zu erstellen:

gcloud container clusters create cluster-name --preemptible

Dabei ist cluster-name der Name des zu erstellenden Clusters.

Führen Sie den folgenden Befehl aus, um einen Knotenpool mit VMs auf Abruf zu erstellen:

gcloud container node-pools create pool-name --preemptible \
    --cluster cluster-name

Dabei gilt:

  • pool-name ist der Name des zu erstellenden Knotenpools.
  • cluster-name ist der Name des Clusters für den Knotenpool.

Console

  1. Rufen Sie in der Cloud Console die Seite Google Kubernetes Engine auf.

    Zur Seite "Google Kubernetes Engine"

  2. Klicken Sie auf Erstellen.

  3. Konfigurieren Sie den Cluster wie gewünscht.

  4. Klicken Sie im Navigationsbereich unter Knotenpools für den Knotenpool, den Sie konfigurieren möchten, auf Knoten.

  5. Klicken Sie das Kästchen Knoten auf Abruf aktivieren an.

  6. Klicken Sie auf Erstellen.

Nächste Schritte