[cicd] 5주차 - Argo CD

안녕하세요, CICD 학습을 위해 CloudNetaStudy 스터디 모임을 통해 진행한 내용을 정리하였습니다.

 

5주차는 [Argo CD] 3~5장(184p) - Argo CD 운영, 접근 제어, App of apps 패턴에 대해 중점적으로 학습합니다. 

 

 

[실습환경]

• kind k8s 배포: kind create cluster 명령으로 myk8s 클러스터를 생성하며, control-plane 노드에 80, 443, 30000~30003 포트 매핑을 설정
• 관찰 도구: kube-ops-view를 NodePort: 30001로 배포하여 클러스터 상태를 시각적으로 모니터링함
• NGINX Ingress 배포:
  • ingress-nginx를 배포하고, 호스트 포트 80과 443을 Ingress Controller 파드로 전달하도록 설정
  • 배포 시 ingress-ready: "true" 레이블이 있는 노드에만 스케줄링되도록 설정

 

kind k8s 배포 실습

# kind k8s 배포
kind create cluster --name myk8s --image kindest/node:v1.32.8 --config - <<EOF
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
  labels:
    ingress-ready: true
  extraPortMappings:
  - containerPort: 80
    hostPort: 80
    protocol: TCP
  - containerPort: 443
    hostPort: 443
    protocol: TCP
  - containerPort: 30000
    hostPort: 30000
  - containerPort: 30001
    hostPort: 30001
  - containerPort: 30002
    hostPort: 30002
  - containerPort: 30003
    hostPort: 30003
EOF

# kube-ops-view
helm repo add geek-cookbook https://geek-cookbook.github.io/charts/
helm install kube-ops-view geek-cookbook/kube-ops-view --version 1.2.2 --set service.main.type=NodePort,service.main.ports.http.nodePort=30001 --set env.TZ="Asia/Seoul" --namespace kube-system

# kube-ops-view 접속 URL 확인 (1.5 , 2 배율)
open "http://127.0.0.1:30001/#scale=1.5"
open "http://127.0.0.1:30001/#scale=2"

 

 

ingress-nginx 배포 및 Argo CD 설치

• TLS 인증서 생성: argocd.example.com 도메인에 대한 자체 서명된 TLS 키/인증서를 생성
• TLS Secret 생성: 생성된 인증서를 사용하여 argocd 네임스페이스에 argocd-server-tls Secret을 생성 (Argo CD Helm 차트에서 기본적으로 참조하는 시크릿 이름)
• Helm 설치 및 Ingress 설정:
  • argocd-values.yaml을 사용하여 Argo CD를 Helm으로 설치
  • Ingress를 활성화하고, nginx.ingress.kubernetes.io/ssl-passthrough: "true" 어노테이션을 설정하여 Ingress에서 TLS를 종료하지 않고 Argo CD 서버로 전달(SSL Passthrough)
• 접속 확인: 로컬 hosts 파일에 127.0.0.1 argocd.example.com을 추가하여 HTTPS로 Argo CD 웹 UI에 접속할 수 있도록 설정
• 초기 비밀번호: argocd-initial-admin-secret에서 Base64 디코딩하여 admin 계정의 초기 비밀번호를 확인

# 노드 라벨 확인
kubectl get nodes myk8s-control-plane -o jsonpath={.metadata.labels} | jq
...
  "ingress-ready": "true",
...

# NGINX ingress 배포
## The manifests contains kind specific patches to forward the hostPorts to the ingress controller, 
## set taint tolerations and schedule it to the custom labelled node.
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/kind/deploy.yaml
-------------------------
## 호스트 포트 80,443 사용
ports:
- containerPort: 80
  hostPort: 80
  name: http
  protocol: TCP
- containerPort: 443
  hostPort: 443
  name: https
  protocol: TCP
...

## nodeSelector 로 배포 노드 지정
nodeSelector:
  ingress-ready: "true"
  kubernetes.io/os: linux

## taint 예외 tolerations 설정
tolerations:
- effect: NoSchedule
  key: node-role.kubernetes.io/master
	operator: Equal
