Argo Rollout 을 사용한 블루/그린 배포

감자 23.12.11

8,296 31 1

facebook twitter kakao link

31 1

facebook twitter kakao link

DEVOTEE 요약: 블루/그린 배포는 신규 버전을 기존 버전과 동일한 환경에 구성하여 테스트 이후 신규 버전으로 전환하는 배포 방식입니다. 장점으로는 테스트 후 버전 변경이 가능하며, 빠른 롤백이 가능하다는 점이 있습니다. 반면 Argo CD를 이용하는 이유는 롤링 업데이트의 제어가 어려운 단점을 보완하기 위함이며, 또한 Argo Rollout를 사용하면 블루/그린 업데이트 전략을 통한 자동 롤백이 가능합니다.

Background

Blue/Green 배포란?
Blue를 구버전, Green을 새로운 버전으로 가정한다면, 운영 환경에 기존 버전인 Blue와 동일하게 새로운 Green 버전의 인스턴스를 구성하고,
테스트를 완료 후 라이브 트래픽을 로드밸런서를 통해 새로운 버전으로 전환하는 형태의 배포 방식입니다.
장점:
- 새로운 버전을 구버전과 동일한 운영 환경으로 인스턴스를 구성하기 때문에 실제 운영 환경에서 새로운 버전을 테스트 후 버전을 바꿀 수 있는 장점이 있고
  트래픽을 다시 구버전으로 돌릴 수 있으므로 빠른 롤백이 가능합니다.
단점:
- Blue/Green 배포를 위해서는 시스템 자원이 두 배로 필요로하기 때문에 비용등의 단점이 있을 수 있습니다.
왜 Argo CD 를 이용해서 Blue/Green 배포를 해야 하는가?
K8S의 기본적인 배포 방식: Rolling update
- 롤링 업데이트란 새 버전을 배포하면서, 새 버전 파드를 하나씩 늘려가고 기존 버전의 파드를 하나씩 줄여나가는 방식입니다.
- 무중단 배포 라고도 합니다.
- 이전 버전과 새로운 버전이 공존하는 시간이 발생한다는 단점이 있습니다.
단점:
- Rollout 속도에 대한 제어가 어렵고
- 새로운 버전으로 트래픽 흐름을 제어할 수 없으며
- 업데이트 진행을 중단할 수 있지만, 업데이트를 자동으로 중단하고 롤백하는 등의 심화된 기능이 없습니다.
Blue/Green 배포시 발생하는 문제:
- blast radius(문제 발생시 그로 인한 영향 범위)에 대한 제어가 없고
- 공격적으로 Rollout 할 수 있으며
- 실패 시 자동 롤백을 제공하지 않으므로 위험합니다.
Argo Rollout 을 사용한다면?
- Blue/Green update 전략을 사용 가능하고
- 자동 롤백이 가능합니다

Installation

minikube start
kubectl create namespace argo-rollouts
kubectl get all -n argo-rollouts

Untitled 1.png

Kubectl 에 argo-rollout plugin 설치합니다.

# M1 mac 기준
# Intel mac 의 경우 amd64로 설치
curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-darwin-arm64
chmod +x ./kubectl-argo-rollouts-darwin-arm64
sudo mv ./kubectl-argo-rollouts-darwin-arm64 /usr/local/bin/kubectl-argo-rollouts
kubectl argo rollouts version

Blue/Green 서비스 배포

우선 rollout.yaml 을 작성하여 서비스를 배포하겠습니다.

ref: https://gomgomshrimp.oopy.io/posts/2

strategy: 하위에 배포 전략을 선택하며 여기서는 blueGreen을 명시

blueGreen
- activeService: 현재 운영 중인 application에 연결될 서비스
- previewService: 변경될 application에 연결될 서비스

# rollout.yaml
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollout-bluegreen
spec:
  replicas: 2
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: rollout-bluegreen
  template:
    metadata:
      labels:
        app: rollout-bluegreen
    spec:
      containers:
      - name: rollouts-demo
        image: argoproj/rollouts-demo:blue
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
  strategy:
    blueGreen:
      activeService: rollout-bluegreen-active
      previewService: rollout-bluegreen-preview
      autoPromotionEnabled: false
 
---
kind: Service
apiVersion: v1
metadata:
  name: rollout-bluegreen-active
spec:
  type: NodePort
  selector:
    app: rollout-bluegreen
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
    nodePort: 30081
 
---
kind: Service
apiVersion: v1
metadata:
  name: rollout-bluegreen-preview
spec:
  type: NodePort
  selector:
    app: rollout-bluegreen
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
    nodePort: 30082

https://github.com/argoproj/rollouts-demo 에서 제공하는 데모용 이미지를 사용하였고, 사각형 타일들의 색 (Blue/Green) 이 변경되는 데모입니다.

Pod 생성

kubectl apply -f rollout.yaml

생성된 pod 확인

kubectl argo rollouts get rollout rollout-bluegreen --watch

Red box 는 Rollout-pod-template-hash 를 나타냅니다. 두 개의 pod이 동일한 replicaset 과 연결된 것을 확인할 수 있습니다.

# service 확인
# kubectl get svc 명령어의 IP 로 접근할 수 없는건 minikube 클러스터를 따로 사용하고 있기 때문
# 포트프록시를 따로 설정하기 귀찮기 때문에 아래 방식으로 웹브라우저접근
minikube service rollout-bluegreen-active
minikube service rollout-bluegreen-preview

Untitled 6.png

Untitled 7.png

Untitled 8.png

양쪽 다 Blue 로 배포되어 있음을 알 수 있습니다.

