Laufzeit von Autopilot-Pods verlängern

Auf dieser Seite wird beschrieben, wie Sie längere Laufzeiten für Pods anfordern, bevor sie von Google Kubernetes Engine (GKE) entfernt werden.

Von GKE initiierte Pod-Bereinigung

Pod-Bereinigungen sind ein normaler Teil der Ausführung von Arbeitslasten in Kubernetes. GKE bereinigt Arbeitslasten während geplanter Ereignisse wie automatischen Knotenupgrades und automatischen Herunterskalierungen, damit Ihre Knoten auf dem neuesten Stand sind und für eine effiziente Ressourcennutzung optimiert werden. Standardmäßig sendet GKE eine Beendigungsanfrage an den Container, sobald das Ereignis eintritt. Danach hat der Container einen Kulanzzeitraum, um sich zu beenden, bevor Kubernetes den Pod bereinigt. Bei automatischen Knotenupgrades kann der Kulanzzeitraum bis zu einer Stunde betragen. Bei Ereignissen mit Herunterskalieren kann der Kulanzzeitraum bis zu 10 Minuten betragen.

Kubernetes bietet integrierte Features, mit denen Container eine Bereinigung ordnungsgemäß ausführen können, z. B. PodDisruptionBudgets und ordnungsgemäße Beendigungszeiträume. Einige Arbeitslasten wie Batch-Warteschlangen oder Mehrspieler-Gameserver müssen jedoch länger ausgeführt werden, bevor sie entfernt werden. Der standardmäßige Kulanzzeitraum, die GKE bei von GKE initiierten Bereinigungen gewährt, ist für diese Arbeitslasten möglicherweise nicht ausreichend. In diesen Fällen können Sie Autopilot anweisen, bestimmte Arbeitslasten bis zu sieben Tage lang nicht zu entfernen.

Anwendungsfälle

Möglicherweise möchten Sie GKE anweisen, Arbeitslasten nicht zu entfernen:

  • Sie betreiben Multiplayer-Spiele-Server, die Spieler aus ihren Sitzungen werfen würden, wenn die Server vorzeitig beendet werden.
  • Sie führen Audio- oder Videokonferenzsoftware aus, die laufende Videokonferenzen stören würde, wenn die Server beendet werden.
  • Sie führen Aufgaben aus, die viel Zeit in Anspruch nehmen. Eine frühzeitige Beendigung würde zu einem Verlust der laufenden Arbeit führen.
  • Sie führen einen zustandsorientierten Dienst aus, der weniger tolerant gegenüber Störungen ist, und Sie möchten die Häufigkeit von Unterbrechungen minimieren.

Preise

Sie können für Ihre Pods kostenlos zusätzliche Laufzeiten anfordern. Beachten Sie jedoch die folgenden verhaltensbezogenen Änderungen, die sich auf Ihre Preise auswirken können:

  • Autopilot-Cluster erzwingen höhere Mindestwerte für die Ressourcenanfragen von Pods mit erweiterter Dauer. Autopilot-Cluster berechnen Ihnen die Ressourcenanfragen Ihrer ausgeführten Pods. Ihnen werden keine Kosten für den Systemaufwand oder die nicht verwendete Knotenkapazität in Rechnung gestellt.
  • Durch die Verwendung von Pods mit erweiterter Dauer kann die Anzahl der Knoten in Ihrem Cluster erhöht werden, was sich auf die Nutzung und Skalierbarkeit der IP-Adresse auswirken kann. Wenn auf jedem Knoten DaemonSets ausgeführt werden, führt dies zu mehr DaemonSets im Cluster.

Preisinformationen finden Sie unter Autopilot-Preise.

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.
  • Achten Sie darauf, dass Sie einen Autopilot-Cluster mit Version 1.27 oder höher haben.

