워크로드 인지 선점

워크로드 인지 선점 (Workload-Aware Preemption)

이 기능을 사용하려면 사용자(또는 클러스터 관리자)가 클러스터의 모든 관련 컴포넌트에서 GenericWorkload 기능 게이트(feature gate)를 활성화해야 해요.

자세한 내용은 기능 게이트 활성화/비활성화 (Enable Or Disable Feature Gates)를 참고하세요.

참고: v1.36에서는 워크로드 인지 선점 로직이 WorkloadAwarePreemption 기능 게이트로 제어됐습니다. 이 기능 게이트는 v1.37에서 GenericWorkload 기능 게이트로 통합됐어요.

**워크로드 인지 선점(Workload-aware preemption)**은 PodGroup을 위해 특별히 설계된 선점 메커니즘을 도입합니다. PodGroup이 스케줄될 수 없을 때 스케줄러는 이 PodGroup의 스케줄링을 가능하게 만들려고 시도하는 선점 로직을 사용합니다. 이 접근 방식은 PodGroup 스케줄링 동안에만 사용되며, 주어진 PodGroup의 Pod에 대한 기본 선점 메커니즘을 대체해요.

이 기능이 활성화되면 스케줄러는 PodGroup의 개별 Pod를 단독으로 평가하는 대신, PodGroup을 하나의 선점자(preemptor) 단위로 취급합니다. 그룹의 대기 중인 Pod를 위한 공간을 만들기 위해 클러스터 전체에서 희생자(victim)를 검색하며, 다른 PodGroup을 그들의 중단 모드(disruption mode)에 따라 희생자로 취급하고 선점하는 방법을 알고 있습니다.

이 기능은 갱 스케줄링 (Gang Scheduling)과 결합되며 Workload API에 의존합니다. 클러스터에서 scheduling.k8s.io/v1beta1 API 그룹이 활성화되어 있는지 확인하세요.

출처: 문서

작동 방식 (How it works)

워크로드 인지 선점 과정은 기본 선점과 몇 가지 차이점을 빼고 같은 원칙을 따릅니다.

  • 클러스터 전체 도메인 (Cluster-wide domain): 스케줄러는 노드별로 선점을 평가하는 대신 클러스터 전체를 하나의 도메인으로 평가합니다. 선점자 PodGroup이 스케줄될 수 있도록 충분한 공간을 만들기 위해 제거할 수 있는 희생자 집합을 여러 노드에 걸쳐 선택합니다.
  • 희생자 중요도 계층 (Victim importance hierarchy): 스케줄러는 엄격한 계층을 사용해 어떤 선점 단위(개별 Pod 또는 PodGroup)가 더 중요하고 선점을 피해야 하는지 결정합니다:
    • 우선순위 (Priority): 우선순위가 높은 단위가 항상 더 중요합니다.
    • 워크로드 유형 (Workload type): PodGroup은 같은 우선순위의 개별 Pod보다 더 중요한 것으로 간주됩니다.
    • 그룹 크기 (Group size, PodGroups): 두 단위 모두 PodGroup이면 구성원(크기)이 더 많은 쪽이 더 중요합니다.
    • 시작 시간 (Start time): 더 일찍 시작된 단위가 더 중요합니다.
  • Pod 그룹 우선순위와 중단 (Pod group priority and disruption): 스케줄러는 PodGroup의 특정 우선순위와 중단 모드를 고려해 선점 이벤트 중 그 Pod를 선점할 수 있는지와 방법을 평가합니다.
  • 성능과 최적성 고려 (Performance and optimality considerations): 성능상의 이유로 워크로드 인지 선점은 먼저 잠재적 희생자를 모두 제거하는 시뮬레이션을 하고 스케줄링을 한 번 실행합니다. 그런 다음 선택된 배치에 대해 가능한 한 많은 희생자를 석방(reprieve)하려고 합니다. 이 트레이드오프 때문에 덜 선점을 발생시키는 대안적인 배치가 존재할 수 있지만, 성능상의 이유로 스케줄러가 선택하지 않을 수 있어요.

