Scheduling, Preemption and Eviction

쿠버네티스에서는 Scheduling, Preemption 및 Eviction을 통해 노드의 자원 사용을 최적화합니다.

• Scheduling: 쿠버네티스는 Pod를 실행할 적합한 노드를 선택하는 프로세스를 말합니다. 적합한 노드를 선택하는 기준은 각 노드의 자원 사용량, 노드와 Pod의 라벨, Pod의 요구사항 등을 고려합니다. Scheduler는 Pod를 노드에 할당할 때 노드의 자원 사용량을 최적화하여 노드의 성능을 향상시키고 Pod의 안정성을 보장합니다.

• Preemption: Preemption은 노드에서 자원 부족 상황이 발생할 때 쿠버네티스가 노드에 배치된 Pod 중 일부를 종료하여 노드에 필요한 자원을 확보하는 프로세스입니다. Preemption은 노드의 자원 사용률을 유지하고 모든 Pod가 안정적으로 실행되도록 보장합니다.

• Eviction: Eviction은 노드에서 실행 중인 Pod를 중지하고 다른 노드로 이동시키는 프로세스입니다. 이는 노드 장애나 유지 보수 작업 등으로 인해 Pod를 다른 노드로 이동해야 할 때 사용됩니다. Eviction은 Pod의 안정성을 보장하고 노드 장애에 대한 복구를 가능하게 합니다.

이러한 Scheduling, Preemption 및 Eviction은 쿠버네티스에서 자원 사용량을 최적화하고 클러스터의 안정성을 보장하는 데 중요한 역할을 합니다. 이를 통해 쿠버네티스는 노드의 자원 사용을 최적화하고, 사용 가능한 모든 자원을 효율적으로 사용하여 클러스터의 성능과 안정성을 향상시킵니다.

Scheduling

Kubernetes Scheduler

스케줄러는 노드가 할당되지 않은 새로 생성된 파드를 감시한다. 스케줄러가 발견한 모든 파드에 대해 스케줄러는 해당 파드가 실행될 최상의 노드를 찾는 책임을 진다. 스케줄러는 아래 설명된 스케줄링 원칙을 고려하여 이 배치 결정을 하게 된다.

kube-scheduler

• 쿠버네티스의 기본 스케줄러이며 컨트롤 플레인의 일부로 실행
• kube-scheduler는 원하거나 필요에 따라 자체 스케줄링 컴포넌트를 만들고 대신 사용할 수 있도록 설계
• 클러스터에서 파드에 대한 스케줄링 요구사항을 충족하는 노드를 실행 가능한(feasible) 노드라고 한다. 적합한 노드가 없으면 스케줄러가 배치할 수 있을 때까지 파드가 스케줄 되지 않은 상태로 유지된다.
• 스케줄러는 파드가 실행 가능한 노드를 찾은 다음 실행 가능한 노드의 점수를 측정하는 기능 셋을 수행하고 실행 가능한 노드 중에서 가장 높은 점수를 가진 노드를 선택하여 파드를 실행한다. 그런 다음 스케줄러는 바인딩 이라는 프로세스에서 이 결정에 대해 API 서버에 알린다.
• 스케줄링 결정을 위해 고려해야 할 요소에는 개별 및 집단 리소스 요구사항, 하드웨어 / 소프트웨어 / 정책 제한조건, 어피니티 및 안티-어피니티 명세, 데이터 지역성(data locality), 워크로드 간 간섭 등이 포함된다.

kube-scheduler에서 노드 선택

kube-scheduler는 2단계 작업에서 파드에 대한 노드를 선택한다.

1. 필터링
2. 스코어링(scoring)

필터링 단계는 파드를 스케줄링 할 수 있는 노드 셋을 찾는다. 예를 들어 PodFitsResources 필터는 후보 노드가 파드의 특정 리소스 요청을 충족시키기에 충분한 가용 리소스가 있는지 확인한다. 이 단계 다음에 노드 목록에는 적합한 노드들이 포함된다. 하나 이상의 노드가 포함된 경우가 종종 있을 것이다. 목록이 비어 있으면 해당 파드는 (아직) 스케줄링 될 수 없다.