- effect: NoSchedule
  key: node-role.kubernetes.io/control-plane
  operator: Equal
-------------------------

# ingress 배포 확인
kubectl get deploy,svc,ep ingress-nginx-controller -n ingress-nginx
kubectl describe -n ingress-nginx deployments/ingress-nginx-controller
...
  --publish-status-address=localhost
...

# control-plane 노드(실제로는 컨테이너)에 IPTABLES에 80,443은 ingress-nginx 파드로 전달 규칙 확인 # 10.244.0.7은 ingress-nginx 파드의 IP
docker exec -it myk8s-control-plane bash
root@myk8s-control-plane:/# iptables -t nat -L -n -v | grep '10.244.0.7'
    0     0 DNAT       6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80 to:10.244.0.7:80
    0     0 DNAT       6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443 to:10.244.0.7:443
...
exit

 

Argo CD 설치 + Ingress by Helm - Ingress , Docs , Argocd-Issue

Ingress tls secret is required since v6 · Issue #2477 · argoproj/argo-helm

# TLS 키·인증서 생성 : 공통 이름이 argocd.example.com 이어야 합니다
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout argocd.example.com.key \
  -out argocd.example.com.crt \
  -subj "/CN=argocd.example.com/O=argocd"

ls -l argocd.example.com.*
-rw-r--r--@ 1 gasida  staff  1184 Nov  8 23:10 argocd.example.com.crt
-rw-------@ 1 gasida  staff  1704 Nov  8 23:10 argocd.example.com.key

openssl x509 -noout -text -in argocd.example.com.crt
...
        Issuer: CN=argocd.example.com, O=argocd
        Validity
            Not Before: Nov  8 14:10:14 2025 GMT
            Not After : Nov  8 14:10:14 2026 GMT
        Subject: CN=argocd.example.com, O=argocd
        ...
            X509v3 Basic Constraints: critical
                CA:TRUE

# Argo CD가 자신의 TLS를 쓰도록 argocd 네임스페이스에 tls 타입 시크릿 생성
kubectl create ns argocd

# tls 시크릿 생성 : key/crt 파일이 로컬에 있어야 함
kubectl -n argocd create secret tls argocd-server-tls \
  --cert=argocd.example.com.crt \
  --key=argocd.example.com.key

kubectl get secret -n argocd
NAME                TYPE                DATA   AGE
argocd-server-tls   kubernetes.io/tls   2      7s

# SSL-Passthrough : The 'tls: true' option will expect that the 'argocd-server-tls' secret exists as Argo CD server loads TLS certificates from this place.
## certificate.enabled=true 는 cert-manager가 있을 때만 동작하는 것 같네요
## 이번 실습환경 구성에서는 argocd-server-tls 를 사전에 만들어서 알아서 참조하는 구조네요. (다른 시크릿 사용시 certificateSecret 사용)
cat <<EOF > argocd-values.yaml
global:
  domain: argocd.example.com

# TLS certificate configuration via cert-manager # 해당 부분은 빼도 되겠네요
certificate: 
  enabled: true

server:
  ingress:
    enabled: true
    ingressClassName: nginx
    annotations:
      nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
      nginx.ingress.kubernetes.io/ssl-passthrough: "true"
    tls: true
EOF

# 설치 : Argo CD v3.1.9 , (참고) 책 버전 Argo CD v2.1 ~ v2.2
# https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/values.yaml
helm repo add argo https://argoproj.github.io/argo-helm
helm install argocd argo/argo-cd --version 9.0.5 -f argocd-values.yaml --namespace argocd

# 각 구성요소 확인
kubectl get-all -n argocd
kubectl get pod,ingress,svc,ep,secret,cm -n argocd

kubectl describe ingress -n argocd argocd-server
kubectl get ingress -n argocd argocd-server # 아래 address 에 localhost 는 배포 후 sync 까지 다소 시간 소요
NAME            CLASS   HOSTS                ADDRESS     PORTS     AGE
argocd-server   nginx   argocd.example.com   localhost   80, 443   6m42s