Beschränkungen

  • Sie können keine längeren Laufzeiten für Ihre Spot-Pods anfordern.
  • Image-Pull-Zeiten werden bei der Berechnung der erweiterten Laufzeit berücksichtigt.
  • Jeder Cluster kann maximal 50 Arbeitslasten mit erweiterter Dauer (mit unterschiedlichen CPU-Anfragen) haben. Das bedeutet, dass bis zu 50 verschiedene Gruppen von CPU-Anfragewerten, nachdem sie die Autopilot-Ressourcen-Mindestwerte, -Verhältnisse und -Inkrementgrößenprüfungen bestanden haben, in jedem Cluster eine verlängerte Dauer haben können.
  • Sie können die Affinitäten zwischen Pods bei Kubernetes in Pods mit verlängerter Dauer nicht verwenden.
  • Wann immer möglich platziert GKE jeden Pod mit erweiterter Laufzeit auf einem eigenen Knoten. Dieses Verhalten gewährleistet, dass Knoten herunterskaliert werden können, wenn sie nicht ausgelastet sind.

Verlängerte Laufzeit anfordern

Zum Anfordern einer verlängerten Laufzeit für einen Pod legen Sie für die Kubernetes-Annotation cluster-autoscaler.kubernetes.io/safe-to-evict in der Pod-Spezifikation den Wert false fest.

  1. Speichern Sie das folgende Manifest als extended-deployment.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: extended-pods
  labels:
    duration: extended
spec:
  selector:
    matchLabels:
      duration: extended
  template:
    metadata:
      annotations:
        cluster-autoscaler.kubernetes.io/safe-to-evict: "false"
      labels:
        duration: extended
    spec:
      containers:
      - name: example-container
        image: registry.k8s.io/pause
        resources:
          requests:
            cpu: 200m

  2. Erstellen Sie das Deployment:

    kubectl create -f extended-deployment.yaml

Die Pods werden mindestens sieben Tage lang ausgeführt, bevor ein Herunterskalieren oder ein automatisches Knotenupgrade durchgeführt werden kann.

Überlegungen und Empfehlungen

Beachten Sie Folgendes, wenn Sie diese Funktion verwenden:

  • Pods mit verlängerter Dauer sind nicht vor Prioritätsbereinigung geschützt. Wenn Sie Kubernetes PriorityClasses verwenden, sollten Sie die folgenden Methoden berücksichtigen, um die Wahrscheinlichkeit einer prioritätsbasierten Bereinigung zu minimieren:
    • Achten Sie darauf, dass Ihre Pods mit verlängerter Dauer die höchste Prioritätspriorität verwenden, damit andere Nutzer-Pods die Pods mit verlängerter Dauer nicht entfernen.
    • Verwenden Sie die Arbeitslasttrennung, um Pods mit verlängerter Dauer getrennt von anderen Pods auszuführen.
  • System-Pods werden mit der höchsten Priorität ausgeführt und können Pods mit verlängerter Dauer immer entfernen. Zur Minimierung dieser Wahrscheinlichkeit plant GKE System-Pods auf dem Knoten, bevor der Pod für die verlängerte Dauer geplant wird.
  • In folgenden Situationen können Pods mit verlängerter Dauer immer noch vorzeitig entfernt werden:
    • Bereinigung, um Platz für Nutzer-Pods mit höherer Priorität zu schaffen (mithilfe einer höheren Prioritätsklasse)
    • Bereinigung, um Platz für Kubernetes-Systemkomponenten zu schaffen
    • Bereinigung wegen fehlendem Arbeitsspeicher bei Kubelet, wenn der Pod mehr Arbeitsspeicher verwendet als angefragt (OOMKill)
    • VM-Wartungsereignisse von Compute Engine Beschleunigeroptimierte Maschinentypen sind von diesen Ereignissen eher betroffen, da diese Maschinen keine Live-Migration unterstützen.
    • Automatische Knotenreparaturen
    • Vom Nutzer initiierte Ereignisse, z. B. das Leeren von Knoten
  • Sie können die Annotation cluster-autoscaler.kubernetes.io/safe-to-evict in Standardclustern verwenden, das Ergebnis ist jedoch nicht dasselbe. Pods laufen auf unbestimmte Zeit, selbst wenn ein Herunterskalierungsereignis eintritt, was das Löschen von nicht ausgelasteten Knoten verhindert und dazu führt, dass Sie weiterhin für diese Knoten bezahlen. Pods sind auch nicht vor Bereinigungen geschützt, die durch automatische Knotenupgrades verursacht werden.

Nächste Schritte