초록불의 의미와 느린 시작의 예산

한 줄 요약

프로브의 성공은 선택한 검사 조건이 참이라는 뜻입니다. 포트가 열렸다는 사실을 업무 성공으로
해석하거나, 느린 초기화를 즉시 죽여야 할 장애로 해석하면 자동 복구가 오히려 장애를 만듭니다.

왜 이게 필요했나

전화가 연결되는 식당과 주문을 받을 수 있는 식당은 다릅니다. 직원은 전화를 받지만 주방이 멈췄을 수
있습니다. 모니터링에서 '연결 성공'을 '주문 성공'으로 바꾸어 읽는 순간, 초록 화면과 고객 불만이
동시에 존재하게 됩니다. 서버의 health endpoint도 이름에 health가 들어간다고 자동으로 올바른
검사가 되는 것은 아닙니다. 성공 조건을 누가 무엇으로 구현했는지까지 보아야 합니다.

어떻게 동작하나

TCP 검사는 지정된 포트에 연결할 수 있는지 확인합니다. HTTP 검사는 지정된 경로의 응답 코드를
관찰합니다. 예를 들어 웹 서버가 모든 주문에 503을 돌려주어도 TCP 연결을 받아 주는 소켓은 열려
있을 수 있습니다. 이 경우 TCP readiness는 성공하는데 사용자는 실패 응답을 받습니다.

그렇다고 모든 앱에서 TCP 검사가 틀렸다는 뜻은 아닙니다. 검사 목적이 연결 수락 여부라면 정확한
질문입니다. 문제는 그 결과가 보장하지 않는 업무 의미까지 붙이는 것입니다. HTTP 검사도 마찬가지로,
항상 200을 반환하는 경로라면 데이터베이스 조회 실패를 발견하지 못합니다. 반대로 건강 검사마다
무거운 조회를 수행하면 검사 자체가 서비스에 부담을 줄 수 있습니다.

| 경로의 예 | 확인하려는 것 | 함부로 섞지 말아야 할 것 |
| --- | --- | --- |
| /startupz | 이번 프로세스의 초기화가 끝났는가 | 이미 시작한 뒤 매번 같은 초기화 수행 |
| /livez | 계속 실행시키는 것이 의미 있는가 | 모든 외부 의존 서비스의 일시 장애 |
| /readyz | 새 업무 요청을 맡길 수 있는가 | 사용자 전체 여정의 완전한 성공 보장 |
| 실제 업무 경로 | 실제 요청 결과와 응답 내용 | 단 한 번 성공한 것을 가용성 보장으로 확대 |

startup probe는 느린 시작을 보호하는 별도의 검사입니다. 이것이 성공하기 전에는 liveness와
readiness가 실행되지 않습니다. 초기화에 시간이 걸리는 앱에 공격적인 liveness부터 적용하면,
앱이 시작을 마치기도 전에 계속 죽는 상황이 생길 수 있습니다. 시작에 허용할 시간과 실행 도중
회복 불능 상태를 감지할 시간을 별도로 다루는 이유입니다.

예를 들어 실험 앱은 시작한 뒤 20초 동안 초기화 중인 응답을 내고, 그 뒤 정상 응답을 냅니다.
startup의 검사 주기가 1초, 연속 실패 한도가 45라면 20초 초기화보다 여유 있는 설정입니다.
이 수치는 모든 환경에서 정확히 45.000초 후 종료된다는 보장이 아닙니다. 실행·스케줄링·검사 소요가
있으므로 실제 전이는 관측해야 합니다. 시험에서도 숫자를 외우는 것보다 어떤 예산이 어느 실패를
보호하는지 설명할 수 있는지가 중요합니다.

초기화가 끝난 뒤 readiness가 잠시 실패한다고 startup이 처음부터 다시 도는 것은 아닙니다.
반대로 컨테이너가 재시작되면 새 프로세스의 시작 단계가 생깁니다. 이때 이전 프로세스의 성공 기록을
새 프로세스의 증거로 재사용하면 안 됩니다. Pod UID만 아니라 컨테이너 ID와 앱의 실행 식별자를
같이 기록하는 이유가 여기에 있습니다.

현장에서 만나는 모습

새 버전이 배포된 뒤 연결 검사에는 성공하지만 실제 API만 실패한다고 합시다. 우선 probe를 없애거나
Service가 준비되지 않은 주소까지 공개하도록 바꾸지 않습니다. 업무 경로와 검사 경로의 차이,
Pod 조건, EndpointSlice 대상, 실제 요청 결과를 나누어 조사합니다. 그 뒤 그 서비스가 약속하는
준비 상태를 표현하도록 검사를 고칩니다. 검사에서 빨간불이 사라지는 것과 장애가 해결되는 것은 다릅니다.

검사를 바꿀 때도 객체 수명을 존중해야 합니다. 실행 중인 독립 Pod의 probe 필드는 마음대로 수정할 수
없습니다. 선언을 수정하고 어떤 관리 객체가 새 Pod를 만들 것인지, 교체 동안 가용한 비교군이 있는지를
확인합니다. 교재의 폐기용 단일 Pod 교체 절차를 운영 Deployment의 무중단 배포 절차로 그대로 쓰지는 마세요.

다음 실습에서 할 것

두 정상 Pod 중 하나의 readiness를 실패시켜 재시작 없이 요청 배정만 바뀌는지 봅니다. 이어 합성
liveness 장애로 컨테이너 재시작을 관찰하고, TCP readiness를 통과하면서 HTTP 503을 내는 별도
Pod를 비교합니다. 마지막으로 느린 시작 동안의 상태와 초기화 완료 뒤의 상태를 실제 기록으로
연결합니다. 전이는 시간이 걸릴 수 있으므로 설정을 반복해서 덮기 전에 같은 객체의 진행 상황을 봅니다.

공식 근거: [프로브 구성과 주의사항](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).