{"id":"IL-0112","org":"DFDS","date":"2022-10-31","docs":[],"title":{"en":"The daily node rollover put DFDS's EKS nodes on an AMI later recalled for a kernel issue, causing \"PLEG is not healthy\" NodeNotReady flaps and pod network timeouts","ko":"나중에 회수된 EKS 노드 AMI 로 노드를 교체한 뒤 노드가 PLEG is not healthy 를 보고하며 NotReady 를 오갔고 파드 네트워크 타임아웃이 났다"},"domain":["kubernetes","aws"],"impact":{"scope":"Cluster nodes on AMI v20221027: NodeNotReady flapping, a stalled vpc-cni upgrade, growing socket use per node, and network timeouts from one team's pods","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"When a new node AMI has just been rolled out, upgrading other cluster components on the same day makes it hard to tell which change is causing trouble; here the vpc-cni upgrade on the same day confused matters.\n\nTaking the latest AMI automatically with no way to pin one meant a rollback first needed a Terraform change. The team also concluded that it needs better communication paths with application teams during incidents.","ko":"새 AMI 를 배포한 날에는 다른 컴포넌트 업그레이드를 매우 조심해야 한다. 이번에는 새 노드 AMI 를 쓴 날 EKS 컴포넌트도 함께 올리면서 원인을 가리기 어려웠다. 장애나 문제가 생겼을 때 각 팀과 소통하는 경로도 개선해야 한다. 문제를 알린 팀에게서 자세한 내용을 받기 어려웠고, 팀별 당직 호출 경로도 없었다. 팀이 Kubernetes 컴포넌트를 깊이 이해하지 못했던 점도 장애에 영향을 준 요인이었다."},"related":[],"sources":[{"url":"https://github.com/dfds/postmortems/blob/master/PM2022-009%20-%20Bad%20AWS%20EKS%20AMI%20causing%20Kubernetes%20issues","kind":"github","license":"unknown","archived":null}],"summary":{"en":"DFDS's Terraform infrastructure-modules were hard-coded to use the latest AWS EKS node AMI as soon as it was available, with no way to pin a specific one, and a daily rollover replaced the cluster's nodes. On 2022-10-31 the rollover picked up AMI v20221027, which was later recalled because of a kernel issue. Nodes on that image had sporadic communication problems: they briefly reported \"PLEG is not healthy\", sometimes went unhealthy, the number of sockets per node kept growing, and one team saw network timeouts from its pods to other services.\n\nThe same day the team upgraded the vpc-cni add-on, the upgrade stalled, and the node flapping was first blamed on it. The team completed the upgrade by cordoning, draining and deleting the stuck nodes one at a time, 15 in total, by 17:35. At 17:21 a GitHub issue about PLEG errors with this AMI led the team to learn that the AMI had been recalled. With no service loss visible, the team decided to monitor and wait for a new AMI release. As socket use kept rising and Kubernetes events reported communication problems, the team decided to roll back on 2022-11-02 at 11:56. A Terraform change that allowed setting a specific AMI was merged at 13:14, the pipeline rolled the nodes back to the previous AMI at 13:46, and at 14:40 the team judged the problem resolved. Time to detection was 7 hours and time to recovery 54 hours 10 minutes.\n\nThe write-up lists more factors that made the incident worse or harder to handle: some team applications had no readiness or liveness probes; it happened during an IT conference that most development teams and members of the reporting team itself attended; there were no on-call escalation paths with individual teams; the team that reported problems was hard to get specifics from; upgrading an EKS component on the same day as the new AMI confused the diagnosis; alerting did not catch the NodeNotReady events or the socket growth; and the team lacked deeper knowledge of Kubernetes components.","ko":"DFDS 의 인프라 모듈은 매일 노드를 롤오버할 때 나와 있는 가장 최신 AWS EKS 노드 AMI 를 쓰도록 고정돼 있었고, 특정 AMI 를 지정하는 기능이 없었다. 2022-10-29 에 나온 AMI v20221027 은 나중에 커널 문제로 회수됐는데, 10-31 아침 롤오버가 이 AMI 로 노드를 바꿨다. 이 이미지 때문에 클러스터 안에서 간헐적인 통신 문제가 생겼다. 노드가 잠깐씩 \"PLEG is not healthy\" 를 보고하거나 unhealthy 로 나타났고, 한 팀은 배포한 파드에서 다른 서비스로 가는 통신에서 네트워크 타임아웃을 겪었다.\n\n같은 날 오후 vpc-cni 애드온 업그레이드를 함께 진행하면서 상황이 더 헷갈렸다. 업그레이드가 멈췄고, 팀은 Terminating 에 멈춘 노드를 하나씩 cordon, drain, 삭제해 업그레이드를 끝냈다. 이렇게 지운 노드가 모두 15대였다. 팀은 17:21 에 GitHub 에서 v20221027 의 PLEG 관련 이슈를 찾았고, 이 AMI 가 커널 문제로 회수됐다는 것을 알았다.\n\n서비스 손실은 보이지 않아서 팀은 새 AMI 를 기다리며 지켜보기로 했다. 그러나 노드당 소켓 수가 계속 늘고 Kubernetes 이벤트가 통신 문제를 보고하자 11-02 11:56 에 AMI 를 되돌리기로 했다. 특정 AMI 를 지정할 수 있게 terraform 을 고쳐 머지했고, 13:46 에 파이프라인이 노드를 이전 AMI 로 되돌렸다. 14:40 에 문제가 풀린 것을 확인했다. 감지까지 7시간, 복구까지 54시간 10분이 걸렸다.\n\n장애는 개발팀 대부분과 이 글을 쓴 팀의 팀원들이 IT 컨퍼런스에 가 있던 때 일어났다. 일부 팀 애플리케이션은 readiness, liveness 프로브를 쓰지 않았고, 알림은 NodeNotReady 와 소켓 증가를 잡지 못했다."},"trigger":{"en":"At 07:30 UTC on 2022-10-31 the daily node rollover replaced the existing nodes with nodes built from AMI v20221027, the latest AWS EKS node AMI, released on 2022-10-29 and later recalled because of a kernel issue.","ko":"매일 도는 노드 롤오버가 2022-10-31 07:30 UTC 에 가장 최신 EKS 노드 AMI 인 v20221027 을 가져와 기존 노드를 이 AMI 로 만든 새 노드로 바꿨다. 이 AMI 는 나중에 커널 문제로 회수됐다."},"severity":"unknown","symptoms":["node-not-ready","upgrade-stuck","intermittent-timeouts","intermittent-connection-failures"],"timeline":{"detected_after":"7h","resolved_after":"54h 10m"},"date_kind":"incident","detection":{"en":"The team noticed nodes flapping between NodeNotReady and NodeReady (\"KubeletNotReady PLEG is not healthy\") at 14:30 UTC while watching the stalled vpc-cni upgrade, about seven hours after the rollover. Time to detection was 7 hours. Alerting did not catch the NodeNotReady events or the socket growth.","ko":"07:30 롤오버 뒤 14:10 에 vpc-cni 업그레이드 파이프라인이 타임아웃으로 실패했다. 팀은 롤오버 7시간 뒤인 14:30 에 노드가 NodeNotReady 를 오가는 것을 보고 이상을 알았다. 감지까지 7시간이 걸렸다. 알림은 NodeNotReady 이벤트와 소켓 증가를 잡지 못했다. 팀은 17:21 에 GitHub 에서 v20221027 의 PLEG 관련 이슈를 찾고 나서 원인을 알았다."},"components":["node-image","linux-kernel","kubelet","vpc-cni","launch-template","terraform"],"root_cause":"software-bug","remediation":[{"text":{"en":"cordoned, drained and deleted 15 stuck nodes one at a time to complete the vpc-cni upgrade","ko":"Terminating 에 멈춘 노드를 하나씩 cordon, drain, 삭제해 vpc-cni 업그레이드를 끝냈다. 모두 15대를 지웠다."}},{"text":{"en":"changed the Terraform infrastructure-modules so a specific AMI could be set","ko":"특정 AMI 를 지정할 수 있도록 인프라 모듈의 terraform 을 고치고 테스트해 master 브랜치에 머지했다."}},{"text":{"en":"rolled the EC2 Auto Scaling group launch configuration back to the previous known good AMI through the pipeline","ko":"파이프라인으로 EC2 Auto Scaling 그룹 launch configuration 의 AMI 를 이전의 정상 버전으로 되돌려 노드를 다시 만들었다."}}],"action_items":[{"text":{"en":"Reach out to teams with suggestions about readiness and liveness probes","ko":"각 팀에 readiness, liveness 프로브를 쓰자고 제안한다."}},{"text":{"en":"Create a dashboard for readiness and liveness probe coverage","ko":"readiness, liveness 프로브 적용 현황을 보여 주는 대시보드를 만든다."}},{"text":{"en":"Write a wiki article on readiness and liveness probes and their usefulness","ko":"readiness, liveness 프로브와 그 쓸모를 설명하는 위키 글을 쓴다."}},{"text":{"en":"Modify infrastructure-modules to allow specifying a particular AMI","ko":"인프라 모듈에서 특정 AMI 를 지정할 수 있게 고친다."}},{"text":{"en":"Schedule a discussion on whether to take the latest AMI immediately and how to test new AMIs before they are deployed","ko":"최신 AMI 를 바로 받을지, 새 AMI 를 배포 전에 어떻게 시험할지 논의하는 자리를 잡는다."}},{"text":{"en":"Implement alerting on abnormal NodeNotReady events and on increased socket use","ko":"비정상적인 NodeNotReady 이벤트나 소켓 사용 증가를 잡는 알림을 만든다."}},{"text":{"en":"Create a learning path for Kubernetes within the team","ko":"팀 안에 Kubernetes 학습 과정을 만든다."}},{"text":{"en":"Collect logs from nodes centrally","ko":"노드 로그를 중앙에서 모은다."}},{"text":{"en":"Create a Prometheus exporter that retrieves the latest available AMI, with a dashboard and alerts","ko":"나와 있는 최신 AMI 를 조회하는 Prometheus exporter 를 만들고, 이를 쓰는 대시보드와 알림도 만든다."}}],"contributing":["no-staged-rollout","automation-amplified","overlapping-failures","monitoring-blind-spot","no-health-probe"],"recurrence_of":null,"symptoms_text":{"en":"On 2022-10-31 a planned upgrade of the vpc-cni EKS add-on, started from the deployment pipeline at 13:45 UTC, timed out at 14:10. Only about 10 of the 45 aws-node pods had upgraded, 5 were stuck in Terminating and the other 30 had not been attempted.\n\nFrom 14:30 some nodes reported NodeNotReady for about 30 seconds at a time and then NodeReady again, with the message \"KubeletNotReady PLEG is not healthy\". The team assumed this came from the vpc-cni upgrade in progress. Some aws-node pods made progress and then got stuck again, and a terminating pod that was force-deleted was replaced by a new one that never became Ready. Logs for some containers could not be read through the Kubernetes API, although the aws-node containers were running and logging on the nodes themselves.\n\nAfter the upgrade was finished by hand the NodeNotReady events continued, but no loss of service was seen or reported. On 2022-11-01 at 11:12 the team saw the number of sockets used per node rising continuously. On 2022-11-02 at 10:52 one team reported connectivity problems from some of its pods, network timeouts when talking to other services, but gave no details to investigate.","ko":"2022-10-31 13:45 UTC 에 팀은 계획된 vpc-cni EKS 애드온 업그레이드를 배포 파이프라인으로 시작했다. 14:10 에 파이프라인이 업그레이드 중 타임아웃으로 실패했다. 45개 aws-node 파드 가운데 약 10개만 업그레이드됐다. 5개는 Terminating 에 멈췄고, 나머지 30개는 업그레이드를 시도하지도 못했다.\n\n14:30 에 일부 노드가 \"KubeletNotReady PLEG is not healthy\" 를 보고하며 30초쯤 NodeNotReady 였다가 다시 NodeReady 로 돌아오는 것이 보였다. 팀은 진행 중이던 vpc-cni 업그레이드와 관련이 있다고 여겼다. 14:50 에 일부 파드는 업그레이드가 진행됐지만 결국 다시 멈췄다.\n\nTerminating 파드를 강제로 지우자 새 파드가 생겼지만 Ready 가 되지 않았다. 노드 로그를 살폈지만 뚜렷한 단서가 없었다. 일부 컨테이너는 Kubernetes API 로 로그를 볼 수 없었지만, aws-node 컨테이너는 노드에서 돌면서 로그를 남기고 있었다.\n\n다음 날인 11-01 11:12 에 노드마다 쓰는 소켓 수가 계속 늘어나는 것이 보였다. 11-02 10:52 에는 한 팀이 일부 파드에서 연결 문제가 있다고 알려 왔지만 조사할 만한 자세한 정보는 주지 않았다."},"updated_at":"2026-11-10T00:00:33.908927Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0112","org_slug":"dfds"}