Kubernetes probe 설계: 시작·복구·트래픽 준비를 분리하기
startup·liveness·readiness가 컨테이너 종료와 재시작, Service의 엔드포인트 상태에 미치는 영향을 구분하고 의존성 장애와 과도한 검사에서 생기는 운영 위험을 설명합니다.
발행·오류 제보: infostoa · 편집 기준
이 글의 개별 작성자와 전문 검토자 정보는 제공되지 않습니다.
Kubernetes probe는 컨테이너 상태에 따라 시작 지연, 재시작, 트래픽 준비 상태를 판단하는 kubelet 진단입니다. startup은 초기화 완료를, liveness는 프로세스가 재시작 없이 회복하기 어려운 상태인지를, readiness는 요청을 받을 준비가 되었는지를 확인합니다. 세 검사는 서로 다른 조치를 유발하므로 같은 엔드포인트를 무조건 복사해 쓰지 말고 각각의 실패 의미를 정해야 합니다.
세 probe의 결과가 바꾸는 것
Startup probe는 애플리케이션이 초기화되는 동안 liveness와 readiness 검사를 미룹니다. startup이 성공하면 두 검사가 시작되고, startup probe가 설정된 경우 실패 한도에 도달하면 kubelet이 컨테이너를 종료합니다. 느리게 시작하는 애플리케이션에서 초기화 시간을 허용하려면 startup 검사 주기와 실패 한도를 맞춰 설정할 수 있습니다. 이 방식은 liveness의 감시 간격을 과도하게 늘리지 않고도 시작 시간을 따로 다룹니다.
Liveness probe는 컨테이너가 살아 있어도 내부 교착처럼 자체 회복이 어려운 상태를 찾아 재시작하도록 할 때 사용합니다. 실패하면 kubelet이 컨테이너를 종료하며 Pod의 restart policy가 후속 동작을 결정합니다. 프로세스가 스스로 종료하고 정책에 따라 재시작될 수 있다면 별도 liveness가 필요하지 않을 수도 있습니다. 반면 의존 서비스의 일시 장애까지 liveness 실패로 간주하면 정상 컨테이너를 반복 재시작할 수 있습니다.
Readiness probe는 컨테이너가 서비스 요청을 처리할 준비가 되었는지 나타냅니다. 실패한 컨테이너는 Ready가 아니게 되고, 해당 Pod를 대상으로 하는 Service의 정상 트래픽 선택에서 제외됩니다. 이 검사는 컨테이너를 재시작하는 수단이 아닙니다. 초기 데이터 로딩, 캐시 준비 또는 애플리케이션이 처리 가능한 용량처럼 실제 수신 가능 여부에 관련된 조건을 확인하는 데 적합합니다.
검사 방식 선택
Kubernetes는 HTTP, TCP, gRPC, exec probe 방식을 제공합니다. HTTP 검사는 컨테이너 IP의 지정 포트와 경로에 GET 요청을 보내며 200 이상 400 미만 응답을 성공으로 봅니다. TCP 검사는 포트가 열려 있는지 확인할 뿐 애플리케이션이 올바른 응답을 만드는지까지 증명하지 않습니다. gRPC 검사는 표준 health checking 프로토콜을 사용하고, exec는 컨테이너 안에서 명령을 실행해 종료 상태를 판단합니다. 선택은 앱이 실제로 준비되었거나 멈췄다는 뜻을 가장 잘 나타내는 신호에 맞춰야 합니다.
주기와 실패 판정 조정
periodSeconds, timeoutSeconds, failureThreshold, successThreshold, initialDelaySeconds는 검사 빈도와 실패 판정 시간을 결정합니다. startup probe를 사용하면 성공 전까지 liveness와 readiness의 초기 지연 계산이 시작되지 않습니다. 단순히 모든 값을 짧게 두면 회복 가능성이 있는 일시 지연을 실패로 오판할 수 있습니다. 반대로 너무 긴 주기와 높은 실패 한도는 장애 탐지와 트래픽 제외를 늦출 수 있으므로 시작 시간과 실제 회복 시간에 맞춰 조정합니다.
Kubernetes 문서는 exec probe가 매 실행마다 프로세스를 만들기 때문에 Pod 밀도가 높고 주기가 짧을 때 노드 CPU 부담이 생길 수 있다고 경고합니다. 가벼운 HTTP나 TCP 진단이 요구에 맞는지 검토하고, 검사 자체가 비싼 데이터베이스 쿼리나 깊은 외부 의존성 순회를 반복하지 않도록 합니다. probe는 별도의 고빈도 부하 생성기가 아니라 kubelet이 상태에 따라 조치하도록 돕는 진단입니다.
의존성 장애와 readiness의 경계
앱은 정상 작동하지만 필수 백엔드가 중단될 수 있습니다. Kubernetes 문서는 엄격한 백엔드 의존성이 있을 때 liveness는 앱 자체를, readiness는 백엔드 가용성까지 확인할 수 있다고 설명합니다. readiness 실패는 Service EndpointSlice 상태에 반영되어 일반 트래픽 선택에 영향을 주지만, 기존 연결 종료나 모든 프록시의 즉시 갱신을 보장하지 않습니다.
공유 백엔드 장애를 liveness에 넣으면 여러 컨테이너가 함께 재시작될 수 있습니다. 요청 처리에 필수인 의존성을 구분해 readiness 범위를 정하고, 사용자 영향과 원인 파악은 서비스 모니터링으로 따로 추적하세요.
실무자 관점: 증상과 원인을 probe 하나에 섞지 않기
Google SRE의 모니터링 장은 사용자에게 보이는 증상과 그 원인을 구분하고, 외부에서 보이는 동작을 확인하는 black-box 신호와 내부 동작을 설명하는 white-box 신호를 함께 쓰는 관점을 제시합니다. 이를 probe에 적용하면 readiness는 수신 불가능 상태를 트래픽 선택에 반영하고, liveness는 컨테이너 재시작이 적절한 내부 상태만 겨냥하도록 좁힐 수 있습니다. 외부 API 전체의 정상성이나 데이터베이스 상태를 liveness에 모두 포함하면 의존성 장애가 여러 Pod의 재시작으로 번질 수 있습니다.
검증할 때는 의도적으로 startup 지연, readiness 실패, 프로세스 교착을 각각 재현해 Kubernetes의 상태 변화와 재시작 결과를 확인합니다. readiness 실패 때 실제로 트래픽이 빠지는지, liveness 실패 때 restart policy에 따른 결과가 맞는지, 복구 후 상태가 정상으로 돌아오는지 살핍니다. 별도 대시보드와 서비스 수준 지표는 사용자의 증상과 근본 원인을 파악하는 데 계속 필요합니다. probe 성공은 검사한 진단이 성공했다는 뜻이지 전체 서비스의 모든 기능이 정상이라는 증명은 아닙니다.