kubectl get ingress -n argocd argocd-server -o yaml | kubectl neat |yq 
...
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/ssl-passthrough: "true"
  ...
  name: argocd-server
  namespace: argocd
spec:
  ingressClassName: nginx
  rules:
    - host: argocd.example.com
      http:
        paths:
          - backend:
              service:
                name: argocd-server
                port:
                  number: 443
            path: /
            pathType: Prefix
  tls:
    - hosts:
        - argocd.example.com
      secretName: argocd-server-tls
# tls.secretName은 Ingress 자체에 인증서를 붙이는 것처럼 보이지만, passthrough 모드에서도 일부 chart/환경은 이 값(시크릿 존재)을 
# 요구할 수 있으니(특히 Argo Helm chart) 시크릿을 동일 네임스페이스에 만들어 두는 것이 안전합니다.


# 도메인 설정
## macOS의 /etc/hosts 파일 수정
echo "127.0.0.1 argocd.example.com" | sudo tee -a /etc/hosts
cat /etc/hosts

## C:\Windows\System32\drivers\etc\hosts 관리자모드에서 메모장에 내용 추가
127.0.0.1 argocd.example.com


# 접속 확인
curl -vk https://argocd.example.com/
kubectl -n ingress-nginx logs deploy/ingress-nginx-controller
kubectl -n argocd logs deploy/argocd-server

# 최초 접속 암호 확인
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d ;echo
38L2ZmXne7jIaRSZ

# Argo CD 웹 접속 주소 확인 : 초기 암호 입력 (admin 계정)
open "http://argocd.example.com"
open "https://argocd.example.com"

 

 

[접근제어]

1. Argo CD 사용자 계정 및 비밀번호 관리

Argo CD 설치 시 생성되는 기본 admin 계정을 관리하고, 새로운 로컬 사용자를 생성하여 관리 권한을 위임하는 과정을 설명합니다.

 

사용자 계정 관리

• admin 계정: 초기 비밀번호를 확인하고 argocd account update-password를 통해 새 비밀번호로 변경. 보안을 위해 최종적으로는 admin.enabled: "false"로 비활성화하는 것을 권장.

      - 초기 비밀번호 확인: 아래 명령어를 통해 Secret에서 Base64 디코딩하여 확인

$ kubectl get secret -n argocd argocd-initial-admin-secret -o jsonpath='{.data.password}' | base64 -d

 

     - 비밀번호 변경: UI의 User-Info 탭 또는 CLI 명령어 $ argocd account update-password를 사용

#
argocd account update-password
*** Enter password of currently logged in user (admin): fNdOLSMFO83X1s8p%
*** Enter new password for user admin: qwe12345
*** Confirm new password for user admin: qwe12345
Password updated
Context 'argocd.example.com' updated

# (참고) Update the password for user foobar
argocd account update-password --account foobar

 

    - 보안 권장 사항: 초기 구성 후에 로컬 사용자 계정으로 전환하거나 SSO를 통합한 후 admin.enabled: "false" 설정으로 관리자 계정을 비활성화하는 것을 권장

• 로컬 사용자 생성 (alice):
  
  • 사용자 추가: argocd-cm ConfigMap을 편집하여 accounts.alice: apiKey, login을 추가(apiKey는 API 키 생성 권한, login은 UI 로그인 권한).
  • 비밀번호 설정: $ argocd account update-password --account alice --current-password <현재_관리자_비밀번호> --new-password <새_비밀번호> 명령으로 새 사용자의 비밀번호를 설정
  • 확인: $ argocd account list 및 argocd-secret Secret에서 계정 정보 및 암호 해시 저장 여부를 확인

# alice 사용자 추가 : ui, cli 
kubectl get cm -n argocd argocd-cm -o yaml
KUBE_EDITOR="nano"  kubectl edit cm -n argocd argocd-cm
  # add an additional local user with apiKey and login capabilities
  #   apiKey - allows generating API keys
  #   login - allows to login using UI
  accounts.alice: apiKey, login
  # disables user. User is enabled by default
  # accounts.alice.enabled: "false"
...

 

# 사용자 확인
argocd account list
NAME   ENABLED  CAPABILITIES
admin  true     login
alice  true     apiKey, login

