프로브 설계와 중단 예산

목표

세 가지 프로브를 검사 방식(httpGet/tcpSocket/exec)과 타이밍 필드까지 지정해서 만들고, Deployment 의 준비 상태와 종료 동작, 그리고 PodDisruptionBudget 을 설계할 수 있게 된다.

왜 중요한가

프로브를 안 붙인 Deployment 는 롤링 업데이트의 안전장치가 전부 무력화된 상태다. maxUnavailable: 0 을 줘도 컨테이너가 뜬 즉시 Ready 로 간주되어 초기화 중인 파드로 트래픽이 흘러 들어간다. 반대로 프로브를 너무 공격적으로 잡으면 정상 파드가 계속 재시작되면서 오히려 장애를 만든다. 그래서 프로브는 "붙였는가"가 아니라 "숫자를 계산해서 붙였는가"가 관건이다.

liveness 와 readiness 를 헷갈리면 사고가 커진다. 의존 서비스(DB)가 잠깐 죽었을 때 그걸 liveness 로 검사하면, 모든 파드가 동시에 재시작을 반복하며 DB 가 살아나도 회복이 늦어진다. 외부 의존성은 readiness 로 검사한다 — 트래픽만 안 받으면 되고 재시작할 이유는 없다.

startup 프로브는 이 둘 사이의 긴장을 푼다. liveness 에 initialDelaySeconds: 300 을 주면 운영 중 장애 감지도 5분 늦어지지만, startup 으로 300초 예산을 따로 주면 기동 후에는 liveness 를 촘촘하게 유지할 수 있다.

단계

1. 네임스페이스 ckad-obs 를 만들고 파드 web-live 를 만든다. 이미지 nginx:1.27, livenessProbe 는 httpGet 으로 path /healthz, port 80, initialDelaySeconds: 5, periodSeconds: 10.
2. 파드 db-ready 를 만든다. 이미지 nginx:1.27, readinessProbe 는 tcpSocket port 5432, initialDelaySeconds: 10, periodSeconds: 5, failureThreshold: 3.
3. 파드 file-check 를 만든다. 이미지 busybox:1.36, command: ["/bin/sh","-c","sleep 3600"], livenessProbe 는 exec 으로 command: ["cat","/tmp/healthy"], periodSeconds: 5, failureThreshold: 2.
4. 파드 legacy-app 을 만든다. 이미지 nginx:1.27. startupProbe 는 httpGet path /startup, port 8080, failureThreshold: 30, periodSeconds: 10 (= 300초 예산). 같은 컨테이너에 livenessProbe 도 httpGet path /healthz, port 8080, periodSeconds: 10 으로 붙인다.
5. 파드 budget-app 을 만든다. 이미지 nginx:1.27, readinessProbe 는 httpGet path /ready, port 80, initialDelaySeconds: 15. 첫 실패 이후 20초 안에 엔드포인트에서 빠지도록 periodSeconds 와 failureThreshold 를 직접 정한다. 조건은 periodSeconds × failureThreshold ≤ 20, failureThreshold ≥ 3, periodSeconds ≥ 2.
6. Deployment api 를 만든다. 레플리카 3, 라벨 app=api, 이미지 nginx:1.27. 컨테이너에 readinessProbe(httpGet /ready:8080)와 livenessProbe(httpGet /healthz:8080)를 붙이고, terminationMessagePolicy: FallbackToLogsOnError 를 지정한다.
7. PodDisruptionBudget api-pdb 를 만든다. minAvailable: 2, selector 는 app=api.
8. Deployment api 에 startupProbe 를 추가한다 — httpGet path /startup, port 8080, failureThreshold: 12, periodSeconds: 5. 그리고 파드 스펙의 terminationGracePeriodSeconds 를 60 으로 설정한다. 기존 readiness/liveness 프로브와 레플리카 3은 그대로 유지한다.

참고

• kubectl explain pod.spec.containers.livenessProbe / .startupProbe 로 필드 이름을 확인한다.
• kubectl create deployment api --image=nginx:1.27 --replicas=3 -n ckad-obs --dry-run=client -o yaml > api.yaml 로 뼈대를 뽑고 프로브를 손으로 채우는 편이 빠르다.
• 이 환경에서는 kubectl logs 와 kubectl exec 이 동작하지 않는다. 그 명령들은 이 모듈의 퀴즈에서 다룬다.
• 흔한 실수 1: 프로브를 파드 수준(spec.livenessProbe)에 쓰는 것. 컨테이너 수준 필드다.
• 흔한 실수 2: PDB 의 selector 에 Deployment 이름을 넣는 것. 파드 라벨이어야 한다.
• 흔한 실수 3: terminationGracePeriodSeconds 를 컨테이너 밑에 쓰는 것. 파드 스펙 수준이다.

단계 8개

1. HTTP liveness 프로브
2. TCP readiness 프로브
3. exec 프로브
4. startup 프로브로 느린 기동 감싸기
5. 감지 지연을 계산해서 값 정하기
6. Deployment 에 프로브와 종료 메시지 정책 붙이기
7. PodDisruptionBudget 으로 자발적 중단 제한
8. 기동 예산과 종료 예산을 함께 (종합)