AKS 장애 대응 - Node Not Ready, POD Pending 등 이슈 원인 파악 및 해결 방안

1. 개요

• AKS는 작업자 노드의 상태를 지속적으로 모니터링하고 비정상상태가 되면 노드를 자동 복구하며 두 가지 이중화된 방법으로 상태를 체크합니다..
• status 업데이트: kubelet이 주기적으로 Node의 리소스 상태를 API 서버에 업데이트
• Lease 객체: kubelet이 10초마다 Lease 객체를 갱

2. 자동 복구 방법

• AKS가 5분 이상 비정상으로 유지되는 노드를 식별하는 경우 다음 작업을 수행
  - AKS가 노드를 다시 부팅
  - 부팅 후 노드가 비정상이라면 AKS는 노드를 이미지로 다시 설치
  - 이미지 설치 후 노드가 비정상이고 Linux 노드인 경우 AKS가 노드를 다시 배포
  - 위 과정은 최대 3회 다시 시도

3. 자동 복구가 수행되지 않는 경우

• 네트워크 구성 오류로 노드 상태가 들어오지 않을 때
• 노드가 처음에 정상 노드로 등록하지 못한 경우
• 노드에 다음 taint중 하나가 있는 경우 : node.cloudprovider.kubernetes.io/shutdownToBeDeletedByClusterAutoscaler
• 노드가 업그레이드 중인 경우

4. Node Not Ready 원인 및 대응 방법

• 상황 :
  - kubectl get nodes 에 NotReady 표기
  - kubectl describe node 의 Conditions에서 Ready=False, NetworkUnavailable=True, MemoryPressure=True, DiskPressure=True, PIDPressure=True 등 확인
• 원인 및 대응 방법

