[kubernetes] 데몬셋 파드 Pending 현상 (PriorityClass)

들어가기 앞서

현재 운영 중인 서비스는 비용 최적화 목적으로 개발·품질 환경의 총 4개 EKS 클러스터 워커 노드에 인스턴스 스케줄러가 적용되어 있다. 즉, 매일 오후 10시에 모든 워커 노드가 종료되고, 오전 8시에 다시 생성된다. 그런데 워커 노드가 재생성된 직후, 일부 파드가 스케줄되지 않고 Pending 상태로 머물러 있는 현상이 관찰되었다. 최초로 확인된 점은, Pending 상태로 남아 있는 파드가 모두 DaemonSet으로 배포된 파드라는 것이었다.

PriorityClass

원인을 식별하기 앞서 PriorityClass 개념을 이해해야 한다. 자세한 사항은 공식 문서를 확인하도록 하자

https://kubernetes.io/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/

파드 우선순위(priority)와 선점(preemption)

간단히 설명하면 priorityclass는 쿠버네티스에서 Pod의 스케줄링 우선순위를 결정하는 리소스이다. 

• 역할: Pod의 중요도(우선순위)를 정의해 스케줄러가 자원 부족 시 어떤 Pod를 먼저 스케줄하고, 자원 회수 시 어떤 Pod를 먼저 종료할지를 결정한다.
• 값(value): 정수로 정의되며 값이 높을수록 높은 우선순위를 가짐
• 종류: 시스템용 PriorityClass (예: system-cluster-critical, system-node-critical)은 매우 높은 값(2,000,000,000 이상)을 가지며 일반 애플리케이션용 PriorityClass는 개발자가 정의 가능
• 활용 사례
  • 중요 서비스 Pod는 높은 값 부여
  • 덜 중요 서비스 Pod는 낮은 값 부여
• 중요 속성
  • globalDefault: 다른 Pod가 PriorityClass를 지정하지 않은 경우 기본값으로 사용할지 여부
  • preemptionPolicy: 높은 우선순위 Pod가 스케줄되지 않을 때 낮은 우선순위 Pod를 강제로 종료(preemption) 가능 여부

원인 분석

근본적인 원인은 노드에 스케줄되는 파드의 PriorityClass 설정에 있었다. 오전 8시에 워커 노드가 생성될 때 Deployment 파드가 먼저 스케줄되어 리소스를 선점하고, 뒤이어 DaemonSet 파드가 스케줄될 때는 잔여 리소스가 부족해 배치되지 못하는 상황이 발생했다.

DaemonSet 파드는 원칙적으로 각 노드마다 하나씩 반드시 배치되어야 하므로, Cluster 오토스케일링으로도 해결할 수 없다.

일부 애드온과 같은 kube-system 네임스페이스에서 사용하는 Daemonset 의 경우 PriorityClass 가 system-node-critical 로 설정되어 있어 우선 순위가 낮거나 없는 파드 들을 퇴거시키고 스케줄링됐지만, PriorityClass 가 설정되지 않은 Daemonset 파드의 경우 최종적으로 스케줄링되지 못하고 Pending 상태에 남게 됐다. 

개발 환경인 만큼 파드 자체가 실제로 많은 자원을 소비하는 상황은 아니었지만, 최근 진행된 Pod Re‑Sizing 작업으로 Deployment 파드의 Request/Limit 값을 조정하면서 각 노드의 가용 자원이 감소했던 것이 원인으로 작용했다.

해결 방법

해결 방법은 매우 간단하다. 스케줄되지 않은 DaemonSet의 PriorityClass를 system-node-critical로 지정하여, 다른 파드가 Evict(퇴거)되더라도 DaemonSet이 우선 스케줄될 수 있도록 한다. 이렇게 Evict된 Deployment 파드는 다른 노드로 재스케줄되며, 자원이 부족한 경우 Cluster Autoscaler가 새로운 노드를 생성해 파드가 정상적으로 배치될 수 있도록 했다.