IL-0112 DFDS · 2022-10-31kubernetesaws
DFDS 의 인프라 모듈은 매일 노드를 롤오버할 때 나와 있는 가장 최신 AWS EKS 노드 AMI 를 쓰도록 고정돼 있었고, 특정 AMI 를 지정하는 기능이 없었다. 2022-10-29 에 나온 AMI v20221027 은 나중에 커널 문제로 회수됐는데, 10-31 아침 롤오버가 이 AMI 로 노드를 바꿨다. 이 이미지 때문에 클러스터 안에서 간헐적인 통신 문제가 생겼다. 노드가 잠깐씩 "PLEG is not healthy" 를 보고하거나 unhealthy 로 나타났고, 한 팀은 배포한 파드에서 다른 서비스로 가는 통신에서 네트워크 타임아웃을 겪었다.
같은 날 오후 vpc-cni 애드온 업그레이드를 함께 진행하면서 상황이 더 헷갈렸다. 업그레이드가 멈췄고, 팀은 Terminating 에 멈춘 노드를 하나씩 cordon, drain, 삭제해 업그레이드를 끝냈다. 이렇게 지운 노드가 모두 15대였다. 팀은 17:21 에 GitHub 에서 v20221027 의 PLEG 관련 이슈를 찾았고, 이 AMI 가 커널 문제로 회수됐다는 것을 알았다.
서비스 손실은 보이지 않아서 팀은 새 AMI 를 기다리며 지켜보기로 했다. 그러나 노드당 소켓 수가 계속 늘고 Kubernetes 이벤트가 통신 문제를 보고하자 11-02 11:56 에 AMI 를 되돌리기로 했다. 특정 AMI 를 지정할 수 있게 terraform 을 고쳐 머지했고, 13:46 에 파이프라인이 노드를 이전 AMI 로 되돌렸다. 14:40 에 문제가 풀린 것을 확인했다. 감지까지 7시간, 복구까지 54시간 10분이 걸렸다.
장애는 개발팀 대부분과 이 글을 쓴 팀의 팀원들이 IT 컨퍼런스에 가 있던 때 일어났다. 일부 팀 애플리케이션은 readiness, liveness 프로브를 쓰지 않았고, 알림은 NodeNotReady 와 소켓 증가를 잡지 못했다.
2022-10-31 13:45 UTC 에 팀은 계획된 vpc-cni EKS 애드온 업그레이드를 배포 파이프라인으로 시작했다. 14:10 에 파이프라인이 업그레이드 중 타임아웃으로 실패했다. 45개 aws-node 파드 가운데 약 10개만 업그레이드됐다. 5개는 Terminating 에 멈췄고, 나머지 30개는 업그레이드를 시도하지도 못했다.
14:30 에 일부 노드가 "KubeletNotReady PLEG is not healthy" 를 보고하며 30초쯤 NodeNotReady 였다가 다시 NodeReady 로 돌아오는 것이 보였다. 팀은 진행 중이던 vpc-cni 업그레이드와 관련이 있다고 여겼다. 14:50 에 일부 파드는 업그레이드가 진행됐지만 결국 다시 멈췄다.
Terminating 파드를 강제로 지우자 새 파드가 생겼지만 Ready 가 되지 않았다. 노드 로그를 살폈지만 뚜렷한 단서가 없었다. 일부 컨테이너는 Kubernetes API 로 로그를 볼 수 없었지만, aws-node 컨테이너는 노드에서 돌면서 로그를 남기고 있었다.
다음 날인 11-01 11:12 에 노드마다 쓰는 소켓 수가 계속 늘어나는 것이 보였다. 11-02 10:52 에는 한 팀이 일부 파드에서 연결 문제가 있다고 알려 왔지만 조사할 만한 자세한 정보는 주지 않았다.
07:30 롤오버 뒤 14:10 에 vpc-cni 업그레이드 파이프라인이 타임아웃으로 실패했다. 팀은 롤오버 7시간 뒤인 14:30 에 노드가 NodeNotReady 를 오가는 것을 보고 이상을 알았다. 감지까지 7시간이 걸렸다. 알림은 NodeNotReady 이벤트와 소켓 증가를 잡지 못했다. 팀은 17:21 에 GitHub 에서 v20221027 의 PLEG 관련 이슈를 찾고 나서 원인을 알았다.
새 AMI 를 배포한 날에는 다른 컴포넌트 업그레이드를 매우 조심해야 한다. 이번에는 새 노드 AMI 를 쓴 날 EKS 컴포넌트도 함께 올리면서 원인을 가리기 어려웠다. 장애나 문제가 생겼을 때 각 팀과 소통하는 경로도 개선해야 한다. 문제를 알린 팀에게서 자세한 내용을 받기 어려웠고, 팀별 당직 호출 경로도 없었다. 팀이 Kubernetes 컴포넌트를 깊이 이해하지 못했던 점도 장애에 영향을 준 요인이었다.
같은 원인 · 공통 노드 운영체제 이미지, 리눅스 커널
같은 원인 · 공통 kubelet, 리눅스 커널
같은 원인 · 공통 노드 운영체제 이미지, 리눅스 커널
IL-0171 Bottlerocket AMI 에 libdcgm.so 가 없어 GPU 노드의 AcceleratedHardwareReady 가 False 가 됐고, Karpenter 노드 자동 복구가 Ready 뒤 10~11분마다 GPU 노드를 교체하는 일을 끝없이 되풀이했다.Inflab · 2025같은 원인 · 공통 노드 운영체제 이미지
IL-0147 AKS 202508 노드 이미지가 캐시되지 않은 쿠버네티스 바이너리를 받을 때 HTTP 프록시 설정을 쓰지 않아, 프록시 뒤에 있는 노드의 프로비저닝이 CSE 종료 코드 31 로 실패했다.Microsoft · 2025같은 원인 · 공통 노드 운영체제 이미지
https://incidentlib-mcp.benchlet.com/mcpAPI 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.
같은 원인 · 공통 Terraform
IL-0138 nvidia-dkms-390 드라이버 빌드 실패로 망가진 커널 헤더가 몇 주 동안 방치됐다가, 정전 뒤 재부팅하자 하나뿐인 마스터 노드가 커널 패닉에 빠져 홈랩 쿠버네티스 클러스터가 6일 동안 멈췄다.Barush Mendez · 2025같은 원인 · 공통 리눅스 커널
IL-0139 Calico 네트워크 정책을 쓰는 GKE 클러스터를 1.22 이상으로 업그레이드하자 경쟁 조건 때문에 CNI 정리가 Unauthorized 로 실패해 파드가 Terminating 이나 Pending 에 멈췄다.Google Cloud · 2022같은 원인 · 공통 kubelet
IL-0146 Central India 에서 새로 만든 Azure CNI 클러스터의 VM 이 높은 값의 MAC 주소를 받으면서 bridge 모드 Azure CNI 의 오래된 버그가 드러나 터널 연결이 끊기고 kubectl exec 와 파드 간 통신이 타임아웃됐다.Microsoft Azure · 2020같은 원인 · 공통 노드 운영체제 이미지
IL-0074 워커 노드가 잇달아 Not Ready 에 빠지고 네트워크와 DNS 실패로 사이드카가 죽으면서, AirMap 플랫폼의 모든 서비스가 다섯 시간 동안 응답하지 않았다.AirMap · 2018같은 원인 · 공통 kubelet