Kubernetes 노드 OOM으로 인한 서비스 셧다운: 엔터프라이즈 복구 전략 AI 생성 이미지: Kubernetes 노드 OOM 발생 시 서비스 셧다운 복구 전략 문제 정의 — 노드 OOM이 서비스 가용성에 미치는 영향 커널의 OOM-killer는 노드의 전체 메모리가 고갈될 때 oom_score를 기준으로 프로세스를 강제로 종료한다. 쿠버네티스 환경에서는 kubelet이 자원 압박을 감지하면 컨테이너 프로세스를 종료하거나 QoS 및 eviction 정책에 따라 파드를 퇴출시킨다. 단일 프로세스의 종료는 서비스 인스턴스 감소, 세션 손실, 리더 교체를 초래할 수 있다. 이어지는 재스케줄링 지연과 이미지 풀·로그 쓰기 경쟁은 I/O 병목을 유발한다. 실무 체크: 먼저 문제 노드의 oom 관련 로그와 컨테이너 재시작 사유(oom_score, eviction reason)를 수집하고, 재스케줄링 시 트래픽을 단계적으로 분산해 동시 재시작 충돌을 완화하라. Kubernetes 노드 OOM 발생 시 서비스 셧다운 복구 전략을 수립할 때 이들 영향을 우선 고려해야 한다. 리더·스테이트풀 장애: 리더 선출 지연이 전체 처리 지연으로 이어진다 동시 재시작(Thundering Herd): 많은 파드가 동시에 기동하면 API 서버와 스케줄러에 큰 부하가 걸린다 스케줄링·노드 압박 전이: Eviction으로 부하가 다른 노드로 전이되며 연쇄 OOM이 발생할 수 있다 운영 영향: 모니터링과 알람이 폭주하고 롤백이나 수동 개입이 잦아진다 원인 진단과 탐지 방법 먼저 dmesg와 syslog에서 "Out of memory" 또는 oom_reaper/oom_kill 관련 로그를 찾아 커널 수준의 셧다운 시점을 파악한다. 이어서 kubelet 이벤트(예: kubectl describe node 또는 pod의 Events)에서 어떤 파드가 순차적으로 종료되었는지, eviction이나 Killed 메시지가 발생했는지 확인한다. ...