이 페이지에서는 Google Kubernetes Engine(GKE)에서 포드를 삭제하기 전에 포드의 연장된 실행 시간을 요청하는 방법을 보여줍니다.
GKE에서 시작된 포드 제거 정보
포드 제거는 Kubernetes에서 워크로드 실행의 일반적인 부분입니다.
GKE는 자동 노드 업그레이드 및 자동 확장 축소와 같은 예약된 이벤트 동안 워크로드를 제거하여 노드가 최신 상태이고 효율적인 리소스 사용을 위해 최적화되도록 합니다. 기본적으로 GKE는 이벤트가 발생하는 즉시 컨테이너에 종료 신호를 보내고, 컨테이너는 Kubernetes가 포드를 제거하기 전에 종료할 유예 기간을 갖습니다. 자동 노드 업그레이드의 경우 유예 기간은 최대 1시간이 될 수 있습니다. 축소 이벤트의 경우 유예 기간은 최대 10분이 될 수 있습니다.
Kubernetes에는 PodDisruptionBudgets와 단계적 종료 기간과 같이 컨테이너가 제거를 정상적으로 처리하는 데 사용할 수 있는 기능이 내장되어 있습니다.
하지만 일괄 큐 또는 멀티플레이어 게임 서버와 같은 일부 워크로드는 제거되기 전에 더 오랜 시간 동안 실행되어야 합니다. GKE에서 시작된 제거 중 GKE가 부여하는 기본 유예 기간은 이러한 워크로드에 충분하지 않을 수 있습니다. 이러한 상황에서는 최대 7일 동안 특정 워크로드를 제거하지 않도록 Autopilot에 지시할 수 있습니다.
사용 사례
다음과 같은 경우에는 워크로드를 제거하지 않도록 GKE에 지시할 수 있습니다.
서버가 조기에 종료되면 플레이어를 세션에서 내보내는 멀티플레이어 게임 서버를 실행합니다.
서버가 종료된 경우 진행 중인 회의를 중단하는 오디오 또는 화상 회의 소프트웨어를 실행합니다.
완료하는 데 시간이 걸리는 작업을 실행하며, 조기 종료 시 진행 중인 작업이 손실됩니다.
중단에 대한 내결함성이 낮은 스테이트풀(Stateful) 서비스를 실행하며, 중단 발생 빈도를 최소화하려고 합니다.
가격 책정
포드의 연장된 실행 시간을 추가 비용 없이 요청할 수 있습니다.
그러나 가격 책정에 영향을 줄 수 있는 다음과 같은 동작 변경사항을 고려하세요.
Autopilot 클러스터는 기간이 연장된 포드의 리소스 요청에 더 높은 최솟값을 적용합니다. Autopilot 클러스터는 실행 중인 포드의 리소스 요청에 요금을 청구합니다. 시스템 오버헤드 또는 사용하지 않은 노드 용량에는 요금이 청구되지 않습니다.
기간이 연장된 포드를 사용하면 클러스터의 노드 수가 늘어날 수 있으며 이는 IP 주소 사용량 및 확장성에 영향을 줄 수 있습니다. 모든 노드에서 실행되는 DaemonSet가 있으면 클러스터에 DaemonSet가 더 많이 생성됩니다.
각 클러스터에는 최대 50개의 기간이 연장된 워크로드(서로 다른 CPU 요청 포함)가 있을 수 있습니다. 즉, Autopilot 리소스 최솟값, 비율, 증분 크기 검사를 통과한 후 최대 50개의 서로 다른 CPU 요청 값 집합이 각 클러스터에서 기간이 연장될 수 있습니다.
기간이 연장된 포드에서는 Kubernetes 포드 간 어피니티를 사용할 수 없습니다.
가능한 모든 경우에 GKE는 각 연장된 실행 시간 포드를 자체 노드에 배치합니다. 이 동작을 통해 사용률이 낮을 경우 노드가 축소될 수 있습니다.
연장 실행 시간 요청
포드의 연장된 실행 시간을 요청하려면 포드 사양에서 Kubernetes cluster-autoscaler.kubernetes.io/safe-to-evict 주석을 false로 설정합니다.
Compute Engine VM 유지보수 이벤트.
가속기 최적화 머신 유형은 해당 머신이 라이브 마이그레이션을 지원하지 않으므로 이러한 이벤트의 영향을 받을 가능성이 더 큽니다.
노드 자동 복구
노드 드레이닝과 같은 사용자 시작 이벤트
Standard 클러스터에서 cluster-autoscaler.kubernetes.io/safe-to-evict 주석을 사용할 수 있지만 결과가 동일하지 않습니다. 포드는 축소 이벤트가 발생하더라도 무기한 실행되므로 사용률이 낮은 노드가 삭제되지 않고 해당 노드에 대한 요금이 계속 청구됩니다. 포드는 또한 노드 자동 업그레이드로 인한 제거로부터 보호되지 않습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2024-11-29(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)"]]
