Kubernetes에서 Liveness Probe 실패 시 Pod 내부에서 벌어지는 일, 제대로 파헤치기

Kubernetes를 사용하다 보면 'Pod의 liveness probe가 실패하면 어떻게 될까?'라는 질문을 자주 접하게 됩니다. 많은 개발자들이 '그냥 재시작한다'고 답하지만, DevOps 전문가라면 그 이면에서 어떤 컴포넌트들이 어떻게 움직이고 있는지 깊이 이해해야 합니다. 이번 글에서는 Kubernetes Pod의 liveness probe가 실패했을 때 실제로 내부에서 발생하는 절차와, 그로 인한 시스템의 변화, 그리고 실전 디버깅 방법까지 쉽고 재미있게 안내해 드리겠습니다.

liveness probe 실패: kubelet과 API Server의 상호작용

Pod의 liveness probe가 지정한 조건을 충족하지 못하면, 먼저 kubelet이 그 사실을 감지합니다. kubelet은 이 정보를 바로 API Server에 보고하고, API Server는 Pod의 상태를 etcd 데이터베이스에 'Unhealthy'로 기록하죠. 이때부터 해당 Pod는 더 이상 건강한 Pod로 간주되지 않습니다.

컨테이너 종료 및 재시작: kubelet과 Container Runtime의 역할

이후 kubelet은 containerd나 CRI-O 같은 런타임에게 현재 컨테이너를 종료하라고 명령합니다. 여기서 핵심은 'restartPolicy' 설정에 따라 Pod를 즉시 재시작할 수도, 아니면 영구적으로 종료해 둘 수도 있다는 점입니다. 단순히 '재시작한다'는 답변에 머무르지 말고, 이 과정에서 정책에 따라 다른 행동이 나온다는 점을 기억하세요.

컨트롤러의 조율: 배포와 ReplicaSet의 자동 복구

Pod가 비정상 상태가 되면, Deployment나 ReplicaSet과 같은 컨트롤러가 필요한 Pod 수를 체크합니다. 만약 건강한 Pod 개수가 부족하다면, 새로운 Pod을 스케줄링하여 자동으로 복구하는 작업을 시작합니다. Kubernetes 클러스터가 장애에 강한 이유가 바로 이런 자동 조율과 복구 덕분이랍니다.

스케줄러의 역할: 새 Pod 스케줄링과 자원 평가

새로운 Pod를 배치할 필요가 있을 때, 스케줄러가 나섭니다. 남은 노드의 리소스 상태, taint/toleration, affinity 정책 등을 꼼꼼하게 확인하여 최적의 위치에 Pod를 재배치합니다. 이렇게 해서 서비스가 중단되지 않고, 안정적으로 트래픽을 처리할 수 있죠.

네트워킹 후속조치: kube-proxy와 서비스 트래픽의 변화

네트워크 레벨에서도 변화가 생깁니다. kube-proxy가 IPVS/iptables 규칙을 업데이트해, 비정상 Pod의 엔드포인트를 서비스 목록에서 제거합니다. 결과적으로 기존 DNS는 정상 동작하지만, 문제의 Pod로는 트래픽이 더 이상 흐르지 않습니다. 실시간 트래픽 라우팅이 이처럼 유연하게 바뀌는 셈입니다.

관찰성 및 이벤트 모니터링: probe 실패 알림과 디버깅 포인트

Probe 실패 이벤트는 자동으로 생성되어 kubectl describe pod 명령으로 확인할 수 있습니다. 하지만 만약 Prometheus 등 모니터링 도구가 kubelet이나 이벤트를 제대로 수집하지 않는다면, 실제 사용자 불만이 접수되기 전까지는 이런 장애를 알기 힘들기도 합니다. 꾸준한 모니터링 체계 구축이 필수라는 점, 다시 한번 강조합니다.

liveness probe 오·남용의 위험성과 설정 팁

liveness probe를 지나치게 엄격하거나 잘못 설정하면, 멀쩡한 Pod조차 자주 재시작되는 불상사가 벌어질 수 있습니다. probe 설정은 실제 서비스 환경과 트래픽 패턴에 맞게 적절히 조정해 주세요. 불필요한 장애를 스스로 만들어내지 않기 위해서입니다.

readiness probe 실패 시의 트래픽 처리 방식

liveness probe와 달리 readiness probe가 실패하면, Pod는 종료되거나 재시작되지 않습니다. 대신 서비스의 엔드포인트 목록에서 해당 Pod의 아이피만 빠지기 때문에, 트래픽 경로만 우회하게 됩니다. 시스템의 중단 없이도 불완전한 Pod을 효율적으로 격리할 수 있어, 안정성이 더욱 up되는 핵심 기능입니다.

로그가 없을 때 probe 실패 디버깅 노하우

가끔 Pod 로그에는 아무런 이상 신호가 없는데도 probe가 계속 실패할 수 있습니다. 이럴 땐 probe 실행 환경(네트워크, 파일 권한, 리소스 사용량 등)과 probe 명령어 자체를 꼼꼼히 리뷰하고, kubectl describe pod로 이벤트를 정확히 파악하는 것이 디버깅의 첫걸음입니다. 다양한 설정값(타임아웃, 실패 횟수 등)도 함께 점검해 보세요.

마무리하며, Kubernetes의 liveness probe 실패는 단순한 '재시작'만으로 끝나지 않습니다. kubelet, API Server, 컨트롤러, 스케줄러, 네트워크 그리고 모니터링까지 다양한 컴포넌트들이 맞물려 서비스 안정성과 자동 복구를 실현합니다. 여러분도 이런 내부 절차와 각종 설정 팁을 잘 이해해 두면, 실제 장애 발생 시 빠르고 정확하게 대응할 수 있을 거예요. Kubernetes 운영, 제대로 알고 활용합시다!

출처 및 참고 : Mastering One Question At a Time in Kubernetes | by Devops Diaries | Sep, 2025 | Medium