{"id":"IL-0449","org":"Enigmo","date":"2020-12-13","docs":[],"title":{"en":"Pods on Enigmo's new EKS managed node groups kept restarting or stuck Terminating and the nodes became unusable","ko":"EKS 관리형 노드 그룹으로 옮긴 며칠 뒤 파드가 재시작을 되풀이하거나 Terminating 상태에 멈추고 노드를 쓸 수 없게 됐다"},"domain":["kubernetes","aws"],"impact":{"scope":"Pods on the EKS cluster's managed node groups restarted repeatedly or could not stop, and nodes became unusable under CPU and memory load","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"As long as a team uses Amazon EKS or Kubernetes, it has to keep track of upgrades of the cluster and of modules such as ingress controllers, because a release with breaking changes can be announced without warning after a long stable period. Checking releases and upgrading on a regular schedule keeps the effect of each upgrade on the service small.","ko":"Amazon EKS 나 쿠버네티스를 쓰는 한 클러스터 본체와 Ingress Controller 같은 모듈의 업그레이드를 늘 신경 써야 한다. 안정적으로 돈다고 한동안 손대지 않고 두면, 그사이 호환성을 깨는 변경이 담긴 릴리스가 갑자기 발표되는 일이 드물지 않다. 쿠버네티스 마이너 버전은 3개월쯤마다 나오므로 1년에 적어도 한 번은 업그레이드해야 한다."},"related":[],"sources":[{"url":"https://tech.enigmo.co.jp/entry/2020/12/13/100000","kind":"blog","archived":"https://web.archive.org/web/20260307002933/https://tech.enigmo.co.jp/entry/2020/12/13/100000"}],"summary":{"en":"Enigmo upgraded its EKS clusters from 1.13 to 1.15 in spring 2020 and soon began preparing for 1.16. Its node groups had been built from an EC2 LaunchTemplate and AutoScalingGroup following the AWS documentation of the EKS 1.13 era, so each upgrade meant creating new node groups with the new AMI, tainting and draining the old ones and deleting them, three CloudFormation change sets in all. Managed node groups first could not be given security groups, which Pods need to reach RDS, ElastiCache and ALB, but that summer they gained LaunchTemplate support, so Enigmo moved to managed node groups before the 1.16 upgrade. The move itself, creating managed node groups, evicting pods from the old ones and deleting them, went smoothly.\n\nTwo or three days later pods began restarting repeatedly or getting stuck in Terminating, and node CPU and memory load made the nodes unusable. The cause was a bug in the AMI the managed node groups were created with. The old node groups were gone, and managed node groups accept only the latest AMI version, so going back to the previous AMI was refused. After an AMI with the fix was released, the managed node group update to it failed, because the update evicts pods and the pods could not stop.\n\nEnigmo finally ran the managed node group update through CloudFormation while watching `kubectl get pods --all-namespaces`, and whenever a pod stayed in Terminating for a while it killed it with `kubectl delete pods <pod name> --grace-period=0 --force`.","ko":"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 을 자유롭게 지정할 수 있게 됐다.\n\n옮기고 2~3일 뒤 파드가 재시작을 되풀이하거나 종료되지 못하고 남았다. 노드의 CPU 와 메모리 부하가 높아져 노드를 쓸 수 없게 됐다. 원인은 관리형 노드 그룹을 만든 AMI 의 버그였다. 옛 노드 그룹은 이미 없었고, 관리형 노드 그룹은 최신 AMI 만 허용해 옛 AMI 로 되돌릴 수 없었다. 수정된 AMI 가 나온 뒤에도 파드가 종료되지 않아 노드 그룹 업데이트 중 Eviction 이 실패했다. 팀은 CloudFormation 으로 업데이트를 돌리면서 kubectl get pods --all-namespaces 로 파드를 지켜보고, Terminating 상태에서 한동안 변화가 없는 파드를 강제로 지웠다."},"trigger":{"en":"Enigmo created EKS managed node groups that used an AMI containing the bug and moved its pods onto them, as preparation for upgrading EKS from 1.15 to 1.16.","ko":"EKS 1.16 업그레이드를 앞두고 파드를 버그가 있는 AMI 로 만든 새 관리형 노드 그룹으로 옮기고 옛 노드 그룹을 지웠다."},"severity":"unknown","symptoms":["pod-stuck-terminating","node-high-cpu","memory-pressure","node-not-ready","upgrade-stuck"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":null,"components":["node-image","node-pool"],"root_cause":"upgrade-breaking-change","remediation":[{"text":{"en":"Changed the managed node groups' AMI version to the fixed release","ko":"수정된 AMI 가 나오자 관리형 노드 그룹의 AMI 버전을 바꿨다."}},{"text":{"en":"Ran the managed node group update through CloudFormation","ko":"CloudFormation 으로 관리형 노드 그룹 업데이트를 실행했다."}},{"text":{"en":"Watched the pods across all namespaces during the update","ko":"업데이트가 도는 동안 kubectl get pods --all-namespaces 로 파드 상태를 지켜봤다."}},{"text":{"en":"Force-deleted every pod that stayed in Terminating with kubectl delete --grace-period=0 --force","ko":"Terminating 상태로 한동안 변화가 없는 파드를 찾을 때마다 kubectl delete pods <pod name> --grace-period=0 --force 로 강제로 지웠다."}}],"action_items":[{"text":{"en":"Check the latest releases of the cluster's modules quarterly or monthly and upgrade them regularly","ko":"분기나 달마다 각종 모듈의 최신 릴리스를 확인하고 정기적으로 업그레이드해, 서비스 영향을 가장 작게 하는 운영 방법을 찾는다."}}],"contributing":["revert-did-not-restore","delayed-effect-change"],"recurrence_of":null,"symptoms_text":{"en":"Two or three days after Enigmo created EKS managed node groups and moved its pods there from the old node groups, the cluster suddenly became unstable: pods restarted again and again or could not stop and stayed around indefinitely, node CPU and memory load rose high, and the nodes became unusable from the cluster.\n\nThe old node groups had already been deleted, so the pods could not be moved back. While keeping the pods running as best it could, the team found it had hit a known bug, \"Pods stuck in terminating state after AMI amazon-eks-node-1.16.15-20201112\". An attempt to switch the managed node groups to the older AMI with CloudFormation failed with `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`, because managed node groups can only use the latest AMI version.\n\nWhen an AMI with the fix was released, updating the managed node groups to it also failed. The managed node group update taints the nodes, drains them and evicts the pods, and because pods could not stop, the eviction failed and with it the node group update.","ko":"EKS 클러스터의 파드를 새로 만든 관리형 노드 그룹으로 옮기고 2~3일 지나자, 파드가 갑자기 재시작을 되풀이하거나 제대로 종료되지 못하고 Terminating 상태로 계속 남았다. 노드의 CPU 와 메모리 부하가 높아져 클러스터에서 노드를 쓸 수 없게 됐다.\n\n옛 노드 그룹은 이미 지운 뒤라 파드를 되돌릴 수 없었다. 팀은 파드를 간신히 돌리며 조사했고, \"Pods stuck in terminating state after AMI amazon-eks-node-1.16.15-20201112\" 로 알려진 버그에 걸렸다는 것을 알았다.\n\nCloudFormation 으로 관리형 노드 그룹을 옛 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 만 쓸 수 있어서 되돌릴 방법이 없었다.\n\n수정된 AMI 가 나와 노드 그룹을 업데이트했다. 업데이트 과정에는 Taint 부여, Drain, 파드 Eviction 이 있는데, 파드가 종료되지 않아 Eviction 이 실패했고 노드 그룹 업데이트도 실패했다."},"updated_at":"2026-11-14T12:34:09.801764Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0449","org_slug":"enigmo"}