# if you are managing users as the admin user, <current-user-password> should be the current admin password.
argocd account update-password \
  --account alice \
  --current-password qwe12345 \
  --new-password alice12345
Password updated
# 혹은 argocd account update-password --account alice : 대화형 셸 사용 , 비밀번호가 셸 히스토리에 저장되지 않음.

# 변경된 내용 확인 : argocd-secret 에 새로운 사용자에 대한 값 추가 확인
kubectl get secret -n argocd argocd-secret -o jsonpath='{.data}' | jq
{
  "accounts.alice.password": "JDJhJDEwJE5QNkVISVdzR2dJUHBkbmNUVHA1WHV6Z0ZYL3JaZzY5UFE2ajlXaE9lLmtrRG9mV0VzUVRt",
  "accounts.alice.passwordMtime": "MjAyNS0xMS0wOVQwNToyMToxNlo=",
  "accounts.alice.tokens": "bnVsbA==",
  "admin.password": "JDJhJDEwJFBGbjFmM1dKZE51ZnpDcHYvTXRyZnVTejI3M2NGWklZLjBqQVdqZTZYMU96QXBJa1JiVE02",
  "admin.passwordMtime": "MjAyNS0xMS0wOVQwNToxMjo1OVo=",
  "server.secretkey": "SWhWbjd6bDVPUUUybzFHOUZ5NmpqNmhyaWNMemh2ZEt2Y1BRUkZxMW5WUT0="
}

# alice.token 은 아직 값이 없어서 null
kubectl get secret -n argocd argocd-secret -o jsonpath='{.data.accounts\.alice\.tokens}' | base64 -d ; echo
null

 

샘플 애플리케이션 배포 - Guestbook

argocd-example-apps/helm-guestbook at master · argoproj/argocd-example-apps

# guestbook helm 차트 애플리케이션 생성
cat <<EOF | kubectl apply -f -
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
  finalizers:
  - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    helm:
      valueFiles:
      - values.yaml
    path: helm-guestbook
    repoURL: https://github.com/argoproj/argocd-example-apps
    targetRevision: HEAD
  syncPolicy:
    automated:
      enabled: true
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true
  destination:
    namespace: guestbook
    server: https://kubernetes.default.svc
EOF

#
kubectl get applications -n argocd guestbook
kubectl get applications -n argocd guestbook -o yaml | kubectl neat | yq
kubectl get pod,svc,ep -n guestbook

 

- Argo CD RBAC (역할 기반 접근 제어) 설정

사용자에게 Argo CD 리소스에 대한 접근 권한을 제한하기 위한 RBAC 설정 방법

• RBAC 기본:
  • Argo CD는 자체 사용자 관리 시스템 대신 기본 admin 사용자만 제공하며, RBAC를 사용하려면 SSO 또는 로컬 사용자 설정이 필요합니다.
  • 기본 내장 역할: role:readonly (모든 리소스 읽기 전용), role:admin (무제한 액세스).
  • 기본 정책: 사용자가 인증되면 argocd-rbac-cm ConfigMap의 policy.default에 지정된 역할이 부여됩니다.

• 읽기 전용 기본 정책 설정:
  • argocd-rbac-cm ConfigMap을 편집하여 policy.default: role:readonly로 설정합니다. 이로써 alice와 같은 일반 사용자는 기본적으로 리소스에 대한 읽기 권한만 갖게 됩니다.

# rbac 설정
kubectl get cm -n argocd argocd-rbac-cm -o jsonpath='{.data}' | jq
{
  "policy.csv": "",
  "policy.default": "",
  "policy.matchMode": "glob",
  "scopes": "[groups]"
}

#
KUBE_EDITOR="nano" kubectl edit cm -n argocd argocd-rbac-cm
  policy.default: role:readonly

