Halaman ini menunjukkan cara meminta runtime yang diperpanjang untuk Pod sebelum
dikeluarkan oleh Google Kubernetes Engine (GKE).
Tentang penghapusan Pod yang dimulai oleh GKE
Penghapusan pod adalah bagian yang normal saat menjalankan workload di Kubernetes.
GKE menghapus workload selama peristiwa terjadwal, seperti upgrade node otomatis dan penurunan skala penskalaan otomatis, untuk memastikan bahwa node Anda sudah yang terbaru dan dioptimalkan untuk penggunaan resource yang efisien. Secara default, GKE mengirimkan sinyal penghentian ke container segera setelah peristiwa terjadi, setelah itu container memiliki masa tenggang untuk berhenti sebelum Kubernetes mengeluarkan Pod. Untuk upgrade node otomatis, masa tenggang
dapat mencapai satu jam. Untuk peristiwa penurunan skala, masa tenggang dapat mencapai
10 menit.
Kubernetes memiliki fitur bawaan yang dapat digunakan container untuk menangani penghapusan dengan baik, seperti PodDisruptionBudgets dan periode penghentian secara tuntas.
Namun, beberapa workload, seperti antrean batch atau server game multiplayer, harus berjalan untuk jangka waktu yang lebih lama sebelum dikeluarkan. Masa tenggang
default yang diberikan GKE selama penghapusan
yang dimulai oleh GKE mungkin tidak cukup untuk workload ini. Dalam situasi ini, Anda dapat memberi tahu Autopilot untuk menghindari penghapusan workload tertentu hingga 7 hari.
Kasus penggunaan
Beberapa situasi yang dapat membuat Anda perlu memberi tahu GKE untuk menghindari penghapusan workload meliputi:
Anda menjalankan server game multiplayer yang akan mengeluarkan pemain dari sesi mereka jika server dihentikan lebih awal.
Anda menjalankan software konferensi audio atau video yang akan mengganggu rapat yang sedang berlangsung jika server dihentikan.
Anda menjalankan tugas yang memerlukan waktu untuk diselesaikan, dan penghentian lebih awal akan menyebabkan hilangnya pekerjaan yang sedang berlangsung.
Anda menjalankan layanan stateful yang tidak terlalu toleran terhadap gangguan dan Anda ingin meminimalkan frekuensi terjadinya gangguan.
Harga
Anda dapat meminta runtime yang diperpanjang untuk Pod Anda tanpa biaya tambahan.
Namun, pertimbangkan perubahan perilaku berikut yang dapat memengaruhi harga Anda:
Cluster autopilot menerapkan
nilai minimum yang lebih tinggi
untuk permintaan resource untuk Pod dengan durasi yang lebih lama. Cluster Autopilot menagih Anda untuk permintaan resource dari Pod yang sedang berjalan. Anda tidak dikenai biaya untuk overhead sistem atau kapasitas node yang tidak digunakan.
Menggunakan Pod dengan durasi yang diperpanjang dapat meningkatkan jumlah node dalam
cluster Anda, yang dapat memengaruhi penggunaan dan skalabilitas alamat IP. Jika Anda memiliki
DaemonSets yang berjalan pada setiap node, ini akan menghasilkan lebih banyak DaemonSets
dalam cluster,
Jika ingin menggunakan Google Cloud CLI untuk tugas ini,
instal lalu
lakukan inisialisasi
gcloud CLI. Jika sebelumnya Anda telah menginstal gcloud CLI, dapatkan versi terbaru dengan menjalankan gcloud components update.
Pastikan Anda memiliki
cluster Autopilot
yang menjalankan versi 1.27 atau yang lebih baru.
Batasan
Anda tidak dapat meminta waktu percobaan yang diperpanjang untuk Pod Spot Anda.
Waktu ambil image dihitung saat menghitung runtime yang diperpanjang.
Anda dapat memiliki maksimal 50 workload dengan durasi yang lebih lama (dengan permintaan CPU yang berbeda) di setiap cluster. Artinya, hingga 50 kumpulan nilai permintaan CPU
yang berbeda, setelah lulus pemeriksaan ukuran minimum, rasio,
dan penambahan ukuran resource Autopilot, dapat memperpanjang durasi di setiap cluster.
Anda tidak dapat menggunakan afinitas antar-Pod Kubernetes dalam Pod dengan durasi yang diperpanjang.
Jika memungkinkan, GKE akan menempatkan setiap Pod dengan waktu berjalan yang diperpanjang di node-nya sendiri. Perilaku ini memastikan bahwa node dapat di-scale down jika kurang dimanfaatkan.
Anda tidak dapat meminta waktu percobaan yang diperpanjang untuk Pod yang menargetkan class komputasi kustom.
Meminta perpanjangan runtime
Untuk meminta perpanjangan runtime untuk Pod, setel anotasi cluster-autoscaler.kubernetes.io/safe-to-evict
Kubernetes ke false di
spesifikasi Pod.
Simpan manifes berikut sebagai extended-deployment.yaml:
Pod akan terus berjalan minimal selama 7 hari sebelum penurunan skala atau upgrade otomatis
node dapat terjadi.
Pertimbangan dan rekomendasi
Saat Anda menggunakan fungsi ini, pertimbangkan hal-hal berikut:
Pod dengan durasi yang lebih lama tidak dilindungi dari penghapusan berbasis prioritas. Jika Anda menggunakan Kubernetes PriorityClasses, pertimbangkan metode berikut untuk meminimalkan kemungkinan penghapusan berbasis prioritas:
Pastikan Pod dengan durasi yang diperpanjang menggunakan prioritas tertinggi
PriorityClass, sehingga Pod pengguna lain tidak mengeluarkan Pod dengan durasi yang diperpanjang.
Gunakan
pemisahan workload
untuk menjalankan Pod dengan durasi yang diperpanjang secara terpisah dari Pod lainnya.
Pod Sistem berjalan dengan prioritas tertinggi dan akan selalu dapat menghapus
Pod dengan durasi yang diperpanjang. Untuk meminimalkan kemungkinan hal ini,
GKE menjadwalkan Pod sistem pada node sebelum menjadwalkan
Pod dengan durasi yang diperpanjang.
Pod dengan durasi yang lebih lama masih dapat dikeluarkan lebih awal dalam situasi
berikut:
Penghapusan untuk memberi ruang bagi Pod pengguna dengan prioritas lebih tinggi (menggunakan
PriorityClass yang lebih tinggi)
Penghapusan untuk menyediakan ruang bagi komponen sistem Kubernetes
Peristiwa yang dimulai pengguna seperti menghabiskan node
Anda dapat menggunakan anotasi cluster-autoscaler.kubernetes.io/safe-to-evict di
cluster Standard, tetapi hasilnya tidak sama. Pod berjalan tanpa batas waktu
meskipun terjadi peristiwa penurunan skala, sehingga mencegah penghapusan node
yang kurang dimanfaatkan dan menyebabkan Anda terus membayar node tersebut. Pod juga
tidak terlindungi dari penghapusan yang disebabkan oleh upgrade otomatis node.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-01 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)"]]