스코어링 단계에서 스케줄러는 목록에 남아있는 노드의 순위를 지정하여 가장 적합한 파드 배치를 선택한다. 스케줄러는 사용 중인 스코어링 규칙에 따라 이 점수를 기준으로 필터링에서 통과된 각 노드에 대해 점수를 지정한다.

마지막으로 kube-scheduler는 파드를 순위가 가장 높은 노드에 할당한다. 점수가 같은 노드가 두 개 이상인 경우 kube-scheduler는 이들 중 하나를 임의로 선택한다.

스케줄러의 필터링 및 스코어링 동작을 구성하는 데 지원되는 두 가지 방법이 있다.

1. 스케줄링 정책을 사용하면 필터링을 위한 단정(Predicates) 및 스코어링을 위한 우선순위(Priorities) 를 구성할 수 있다.
2. 스케줄링 프로파일을 사용하면 QueueSort, Filter, Score, Bind, Reserve, Permit 등의 다른 스케줄링 단계를 구현하는 플러그인을 구성할 수 있다. 다른 프로파일을 실행하도록 kube-scheduler를 구성할 수도 있다.

Assigning Pods to Nodes

노드에 파드를 할당하는 방법은 다음과 같습니다:

1. 노드 선택: 노드 선택은 파드를 배치할 적합한 노드를 선택하는 것입니다. 노드 선택은 파드가 요구하는 자원(메모리, CPU 등)과 노드가 가진 자원 사용률, 라벨, 애노테이션 등을 고려합니다.

2. 파드 스펙 정의: 파드 스펙은 파드가 요구하는 자원, 이미지 및 컨테이너 설정, 환경 변수 등을 정의합니다. 파드 스펙은 YAML 파일 또는 JSON 파일 형식으로 작성할 수 있습니다.

3. 파드 배포: 파드 배포는 kubectl을 사용하여 쿠버네티스에 파드를 생성하고 배포하는 것입니다. kubectl 명령어를 사용하여 파드 스펙을 포함한 YAML 파일을 쿠버네티스에 전달합니다.

4. 파드 확인: 파드가 정상적으로 배치되었는지 확인합니다. kubectl 명령어를 사용하여 파드 상태 및 로그를 확인할 수 있습니다.

노드에 파드를 할당할 때, 파드의 자원 요구사항과 노드의 자원 사용량을 고려하여 적절한 노드를 선택해야 합니다. 파드를 적절한 노드에 배치하면 자원을 효율적으로 사용할 수 있으며, 클러스터의 안정성을 보장할 수 있습니다.

Pod Overhead

쿠버네티스에서 파드 오버헤드는 파드를 실행하는 데 필요한 최소한의 자원을 의미합니다. 파드 오버헤드는 파드가 실행되는 노드에 할당되는 자원으로, 파드 자체를 제어하는 데 필요한 자원과 파드를 실행하는 데 필요한 최소한의 인프라 자원 및 네트워크 자원을 포함합니다.

파드 오버헤드는 파드마다 최소한 10MB의 메모리와 0.1 CPU의 자원을 필요로 하며, 파드가 실행되는 환경에 따라 달라질 수 있습니다. 또한, 멀티 컨테이너 파드의 경우 파드 오버헤드는 추가로 컨테이너를 실행하는 데 필요한 자원으로 증가할 수 있습니다.

파드 오버헤드는 파드가 실행되는 환경에 따라 다르며, 파드마다 최소한의 자원을 보장하여 안정적으로 실행될 수 있도록 하기 위해 필요합니다. 파드 오버헤드를 고려하지 않고 파드를 배치할 경우, 파드가 실행 중에 자원 부족 상황이 발생하여 클러스터 전체의 안정성을 저해할 수 있습니다. 따라서, 적절한 자원 할당과 파드 오버헤드를 고려하여 파드를 배치하는 것이 중요합니다.

