Running인데 왜 서비스는 실패할까

목표

Running·Ready·HTTP 응답·재시작을 실제 kubelet 동작으로 구분하고 검사 의미가 잘못됐을 때의 착시를 설명합니다.

왜 중요한가

포트가 열려 있다는 사실은 업무 성공을 보장하지 않습니다. 잠시 요청을 받지 말아야 할 앱과 다시 시작해야 할 앱을 혼동하면 자동 복구가 장애를 키웁니다.
정상 비교군을 유지하면서 준비 실패, 프로세스 재시작, TCP/HTTP 검사 차이, 느린 초기화를 각각 관찰합니다.
모든 실험은 개인 k3s VM의 합성 앱에 한정합니다. 운영 kubeconfig·실제 비밀·외부 서버를 가져오지 마세요.
55분 실습이며 준비에 수분이 걸릴 수 있습니다. 더 필요하면 세션 만료 전에 연장하세요. 종료하면 VM과 파일은 회수됩니다.

준비된 환경과 도우미

네임스페이스 kcna-health의 web-a·web-b는 healthy Service 뒤에 있습니다. 비교용 lying Service는 처음에는 대상이 없습니다.
두 Service는 ClusterIP:8080이며 publishNotReadyAddresses=false입니다. 앱 이미지는 digest 고정·Always pull,
non-root·cap drop ALL·seccomp RuntimeDefault·읽기 전용 루트·ServiceAccount 토큰 미마운트로 실행됩니다.
/state의 1Mi emptyDir만 합성 장애 표식에 씁니다. workload 보안이나 정상 비교군을 바꿔 과제를 해결하지 마세요.

도우미 명령은 python3 /opt/fixtures/kcna_health_lab.py 뒤에 act·capture·observe·grade·prepare와 단계 번호를 붙입니다.
act는 입력 JSON을 검증한 뒤 지정된 실험 변경만 합니다. capture는 실제 관측을 기다려 /root/kcna-health에 저장합니다.
observe는 현재 관측을 출력합니다. grade는 자원이나 학생 파일을 바꾸지 않습니다.
학생이 만드는 것은 change/probe 입력 JSON입니다. 관측 JSON의 성공·UID·상태 값을 직접 꾸며 넣지 마세요.
/opt/fixtures/kcna-health-context.json·kcna-health-lab-context.json·kcna-health-warming.json은 도우미가 관리하는 내부 기록입니다.

단계

1. capture 1로 /root/kcna-health/baseline.json을 저장하세요. kcna-health의 web-a·web-b Pod UID, containerID, restartCount, Ready, healthy Service와 EndpointSlice 조건, 실제 HTTP 200을 조사합니다. Pod는 non-root·cap drop ALL·읽기 전용 루트·토큰 미마운트이며 정상 비교군 B를 끝까지 보존합니다.
2. /root/kcna-health/not-ready-change.json에 pod=web-a, flag=not-ready, present=true인 JSON을 작성하세요. act 2와 capture 2로 not-ready.json을 저장합니다. A는 Running인 채 Ready=false·직접 HTTP 503·EndpointSlice ready=false가 되고 컨테이너와 재시작 횟수는 그대로여야 합니다. Service 요청 여섯 개가 정상 B로 전달되는지 함께 봅니다.
3. /root/kcna-health/restored-change.json에 pod=web-a, flag=not-ready, present=false를 작성하세요. act 3과 capture 3으로 restored.json을 저장합니다. 같은 Pod·컨테이너·재시작 횟수에서 Ready와 정상 HTTP 응답이 돌아와야 합니다.
4. /root/kcna-health/restarted-change.json에 pod=web-a, flag=unhealthy, present=true를 작성하세요. act 4와 capture 4로 restarted.json을 저장합니다. 같은 Pod UID에서 컨테이너 ID와 앱 boot_id가 달라지고 재시작 횟수가 증가해야 합니다. 이 표식은 새 프로세스가 시작하면 지워지는 합성 장애입니다.
5. /root/kcna-health/tcp-probe.json에 tcpSocket.port=8080, periodSeconds=2, timeoutSeconds=1, failureThreshold=2, successThreshold=1을 작성하세요. act 5는 이 설정으로 liar Pod를 만들고 준비 실패 표식을 넣습니다. capture 5로 tcp-lie.json을 저장하세요. TCP Ready=true와 lying Service의 HTTP 503이 동시에 관측돼야 합니다.
6. /root/kcna-health/http-probe.json에서 tcpSocket 대신 httpGet.path=/readyz, httpGet.port=8080을 사용하고 나머지 네 숫자는 5단계와 같게 하세요. act 6은 원래 liar UID를 확인해 새 HTTP 프로브 Pod로 교체합니다. capture 6으로 http-excluded.json을 저장합니다. 직접 HTTP 503, Ready=false, EndpointSlice ready=false, Service에서 정상 HTTP 응답 없음과 변경된 Pod UID를 비교하세요.
7. /root/kcna-health/startup-probe.json에 httpGet.path=/startupz, httpGet.port=8080, periodSeconds=1, timeoutSeconds=1, failureThreshold=45를 작성하세요. act 7은 20초 초기화 앱 slow를 만들고 시작 직후 started=false·Ready=false·재시작 0·/livez 503을 기록합니다. capture 7로 warming.json을 저장합니다. 늦게 capture를 눌러도 실제 초기 관측은 유지됩니다.
8. capture 8로 /root/kcna-health/started.json을 저장하세요. slow는 7단계와 같은 Pod·컨테이너에서 재시작 없이 started=true·Ready=true·HTTP 200이어야 합니다. A의 복구, HTTP 프로브로 제외한 liar, 원래 B의 신원·컨테이너·정상 응답도 보존해야 합니다.

참고

실패하면 같은 VM에서 observe와 kubectl -n kcna-health get pods -o json을 읽어 원인을 조사하세요.
새 상태를 기다리는 동안 act를 반복 호출하지 않습니다. 완료한 변경과 관측은 보존하며 과거 상태를 현재 값으로 다시 만들지 않습니다.
초기화는 시간이 지나면 끝나므로 7단계의 채점은 실제 초기 관측과 현재의 동일 컨테이너·재시작 0을 함께 봅니다.
8단계에서는 실제 시작 완료까지 추가로 확인합니다. 일반 채점은 60초, 단계 준비 전체는 90초 예산을 유지합니다.
준비는 없는 이전 단계만 실행합니다. 현재 입력·관측을 대신 만들지 않고 잘못 작성한 기존 입력도 덮지 않습니다.
실험의 liveness 표식은 재시작 시 지워지는 합성 장애이며 실제 교착 탐지기나 모든 장애의 복구법이 아닙니다.
liar의 독립 Pod 교체를 운영 Deployment의 무중단 배포 절차로 그대로 사용하지 마세요.
관측 파일은 학습 자료이지 root를 통제하는 원격 증명·부정행위 방지 장치가 아닙니다.
공식 근거: [프로브 역할](https://kubernetes.io/docs/concepts/workloads/pods/probes/) ·
[EndpointSlice 조건](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/) ·
[프로브 설정](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).

단계 8개

1. 초록불의 기준선 조사
2. 실행 중인 앱을 요청 배정에서 제외
3. 재시작 없이 준비 상태 복구
4. 같은 Pod 안의 컨테이너 재시작
5. 포트는 열렸는데 HTTP는 503
6. 업무 준비를 검사하는 HTTP 프로브
7. 느린 초기화를 보호하고 기록
8. 재시작 없이 시작 완료를 입증