A. kubelet/컨테이너 런타임 장애 1.    ssh를 통해 해당 node에 접속 2.    아래 명령어들을 이용해 kubelet, 컨테이너 런타임 장애여부 확인 journalctl -u kubelet -n 200 --no-pager journalctl -u containerd -n 200 --no-pager sudo systemctl status kubelet containerd 3.    컨테이너 런타임 프로세스 재시작 sudo systemctl restart containerd kubelet B. 리소스 부족 1.    kubectl describe node의 Pressure=True 확인 Memory/PID Pressure: 과소요 파드 제한/리소스쿼터 도입, 문제 파드 축출. 필요 시 노드풀 스케일아웃. 2.    DiskPressure: 이미지/컨테이너 정리 sudo crictl images sudo crictl rmi --prune sudo du -sh /var/lib/containerd/* /var/lib/kubelet/* 2>/dev/null C. 네트워크/CNI 문제 1.    NetworkUnavailable=True, kubelet이 API 서버로 Heartbeat 실패 2.    아래 명령어(CoreDNS, konnectivity 예시)를 이용해 장애 여부 확인 kubectl -n kube-system get pods -l k8s-app=kube-dns kubectl -n kube-system get pods | grep konnectivity 3.    CNI/시스템 파드 재시작, 노드 재부팅, 노드 교체, UDR/NSG 변경 여부 점검 D. 시간 동기화/인증 토큰 문제 1.    노드 시간이 크게 틀어진 경우 API 인증 실패 가능성이 존재, node에 접속 후 2.    아래 명령어를 이용해 시간 확인 timedatectl status 3.    NTP 동기화 복구, kubelet 재시작 E. 노드가 cordon/drain 상태로 방치 1.    NotReady,SchedulingDisabled 또는 kubectl get nodes에 SchedulingDisabled 2.    아래 명령어를 통해 node를 uncordon으로 설정 혹은 필요시 drain  kubectl uncordon <NODE>  kubectl drain <NODE> --ignore-daemonsets --delete-emptydir-data

 

5. POD Pending 원인 및 대응 방법

• 상황 : 
  - 스케줄러가 아직 파드를 어떤 노드에도 배치하지 못한 상태. (이미 스케줄된 뒤 컨테이너 풀/이미지 문제는 보통 ContainerCreating/ImagePullBackOff로 보입니다.)

A. 리소스 부족 1.    아래 명령어로 리소스 부족 확인 kubectl describe pod 2.    진단 결과에 따른 대응 o   스케일 아웃: 노드 풀 증가 o   리소스 요청 조정: requests/limits 현실화, 우선순위 검토 o   pod 수 제한(kubelet의 maxPods)에 걸리면 노드 타임/설정 변경 B. 스케줄링 제약 불일치 1.    nodeSelector/nodeAffinity/topologySpreadConstraints/podAntiAffinity가 현실과 안 맞음, 또는 taint/toleration 미스매치 2.    아래 명령어로 진단 kubectl describe pod <POD> | sed -n '/Events:/,$p' 3.    진단 결과에 따른 대응 o   label/taint 정합성 수정 o   제약 완화 또는 노드풀에 해당 특성 라벨 부여/증설 C. 스토리지 대기(PVC Pending) 1.    파드가 Pending, PVC가 Bound되지 않음 2.    아래 명령어로 진단 kubectl get pvc kubectl describe pvc <PVC> 3.    진단 결과에 따른 대응 o   StorageClass 오타 o   존 불일치 o   용량, I/O 제한 o   디스크/SCI 문제 o   리소스 쿼터 부족

 

6. Pod Pending 해결 방안 풀이

• AKS 클러스터 내에서 Pod가 Pending 상태가 되는 것은 일반적으로 스케줄러가 해당 Pod를 적절한 노드에 할당하지 못하는 것을 의미합니다. 특히 노드가 준비되지 않은 상태일 때, Pod Pending이 자주 발생하는데, 이는 클러스터 운영에 심각한 영향을 줄 수 있으므로 원인 분석과 신속한 대응이 필요합니다.
• 첫째, 노드 자체가 정상적으로 준비되지 않아서 스케줄러가 Pod를 할당하지 못하는 경우입니다. 이때 노드가 `NotReady` 상태이거나, 클러스터 노드 그룹에서 노드 생성 지연, OS 또는 에이전트 문제 등으로 초기화가 완료되지 않은 상황일 수 있습니다. 이에 대한 대응으로는 해당 노드의 상태를 `kubectl get nodes` 등으로 확인하고, AKS 노드 풀 상태를 모니터링하며 필요하면 노드를 재시작하거나, 문제가 지속 시 노드 풀을 재구성하거나 교체하는 조치가 필요합니다.
• 둘째, 리소스 부족 문제입니다. 클러스터 내 가용 노드가 있지만, CPU, 메모리, GPU 등 자원 부족으로 인해 스케줄링이 불가능하여 Pod가 Pending 상태에 머무는 경우입니다. 특히 제한된 리소스를 가진 노드 풀에서 고리소스 요구 Pod가 다수 배포될 때 흔하게 발생합니다. 대응 방법으로는 리소스 요청(Request)과 제한(Limit)을 적절히 설계하고, 필요 시 노드 풀에 노드를 추가하거나 HPA(Horizontal Pod Autoscaler), Cluster Autoscaler를 활용해 클러스터 확장 정책을 적용하는 것이 효과적입니다.
• 셋째, 스케줄링 제약 조건(Scheduling Constraints)으로 인해 노드에 Pod가 할당되지 못하는 경우입니다. 예를 들어, Pod에 설정된 노드 셀렉터(NodeSelector), 노드 친화성(Node Affinity), taint 및 toleration 정책과 같은 배치 제한 조건들이 노드와 맞지 않으면 스케줄러가 매칭을 못해 Pending 상태가 됩니다. 이 경우 Pod 및 노드의 라벨(Label), taint, toleration 설정을 점검하고 불필요하거나 잘못된 제약 조건을 제거하거나 수정해야 합니다.
• 넷째, 네트워크 또는 스토리지 등의 외부 종속성 문제로 인해 Pod가 정상적으로 스케줄링되지 못하는 경우입니다. 예를 들어, Azure Disk, Azure Files와 같이 외부 볼륨 프로비저닝이 지연되거나 실패하면 Pod가 Pending 상태에 머무르게 됩니다. 이런 상황에선 PersistentVolume, PersistentVolumeClaim 상태를 점검하고, 적절한 스토리지 클래스와 프로비저닝 정책을 확인하는 것이 필요합니다.
• 마지막으로, 클러스터 구성 또는 제어 평면(Control Plane) 문제로 노드 상태 갱신이 늦거나, API 서버와 노드 에이전트 간 통신 장애가 발생하는 경우도 있습니다. 이 경우에는 클러스터 상태 대시보드 확인, Azure 모니터링 로그 및 이벤트 분석, 필요한 경우 Azure 지원팀과 협력하여 문제 원인을 규명하고 해결해야 합니다.
• 따라서, AKS에서 노드 준비 실패로 인한 Pod Pending 문제에 대응하기 위해서는 먼저 노드 상태 및 클러스터 리소스 현황을 정확히 파악하고, 스케줄링 제약 조건을 점검하며, 외부 종속성과 클러스터 상태까지 종합적으로 분석하는 체계적인 접근이 필요합니다. 이러한 과정을 통해 적절한 노드 재구성, 클러스터 확장, 배치 제약 완화, 외부 리소스 문제 해결 조치를 시행하여 안정적인 AKS 운영을 유지할 수 있습니다.

7. 참고 문서

• 노드 준비 안됨 현상 https://learn.microsoft.com/ko-kr/troubleshoot/azure/azure-kubernetes/availability-performance/node-not-ready-basic-troubleshooting
• 노드 자동 복구 https://learn.microsoft.com/ko-kr/azure/aks/node-auto-repair
• Pod 스케줄러 오류 https://learn.microsoft.com/ko-kr/troubleshoot/azure/azure-kubernetes/availability-performance/troubleshoot-pod-scheduler-errors
• https://hjin9445s-organization.gitbook.io/archive/work/undefined/cds