Pod Topology Spread Constraints

중요한 내용이 많은데 추후 다시 한번 꼼꼼히 볼 필요가 있음

쿠버네티스 클러스터 내에서 파드의 배치를 조절하는 데 사용되는 스케줄링 기능입니다. 사용자는 토폴로지 분배 제약 조건 을 사용하여 지역(region), 존(zone), 노드 및 기타 사용자 정의 토폴로지 도메인과 같이 장애 도메인으로 설정된 클러스터에 걸쳐 파드가 분배되는 방식을 제어할 수 있다. 이를 통해 고가용성뿐만 아니라 효율적인 리소스 활용의 목적을 이루는 데에도 도움이 된다.

클러스터-수준 제약을 기본값으로 설정하거나, 개별 워크로드마다 각각의 토폴로지 분배 제약 조건을 설정할 수 있다.

Taints and Tolerations

Taints와 Tolerations는 쿠버네티스에서 노드에 파드를 스케줄링할 때 사용되는 도구입니다. 이들은 특정 파드가 특정 노드에만 스케줄링되도록, 또는 특정 노드에서 배제되도록 제어하는데 사용됩니다.

Taints

Taint는 노드에 적용되는 "마크"입니다. Taint는 노드가 특정 파드의 스케줄링을 받아들이지 않음을 나타냅니다. Taint는 key=value:effect 형태로 표현되며, effect 부분은 노드가 파드를 받아들이는 방법을 결정합니다. effect에는 NoSchedule, PreferNoSchedule, NoExecute 등이 있습니다.

• NoSchedule: 이 효과를 가진 Taint가 있는 노드에는 Taint를 허용하는 Toleration이 없는 파드가 스케줄링되지 않습니다.
• PreferNoSchedule: 이 효과를 가진 Taint가 있는 노드에는 가능한 한 Toleration이 없는 파드가 스케줄링되지 않습니다. 그러나 시스템은 이를 강제하지 않습니다.
• NoExecute: 이 효과를 가진 Taint가 있는 노드에는 Taint를 허용하는 Toleration이 없는 파드가 스케줄링되지 않으며, 이미 실행 중인 파드는 추출됩니다.

Tolerations

Toleration은 파드에 적용되는 속성으로, Taint가 적용된 노드에 파드를 스케줄링할 수 있도록 합니다. 즉, Toleration은 파드가 특정 Taint를 "용인"할 수 있게 해줍니다.

Toleration은 key=value:effect 형태로 표현되며, 이는 파드가 어떤 Taint를 용인할 수 있는지를 정의합니다. Taint와 동일하게 effect에는 NoSchedule, PreferNoSchedule, NoExecute 등이 있습니다.

Taints와 Tolerations를 사용함으로써, 쿠버네티스는 특정 작업을 특정 노드에 스케줄링하거나, 일부 노드를 특정 작업으로부터 보호하는 등의 유연한 스케줄링 제어를 할 수 있습니다. 이는 특정 하드웨어가 필요한 작업, 높은 보안 요구를 가진 작업, 노드 유지 관리 등 다양한 시나리오에서 유용합니다.

Scheduling Framework

스케줄링 프레임워크는 쿠버네티스 스케줄러를 위한 플러그 가능한 아키텍처입니다. 이는 기존 스케줄러에 새로운 "플러그인" API 세트를 추가한다. 플러그인은 스케줄러에 컴파일된다. API를 사용하면 대부분의 스케줄링 기능을 플러그인으로 구현할 수 있으며, 스케줄링 "코어"를 가볍고 유지 관리하기 쉽게 유지할 수 있다. 프레임워크 설계에 대한 자세한 기술 정보는 스케줄링 프레임워크의 설계 제안서를 참조하세요.

Scheduling framework extension points

