배포는 성공했다는데 새 버전은 왜 안 보일까

목표

실제 k3s에서 선언 수락·롤아웃 완료·준비 실패·수동 롤백·외부 설정 복구를 각각의 증거로 구분합니다.

왜 중요한가

배포 명령이 끝났다는 사실만으로 새 버전이 요청을 처리한다고 말할 수 없습니다.
롤링 업데이트는 기존 정상 복제본을 유지하므로 새 버전이 실패해도 서비스는 정상처럼 보입니다.
그때 liveness를 고치거나 모든 Pod를 삭제하면 무엇이 실패했는지 증거까지 잃습니다.
이 실습은 정상 비교군과 마지막 정상 복제본을 남기고, 지정한 준비 실패만 주입합니다.
50분 실습입니다. 필요하면 만료 전에 연장하세요. 세션 종료 시 VM과 파일은 회수됩니다.

준비된 환경과 도우미

개인 VM의 kcna-delivery 공간에 web Deployment 두 복제본, settings ConfigMap, web Service와 control Pod가 있습니다.
앱 이미지는 digest로 고정했고 non-root·cap drop ALL·RuntimeDefault·읽기 전용 루트·ServiceAccount 토큰 미마운트를 사용합니다.
v1·v2·v3는 같은 이미지에서 동작을 구분하는 합성 앱 버전입니다. 새 이미지를 빌드하거나 실제 CI·GitOps를 변경하는 실험은 아닙니다.
노드·정상 비교군·롤아웃 보호 설정을 바꾸거나 운영 kubeconfig·비밀을 가져오지 마세요.
모든 학생 파일은 /root/kcna-delivery 아래에 둡니다. 입력 JSON은 직접 작성하고 실제 관측 JSON은 capture로 만듭니다.
python3 /opt/fixtures/kcna_delivery_lab.py 뒤에 act·capture·grade·prepare와 단계 번호 1~8을 붙입니다.
observe는 현재 API·HTTP 응답을 읽습니다. grade는 파일과 객체를 변경하지 않습니다.
act는 조작 완료 기록을 /opt/fixtures/kcna-delivery-action-N.json에 남깁니다. 파일의 UID·응답·완료 여부를 꾸며 쓰지 마세요.

단계

1. capture 1로 /root/kcna-delivery/baseline.json을 저장하세요. v1·blue인 정상 Pod 두 개, Deployment·ReplicaSet·Pod UID, 컨테이너 ID·재시작 횟수, Ready, EndpointSlice와 Service 응답을 조사합니다. control Pod는 독립적인 정상 비교군입니다.
2. annotation.json에 문자열 note=reviewed를 저장하고 act 2·capture 2로 metadata_only.json을 만드세요. Deployment 객체의 주석만 바뀌며 원래 ReplicaSet·Pod·컨테이너·revision은 유지돼야 합니다. 객체 변경이 곧 새 프로세스라는 가설을 반증하세요.
3. config-green.json에 문자열 color=green을 저장하고 act 3·capture 3으로 config_only.json을 만드세요. ConfigMap settings의 값은 green이지만 기존 Pod와 Service의 실행 중 COLOR는 blue입니다. 환경변수 소비 시점과 API에 저장된 값을 구분하세요.
4. release-v2.json에 문자열 release=v2와 불리언 ready=true를 저장하세요. act 4·capture 4로 v2_complete.json을 만듭니다. 새로운 ReplicaSet·Pod 둘이 v2·green으로 응답하고 updatedReplicas=2여야 합니다. 정상 revision 번호를 이 관측에 남기세요.
5. release-v3.json에 문자열 release=v3, 불리언 ready=false, 문자열 color=purple을 저장하세요. act 5·capture 5로 v3_unready.json을 만듭니다. v3는 Running이지만 Ready가 아니며 직접 HTTP 503을 냅니다. 기존 v2·green 두 개는 같은 UID·컨테이너로 남고 Service는 이 정상 복제본으로 전달돼야 합니다.
6. 추가 변경 없이 capture 6으로 deadline_exceeded.json을 저장하세요. 실제 Progressing=False·ProgressDeadlineExceeded와 여전히 v3인 원하는 템플릿을 확인합니다. liveness 재시작이나 자동 롤백이 아니라 준비되지 않는 새 버전의 진도 실패입니다. 이 실험의 20초 기준은 운영 권장값이 아닙니다.
7. v2_complete.json에 저장된 Deployment의 deployment.kubernetes.io/revision을 조사해 rollback.json의 revision에 문자열로 적으세요. act 7·capture 7로 rolled_back.json을 만듭니다. 실제 rollout undo 명령의 완료 기록, 보존된 원래 v2 Pod, 증가한 revision과 여전히 purple인 외부 ConfigMap을 비교하세요.
8. restore-green.json에 문자열 color=green을 저장하고 act 8·capture 8로 config_restored.json을 만드세요. 외부 설정까지 별도로 복구하고 v2·green 응답, 원래 정상 Pod·비교군 보존을 확인합니다. Deployment 롤백과 외부 설정 복구가 다른 조작인 이유를 앞 기록으로 설명하세요.

참고

과제의 note=reviewed 같은 표현은 필드와 값 설명입니다. 파일은 형식 예시처럼 올바른 JSON으로 작성하세요.
true·false는 따옴표 없는 불리언입니다. revision은 문자열이며 반드시 정상 v2 관측에서 읽습니다.
capture는 실제 조건이 수렴하기를 기다립니다. 6회의 Service 응답은 학습용 표본이지 장기간 가용성 보증이 아닙니다.
완료한 관측·입력은 보존하세요. prepare는 없는 이전 단계만 채우며 현재 단계의 답이나 기존 오답을 덮지 않습니다.
도중에 기록이 끊기면 자동 초기화하지 않습니다. 특히 롤백 완료 기록이 사라진 상태에서 현재 v2라는 이유로 과거 성공을 재구성하지 않습니다.
그 경우 필요한 파일을 보관한 뒤 새 실습을 시작하세요. 동일 VM에서 모든 이력을 초기화하는 명령은 제공하지 않습니다.
채점은 60초, 단계 준비는 90초 예산입니다. 정상 기동이나 준비 실패의 기한 대기는 capture에서 수행합니다.
기록 해시는 우발적인 파일 변경 탐지이며 VM root에 대한 원격 증명이나 보안 보증이 아닙니다.
공식 근거: [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) ·
[ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/).

단계 8개

1. 정상 버전의 선언과 실행 증거
2. 객체 주석은 롤아웃이 아니다
3. 설정 변경과 실행 중 환경변수
4. 새 템플릿이 실제로 배포된 증거
5. 새 버전이 살아 있지만 준비되지 않았다
6. 진도 기한 초과는 자동 롤백이 아니다
7. 조사한 revision으로 수동 롤백
8. 외부 설정까지 별도로 복구