본문 요약 (개요 흐름)
핵심 질문
EKS CronJob은 LB가 없이 어떻게 노드에 분산되는가?
스케줄러는 어떤 기준으로 점수를 계산해 Pod을 배치하는가?
Kubernetes 스케줄러의 2단계 배치 알고리즘
- Filtering 단계 – 실행 가능한 노드를 먼저 필터링
- nodeSelector, taints/tolerations, required nodeAffinity 등 하드 조건 기준
- 조건 미충족 시 해당 노드는 제외
- Scoring 단계 – 남은 후보 노드들에 점수를 매김
- 가장 점수가 높은 노드에 Pod 배치됨
- 동률일 경우 우선순위 큐, 생성 시점 등 내부 기준에 따라 결정
점수 산정에 사용되는 주요 요소들
| 기준 | 설명 |
|---|---|
| preferred nodeAffinity | 특정 라벨 가진 노드를 선호 → 점수 +10~+100 |
| podAntiAffinity | 동일한 app의 Pod이 있으면 회피 유도 → 점수 -10~-30 |
| topologySpreadConstraints | hostname, zone 등 기준으로 분산 유도 |
| resource usage (LeastAllocated) | 자원이 가장 덜 쓰인 노드 선호 |
| image locality | 이미지가 해당 노드에 캐싱돼 있으면 점수 가산 |
실전 예제: affinity와 anti-affinity 혼합된 분산 시나리오
- Pod이
group=batch-01,group=batch-02순으로 affinity weight를 가지면- batch-01 노드 존재 시 → 거기로 우선 배치
- 없으면 batch-02 → 없으면 다른 노드
podAntiAffinity로 동일 작업 app의 Pod이 이미 존재하면 해당 노드는 점수 감소
CPU request/limit 에 따른 스케줄링 점수 영향
- request: 스케줄러가 예약할 자원량 (예: 1코어)
- limit: 최대 사용 가능량 (예: 3코어)
- 실제 사용량이 2코어일 경우 → 1코어는 노드에 예약된 상태, 나머지 1코어는 공유 상태
- unused CPU는 다른 Pod이 사용할 수 있음
실전 팁
- 스케줄링이 Pending 되는 경우는 대부분 hard affinity 조건 불만족 때문
- preferred 조건은 fallback 및 유연한 배치에 적합
ttlSecondsAfterFinished로 Completed Pod을 빨리 GC 시키면 podAntiAffinity 조건의 충돌 최소화 가능