• PreEnqueue
  내부 활성 큐에 파드를 추가하기 전에 호출되며, 여기서 파드는 스케줄링 준비가 된 것으로 표시된다.
  모든 프리엔큐 플러그인이 성공을 반환할 때만, 파드가 활성 큐에 들어갈 수 있다. 그렇지 않으면, 내부 스케줄할 수 없는 파드 목록에 배치되고 스케줄할 수 없음 조건이 표시되지 않는다.
  내부 스케줄러 큐의 작동 방식에 대한 자세한 내용은 큐브 스케줄러에서 큐 스케줄링을 읽어보기를 참고한다.
• QueueSort
  스케줄링 큐에서 파드를 정렬하는 데 사용된다. 큐 정렬 플러그인은 기본적으로 Less(파드1, 파드2) 함수를 제공한다. 한 번에 하나의 큐 정렬 플러그인만 활성화할 수 있다.
• PreFilter
  파드에 대한 정보를 사전 처리하거나 클러스터 또는 파드가 충족해야 하는 특정 조건을 확인하는 데 사용된다. 프리필터 플러그인이 오류를 반환하면 스케줄링 주기가 중단된다
• Filter
  파드를 실행할 수 없는 노드를 필터링하는 데 사용된다. 각 노드에 대해 스케줄러는 구성된 순서대로 필터 플러그인을 호출한다. 어떤 필터 플러그인이 노드를 실행 불가능으로 표시하면, 나머지 플러그인은 해당 노드에 대해 호출되지 않는다. 노드는 동시에 평가될 수 있습니다.
• PostFilter
  파드에 대한 정보를 사전 처리하거나 클러스터 또는 파드가 충족해야 하는 특정 조건을 확인하는 데 사용된다. 프리필터 플러그인이 오류를 반환하면 스케줄링 주기가 중단된다.
• PreScore
  Score 플러그인이 사용할 수 있는 공유 가능한 상태를 생성하는 "사전 채점" 작업을 수행하는 데 사용됩니다. 사전 점수 플러그인이 오류를 반환하면 스케줄링 주기가 중단됩니다.
• Score
  필터링 단계를 통과한 노드의 순위를 매기는 데 사용됩니다. 스케줄러는 각 노드에 대해 각 채점 플러그인을 호출합니다. 최소 및 최대 점수를 나타내는 정수의 범위가 잘 정의되어 있을 것입니다. 정규화 점수 단계가 끝나면 스케줄러는 구성된 플러그인 가중치에 따라 모든 플러그인의 노드 점수를 결합합니다.
• NormalizeScore
  케줄러가 노드의 최종 순위를 계산하기 전에 점수를 수정하는 데 사용됩니다. 이 확장 지점에 등록하는 플러그인은 동일한 플러그인의 점수 결과와 함께 호출됩니다. 이는 스케줄링 주기당 플러그인당 한 번 호출됩니다.
• Reserve
  예약 확장을 구현하는 플러그인에는 Reserve 와 Unreserve라는 두 가지 메서드가 있으며, 각각 Reserve와 Unreserve라는 두 가지 정보 스케줄링 단계를 뒷받침한다. 런타임 상태를 유지하는 플러그인(일명 "상태 저장 플러그인")은 이러한 단계를 사용하여 노드의 리소스가 특정 파드에 대해 예약 및 예약 해제될 때 스케줄러에 알림을 받아야 한다.
• Permit
  퍼밋 플러그인은 각 파드의 스케줄링 사이클이 끝날 때 호출되어 후보 노드에 대한 바인딩을 방지하거나 지연시킨다. 퍼밋 플러그인은 세 가지 중 하나를 수행할 수 있다:

1. approve
   Once all Permit plugins approve a Pod, it is sent for binding.
2. deny
   If any Permit plugin denies a Pod, it is returned to the scheduling queue. This will trigger the Unreserve phase in Reserve plugins.
