{"id":"IL-0171","org":"Inflab","date":"2025-08-27","docs":[],"title":{"en":"Karpenter node auto-repair replaced EKS GPU nodes about 10 minutes after they became Ready, in a loop, because the Bottlerocket NVIDIA AMI lacked libdcgm.so and set AcceleratedHardwareReady to False","ko":"Bottlerocket AMI 에 libdcgm.so 가 없어 GPU 노드의 AcceleratedHardwareReady 가 False 가 됐고, Karpenter 노드 자동 복구가 Ready 뒤 10~11분마다 GPU 노드를 교체하는 일을 끝없이 되풀이했다."},"domain":["kubernetes","aws","ai-infra"],"impact":{"scope":"GPU nodes replaced every 10 to 11 minutes and GPU pods restarted continuously, so the video upscaling work could not proceed","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Automatic node repair acts on every unhealthy node condition, including AcceleratedHardwareReady, so an image defect that only breaks GPU health monitoring is enough to have every GPU node terminated and recreated in a loop. Before turning on auto-repair, check which conditions it watches and whether the node image reports them correctly.\n\nDisabling auto-repair stops the loop at once but is only a temporary measure; installing the missing library or changing the AMI address the cause but cost more on an immutable OS such as Bottlerocket.","ko":"Karpenter Node Auto-Repair 는 AcceleratedHardwareReady=False 도 노드를 교체할 사유로 본다. 그래서 GPU 연산에는 문제가 없어도 GPU 모니터링 라이브러리 하나가 빠지면 노드가 끝없이 교체될 수 있다. Node Auto-Repair 를 켠 뒤 GPU 노드가 자주 교체되면 이 기능을 꺼 볼 만하다. 좀비 노드 문제는 이제 메모리가 4GB 이상인 인스턴스 타입을 써서 완화했다."},"related":[],"sources":[{"url":"https://tech.inflab.com/20250827-bottlerocket-ami-gpu-issue/","kind":"blog","license":"unknown","archived":null}],"summary":{"en":"Inflab runs AI upscaling of course videos on Amazon EKS 1.32 with g5g.xlarge GPU instances, the Bottlerocket AMI amazon/bottlerocket-aws-k8s-1.32-nvidia-aarch64-v1.39.1-3a880b44, and Karpenter v1.4.0 managing nodes. The team had turned on Karpenter's node auto-repair, an alpha feature since Karpenter v1.1.0, to deal with \"zombie\" nodes: when kubelet was OOM-killed on Bottlerocket, the EC2 instance stayed up but the node went to the Unknown state.\n\nThe Bottlerocket NVIDIA AMI in use did not include libdcgm.so, so DCGM failed to initialise and the node's AcceleratedHardwareReady condition turned False about a minute after the node was Ready. Node auto-repair counts AcceleratedHardwareReady=False as unhealthy, alongside Ready=False or Unknown and the memory, disk, PID and network pressure conditions. The repair controller waits for a toleration period, about 10 minutes here, after the condition's last transition and then deletes the NodeClaim, so each GPU node was terminated and replaced by an identical node with the same problem, in an endless loop.\n\nThe team considered installing the DCGM library by hand, which Bottlerocket's immutable design makes hard, and switching to another AMI, which would mean large infrastructure changes. It chose to disable node auto-repair by setting nodeRepair: false in the Karpenter settings, accepting that this is a temporary measure. The original zombie-node problem was mitigated separately by using instance types with at least 4 GB of memory.","ko":"Inflab 은 Amazon EKS 1.32 클러스터에서 Bottlerocket AMI amazon/bottlerocket-aws-k8s-1.32-nvidia-aarch64-v1.39.1-3a880b44 와 g5g.xlarge GPU 인스턴스로 강의 영상 업스케일링 작업을 돌렸다. 노드는 Karpenter v1.4.0 이 관리했다. 전에는 Bottlerocket 노드에서 메모리가 부족해 kubelet 이 OOM 으로 죽으면, EC2 인스턴스는 살아 있는데 쿠버네티스에서는 Unknown 으로 보이는 좀비 노드가 생겼다. 이를 정리하려고 Karpenter 의 nodeRepair 기능 게이트를 켰다. Node Auto-Repair 는 Karpenter v1.1.0 부터 들어간 알파 기능이다.\n\n이 AMI 에는 NVIDIA DCGM 라이브러리인 libdcgm.so 가 없었다. DCGM 은 데이터센터 GPU 의 상태와 이벤트를 모으는 NVIDIA 관리 도구다. 라이브러리가 없어도 GPU 연산은 되지만 DCGM 으로 GPU 상태를 볼 수는 없다. 노드가 Ready 가 되고 약 1분 뒤 DCGM 초기화가 실패하면서 AcceleratedHardwareReady 노드 컨디션이 False 가 됐다.\n\nKarpenter Node Auto-Repair 는 Ready=False, Ready=Unknown, MemoryPressure=True, DiskPressure=True, PIDPressure=True, NetworkUnavailable=True 와 함께 AcceleratedHardwareReady=False 도 비정상 노드로 본다. 비정상 컨디션을 찾으면 컨디션이 바뀐 시각에 정책의 유예 시간을 더한 종료 시각까지 기다렸다가 NodeClaim 을 지운다. 그래서 노드는 Ready 뒤 약 10~11분 만에 교체됐고, 새 노드도 같은 AMI 를 써서 같은 일이 끝없이 되풀이됐다.\n\n팀은 DCGM 라이브러리를 직접 설치하는 방법, 다른 AMI 를 쓰는 방법, Node Auto-Repair 를 끄는 방법을 비교했다. Bottlerocket 은 불변 OS 라 직접 설치가 어려웠고, AMI 를 바꾸면 기존 인프라를 바꾸는 부담이 컸다. 팀은 바로 적용할 수 있는 Node Auto-Repair 끄기를 골랐다. 다만 이 방법은 임시 해결책이다."},"trigger":{"en":"Enabling Karpenter's node auto-repair feature gate (nodeRepair: true) and then running GPU pods on nodes from the Bottlerocket NVIDIA AMI.","ko":"kubelet OOM 으로 생기던 좀비 노드를 정리하려고 Karpenter 설정에서 nodeRepair 기능 게이트를 켰다."},"severity":"unknown","symptoms":["nodes-recreated-in-loop","gpu-unavailable"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"The team noticed GPU nodes being replaced repeatedly after running GPU pods, then found the DCGMError message in the node events.","ko":"GPU 노드가 Ready 뒤 10~11분 만에 계속 교체되는 것을 보고 노드 이벤트를 분석해 DCGMError 메시지를 찾았다."},"components":["karpenter","node-image","gpu-driver"],"root_cause":"software-bug","remediation":[{"text":{"en":"Disabled Karpenter node auto-repair by setting the nodeRepair feature gate to false","ko":"Karpenter 설정에서 nodeRepair 기능 게이트를 false 로 바꿔 Node Auto-Repair 를 껐다."}}],"action_items":[],"contributing":["automation-amplified","assumption-unverified"],"recurrence_of":null,"symptoms_text":{"en":"GPU nodes for an AI video upscaling job were created normally and reached Ready, and then about 10 to 11 minutes later Karpenter treated each one as unhealthy and replaced it. Every new node went the same way, so the GPU pods kept restarting and the upscaling work could not make progress.\n\nThe node events showed the sequence. kube-proxy started, kubelet posted \"kubelet is posting ready status\" and the node became Ready. About a minute later an AcceleratedHardwareReady event recorded by Karpenter showed the condition changing from True to False with Reason \"DCGMError\" and Message \"failed to initialize DCGM: libdcgm.so not Found\". Karpenter then logged NodeRepairBlocked with \"more than 20% nodes are unhealthy in the nodepool\", and about ten minutes after that FailedDraining (\"Failed to drain node, 1 pods are waiting to be evicted\") and InstanceTerminating (\"Instance is terminating\").\n\nThe missing library is used by NVIDIA DCGM (Data Center GPU Manager) to collect GPU health and events. Its absence does not stop GPU computation itself, but it makes DCGM-based GPU health monitoring impossible, and the node condition reported the accelerator as not ready.","ko":"강의 영상 업스케일링용 GPU 파드를 띄우자 GPU 노드가 정상적으로 만들어져 Ready 가 됐다가, 약 10~11분 뒤 갑자기 비정상으로 판정되어 Karpenter 가 노드를 교체했다. 새로 만든 노드에서도 같은 일이 되풀이됐고, GPU 파드가 계속 재시작되어 작업이 진행되지 않았다.\n\n노드 이벤트에서 핵심 메시지를 찾았다. Karpenter 가 남긴 AcceleratedHardwareReady 이벤트에서 상태가 True 에서 False 로 바뀌었고, Reason 은 DCGMError, Message 는 \"failed to initialize DCGM: libdcgm.so not Found\" 였다.\n\n이벤트를 시간 순서로 보면 kube-proxy 시작, NodeAllocatableEnforced, NodeReady 까지는 정상이었다. 노드가 Ready 가 되고 약 1분 뒤 AcceleratedHardwareReady 가 False 로 바뀌었다. 이어서 NodeRepairBlocked 경고가 \"more than 20% nodes are unhealthy in the nodepool\" 메시지로, FailedDraining 경고가 \"Failed to drain node, 1 pods are waiting to be evicted\" 메시지로, InstanceTerminating 경고가 \"Instance is terminating\" 메시지로 차례로 찍혔다."},"updated_at":"2026-11-09T11:55:55.205520Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0171","org_slug":"inflab"}