• 서비스 어카운트 및 API Key:
  • CI/CD 파이프라인과 같은 자동화를 위해 login 기능을 제거하고 apiKey만 활성화한 로컬 서비스 계정(gitops-ci)을 생성합니다.
  • 토큰 생성 권한 부여: alice 사용자에게 서비스 계정의 토큰을 생성할 수 있도록 argocd-rbac-cm에 role:user-update 역할을 정의하고 alice에게 할당합니다.
  • 토큰 생성: $ argocd account generate-token -a gitops-ci 명령으로 API 토큰을 생성하고, 이 토큰을 사용하여 자동화에 필요한 작업을 수행할 수 있습니다.
  • 프로젝트 역할과 토큰:
    • AppProject는 애플리케이션 정의에 제약 조건을 적용하고 역할(Role)을 통해 권한을 제한하는 방식입니다.
    • 새로운 sample-apps 프로젝트를 생성하고, 이 프로젝트 내의 애플리케이션에 대해 read-sync 역할(읽기 및 동기화 권한만 허용)을 정의합니다.
    • 프로젝트 역할에 대한 토큰을 $ argocd proj role create-token sample-apps read-sync 명령으로 생성하여, 특정 애플리케이션에 대한 제한된 범위의 동기화 작업에 사용합니다.

3. Keycloak을 사용한 Argo CD SSO 통합 (OpenID Connect) 

Keycloak은 OAuth 2.0, OIDC, SAML 2.0을 지원하는 오픈 소스 ID 및 접근 관리 도구로, Argo CD에 SSO 기능을 통합하는 방법

• Keycloak 소개:
  • SSO 제공: 한 번의 인증으로 여러 애플리케이션에 접근 가능.
  • 표준 프로토콜: OAuth 2.0, OpenID Connect, SAML 2.0 지원.
  • 보안: 사용자 자격 증명에 직접 접근하지 않고 보안 토큰을 제공하여 보안 수준 향상.
• Keycloak 기본 구성:
  • Keycloak 컨테이너 실행 후, 관리자 웹 콘솔에서 새로운 Realm(myrealm 예시)을 생성합니다. Realm은 서로 완전히 독립된 영역입니다.
  • Realm 내에서 사용자(keycloak 예시), 그룹, Realm Role(myrole 예시) 등을 생성하고 사용자에게 할당합니다.
