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.
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.
Nach Möglichkeit platziert GKE jeden Pod mit erweiterter Laufzeit auf einem eigenen Knoten. Dadurch wird sichergestellt, 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.
Speichern Sie das folgende Manifest als 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
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.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2024-12-05 (UTC)."],[],[],null,["# Extend the run time of Autopilot Pods\n\n[Autopilot](/kubernetes-engine/docs/concepts/autopilot-overview)\n\n*** ** * ** ***\n\nThis page shows you how to request extended run times for Pods before they're\nevicted by Google Kubernetes Engine (GKE).\n\nAbout GKE-initiated Pod eviction\n--------------------------------\n\nPod evictions are a normal part of running workloads on Kubernetes.\nGKE evicts workloads during scheduled events, such as automatic\nnode upgrades and autoscaling scale-downs, to ensure that your nodes are\nup-to-date and optimized for efficient resource usage. By default,\nGKE sends a termination signal to the container as soon as the\nevent occurs, after which the container has a grace period to terminate before\nKubernetes evicts the Pod. For automatic node upgrades, the grace period\ncan be up to one hour. For scale-down events, the grace period can be up to\n10 minutes.\n\nKubernetes has built-in features that containers can use to gracefully handle\nevictions, such as\n[PodDisruptionBudgets](https://kubernetes.io/docs/tasks/run-application/configure-pdb/)\nand [graceful termination\nperiods](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination/).\nHowever, some workloads, such as batch queues or multiplayer game servers, need\nto run for a longer period of time before being evicted. The default grace\nperiod that GKE grants during GKE-initiated\nevictions might not be enough for these workloads. In these situations, you can\ntell Autopilot to avoid evicting specific workloads for up to 7 days.\n\n### Use cases\n\nSome situations in which you might want to tell GKE to avoid\nevicting workloads include the following:\n\n- You run multiplayer game servers that would kick players out of their sessions if the servers terminated early.\n- You run audio or video conferencing software that would disrupt in-progress meetings if the servers terminated.\n- You run tasks that need time to complete, and early termination would cause a loss of in-progress work.\n- You run a stateful service that is less tolerant to disruption and you want to minimize how often disruptions occur.\n\nPricing\n-------\n\nYou can request extended run times for your Pods at no additional charge.\nHowever, consider the following behavioral changes that might impact your\npricing:\n\n- Autopilot clusters enforce [higher minimum values](/kubernetes-engine/docs/concepts/autopilot-resource-requests#workload-separation) for the resource requests of extended duration Pods. Autopilot clusters charge you for the resource requests of your running Pods. You're not charged for system overhead or for unused node capacity.\n- Using extended duration Pods might increase the number of nodes in your cluster, which might affect IP address usage and scalability. If you have DaemonSets that run on every node, this results in more DaemonSets in the cluster,\n\nFor pricing details, see\n[Autopilot pricing](/kubernetes-engine/pricing#autopilot_mode).\n\nBefore you begin\n----------------\n\nBefore you start, make sure that you have performed the following tasks:\n\n- Enable the Google Kubernetes Engine API.\n[Enable Google Kubernetes Engine API](https://console.cloud.google.com/flows/enableapi?apiid=container.googleapis.com)\n- If you want to use the Google Cloud CLI for this task, [install](/sdk/docs/install) and then [initialize](/sdk/docs/initializing) the gcloud CLI. If you previously installed the gcloud CLI, get the latest version by running `gcloud components update`. **Note:** For existing gcloud CLI installations, make sure to set the `compute/region` [property](/sdk/docs/properties#setting_properties). If you use primarily zonal clusters, set the `compute/zone` instead. By setting a default location, you can avoid errors in the gcloud CLI like the following: `One of [--zone, --region] must be supplied: Please specify location`. You might need to specify the location in certain commands if the location of your cluster differs from the default that you set.\n\n\u003c!-- --\u003e\n\n- Ensure that you have an [Autopilot cluster](/kubernetes-engine/docs/how-to/creating-an-autopilot-cluster) running version 1.27 or later.\n\n### Limitations\n\n- You can't request extended run times for your Spot Pods.\n- Image pull times are counted when calculating the extended run time.\n- You can have a maximum of 50 extended duration workloads (with different CPU requests) in each cluster. This means that up to 50 different sets of CPU request values, after passing Autopilot resource minimums, ratios, and increment size checks, can have extended duration in each cluster.\n- You can't use Kubernetes inter-Pod affinity in extended duration Pods.\n- Whenever possible, GKE places each extended run time Pod on its own node. This behavior ensures that nodes can scale down if they're under-utilized.\n- You can't request extended run times for Pods that target [custom compute classes](/kubernetes-engine/docs/concepts/about-custom-compute-classes).\n\nRequest extended run time\n-------------------------\n\nTo request extended run time for a Pod, set the Kubernetes\n`cluster-autoscaler.kubernetes.io/safe-to-evict` annotation to `false` in the\nPod specification.\n\n1. Save the following manifest as `extended-deployment.yaml`:\n\n apiVersion: apps/v1\n kind: Deployment\n metadata:\n name: extended-pods\n labels:\n duration: extended\n spec:\n selector:\n matchLabels:\n duration: extended\n template:\n metadata:\n annotations:\n cluster-autoscaler.kubernetes.io/safe-to-evict: \"false\"\n labels:\n duration: extended\n spec:\n containers:\n - name: example-container\n image: registry.k8s.io/pause\n resources:\n requests:\n cpu: 200m\n\n2. Create the Deployment:\n\n kubectl create -f extended-deployment.yaml\n\nThe Pods continue to run for at least 7 days before a scale-down or a node\nauto-upgrade can occur.\n\nConsiderations and recommendations\n----------------------------------\n\nWhen you use this functionality, consider the following:\n\n- Extended duration Pods aren't protected from priority-based eviction. If you use [Kubernetes PriorityClasses](/kubernetes-engine/docs/how-to/capacity-provisioning), consider the following methods to minimize the probability of priority-based eviction:\n - Ensure that your extended duration Pods use the highest priority PriorityClass, so that other user Pods don't evict your extended duration Pods.\n - Use [workload separation](/kubernetes-engine/docs/how-to/workload-separation) to run extended duration Pods separately from other Pods.\n- System Pods run with the highest priority and will always be able to evict extended duration Pods. To minimize the probability of this, GKE schedules system Pods on the node before scheduling the extended duration Pod.\n- Extended duration Pods can still be evicted early in the following situations:\n - Eviction to make space for higher-priority user Pods (using a higher PriorityClass)\n - Eviction to make space for Kubernetes system components\n - [kubelet out-of-memory eviction](https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/) if the Pod uses more memory than it requested (OOMKill)\n - Compute Engine VM maintenance events. [Accelerator-optimized machine types](/compute/docs/accelerator-optimized-machines) are more likely to be affected by these events because those machines don't support [live migration](/compute/docs/instances/live-migration-process).\n - Node auto-repairs\n - User-initiated events such as draining a node\n- You can use the `cluster-autoscaler.kubernetes.io/safe-to-evict` annotation in Standard clusters, but the result is not the same. Pods run indefinitely even if a scale-down event occurs, preventing deletion of underutilized nodes and resulting in you continuing to pay for those nodes. Pods also aren't protected from evictions caused by node auto-upgrades.\n\nWhat's next\n-----------\n\n- [Use PriorityClasses to provision spare capacity in Autopilot for\n rapid Pod scaling](/kubernetes-engine/docs/how-to/capacity-provisioning)"]]