이제 Rollout의 이미지 버전을 Blue -> Green 으로 변경하여 재배포합니다. (rollout.yaml 파일 수정)

# rollout.yaml 에서 line 18 수정
        # image: argoproj/rollouts-demo:blue
        image: argoproj/rollouts-demo:green

kubectl apply -f rollout.yaml

Untitled 9.png

Untitled 11.png

Untitled 10.png

Preview 가 Green 으로 변경된 것을 확인할 수 있습니다.

이렇게 Green 버전 테스트를 마쳤다면, 최종으로 Green 버전으로 변경하는 작업을 수행합니다.

만약 yaml 파일에서 autoPromotionEnabled: true 옵션을 사용했다면 자동으로 Green 이 최종 적용된다
작업자의 승인이 있어야 교체가 발생되도록 하는 옵션이므로 안정성을 위해서 false 로 놓는 것이 좋다.
옵션에 따라서 특정 시간이 지난 후 자동 교체되도록 할 수 있음
- → autoPromotionSeconds: 20 등의 옵션

kubectl argo rollouts promote rollout-bluegreen

Untitled 12.png

Revision 1 이 완전히 종료된 것을 볼 수 있습니다.

Untitled 13.png

Active 와 Preview 모두 Green 버전으로 배포된 것을 확인했습니다.

Rollback

배포한 Green 에서 뒤늦게 문제가 발견되어 rollback 을 시도하는 상황을 살펴보겠습니다.

kubectl argo rollouts undo rollout-bluegreen

Untitled 14.png

Untitled 15.png

아주 간단하게 rollback 이 가능합니다.

References

https://gomgomshrimp.oopy.io/posts/2

https://ahnseungkyu.com/309

#Kubernetes

등록

DEVOTEE를 활성화 시키면
지금 작성한 댓글에 AI가 댓글을 달아줍니다.

익명

감자 님의 최신 블로그

LLaDA: Diffusion language model과 LLM reversal curse

몇 달 전에 Gemini Diffusion 모델이라는 게 나왔다는 뉴스를 봤다. 일단 첫 번째로 Diffusion으로 어떻게 language model을 만든거지? 가 궁금했고, 두 번째로는 데모 비디오를 봤는데 미친듯이 빠른 속도가 눈에 띄었다. (꼭 데모 비디오 보시길!) 그래서 한번 근간이 되는 논문을 읽어보기로 했다. Alibaba Ant group 에서 써낸 Large Language Diffusion Models, 일명 LLaDA 라는 모델을 제안한 논문이 되겠다 (근데 마지막 A가 제목에는 없음...Large Language diffusion with mAsking 라고 함) 꽤 재미있게 읽은데다가, 중간에 LLM reversal curse 라는 개념...
Think-fusion 의 여러가지 방식 (feat. DeepSeek-V3.1, GPT-5)

2025년 LLM 필드에서 가장 중요한 키워드 하나를 꼽으라면 바로 ＇Reasoning＇일 것입니다. Test-time-computing을 통해서 LLM은 사람처럼 생각하는 과정을 거쳐 답변을 이끌어냈고, 이는 다양한 벤치마크 성능을 극적으로 끌어올렸습니다. 하지만 이 Reasoning 모델은 일반 사용자들 (단순한 태스크에 LLM을 적용하려는) 에게는 큰 영향을 주지 못했습니다. 금방 대답할 수 있는 질문들에도 쓸데없는 사고과정을 거치면서 답변을 기다리는 사용자들을 지치게 만들곤 했기 때문입니다. 그래서 제안된 방식 중 하나가 바로 Think-fusion입니다. 이전 블로그 글에서 Qwen3에 적용된 Hybrid think mode 에 대해서 살펴본 바 있습니다...
NVIDIA Isaac Sim 으로 배우는 Physical AI (3회차 모임)

안녕하세요, Devocean OpenLab NVIDIA Isaac Sim 으로 배우는 Physical AI에 참여하고 있는 조재경입니다. 3회차 스터디는 T타워 1층에 있는 T-library 에서 진행하였습니다. 상기님도 와주셔서 저희를 응원해주셨네요!! 이번 3회차에는 1) 로봇을 제어하기 위한 미들웨어인 ROS2의 기초와 2) 유저의 발화만으로 로봇을 컨트롤하여 원하는 곳으로 이동시키기 위해 제안된 효율적 방법론인 ReMEMbR 에 대해서 알아보았습니다. ROS2의 기초는 스터디 대장님인 유석님께서 설명해 주셨습니다. 아주 명쾌한 설명에 무릎을 탁 치면서 감탄하며 들었네요. ReMEMbR는 제가 세미나 형식으로 준비해서 발표를 해보았는데요. 오랜만에 로봇 관련...
Qwen3 의 Hybrid thinking mode

2025년 4월 29일 새벽에 Alibaba의 Qwen3 가 릴리즈되었다. Qwen3 공식 블로그 Technical report 가 공개되지 않고, 블로그로만 공개되었기 때문에 학습이 어떻게 이루어졌는지는 아주 제한적으로 공개되었다. 모델은 총 6개로 MoE 모델 2개와 Dense 모델 6개로 구성되었다. MoE 모델은 235B (22B activate), 30B (3B activate), Dense 모델은 32B, 14B, 8B, 4B, 1.7B, 0.6B 의 사이즈다. 블로그 글에 따르면 각각 가장 큰 모델만 학습한 뒤, strong-to-weak distillation 을 통해 나머지 모델들을 학습한 것으로 보인다. 아마도 base model 들은 pruni...

목록으로

DEVOCEAN

로그인 선택

미리보기

커뮤니티

글 등록

임시저장함

데보션 블로그 게재 요청