IL-0449 Enigmo · 2020-12-13 (게시일)kubernetesaws
EKS 관리형 노드 그룹으로 옮긴 며칠 뒤 파드가 재시작을 되풀이하거나 Terminating 상태에 멈추고 노드를 쓸 수 없게 됐다
Enigmo 는 일부 서비스에 Amazon EKS 클러스터를 쓰고, 2020년 봄 1.13 에서 1.15 로 올렸다. EKS 1.16 이 예상보다 일찍 나오자 팀은 1.16 업그레이드를 준비했다. 팀은 kubent 로 extensions/v1beta1 같은 폐기 예정 API 를 쓰는 리소스를 찾았다. 그리고 복제한 Deployment 를 잠시 띄워 파드 수가 0 이 되지 않게 하면서 그 리소스를 apps/v1 로 바꿨다. 그다음 EKS 1.13 때 EC2 LaunchTemplate 과 AutoScalingGroup 으로 만든 노드 그룹을 관리형 노드 그룹으로 옮기고 옛 노드 그룹을 지웠다. 관리형 노드 그룹은 그해 여름에야 LaunchTemplate 을 지원해 SecurityGroup 을 자유롭게 지정할 수 있게 됐다.
옮기고 2~3일 뒤 파드가 재시작을 되풀이하거나 종료되지 못하고 남았다. 노드의 CPU 와 메모리 부하가 높아져 노드를 쓸 수 없게 됐다. 원인은 관리형 노드 그룹을 만든 AMI 의 버그였다. 옛 노드 그룹은 이미 없었고, 관리형 노드 그룹은 최신 AMI 만 허용해 옛 AMI 로 되돌릴 수 없었다. 수정된 AMI 가 나온 뒤에도 파드가 종료되지 않아 노드 그룹 업데이트 중 Eviction 이 실패했다. 팀은 CloudFormation 으로 업데이트를 돌리면서 kubectl get pods --all-namespaces 로 파드를 지켜보고, Terminating 상태에서 한동안 변화가 없는 파드를 강제로 지웠다.
- 심각도
- –
- 영향 범위
- Pods on the EKS cluster's managed node groups restarted repeatedly or could not stop, and nodes became unusable under CPU and memory load
- 영향 사용자
- –
- 지역
- –
- 감지까지
- –
- 복구까지
- –
증상
EKS 클러스터의 파드를 새로 만든 관리형 노드 그룹으로 옮기고 2~3일 지나자, 파드가 갑자기 재시작을 되풀이하거나 제대로 종료되지 못하고 Terminating 상태로 계속 남았다. 노드의 CPU 와 메모리 부하가 높아져 클러스터에서 노드를 쓸 수 없게 됐다.
옛 노드 그룹은 이미 지운 뒤라 파드를 되돌릴 수 없었다. 팀은 파드를 간신히 돌리며 조사했고, "Pods stuck in terminating state after AMI amazon-eks-node-1.16.15-20201112" 로 알려진 버그에 걸렸다는 것을 알았다.
CloudFormation 으로 관리형 노드 그룹을 옛 AMI 로 바꾸려 하자 다음 오류가 났다. Requested Nodegroup release version 1.15.11-20201007 is invalid. Allowed release version is 1.15.12-20201112 (Service: AmazonEKS; Status Code: 400; Error Code: InvalidParameterException; Request ID: ----; Proxy: null) 관리형 노드 그룹은 최신 AMI 만 쓸 수 있어서 되돌릴 방법이 없었다.
수정된 AMI 가 나와 노드 그룹을 업데이트했다. 업데이트 과정에는 Taint 부여, Drain, 파드 Eviction 이 있는데, 파드가 종료되지 않아 Eviction 이 실패했고 노드 그룹 업데이트도 실패했다.
원인
- 촉발
- EKS 1.16 업그레이드를 앞두고 파드를 버그가 있는 AMI 로 만든 새 관리형 노드 그룹으로 옮기고 옛 노드 그룹을 지웠다.
감지
–
조치
- 수정된 AMI 가 나오자 관리형 노드 그룹의 AMI 버전을 바꿨다.
- CloudFormation 으로 관리형 노드 그룹 업데이트를 실행했다.
- 업데이트가 도는 동안 kubectl get pods --all-namespaces 로 파드 상태를 지켜봤다.
- Terminating 상태로 한동안 변화가 없는 파드를 찾을 때마다 kubectl delete pods <pod name> --grace-period=0 --force 로 강제로 지웠다.
후속 조치
- 분기나 달마다 각종 모듈의 최신 릴리스를 확인하고 정기적으로 업그레이드해, 서비스 영향을 가장 작게 하는 운영 방법을 찾는다.
교훈
Amazon EKS 나 쿠버네티스를 쓰는 한 클러스터 본체와 Ingress Controller 같은 모듈의 업그레이드를 늘 신경 써야 한다. 안정적으로 돈다고 한동안 손대지 않고 두면, 그사이 호환성을 깨는 변경이 담긴 릴리스가 갑자기 발표되는 일이 드물지 않다. 쿠버네티스 마이너 버전은 3개월쯤마다 나오므로 1년에 적어도 한 번은 업그레이드해야 한다.
출처
관련 사례
IL-0101자동 업그레이드를 꺼 둔 GKE 클러스터의 컨트롤 플레인이 지원 종료 기한에 1.33.2 로 강제 업그레이드된 뒤 새 노드가 모두 초기화에 실패해, 오토스케일링과 스팟 노드 복구가 15시간 멈췄다.Wealthy · 2025 · sev1같은 원인 · 공통 노드 풀
IL-0120클라우드 GPU 서버의 정기 OS 업데이트가 systemd-networkd 를 재시작해 자체 네트워크 에이전트와 충돌했고, 많은 GPU 노드의 라우트가 모두 지워져 ChatGPT 와 API 의 오류율이 크게 올랐다.OpenAI · 2025같은 원인 · 공통 노드 운영체제 이미지
IL-0079GKE 노드가 새 ubuntu_containerd 이미지로 자동 업그레이드된 뒤 커널에서 kube-proxy 가 쓰는 iptables 확장이 빠져, 여러 GKE 클러스터의 인그레스 트래픽이 완전히 끊겼다.Altinity · 2025같은 원인 · 공통 노드 운영체제 이미지
IL-0404Karpenter 가 운영 EKS 노드를 Bottlerocket v1.26.0 으로 바꾼 뒤 BSEE SaaS 고객 인스턴스의 파드가 모두 crash loop back off 에 빠졌다PortSwigger · 2024같은 원인 · 공통 노드 운영체제 이미지
IL-0198systemd 보안 패치가 Ubuntu 22.04 노드의 systemd-networkd 를 재시작해 Cilium 이 넣은 IP 규칙을 지웠고, 여러 리전과 세 클라우드의 Kubernetes 노드가 한꺼번에 네트워크를 잃었다.Datadog · 2023같은 원인 · 공통 노드 운영체제 이미지
같은 원인 · 공통 노드 운영체제 이미지
IL-0144Ubuntu 18.04 의 systemd 보안 업데이트가 DNS 설정을 날려 AKS 노드의 kubelet 이 레지스트리 이름을 해석하지 못하고 파드가 ImagePullBackoff 에 빠졌다.Microsoft Azure · 2022같은 원인 · 공통 노드 운영체제 이미지
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0449
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0449/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.