NotReady 상태의 Kubernetes 노드 디버깅

Source: Dev.to

NotReady 상태에 갇힌 노드는 가장 흔하고, 가장 파괴적인 Kubernetes 문제 중 하나입니다. 노드가 NotReady 상태가 되면, 컨트롤 플레인은 해당 노드에 새로운 파드를 스케줄링하는 것을 중단하고, 일정 시간 후 기존 워크로드를 퇴거시키기 시작합니다.

다음은 근본 원인을 진단하고 해결하는 방법입니다.

NotReady는 무엇을 의미하나요?

모든 Kubernetes 노드는 주기적으로 상태를 API 서버에 보고하는 kubelet 프로세스를 실행합니다. API 서버가 이러한 하트비트를 받지 못하면(기본값: 10초마다, 40초 후 타임아웃) 해당 노드를 NotReady 상태로 표시합니다.

NotReady 상태는 제어 플레인이 이 노드가 정상이며 작업에 사용할 수 있는지를 확인할 수 없다는 의미입니다.

노드 상태를 확인하려면 다음을 실행하세요:

kubectl get nodes

문제가 있는 출력 예시:

NAME          STATUS     ROLES    AGE   VERSION
worker-01     Ready         45d   v1.34.2
worker-02     NotReady      45d   v1.34.2
worker-03     Ready         45d   v1.34.2

단계 1: 노드 상태 확인

kubectl describe node 명령을 실행하여 보고되는 상태를 확인합니다:

kubectl describe node worker-02

Conditions 섹션을 살펴보세요:

Conditions:
Type                 Status  Reason
----                 ------  ------
MemoryPressure       False   KubeletHasSufficientMemory
DiskPressure         True    KubeletHasDiskPressure
PIDPressure          False   KubeletHasSufficientPID
Ready                False   KubeletNotReady

일반적인 상태 플래그

단계 2: Kubelet 로그 확인

The kubelet은 노드 상태를 유지하는 에이전트입니다. 충돌하거나 잘못 구성되면 노드가 NotReady 상태가 됩니다.

# SSH into the node
ssh worker-02

# Check kubelet status
systemctl status kubelet

# View recent logs
journalctl -u kubelet --since "10 minutes ago" --no-pager

일반적인 kubelet 문제

단계 3: 컨테이너 런타임 확인

Kubernetes는 컨테이너 런타임(containerd 또는 CRI‑O)에 의존합니다. 런타임에 문제가 있으면 kubelet이 파드를 관리할 수 없습니다.

# containerd 상태 확인
systemctl status containerd

# 런타임 엔드포인트 확인
crictl info

# 컨테이너 목록 (실행 중인 시스템 컨테이너가 표시되어야 함)
crictl ps

containerd가 응답하지 않을 경우:

systemctl restart containerd
systemctl restart kubelet

Step 4: 리소스 고갈 확인

NotReady 노드의 가장 흔한 원인은 리소스 고갈입니다.

Disk Space

df -h /
df -h /var/lib/kubelet
df -h /var/lib/containerd

Fix: 사용되지 않는 컨테이너 이미지와 중지된 컨테이너를 정리합니다.

# containerd
crictl rmi --prune

# Docker (if used)
docker system prune -af

Memory

free -h
# Check top memory consumers
ps aux --sort=-%mem | head -20

Fix: 과도한 메모리를 사용하는 파드를 식별하고 리소스 제한이 설정되어 있는지 확인합니다.

kubectl top pods --all-namespaces --sort-by=memory | head -20

Process IDs

# Check current PID count vs limit
cat /proc/sys/kernel/pid_max
ls /proc | grep -c '^[0-9]'

Step 5: 네트워킹 확인

노드가 API 서버에 도달하지 못하면, 다른 상태가 정상이라도 NotReady 상태가 됩니다.

# Test API server connectivity
curl -k https://:6443/healthz

# Check DNS resolution
nslookup kubernetes.default.svc.cluster.local

# Verify network plugin (CNI) is running
crictl ps | grep -E "calico|flannel|cilium|weave"

