[TIL] Descheduler

TIL: Descheduler

배경

회사 Kubernetes 클러스터에 ECK Elasticsearch 배포 중 일부 데이터 노드가 리소스 부족으로 배포되지 못했다.

Events:
  Type     Reason            Age                    From               Message
  ----     ------            ----                   ----               -------
  Warning  FailedScheduling  18m (x923 over 5h16m)  default-scheduler  0/6 nodes are available: 1 node(s) didn't match Pod's node affinity/selector, 2 Insufficient memory, 5 Insufficient cpu. preemption: 0/6 nodes are available: 1 Preemption is not helpful for scheduling, 1 node(s) had volume node affinity conflict, 2 Insufficient memory, 4 Insufficient cpu.

그래서 노드별 리소스를 확인해보니 pod들이 고르게 퍼져있어 신규 pod가 스케쥴링되지 못했다.
때문에 기존에 배포된 pod들을 다시 스케쥴링해 한 노드로 몰아넣어서 활용률을 높이고 많은 리소스를 요구하는 pod를 배포할 수 있는 환경을 조성하려고 그 방법을 찾던중 발견한것이 Descheduler!

Descheduler란?

Descheduler는 이미 Kubernetes 클러스터에서 실행 중인 Pod를 다시 스케쥴링하는 과정을 자동화하는 도구이다. 기존 Kubernetes 스케쥴러가 새로운 Pod를 배치하는데 초점을 맞추는 반면, Descheduler는 기존 Pod의 배치를 최적화한다.

Descheduler가 필요한 상황

1. 노드 불균형 발생
   새로운 노드가 추가되었지만 기존 파드들은 이전 노드에만 남아 있음
   → Descheduler가 일부 파드를 새 노드로 이동시켜 자원 균형 맞춤
2. PodAffinity/AntiAffinity 위반
   노드 레이블이 바뀌거나, 노드 그룹이 이동되며 정책이 무력화됨
   → 규칙을 위반한 파드들을 찾아 다시 배치
3. 파드 중복 문제
   동일한 ReplicaSet의 파드가 하나의 노드에 몰려 있음
   → HA 확보를 위해 파드를 다른 노드로 분산
4. 비효율적인 자원 사용
   일부 노드는 거의 사용되지 않음 (유휴 상태)
   → 파드를 다른 노드로 옮기고, 유휴 노드를 제거 가능

Descheduler의 작동 원리

1. 클러스터 상태 분석
2. 구성된 정책에 따라 퇴출할 Pod 식별
3. 식별된 Pod 퇴출(evict)
4. 쿠버네티스 스케쥴러가 퇴출된 Pod를 새로운 위치로 재배치하도록 허용

이 프로세스가 주기적으로 실행되어 클러스터의 지속적인 최적화를 보장한다.

Descheduler 전략

확장 지점의 구현에 따라 Deschedule, Balance 두 개의 플러그인으로 나뉜다.

• Deschedule : Pod를 하나씩 처리하고 순차적으로 쫓아낸다.
• Balance : 모든 Pod 또는 Pod 그룹을 처리하고, 어떻게 분산되도록 의도되었는지에 따라 쫓아낼 Pod를 결정한다.

RemoveDuplicates(중복 제거)

• 같은 ReplicaSet이나 StatefulSet에 속한 파드가 동일한 노드에 여러 개 올라가 있는 경우, 하나를 다른 노드로 이동시켜 고가용성(HA) 확보

LowNodeUtilization(낮은 노드 활용도)

LowNodeUtilization은 자원 사용률이 낮은 노드에서 파드를 추출하여, 더 자원이 잘 활용되는 노드로 이동시킴으로써 전체 클러스터의 자원 효율을 높이는 Descheduler 전략이다.

1. 저활용 노드 식별
   설정된 기준(thresholds)보다 낮은 사용률을 가진 노드를 "저활용 노드"로 간주한다.

   thresholds:
    cpu: 20
    memory: 20
    pods: 20

   → CPU, 메모리, 파드 수 중 모든 값이 이 기준 미만이면 저활용 노드로 판단
2. 타깃 노드 확인
   파드를 옮기기 위해 사용 가능한 다른 노드 중 targetThresholds 이하로 사용 중인 노드를 찾는다.

   targetThresholds:
    cpu: 50
    memory: 50
    pods: 50

   → 이 범위를 초과하지 않도록 하여 자원 쏠림을 방지
3. 파드 이동
   저활용 노드의 파드 중에서:

• Eviction 가능한 파드만 선택 (예: ReplicaSet, Deployment 등의 파드)
• 타깃 노드로 이동 가능하면 이동
• 해당 노드가 비워지면, 나중에 노드를 스케일 인할 수 있게 됨 (노드 자동 축소)

⚠️ 주의할 점

• 실행 시점: Descheduler는 스케줄러와 달리 지속적으로 작동하지 않음 → 주기적으로 실행되거나 CronJob 등으로 관리 필요
• Eviction 제한: Eviction API를 사용하므로, PodDisruptionBudget(PDB) 등을 고려해야 함
• Stateful/특수 파드 제외: StatefulSet 등은 이동되지 않음
• Node Autoscaler와 병행 사용 시: 비워진 노드를 자동으로 제거하려면 Cluster Autoscaler 등이 설정되어 있어야 함

근데 저활용 노드의 pod를 다른 노드로 옮기는게 자원 균형이야? 쏠리는거 아냐?

언뜻 보면 저활용(low utilization) 노드에서 파드를 더 많이 사용 중인 노드로 옮기는 건 자원이 쏠리는 것처럼 보일 수 있다. 하지만 LowNodeUtilization 전략의 핵심 목적은 클러스터 전체의 자원 활용 효율을 높이는 것이다.

🔍 왜 저활용 노드에서 파드를 빼는가?
저활용 노드는 보통 이런 상태:

• 노드에 소수의 파드만 올라가 있음
• 해당 파드들의 자원 사용률도 낮음
• 노드 전체 자원은 낭비되고 있음

이 상태에서 파드를 빼서 다른 노드로 옮기면?
👉 해당 노드는 완전히 비우고, 필요하면 스케일 인(노드 제거) 가능
👉 다른 노드의 자원은 적절한 범위 안에서만 추가 부담
👉 전체적으로 노드 수를 줄이고, 비용 절감 및 자원 최적화 효과

📊 자원 쏠림이 아닌 이유: targetThresholds
이 설정이 방지 장치:

targetThresholds:
  "cpu" : 50
  "memory": 50
  "pods": 50

즉, 파드를 옮기려는 대상 노드도 50% 이상 사용되면 더 이상 파드를 받지 않음 → 쏠림 방지

RemovePodsViolatingNodeAffinity

노드 어피니티(Node Affinity) 조건을 더 이상 충족하지 않는 파드를 다른 노드로 옮김

출처

• descheduler Github
• 쿠버네티스 Descheduler: 클러스터 효율성 향상하기
• Chat GPT