파드는 실행 중인데 요청을 못 받는다: Kubernetes 상태 검사 3가지를 나누는 법

파드는 실행 중인데 서비스 요청이 실패하면 상태 표시와 사용자 경험 사이에 간격이 생깁니다. 프로세스가 시작된 것과 지금 요청을 처리할 수 있는 것은 서로 다른 질문이죠. 이번 글은 검사 경로를 구현하는 코드보다 각 검사의 목적과 실패 결과를 구분하는 데 집중합니다.

Running 상태만으로 요청을 받을 준비가 됐다고 볼 수 있나요?

파드의 Running 단계는 실행 상태를 나타내며, 지금 서비스 요청을 처리할 준비까지 보장하지는 않습니다.

Kubernetes의 Pod 생명주기 문서는 파드의 단계와 컨테이너 상태를 구분합니다. 컨테이너 실행과 서비스 준비를 하나의 신호로 합치지 않는 것이 출발점이죠.

예를 들어 프로세스는 시작됐지만 필요한 초기 데이터를 아직 읽는 중인 상황을 생각할 수 있습니다. 이것은 개념을 설명하기 위한 예시이며 특정 운영 장애 사례가 아닙니다. Running이라는 표시와 함께 준비 상태와 해당 컨테이너의 기록도 볼 필요가 있죠.

재시작 횟수도 따로 읽어야 하죠. 컨테이너를 다시 시작하는 것과 기존 파드를 삭제하고 다른 파드로 교체하는 것은 같은 동작이 아닙니다. 문제가 생긴 시점의 파드 식별 정보와 컨테이너 상태를 구분해 남기면 좋아요.

startup probe는 어떤 초기화 시간을 보호하나요?

startup을 설정하면 성공 전까지 liveness와 readiness 검사는 대기합니다.

Kubernetes의 상태 검사 개념 문서는 startup probe를 애플리케이션의 기동 완료를 확인하는 검사로 설명합니다. 성공한 뒤에도 주기적으로 기동 완료를 다시 묻는 검사는 아니죠.

느린 초기화와 실행 중의 복구 불가능한 정지를 다른 조건으로 판단할 수 있습니다. 기동에 오래 걸린다는 이유로 실행 중 장애를 확인하는 간격까지 무작정 늘릴 필요는 없죠.

기동 검사가 정해진 연속 실패 허용치에 도달하면 kubelet은 해당 컨테이너를 종료하고, 이후 동작에는 적용되는 재시작 정책이 관계됩니다. startup을 설정했다고 초기화가 끝날 때까지 무한히 기다려 주는 것은 아니에요.

일반적인 초기화 시간뿐 아니라 오래 걸리는 조건도 관측해 허용 범위를 검토합니다. 이 글은 모든 서비스에 같은 시간값을 권장하지 않습니다. 우리 애플리케이션의 초기화 기록을 확인하는 것이 먼저죠.

readiness 실패와 liveness 실패는 어떻게 다르게 처리되나요?

readiness는 트래픽 준비를, liveness는 컨테이너 재시작이 필요한 상태인지를 확인합니다.

readiness 검사가 실패하면 해당 컨테이너는 준비되지 않은 상태가 됩니다. 일반적인 Service의 트래픽 대상에서 해당 파드를 제외하는 동작과 연결되죠. 그 실패 자체가 컨테이너를 재시작하라는 지시는 아닙니다.

liveness는 설정된 연속 실패 허용치에 도달했을 때 해당 컨테이너의 종료와 재시작 처리로 이어집니다. 실제 적용되는 재시작 정책까지 함께 확인해야 하죠.

readiness가 먼저 성공해야 liveness를 실행하는 구조도 아닙니다. 두 검사를 기다리게 하려는 목적이라면 startup이나 각 검사의 초기 지연 설정을 검토하는 방식이죠. 준비 상태가 false라는 이유만으로 재시작 원인까지 설명할 수는 없어요.

또한 Service의 트래픽 대상에서 빠진다는 설명을 모든 접속 경로의 즉시 차단으로 확대하면 안 됩니다. 실제 요청 경로와 연결 상태까지 따로 살펴봐야 하죠.

외부 의존성 장애를 재시작 조건에 넣으면 무엇을 검토해야 하나요?

외부 장애를 liveness 실패로 연결하기 전, 컨테이너 재시작이 원인을 바꿀 수 있는지 검토합니다.

여러 파드가 같은 외부 시스템을 기다리는 상황에서 각 컨테이너를 다시 시작해도 외부 시스템이 복구되는 것은 아니죠. 어떤 실패가 애플리케이션 자체의 복구 불가능한 상태인지 나누어야 합니다.

Kubernetes의 상태 검사 설정 가이드는 외부 의존성 등으로 일시적으로 요청을 처리할 수 없는 상황과 readiness의 역할을 설명합니다. 재시작이 필요한지와 요청을 보내도 되는지를 각각 묻는 관점이에요.

반대로 공유 의존성 하나가 느리다고 모든 파드를 준비되지 않은 상태로 만들면 어떤 응답이 남는지도 검토해야 하죠. 외부 의존성을 readiness에 넣는 것 역시 서비스의 실제 응답 방식과 함께 결정할 문제입니다.

공식 개념 문서는 잘못 구현한 liveness 검사가 연쇄 장애를 일으킬 수 있다고 경고합니다. 검사를 추가했다는 사실만으로 가용성이 좋아진다고 보장할 수는 없습니다. 정상·지연·일시 실패·복구 조건에서 각각 무엇이 달라지는지 살펴볼 이유죠.

상태 검사 설정을 바꾸기 전 어떤 기록을 확인하나요?

검사 종류와 실패 시점, 현재 설정 및 컨테이너 상태를 함께 남겨 원인과 처리 결과를 구분해 확인합니다.

먼저 기동 중 실패인지, 실행 이후 준비 상태가 바뀐 것인지, 실제로 컨테이너가 종료된 것인지 구분합니다. 비슷한 오류 문구라도 다른 처리 경로를 거쳤을 수 있죠.

• 검사 대상: 어느 컨테이너의 어떤 검사이며 어떤 경로·포트·명령을 확인하는지 기록합니다.

• 시간과 허용치: 초기 지연, 검사 간격, 응답 제한 시간, 연속 실패 허용치를 살펴봅니다.

• 실제 상태: 준비 상태, 이벤트, 컨테이너 재시작 횟수와 종료 기록을 대조합니다.

• 운영 맥락: 당시 초기화 진행, 부하와 의존 시스템 상태를 함께 남깁니다.

이 목록은 변경 전 기록을 정리하기 위한 운영 제안이며 자동으로 원인을 확정하는 판정표는 아닙니다. 기록 없이 허용치만 늘리면 확인하고 싶은 실패까지 늦게 발견할 수 있죠. 한 번의 검사 결과와 반복 양상도 나누어 읽어야 하죠.

요청에 따라 파드를 늘리는 신호와 콜드 스타트는 Knative 운영 실전: KPA는 무엇을 보고 파드를 늘리는가에서 다룹니다. CDN이 오리진을 선택하는 판단은 CDN 오리진 헬스 체크 설정 가이드: 오리진이 죽었는데 CDN만 모르는 상황 막기와 구분해서 읽으면 좋아요.

이것만 기억하세요

자주 묻는 질문 (FAQ)