Argo Rollouts는 Kubernetes에 점진적 배포 기능을 추가하는 컨트롤러와 사용자 정의 자원이다. 새 버전을 바로 전부 노출하지 않고 블루그린·카나리 방식, 일시 정지, 지표 분석 등을 통해 진행을 제어한다. Git과 클러스터 선언을 맞추는 Argo CD와 목적이 다르며 두 도구를 함께 사용할 수 있다. 공식 개요가 제공 범위를 설명한다.
배포를 단계로 나누기
Rollout은 Pod 템플릿과 복제본을 관리하면서 새 버전의 노출 과정을 조정한다. 블루그린에서는 기존 버전에 연결된 active Service와 새 버전을 확인하는 preview Service를 나눌 수 있다. 준비 조건을 만족하면 active Service의 선택 대상이 새 ReplicaSet으로 바뀐다.
전환 뒤 이전 Pod를 즉시 모두 없애지 않고 잠시 유지하는 이유는 서비스 경로 변경이 전파될 시간을 주기 위해서다. 블루그린 문서는 Service 선택자 변경과 scaleDownDelaySeconds를 설명한다. 이 시간은 모든 장기 요청의 안전을 자동으로 보장하는 값은 아니다.
장점과 한계
새 버전을 미리 확인하고, 관측 지표에 따라 승격을 멈추거나 중단하는 배포를 구성할 수 있다. 단순한 Pod 준비 상태보다 업무에 가까운 지표를 판단 근거로 사용할 수 있다는 장점이 있다. 반면 배포 중 신·구 버전을 함께 실행하므로 여분의 CPU·메모리와 연결 수가 필요하다.
분석 기준이 잘못되거나 관측 데이터가 없으면 자동 판단도 잘못될 수 있다. DB 스키마 변경, 메시지 형식, 세션과 장기 연결은 두 버전이 함께 존재하는 동안 호환되어야 한다. 트래픽을 되돌리는 것이 이미 처리된 업무 데이터를 되돌리는 것은 아니다.
예약 API 블루그린 설정 예시
아래는 완전한 Rollout 파일의 spec.strategy 부분만 발췌한 예시다. reading-room 네임스페이스에 올바른 Pod 템플릿과 reservation-active·reservation-preview Service가 준비되었다고 가정한다. 컨트롤러와 CRD도 미리 설치되어 있어야 한다.
spec:
strategy:
blueGreen:
activeService: reservation-active
previewService: reservation-preview
autoPromotionEnabled: false
scaleDownDelaySeconds: 45autoPromotionEnabled: false는 새 버전이 준비돼도 자동 승격하지 않고 검토 지점을 두겠다는 뜻이다. preview 경로로 예약 조회 등 부작용 없는 기능을 확인하고 승격 여부를 판단할 수 있다. 45초는 경로 변경 전파를 고려한 예시값이며 실제 환경의 종료 유예와 요청 특성에 맞춰 정한다.
자주 생기는 오해
preview가 정상이라는 사실만으로 운영 트래픽 전체에서 성능이 충분하다고 단정하지 않는다. 무거운 검증 요청이 공용 데이터베이스에 미치는 영향도 고려한다. 일반 Deployment와 Rollout이 같은 Pod 레이블을 동시에 소유하지 않도록 하고, Service의 선택자를 임의 변경해 컨트롤러와 경쟁하지 않는다.
카나리의 가중치 역시 실제 트래픽 라우터 연동 여부에 따라 의미가 달라질 수 있다. 배포 정의, 실제 엔드포인트, 요청 분포와 오류율을 함께 확인해야 점진적 배포가 의도한 효과를 내는지 판단할 수 있다.