Kubernetes 스케줄링 오류 설명: 해결 방법 및 모범 사례

Kubernetes는 컨테이너화된 애플리케이션을 오케스트레이션하는 사실상의 표준입니다. 선언적 특성으로 배포를 단순화하지만, Pod가 시작을 거부하는 이유, 특히 스케줄링 실패의 원인을 파악하는 것은 클러스터 운영자와 개발자에게 일반적인 장애물입니다. 확장된 기간 동안 Pending 상태를 유지하는 Pod는 Kubernetes 스케줄러가 이를 실행할 적합한 노드를 찾지 못했음을 나타냅니다.

스케줄링 오류를 이해하는 것은 애플리케이션 가동 시간을 유지하고 클러스터 활용도를 최적화하는 데 중요합니다. 이 가이드는 불충분한 리소스, 부적절한 선호도 규칙, 제한적인 Taint와 같은 스케줄링 실패의 가장 빈번한 원인을 체계적으로 분석하고, 사용 가능한 노드에 워크로드가 성공적으로 안착하도록 보장하는 명확한 해결 방법과 모범 사례를 제공할 것입니다.

보류 중인 Pod 진단: 첫 번째 단계

수정을 시도하기 전에 스케줄러가 실패하는 이유를 정확하게 진단해야 합니다. 이 조사를 위한 주요 도구는 kubectl describe pod입니다.

Pod가 Pending 상태에 갇혀 있을 때, describe 출력의 Events 섹션에는 스케줄링 결정 프로세스와 거부 사항을 자세히 설명하는 중요한 정보가 포함되어 있습니다.

`kubectl describe pod` 사용하기

항상 문제가 되는 Pod를 대상으로 하십시오:

kubectl describe pod <pod-name> -n <namespace>

출력을 검토하고 특히 하단의 Events 섹션을 확인하십시오. 여기에 있는 메시지는 스케줄링을 방해한 제약 조건을 명시적으로 나타낼 것입니다. 일반적인 메시지는 종종 Insufficient cpu, Insufficient memory 또는 특정 predicate 실패와 관련이 있습니다.

일반적인 스케줄링 오류 범주 및 해결 방법

스케줄링 실패는 일반적으로 리소스 제약, 정책 제약(선호도/반선호도), 노드 구성(Taint/Toleration)의 세 가지 주요 범주로 나뉩니다.

1. 리소스 제약(리소스 부족)

가장 빈번한 원인입니다. 스케줄러는 Pod 사양에 정의된 요청을 충족할 수 있는 노드를 필요로 합니다. 할당 가능한 CPU 또는 메모리가 충분한 노드가 없으면 Pod는 Pending 상태를 유지합니다.

문제 식별

Events 섹션에는 다음과 같은 메시지가 표시됩니다:

0/3 nodes are available: 3 Insufficient cpu.
0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 2 node(s) didn't match node selector.

리소스 부족 해결 방법

Pod 요청 줄이기: Pod 요청이 과도하게 높으면 Pod 또는 Deployment YAML에서 CPU 또는 메모리 requests를 낮추십시오.
클러스터 용량 늘리기: Kubernetes 클러스터에 더 많은 노드를 추가하십시오.
기존 워크로드 정리: 기존 노드에서 우선순위가 낮거나 필수적이지 않은 Pod를 종료하여 리소스를 확보하십시오. (kubectl drain 사용 또는 기존 배포의 리소스 요청 조정).
Limit Ranges 사용: 네임스페이스에 정의된 리소스 제한이 없는 경우, 단일 Pod가 리소스를 독점하는 것을 방지하기 위해 LimitRange 객체를 구현하십시오.

2. 노드 선택기 및 선호도/반선호도 규칙

Kubernetes는 nodeSelector, nodeAffinity, podAffinity/podAntiAffinity를 사용하여 Pod를 어디에 배치할 수 있는지 또는 배치해야 하는지에 대한 세밀한 제어를 제공합니다.

노드 선택기 불일치

사용 가능한 노드에 존재하지 않는 레이블과 일치하는 nodeSelector를 정의하면 Pod를 스케줄링할 수 없습니다.

YAML 스니펫 예시(실패 원인):

spec:
  nodeSelector:
    disktype: ssd-fast
  containers: [...] # disktype=ssd-fast를 가진 노드가 없으면 Pod는 Pending 상태 유지

해결 방법: nodeSelector에 지정된 레이블이 하나 이상의 노드에 존재하고(kubectl get nodes --show-labels) 대소문자가 정확히 일치하는지 확인하십시오.

노드 선호도 제약 조건

nodeAffinity는 더 유연한 규칙(예: requiredDuringSchedulingIgnoredDuringExecution 또는 preferredDuringSchedulingIgnoredDuringExecution)을 제공합니다. required 규칙을 충족할 수 없으면 Pod는 Pending 상태를 유지합니다.

진단 팁: 복잡한 선호도 규칙을 사용할 때 Events 섹션에는 종종 다음과 같이 표시됩니다: node(s) didn't match node selector.

Pod 선호도 및 반선호도

이러한 규칙은 다른 Pod에 대한 배치를 제어합니다. 예를 들어, 반선호도 규칙이 특정 서비스를 호스팅하는 노드에서 Pod를 실행 하지 않도록 요구하지만, 모든 노드가 이미 해당 서비스를 호스팅하고 있다면 스케줄링이 실패합니다.