참고: 단일 Pod를 스케줄링할 때는 기본 Pod 선점이 적용됩니다. v1.36에서 스케줄러가 단일 Pod에 대해 기본 선점을 수행하고 PodGroup에 속한 Pod를 선점하려고 하면, 그 PodGroup의 priority나 disruptionMode 필드를 존중하지 않습니다. 이 제한은 v1.37에서 더 이상 적용되지 않습니다.

석방 알고리즘 (Reprieval algorithm)

워크로드 인지 선점을 실행할 때 스케줄러는 잠재적 선점 희생자를 제거하고 Pod 그룹 스케줄링 알고리즘을 실행하는 시뮬레이션을 수행합니다. 그런 다음 반환된 배치에 대해 가능한 한 많은 희생자를 석방하려고 합니다. 이를 위해 스케줄러는 Pod 그룹 스케줄링의 CycleState를 재사용합니다. 중요도 순으로 정렬된 각 잠재적 희생자에 대해 스케줄러는 다음을 수행합니다.

  • 희생자 Pod를 그들의 노드와 선점자 Pod의 CycleStates에 다시 추가합니다.
  • PodGroup의 각 Pod에 대해(스케줄링 알고리즘과 같은 순서로): 제안된 노드에서 Pod에 대해 Filter 플러그인 실행 → Pod를 제안된 노드에 추가 → 제안된 노드에서 Pod에 대해 Reserve 플러그인 실행

각 Pod에 대해 필터링이 통과하면 희생자 Pod는 그들의 노드에 유지됩니다.

최소 하나의 Pod에 대해 필터링이 실패하면 희생자 Pod는 CycleStates와 노드에서 제거됩니다.

두 경우 모두 스케줄러는 선점자 Pod를 그들의 노드에서 제거하고 Unreserve를 호출해, 다음 석방 시도가 PodGroup 스케줄링을 검증할 수 있게 합니다. 그런 다음 스케줄러는 모든 희생자를 처리할 때까지 다른 잠재적 희생자로 진행합니다.

CompositePodGroups에 대한 선점 (Preemption for CompositePodGroups)

이 기능을 사용하려면 클러스터의 모든 관련 컴포넌트에서 CompositePodGroup 기능 게이트를 활성화해야 해요.

자세한 내용은 기능 게이트 활성화/비활성화를 참고하세요.

CompositePodGroup 기능 게이트와 scheduling.k8s.io/v1alpha3 API 그룹이 활성화되면 워크로드 인지 선점은 CompositePodGroups도 지원합니다.

기저 선점 메커니즘은 PodGroups와 동일합니다 — 스케줄러가 루트 CompositePodGroup을 배치하기 위해 용량을 확보해야 한다면, 개별 Pod가 아니라 전체 그룹 계층에 대해 선점을 평가합니다.

CompositePodGroups도 선점 희생자로 선택될 수 있어요. 희생자 선택 과정은 다음과 같은 방식으로 CompositePodGroups를 고려하도록 조정됩니다.

  • 희생자 중요도 계층 (Victim importance hierarchy): CompositePodGroups는 같은 우선순위의 독립형 PodGroups보다 더 중요한 것으로 간주됩니다. 같은 우선순위의 두 CompositePodGroups 중 구성원(크기)이 더 많은 쪽이 더 중요합니다.
  • 중단 모드 (Disruption mode): PodGroups와 유사하게 CompositePodGroups는 선점 중 하위 그룹을 어떻게 취급할지 결정하는 중단 모드를 지정합니다.

워크로드 인지 선점 외에도, CompositePodGroups는 Pod 스케줄링 사이클 중 기본 Pod 선점에 의해 PodGroups와 Pods와 함께 선점 희생자로 선택될 수 있어요. 기본 Pod 선점은 워크로드 인지 선점과 희생자 중요도 계층 로직을 공유하며 CompositePodGroups의 disruptionMode 필드를 존중합니다.

다음 단계 (What's next)

더 알아보기 (Learn more)