EKS 노드 NotReady 상태 진단 가이드
1단계: 외부 진단 (kubectl 명령어)
노드에 접속하기 전, 컨트롤 플레인이 인식하고 있는 상태를 먼저 파악합니다.
노드 상태 상세 확인:
kubectl describe node [노드_이름]Conditions 섹션 확인:
MemoryPressure,DiskPressure,PIDPressure가True인지 확인하세요. 리소스 부족이 원인일 수 있습니다.Events 섹션 확인: 최근 발생한 에러 메시지(예:
Kubelet stopped posting node status)를 통해 힌트를 얻을 수 있습니다.
2단계: 내부 진단 (노드 직접 접속 후 로그 확인)
SSM(Session Manager)이나 SSH로 노드에 접속하여 아래 로그들을 순서대로 확인합니다.
확인 대상 | 로그 확인 명령어 (Amazon Linux 2/2023 기준) | 확인 포인트 |
Kubelet 로그 |
| 노드 관리의 핵심. API 서버와의 통신 에러, 인증 문제 등 |
컨테이너 런타임 |
| 컨테이너를 실행하는 엔진(containerd) 자체의 크래시 여부 |
시스템 로그 |
| 커널 수준의 에러, Out of Memory(OOM) 킬러 작동 여부 |
네트워크(CNI) |
| AWS VPC CNI 문제로 IP 할당이 안 되어 발생하는 통신 장애 |
3단계: 네트워크 및 메타데이터 서비스(IMDS) 확인
EKS 노드는 AWS 메타데이터 서비스(IMDS)와 통신이 안 되면 자신을 식별하지 못해 NotReady가 될 수 있습니다.
IMDS 응답 테스트:
curl -H "X-aws-ec2-metadata-token: $(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")" http://169.254.169.254/latest/meta-data/instance-id
응답이 없다면? 보안 그룹(SG)이나 라우팅 문제로 내부 통신이 차단된 상태입니다.
Tip
로그를 봐도 원인이 모호하다면, 해당 노드에 할당된 IAM Role의 권한을 다시 확인해 보세요. 특히 AmazonEKSWorkerNodePolicy, AmazonEC2ContainerRegistryReadOnly, AmazonEKS_CNI_Policy 이 세 가지가 하나라도 빠지면 노드는 절대 Ready가 될 수 없습니다.
흔히 발생하는 NotReady 원인 TOP 3
VPC IP 고갈: 서브넷에 남은 IP가 없어서 새 Pod가 생성되지 못하거나 CNI가 에러를 뿜을 때 발생합니다.
보안 그룹 설정 오류: 워커 노드와 컨트롤 플레인 간의 443 또는 10250 포트가 막히면 노드 상태 업데이트가 불가능해집니다.
AL2023 마이그레이션 이슈: 최신 EKS 노드 OS(Amazon Linux 2023)로 업그레이드하면서 기존 커스텀 스크립트나 보안 솔루션이 충돌을 일으키는 경우가 많습니다.
댓글
댓글 0개
이 문서에는 댓글을 달 수 없습니다.