3. wait (with a timeout)
   If a Permit plugin returns "wait", then the Pod is kept in an internal "waiting" Pods list, and the binding cycle of this Pod starts but directly blocks until it gets approved. If a timeout occurs, wait becomes deny and the Pod is returned to the scheduling queue, triggering the Unreserve phase in Reserve plugins.

• PreBind
  파드가 바인딩되기 전에 필요한 모든 작업을 수행하는 데 사용된다. 예를 들어, 사전 바인딩 플러그인은 네트워크 볼륨을 프로비저닝하고 대상 노드에 마운트한 후 해당 노드에서 파드를 실행하도록 허용할 수 있다.

• Bind
  파드를 노드에 바인딩하는 데 사용된다. 바인드 플러그인은 모든 프리바인드 플러그인이 완료될 때까지 호출되지 않는다. 각 바인드 플러그인은 구성된 순서대로 호출된다. 바인드 플러그인은 주어진 파드를 처리할지 여부를 선택할 수 있다. 한 바인딩 플러그인이 파드를 처리하기로 선택하면 나머지 바인딩 플러그인은 건너뛴다.

• PostBind
  이것은 정보 확장 지점이다. 포스트-바인딩 플러그인은 파드가 성공적으로 바인딩된 후에 호출된다. 이것은 바인딩 사이클의 끝이며, 관련 리소스를 정리하는 데 사용할 수 있다.

Dynamic Resource Allocation

동적 리소스 할당은 파드 내부의 파드와 컨테이너 간에 리소스를 요청하고 공유하기 위한 새로운 API이다. 이것은 일반 리소스에 대한 퍼시스턴트 볼륨 API를 일반화한 것이다. 서드파티 리소스 드라이버는 리소스를 추적하고 할당할 책임이 있다. 다양한 종류의 리소스는 요구사항 정의 및 초기화를 위한 임의의 파라미터를 지원한다.

Scheduler Performance Tuning

상대적으로 큰 규모의 쿠버네티스 클러스터에 대한 성능 튜닝 최적화에 대해 설명한다.

큰 규모의 클러스터에서는 스케줄러의 동작을 튜닝하여 응답 시간 (새 파드가 빠르게 배치됨)과 정확도(스케줄러가 배치 결정을 잘 못하는 경우가 드물게 됨) 사이에서의 스케줄링 결과를 균형 잡을 수 있다.

kube-scheduler 의 percentageOfNodesToScore 설정을 통해 이 튜닝을 구성 한다. 이 KubeSchedulerConfiguration 설정에 따라 클러스터의 노드를 스케줄링할 수 있는 임계값이 결정된다.

Resource Bin Packing for Extended Resources

"리소스 빈 패킹(Resource Bin Packing)"은 컴퓨팅 자원을 최적으로 활용하기 위한 전략 중 하나입니다. 빈 패킹 알고리즘은 일반적으로 가장 적은 수의 빈(여기서는 컴퓨팅 노드를 의미)을 사용하여 주어진 항목(여기서는 컴퓨팅 작업, 예를 들어, 컨테이너 또는 파드)을 패킹하는 것을 목표로 합니다.

쿠버네티스와 같은 컨테이너 오케스트레이션 시스템에서는, 빈 패킹 전략은 클러스터의 전체 자원 사용률을 높이기 위해 사용됩니다. 즉, 가능한 한 적은 수의 노드에서 최대한 많은 파드를 실행하여, 남는 노드를 다른 목적(예: 리눅스 머신에서 실행되는 다른 프로세스)에 사용하거나 에너지를 절약할 수 있습니다.

이 전략은 리소스 사용률을 최적화하며, 쿠버네티스 클러스터의 비용 효율성을 향상시킵니다. 그러나 이 전략의 단점은 클러스터 내에서 파드의 분산을 제한하므로, 단일 노드의 장애가 클러스터 전체의 리소스 가용성에 더 큰 영향을 미칠 수 있다는 것입니다. 따라서 빈 패킹 전략을 사용할 때는 클러스터의 내결함성을 유지하기 위해 적절한 재시작 정책과 함께 사용해야 합니다.