• Argo CD 클라이언트 설정:
  • Keycloak에 Argo CD를 위한 Client(argocd)를 생성하고, Valid redirect URIs(https://argocd.example.com/auth/callback 등)를 설정합니다.
  • 생성된 Client의 Client Secret을 메모합니다.
• Argo CD OIDC 구성:
  • Keycloak Client Secret을 Argo CD의 argocd-secret에 설정
  • argocd-cm ConfigMap에 OIDC 설정 블록을 추가

    oidc.config: |
      name: Keycloak
      issuer: http://<KEYCLOAK_IP>:8080/realms/master
      clientID: argocd
      clientSecret: <CLIENT_SECRET>
      requestedScopes: ["openid", "profile", "email"]
    

  • YAML
     
  • Argo CD 서버를 재시작하여 OIDC 인증을 활성화
  • 그룹 기반 RBAC 연동: Keycloak에서 그룹 정보를 가져와 Argo CD의 RBAC 정책에 매핑하려면 requestedScopes에 groups를 추가해야 합니다.
• SSO 흐름 (OpenID Connect 권한 부여 코드 흐름):
  1. 애플리케이션(Argo CD)이 인증 요청을 준비하고 사용자를 Keycloak으로 리디렉션합니다.
  2. Keycloak에서 사용자가 인증을 수행합니다.
  3. Keycloak은 권한 부여 코드를 Argo CD에 반환합니다.
  4. Argo CD는 권한 부여 코드를 ID 토큰(사용자 신원 확인)과 액세스 토큰으로 교환하여 인증된 세션을 설정합니다.

 

[ Argo Rollout]

1. Argo Rollouts 소개 및 특징

Argo Rollouts는 쿠버네티스 네이티브 배포 객체(Deployment)의 한계를 극복하고 고급 배포 전략을 제공하는 쿠버네티스 컨트롤러 및 CRD(Custom Resource Definition)입니다.

 

주요 기능 및 장점

기능	설명
고급 배포 전략	블루-그린, 카나리, 카나리 분석, 실험, 점진적 전달 등의 기능을 제공합니다.
트래픽 제어	NGINX, ALB, Istio 등 인그레스 컨트롤러 및 서비스 메시와 통합하여 가중치 기반 트래픽 시프팅을 통해 새 버전으로의 트래픽 전환을 점진적으로 제어합니다.
자동화 및 분석	Prometheus, Datadog 등 다양한 메트릭 제공업체와 통합하여 KPI(핵심 성과 지표)를 쿼리하고 해석합니다. 이를 통해 자동 롤백 및 프로모션을 실행할 수 있습니다.
수동 개입	업데이트 진행 중 수동 승인(Manual Judgement) 기능을 제공하여 운영자가 개입할 수 있습니다.

 

기존 쿠버네티스 Deployment의 한계

• 롤아웃 속도에 대한 제어가 거의 없음.
• 새 버전으로의 트래픽 흐름 제어 불가능.
• 외부 메트릭 쿼리 및 분석 기능 부재.
• 업데이트 중단 및 자동 롤백 기능 부재.

 

2. Argo Rollouts 동작 및 아키텍처

Argo Rollouts는 표준 Deployment와 유사하게 동작하지만, 고급 배포 전략을 처리하는 데 특화되어 있습니다.

 

동작 원리

• ReplicaSets 관리: Argo Rollouts 컨트롤러는 Deployment와 마찬가지로 ReplicaSets의 생성, 확장, 삭제를 관리합니다.
• Rollout 리소스: 배포는 Rollout CRD를 통해 정의됩니다. spec.template이 변경되면 컨트롤러는 새로운 ReplicaSet을 도입하고, spec.strategy에 설정된 전략(예: 카나리)을 사용하여 기존 버전에서 새 버전으로의 전환 방식을 결정합니다.
• 안정적인 ReplicaSet: 새 ReplicaSet이 확장되고 분석을 통과하면 "안정적"으로 표시됩니다. 롤아웃 도중 템플릿 변경이 발생하면 이전 신규 ReplicaSet은 축소되고 업데이트된 템플릿을 반영하는 새로운 Rollout이 다시 진행됩니다.

아키텍처 구성 요소 (Docs 참조)

• Argo Rollouts Controller: 핵심 로직을 수행하는 컨트롤러.
• Rollout resource: 고급 배포 전략을 정의하는 CRD.
• Replica sets for old and new version: 이전 및 새 버전의 파드를 관리하는 ReplicaSet.
• Ingress/Service: 트래픽 라우팅을 담당하는 쿠버네티스 서비스 및 인그레스 객체.
• AnalysisTemplate and AnalysisRun: 메트릭을 쿼리하고 배포의 건전성을 평가하는 분석 리소스.
• Metric providers: Prometheus, Datadog 등 메트릭 데이터 소스.
• CLI and UI: Argo Rollouts를 관리하고 시각화하는 커맨드 라인 도구 및 대시보드.

 

3. 설치 및 카나리 배포 테스트

Argo Rollouts를 설치하고 카나리 전략을 사용한 예제 배포를 테스트합니다.

 

Argo Rollouts 설치

# 네임스페이스 생성 및 파라미터 파일 작성
kubectl create ns argo-rollouts
cat <<EOT > argorollouts-values.yaml
dashboard:
  enabled: true
  service:
    type: NodePort
    nodePort: 30003
EOT

# 설치
helm install argo-rollouts argo/argo-rollouts --version 2.40.5 -f argorollouts-values.yaml --namespace argo-rollouts

# 확인
kubectl get all -n argo-rollouts
kubectl get crds

# Argo rollouts 대시보드 접속 주소 확인
echo "http://127.0.0.1:30003"
open "http://127.0.0.1:30003"

 

 

ArgoCD Extension 설치 (선택 사항) : Argo CD의 기본 기능을 확장 https://github.com/argoproj-labs/rollout-extension - Blog 이는 Argo CD UI에서 Rollouts 기능을 시각적으로 관리할 수 있도록 해줍니다.

#
cat <<EOF > argocd-values.yaml
global:
  domain: argocd.example.com

certificate:
  enabled: true

server:
  ingress:
    enabled: true
    ingressClassName: nginx
    annotations:
      nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
      nginx.ingress.kubernetes.io/ssl-passthrough: "true"
    tls: true
  extensions:
    enabled: true
    extensionList:
      - name: rollout-extension
        env:
          - name: EXTENSION_URL
            value: https://github.com/argoproj-labs/rollout-extension/releases/download/v0.3.7/extension.tar
EOF
helm upgrade -i argocd argo/argo-cd --version 9.0.5 -f argocd-values.yaml --namespace argocd

# initContainer 환경변수 EXTENSION_URL에 설치할 extension을 명시하면 됩니다. 
# mainContainer는 initContainer가 설치한 extension을 가져오기 위해 volumeMount로 가져옵니다.
k describe deploy -n argocd argocd-server
...
  Init Containers:
   rollout-extension:
    Image:           quay.io/argoprojlabs/argocd-extension-installer:v0.0.8
    Port:            <none>
    Host Port:       <none>
    SeccompProfile:  RuntimeDefault
    Environment:
      EXTENSION_URL:  https://github.com/argoproj-labs/rollout-extension/releases/download/v0.3.7/extension.tar
    Mounts:
      /tmp from tmp (rw)
      /tmp/extensions/ from extensions (rw)
...
  Volumes:
   extensions:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:     
    SizeLimit:  <unset>

 

Deploying a Rollout

카나리 배포 전략을 사용하여 rollout-test 애플리케이션을 배포하고 업데이트합니다.

• Rollout 정의: replicas: 5로 설정하고, 카나리 전략에서 가중치(setWeight)와 일시 중지(pause) 단계를 반복하도록 정의합니다.
  • 예시 단계: setWeight: 20 → pause: {} (수동 승인) → setWeight: 40, pause: {duration: 10} (10초 대기)
• 초기 배포 확인: rollout-demo Rollout이 이미지 버전 blue로 배포되고 ReplicaSet이 생성되었는지 확인합니다.
• Rollout 업데이트: $ kubectl argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:yellow 명령을 통해 컨테이너 이미지를 yellow 버전으로 업데이트합니다.
• Promote (승격): UI 또는 $ kubectl argo rollouts promote rollouts-demo 명령을 통해 다음 카나리 단계로 진행하거나 최종적으로 새 버전으로 완전 전환(프로모션)합니다.

spec:
  replicas: 5
  strategy:
    canary:
      steps:
      - setWeight: 20
      - pause: {}
      - setWeight: 40
      - pause: {duration: 10}
      - setWeight: 60
      - pause: {duration: 10}
      - setWeight: 80
      - pause: {duration: 10}

• App name : rollout-test
• project name : default
• sync policy : manual
• set deletion finalizer : check
• auto-create namespae : check
• Repo URL : https://github.com/gasida/my-sample-app
• path : argo-rollouts
• Destination : https://kubernetes.default.svc
• Namespace : test
• ⇒ SYNC

# Run the following command to deploy the initial Rollout and Service:
mkdir argo-rollouts && cd argo-rollouts
wget https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/basic/rollout.yaml
wget https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/basic/service.yaml
git add . && git commit -m "Add sample yaml" && git push -u origin main

# 확인
kubectl get rollout -n test
kubectl describe rollout -n test

kubectl get pod -l app=rollouts-demo -n test
kubectl get svc,ep rollouts-demo -n test
kubectl get rollouts rollouts-demo -n test -o json | grep rollouts-demo
...
   "image": "argoproj/rollouts-demo:blue"
...

 

Updating a Rollout

# Run the following command to update the rollouts-demo Rollout with the "yellow" version of the container:
\kubectl edit rollouts rollouts-demo -n test
..
     - image: argoproj/rollouts-demo:yellow
...

# 파드 label 정보 확인
watch -d kubectl get pod -l app=rollouts-demo -n test -owide --show-labels

 

 

이 과정을 통해 운영자는 트래픽을 단계적으로 전환하고, 각 단계에서 안정성을 확인(수동 또는 분석 기반)하며 안전하게 새 버전을 배포할 수 있습니다.