Self-healing GPU nodes in Kubernetes: What we learned building the EKS node monitoring agent

대규모 Kubernetes 환경에서의 노드 장애, 왜 피할 수 없는가

Amazon EKS처럼 대규모 Kubernetes 클러스터를 운영하다 보면, 노드 장애는 예외적인 사건이 아니라 일상적인 운영 현실이 된다. 특히 GPU 워크로드를 다루는 환경에서는 GPU가 PCIe 버스에서 분리되거나, 드라이버가 응답 불능 상태에 빠지는 등 소프트웨어 레이어만으로는 감지하기 어려운 하드웨어 수준의 이상 현상이 실제로 빈번하게 발생한다.

이런 환경에서 단순히 "노드가 NotReady 상태가 되면 알림을 보낸다"는 수준의 대응은 충분하지 않다. 장애가 발생한 뒤 사람이 개입해 조치하는 방식은 복구 시간이 길어지고, 그 사이 스케줄링된 파드들이 비정상 노드에 묶여 전체 서비스 가용성에 영향을 준다. 결국 노드 상태를 지속적으로 모니터링하고, 이상을 감지하는 즉시 자동으로 격리·복구하는 self-healing 메커니즘이 필수가 된다.

Self-healing 에이전트 설계 시 핵심 고려 사항

EKS 환경에서 노드 모니터링 에이전트를 직접 구축할 때 실무적으로 중요한 설계 포인트는 다음과 같다.

DaemonSet으로 배포: 에이전트는 모든 노드에 1:1로 배포되어야 하므로 DaemonSet이 기본 패턴이다. 이를 통해 각 노드의 로컬 상태(GPU, 디스크, 네트워크 인터페이스 등)를 직접 수집할 수 있다.
노드 Taint와 Condition 활용: 이상 노드를 감지했을 때 즉시 kubectl taint로 신규 파드 스케줄링을 차단하고, Custom Node Condition을 등록해 클러스터 운영자가 상태를 명확히 인지할 수 있게 한다.
하드웨어 수준 헬스체크: GPU의 경우 NVIDIA DCGM(Data Center GPU Manager)과 같은 도구를 통해 ECC 오류, PCIe 링크 상태, 온도 임계값 등을 주기적으로 폴링하는 로직이 필요하다.
자동 복구 vs. 안전한 격리: 일부 장애는 노드 재부팅으로 복구되지만, 하드웨어 손상이 의심되는 경우에는 자동 재부팅보다 노드를 cordon 상태로 격리하고 알림을 발생시키는 보수적 전략이 더 안전하다.

# 이상 노드에 taint를 추가하는 예시
kubectl taint nodes <node-name> \
  gpu-health=unhealthy:NoSchedule

Java 백엔드 관점에서의 시사점

GPU 클러스터 운영이 직접적인 업무가 아니더라도, 이 접근 방식은 Kubernetes 위에서 Java 서비스를 운영하는 모든 백엔드 개발자에게 유효한 교훈을 준다.

첫째, 애플리케이션 레벨의 헬스체크(/actuator/health)만으로는 인프라 수준의 장애를 막을 수 없다. Spring Boot 서비스가 정상 응답을 반환하더라도, 그 노드의 네트워크 인터페이스나 스토리지가 비정상일 수 있다. 인프라 팀과 협력해 노드 레벨 헬스체크가 파드 스케줄링 정책과 연동되는 구조를 갖춰야 한다.

둘째, PodDisruptionBudget(PDB)과 terminationGracePeriodSeconds 설정이 self-healing 시나리오에서 예상치 못한 방식으로 동작할 수 있다. 노드가 강제 격리될 때 파드가 graceful shutdown을 충분히 마칠 수 있는지, 트래픽이 다른 노드로 원활하게 전환되는지를 사전에 검증해두는 것이 중요하다.

# PodDisruptionBudget 예시
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-service-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-service

정리

대규모 Kubernetes 환경에서 노드 장애는 필연적이며, 자동 감지·격리·복구를 갖춘 self-healing 구조가 운영 안정성의 핵심이다.
GPU 등 하드웨어 의존 워크로드는 소프트웨어 헬스체크만으로 부족하며, DCGM 같은 하드웨어 수준 모니터링 도구와의 연동이 필요하다.
Java 백엔드 서비스도 PDB, taint/toleration, graceful shutdown 설정을 통해 노드 장애 시나리오에 대한 회복 탄력성을 사전에 설계해야 한다.