Pod Scheduling Readiness

Pod Scheduling Readiness는 쿠버네티스에서 파드를 노드에 할당하기 전에 파드가 실행될 준비가 되었는지 확인하는 프로세스입니다.

파드 Scheduling Readiness를 사용하면 파드가 실행되기 전에 필요한 모든 작업(컨테이너 이미지 다운로드, 데이터베이스 마이그레이션 등)이 완료되었는지 확인할 수 있습니다. 이를 통해 파드가 실행 중인 노드에 대한 부하를 줄이고, 클러스터의 안정성과 가용성을 보장할 수 있습니다.
~~
~~파드 Scheduling Readiness는 두 가지 메커니즘으로 수행됩니다.
~~
~~1. Liveness Probe: Liveness Probe는 파드가 정상적으로 실행 중인지 확인하는 데 사용됩니다. Liveness Probe를 사용하여 파드가 실행 중인 노드에서 충돌 또는 오류가 발생하면 파드를 중지하고, 다른 노드에 재배치하여 안정성을 유지할 수 있습니다.

2. Readiness Probe: Readiness Probe는 파드가 실행 준비가 되었는지 확인하는 데 사용됩니다. Readiness Probe를 사용하여 파드가 실행되기 전에 필요한 모든 작업이 완료되었는지 확인하여, 실행 중인 노드에 대한 부하를 줄이고, 클러스터의 안정성과 가용성을 보장할 수 있습니다.
~~
이러한 두 가지 메커니즘을 사용하여 파드 Scheduling Readiness를 구현하면 파드가 노드에 할당되기 전에 파드가 실행 가능한 상태인지 확인할 수 있으므로, 안정성과 가용성을 보장하면서 클러스터의 자원 사용을 최적화할 수 있습니다.

Configuring Pod schedulingGates

Pod Disruption

노드의 파드가 자발적 또는 비자발적으로 종료되는 프로세스이다.
자발적 중단은 애플리케이션 소유자 또는 클러스터 관리자에 의해 의도적으로 시작된다. 비자발적 중단은 의도하지 않은 중단으로, 노드의 리소스 부족이나 실수로 인한 삭제와 같은 피할 수 없는 문제로 인해 발생할 수 있다.

Pod Priority and Preemption

(경고) 모든 사용자를 신뢰할 수 없는 클러스터에서, 악의적인 사용자가 우선순위가 가장 높은 파드를 생성하여 다른 파드가 축출되거나 스케줄링되지 않을 수 있다. 관리자는 리소스쿼터를 사용하여 사용자가 우선순위가 높은 파드를 생성하지 못하게 할 수 있다.
쿠버네티스의 파드 우선순위와 선점 기능은 클러스터 내의 리소스가 제한적일 때 중요한 작업을 보장하는 데 도움이 됩니다.

파드 우선순위(Priority)

파드 우선순위는 파드 간에 상대적인 스케줄링 중요성을 지정하는 메커니즘입니다. 이를 통해, 어떤 파드가 더 중요한지 결정하고, 이에 따라 스케줄링과 축출 결정을 내릴 수 있습니다.

파드 우선순위는 PriorityClass라는 객체를 통해 설정됩니다. PriorityClass에는 이름과 우선순위 값이 포함되며, 파드 스펙에서 이 PriorityClass 이름을 참조하여 파드의 우선순위를 지정할 수 있습니다.

선점(Preemption)

선점은 더 높은 우선순위의 파드가 스케줄링될 수 있도록, 더 낮은 우선순위의 파드를 축출하는 프로세스입니다. 즉, 높은 우선순위의 파드가 실행될 수 있는 공간을 확보하기 위해, 쿠버네티스 스케줄러는 필요한 경우 더 낮은 우선순위의 파드를 종료합니다.