CNI 플러그인 충돌? 이것은 놀라울 정도로 흔한 문제입니다. 네트워크‑플러그인 파드(Calico, Flannel, Cilium 등)가 실행 중이 아니면 모든 네트워킹이 실패합니다:

kubectl get pods -n kube-system | grep -E "calico|flannel|cilium"

단계 6: 클라우드 제공자 문제 확인

관리형 Kubernetes(EKS, GKE, AKS)에서 NotReady 노드는 다음을 의미할 수도 있습니다:

• 인스턴스가 자동 스케일러 또는 스팟 인스턴스 회수에 의해 종료되었습니다.
• 클라우드 제공자 수준에서 인스턴스 건강 검사가 실패했습니다.

특정 클라우드 제공자의 진단 정보를 기반으로 문제 해결을 계속하십시오.

네트워크 ACL 또는 보안 그룹이 kubelet‑to‑API‑server 트래픽을 차단함

클라우드 제공자의 인스턴스 상태를 확인하십시오:

# AWS EKS
aws ec2 describe-instance-status --instance-ids <instance-id>

# GKE – check node pool status
gcloud container node-pools describe <node-pool> --cluster <cluster-name>

# AKS
az aks nodepool show --name <nodepool-name> --cluster-name <cluster-name> -g <resource-group>

예방: NotReady가 발생하기 전에 방지

• 모든 파드에 리소스 요청 및 제한을 설정합니다. 제한이 없으면 단일 파드가 전체 메모리를 소모해 노드를 충돌시킬 수 있습니다.
• 관리형 서비스에서 노드 자동 복구를 활성화합니다 (GKE와 AKS는 기본적으로 지원하고, EKS는 노드 상태 검사를 통해 지원합니다).
• 디스크 사용량을 모니터링하고 85 % 퇴거 임계값보다 훨씬 앞선 70 % 용량에서 알림을 설정합니다.
• **Pod Disruption Budget(PDB)**을 사용하여 동시에 퇴거될 수 있는 파드 수를 제어합니다.
• Kubernetes 버전을 최신 상태로 유지합니다. 오래된 버전에는 잘못된 NotReady 이벤트를 일으키는 알려진 kubelet 버그가 있습니다. 버전의 상태는 ReleaseRun에서 확인하세요.

빠른 문제 해결 흐름도

kubectl describe node    # Check conditions

• DiskPressure/MemoryPressure가 true인가요? → 리소스를 정리합니다.
• kubelet이 실행 중인가요? → systemctl status kubelet → 필요하면 재시작합니다.
• containerd가 실행 중인가요? → systemctl status containerd → 필요하면 재시작합니다.
• 노드가 API 서버에 접근할 수 있나요? → 네트워크/방화벽 규칙을 확인합니다.
• CNI 플러그인이 실행 중인가요? → kube‑system 파드를 확인합니다.
• 아직도 문제가 있나요? → journalctl -u kubelet을 검사하여 구체적인 오류를 확인합니다.

Kubernetes 버전 상태 추적

오래된 Kubernetes 버전을 실행하면 NotReady 이벤트를 일으키는 kubelet 버그 위험이 증가합니다. Kubernetes 1.32는 2026년 2월 28일에 수명이 종료됩니다. 아직 사용 중이라면, 우리의 migration playbook을 참고하세요.

ReleaseRun’s Kubernetes hub에서 모든 버전의 상태, CVE 현황 및 EOL 날짜를 모니터링하세요.

관련 읽을거리

• Kubernetes Upgrade Checklist – 업그레이드 중 NotReady 상태를 방지하는 런북.
• Kubernetes 1.32 End of Life: Migration Playbook – 마감일: 2026년 2월 28일.
• Kubernetes EOL Policy Explained – 버전 지원이 종료되는 시점을 확인하세요.
• Kubelet Restarts in K8s 1.35.1 – 테스트할 관련 노드‑안정성 이슈.
• Popular Kubernetes Distributions Compared – 다양한 배포판이 노드 문제를 어떻게 처리하는지 비교.