소개
초급 과정의 마지막 챌린지에 도달했습니다. 앞선 실습에서는 Pod, Deployment, Service, 스케일링, 문제 해결 및 롤백을 단계적으로 익혔습니다. 이제 명령어를 하나씩 안내받지 않고, 이러한 개념을 하나의 작은 릴리스 작업에 직접 적용해 보겠습니다.
환경에는 web-app이라는 정상적으로 실행 중인 초기 릴리스가 준비되어 있습니다. 여러분의 목표는 사용 가능한 복제본 3 개와 안정적인 Service 를 유지하면서, 고정된 다음 NGINX 이미지를 배포하는 것입니다. 최종 클러스터 상태와 저장된 매니페스트가 서로 일치해야 챌린지 이후에도 릴리스를 재현할 수 있습니다.
다음 NGINX 버전 릴리스
환경 시작: 이 실습에서는 완전한 Kubernetes 클러스터가 시작됩니다. 컨트롤 플레인, 노드 및 네트워크 구성 요소를 설정하는 데 일반적으로 2～3분이 걸립니다. 환경 로딩이 완료될 때까지 잠시 기다린 후 작업을 시작하세요.
현재 상황
플랫폼 팀이 /home/labex/project/final-release/web-app.yaml에 초기 릴리스를 준비해 두었습니다. 현재 Service web-app 뒤에서 nginx:1.26-alpine을 복제본 3 개로 실행하고 있습니다.
범위
- 기존
web-appDeployment, Service, 매니페스트 및release-check클라이언트를 사용합니다. - 리소스 이름을 변경하거나 셀렉터를 수정하거나 승인된 롤링 업데이트 예산을 변경하지 마세요.
- 고정된 대상 이미지를 사용하세요.
latest와 같은 부동 태그는 승인된 릴리스에 사용할 수 없습니다.
목표
기존 Deployment 를 통해 nginx:1.27-alpine을 배포하고, 실행 중인 클러스터와 Service 액세스 경로 및 저장된 매니페스트를 모두 정상적이고 재현 가능한 상태로 유지하세요.
승인 기준
- Deployment
web-app의 원하는 복제본 수가 정확히 3 개입니다. - 해당 Deployment 의
nginx컨테이너가 고정 이미지nginx:1.27-alpine을 사용합니다. - 롤링 업데이트 예산이
maxUnavailable: 0및maxSurge: 1로 유지됩니다. - 변경 원인 주석에 NGINX 1.27 릴리스가 명확히 설명되어 있습니다.
- Service
web-app이 여전히 Deployment 의 Pod 를 선택하며, 준비된 백엔드가 3 개입니다. - 업데이트된 복제본 3 개가 모두 준비 및 사용 가능 상태이고, 클러스터 내부에서
http://web-app으로 보낸 HTTP 요청이 성공합니다. /home/labex/project/final-release/web-app.yaml에 최종 이미지와 롤아웃 설정이 포함되어 있어, 다시 적용해도 승인된 상태가 유지됩니다.
Kubernetes 상태 확인 및 롤아웃 명령어를 사용하여 릴리스 완료 시점을 판단하세요. 업데이트가 아직 진행 중이라면 첫 번째 kubectl get 출력만 보고 판단하지 말고 완료될 때까지 기다리세요.
힌트
Deployment 의 READY, UP-TO-DATE, AVAILABLE 열, Pod 이미지, 롤아웃 기록 및 Service 의 EndpointSlice 주소를 확인하면 유용합니다.
요약
Kubernetes Deployment 를 통해 고정된 NGINX 이미지를 직접 릴리스하며 이 과정을 마쳤습니다. 명시적인 가용성 예산을 유지하고, 업데이트된 복제본이 모두 준비될 때까지 기다렸으며, Service 가 준비된 백엔드 3 개에 계속 연결되도록 했습니다. 또한 클러스터 내부 요청을 확인하고 승인된 상태를 YAML 에 저장했습니다.
이러한 확인 절차는 초급 단계에서 반복해서 사용할 수 있는 작업 흐름을 구성합니다. 원하는 상태를 선언하고, 적용하고, 컨트롤러의 진행 상황을 관찰하고, 워크로드와 액세스 경로를 검증한 다음, 매니페스트와 클러스터 상태를 일치시키는 방식입니다.