선점은 파드가 스케줄링될 수 없는 경우에만 발생하며, 다른 파드를 축출하는 결정은 파드의 우선순위, 파드가 사용하는 리소스 양, 그리고 파드가 얼마나 오래 실행되었는지 등을 고려하여 이루어집니다.

이 두 기능은 함께 작동하여 높은 우선순위의 작업이 중요한 경우에도 적시에 스케줄링되고 실행될 수 있도록 합니다.

Node-pressure Eviction

노드 프레셔 축출(Node-pressure Eviction)은 쿠버네티스 노드에서 발생하는 자원 부족 상황을 처리하는 프로세스입니다. 이 프로세스는 Kubelet, 즉 쿠버네티스 노드를 관리하는 에이전트에 의해 수행됩니다.

일반적으로, Kubelet은 노드의 다양한 자원에 대해 축출 임계값(Eviction Thresholds)을 설정합니다. 이 임계값은 메모리, CPU, 디스크 공간, inode 등의 자원에 대해 설정될 수 있습니다. 노드의 해당 자원 사용률이 설정된 임계값을 초과하면, Kubelet은 노드 프레셔 축출 프로세스를 시작합니다.

노드 프레셔 축출 프로세스는 다음과 같습니다:

1. Kubelet은 노드의 자원 부족 상황을 감지합니다.
2. Kubelet은 API 서버에 이를 알리며, 노드를 "조건부로 비활성화"합니다. 이는 노드에 더 이상 새로운 파드를 스케줄링하지 않게 만듭니다.
3. Kubelet은 노드에서 실행 중인 파드를 축출합니다. 이때 파드의 축출 순서는 파드의 우선순위, 파드가 사용하는 자원 등을 고려하여 결정됩니다.
4. 축출된 파드는 다른 노드에 스케줄링되어 재시작됩니다.

노드 프레셔 축출을 통해, 쿠버네티스는 노드의 자원 부족 상황을 자동으로 처리하고, 노드의 안정성을 유지하는 데 도움을 줍니다. 그러나 축출 프로세스는 일시적으로 파드의 가용성을 저하시킬 수 있으므로, 이 기능은 신중하게 사용해야 합니다.

API-initiated Eviction

API-initiated Eviction은 쿠버네티스 API 서버를 통해 명시적으로 파드를 축출하는 프로세스입니다. 일반적으로, 이 프로세스는 파드를 안전하게 종료하고, 필요한 경우 다른 노드에 파드를 재스케줄링하는 데 사용됩니다.

API-initiated Eviction은 Eviction API 오브젝트를 사용하여 수행됩니다. 사용자는 Eviction 오브젝트를 생성하여 특정 파드의 축출을 요청할 수 있습니다. 이 오브젝트는 파드의 이름과 네임스페이스를 포함합니다.

API-initiated Eviction은 다음과 같은 단계를 포함합니다:

1. 사용자는 Eviction 오브젝트를 생성하여 특정 파드의 축출을 요청합니다.
2. API 서버는 요청을 수신하고, 해당 파드에 대한 축출 프로세스를 시작합니다.
3. API 서버는 해당 파드를 "종료 중"으로 표시하고, 파드의 terminationGracePeriodSeconds 필드에 지정된 시간 동안 파드가 자체적으로 종료되도록 기다립니다.
4. 만약 파드가 기간 내에 자체적으로 종료되지 않으면, API 서버는 파드를 강제 종료합니다.
5. 파드가 종료되면, 쿠버네티스는 파드를 다시 스케줄링하여 다른 노드에서 재시작합니다. 이는 파드가 ReplicaSet, StatefulSet, Deployment 등의 컨트롤러에 의해 관리되는 경우에만 해당됩니다.

이 프로세스는 안전한 파드 종료를 보장하며, 필요한 경우 파드의 재스케줄링을 가능하게 합니다. 그러나 이 프로세스는 파드의 가용성을 일시적으로 저하시킬 수 있으므로, API-initiated Eviction은 신중하게 사용해야 합니다.

Troubleshooting stuck evictions