해결 방법: 선호도 규칙에서 토폴로지 키와 선택기를 주의 깊게 검토하십시오. 반선호도 규칙이 너무 제한적이라면 요구 사항을 완화하거나 규칙으로 선택된 대상 Pod가 실제로 피하려는 노드에서 실행 중인지 확인하십시오.

3. Taints 및 Tolerations

Taint는 Pod를 거부하기 위해 노드에 직접 적용되고, Toleration은 Taint된 노드에 Pod가 배치되도록 허용하기 위해 Pod 사양에 추가됩니다.

Taint: 일치하는 toleration이 없으면 Pod를 거부합니다.
Toleration: 일치하는 taint가 있는 노드에 Pod를 스케줄링할 수 있도록 허용합니다.

Taint 거부 식별

Events는 명확하게 거부 이유를 명시합니다:

0/3 nodes are available: 2 node(s) had taint {dedicated: special-workload, effect: NoSchedule}, that the pod didn't tolerate.

Taints 및 Tolerations 해결 방법

두 가지 주요 경로가 있습니다:

Pod 수정 (애플리케이션 Pod에 권장): 노드의 Taint와 일치하는 필요한 tolerations를 Pod 사양에 추가하십시오.

Toleration 예시:

yaml spec: tolerations: - key: "dedicated" operator: "Equal" value: "special-workload" effect: "NoSchedule" containers: [...]
노드 수정 (클러스터 관리자에게 권장): 제한이 더 이상 필요하지 않으면 노드에서 Taint를 제거하십시오.

```bash

Taint 제거 방법

kubectl taint nodes dedicated:special-workload:NoSchedule-
```

모범 사례 경고: 의도적으로 마스터 노드에 중요한 제어 영역 구성 요소를 스케줄링하는 경우가 아니라면, 애플리케이션 Pod에 전역 node-role.kubernetes.io/master:NoSchedule Taint를 허용하지 마십시오.

고급 스케줄링 제약 조건

덜 일반적이지만 중요한 제약 조건도 스케줄링을 차단할 수 있습니다:

스토리지 볼륨 제약 조건

Pod가 현재 사용 가능한 노드에 바인딩될 수 없는 PersistentVolumeClaim(PVC)을 요청하는 경우(예: 특정 스토리지 프로비저너 요구 사항 또는 볼륨 부족으로 인해), Pod는 Pending 상태를 유지할 수 있습니다.

진단: 먼저 PVC 상태를 확인하십시오 (kubectl describe pvc <pvc-name>). PVC가 Pending 상태에 갇혀 있다면 볼륨이 사용 가능해질 때까지 Pod 스케줄링이 중단됩니다.

DaemonSets 및 토폴로지 확산

DaemonSets는 (있는 경우) 선택 기준과 일치하는 노드에만 스케줄링됩니다. 클러스터가 분할되었거나 새 노드가 DaemonSet의 선택기와 일치하지 않으면 실행되지 않습니다.

토폴로지 확산 제약 조건 (정의된 경우)은 균등한 배포를 보장합니다. 현재 배포가 확산 제약 조건을 준수하면서 어느 노드에도 배치를 방해하는 경우 스케줄링이 실패합니다.

성공적인 스케줄링을 위한 모범 사례

스케줄링 문제를 최소화하려면 다음과 같은 운영 모범 사례를 채택하십시오:

리소스 요청 명시적으로 정의: 항상 CPU 및 메모리에 대해 합리적인 requests (및 선택적 limits)를 설정하십시오. 이를 통해 스케줄러는 노드 용량을 정확하게 평가할 수 있습니다.
영역 지정에 노드 레이블 사용: 일관된 노드 레이블링(예: hardware=gpu, zone=us-east-1a)을 구현하고 nodeSelector 또는 nodeAffinity를 사용하여 워크로드를 적절한 하드웨어로 안내하십시오.
Taints 및 Tolerations 문서화: 유지 보수 또는 하드웨어 분리를 위해 노드가 Taint된 경우, 이러한 Taint를 중앙에 문서화하십시오. Taint된 리소스에 대한 액세스가 필요한 애플리케이션 매니페스트에는 해당 Tolerations가 포함되도록 하십시오.
클러스터 자동 스케일러 모니터링 (사용 중인 경우): 스케일링 솔루션에 의존하는 경우, 기능이 제대로 작동하는지 확인하십시오. 스케일링을 트리거해야 하는 용량 부족이 조용히 실패하여 Pod가 보류 상태로 남겨질 수 있습니다.
스케줄러 로그 검토 (고급): 심층 진단을 위해 kube-scheduler 구성 요소 자체의 로그를 검토하십시오. 이 구성 요소는 모든 스케줄링 시도와 거부 이유를 기록합니다.

결론

Kubernetes 스케줄링 오류는 답답할 수 있지만, 거의 항상 Pod가 필요로 하는 것(요청, 선호도, Tolerations)과 노드가 제공하는 것(용량, 레이블, Taint 부족) 간의 불일치로 추적될 수 있습니다. kubectl describe pod를 체계적으로 사용하여 Events를 검사하고 리소스 제한, 선호도 불일치 또는 Taint 장벽을 해결함으로써 보류 중인 Pod를 신속하게 해결하고 컨테이너 오케스트레이션이 원활하게 실행되도록 보장할 수 있습니다.