본문 바로가기
카테고리 없음

ArgoCD Deployment and demo_app

vmguru 2025. 8. 11. 22:15

Argo CD는 실행 중인 애플리케이션을 지속적으로 모니터링하고 현재 라이브 상태를 Git 저장소에 지정된 목표 대상 상태와 비교하는 쿠버네티스 컨트롤러로 구현됩니다. 배포된 애플리케이션의 라이브 상태가 목표 대상 상태와 다를 경우, 동기화되지 않은 것으로 간주됩니다. Argo CD는 이러한 차이를 보고하고 시각화하는 동시에 라이브 상태를 목표 대상 상태로 자동 또는 수동으로 동기화하는 기능을 제공합니다. Git 저장소에서 목표 대상 상태에 적용된 모든 수정 사항은 지정된 대상 환경에 자동으로 적용되고 반영됩니다.

Features

  • 지정된 대상 환경에 애플리케이션 자동 배포
  • 다양한 구성 관리/템플릿 도구 지원(Kustomize, Helm, Jsonnet, 일반 YAML)
  • 여러 클러스터에 관리 및 배포 가능
  • SSO 통합(OIDC, OAuth2, LDAP, SAML 2.0, GitHub, GitLab, Microsoft, LinkedIn)
  • 권한 부여를 위한 멀티테넌시 및 RBAC 정책
  • Git 저장소에 커밋된 모든 애플리케이션 구성으로 롤백/롤애니웨어 가능
  • 애플리케이션 리소스 상태 분석
  • 자동화된 구성 드리프트 감지 및 시각화
  • 애플리케이션을 원하는 상태로 자동 또는 수동으로 동기화
  • 애플리케이션 활동을 실시간으로 볼 수 있는 웹 UI
  • 자동화 및 CI 통합을 위한 CLI
  • 웹훅 통합(GitHub, BitBucket, GitLab)
  • 자동화를 위한 액세스 토큰
  • 복잡한 애플리케이션 롤아웃(예: 블루/그린 및 카나리아 업그레이드)을 지원하는 PreSync, Sync,
  • PostSync 후크
  • 애플리케이션 이벤트 및 API에 대한 감사 추적 호출
  • Prometheus 메트릭
  • Git에서 helm 매개변수를 재정의하기 위한 매개변수 재정의

Quck Installation(/w LB)

Installation with Contour Ingress(HTTPProxy)

  • Non-HA 모드 및 HA 모드 배포 방식에서 선택
  • 경량화된 core 버전 지원(Headless) 지원
  • Cluster-role(cluster-admin access)과 함께 클러스터 레벨 동작 혹은 Namespace 레벨 동작으로 권한 제어 선택

자세한 사항은 아래 설치 페이지 참조

https://argo-cd.readthedocs.io/en/stable/operator-manual/installation/

argocd namespace 생성

kubectl apply -f- << EOF 
apiVersion: v1
kind: Namespace
metadata:
  name: argocd
EOF

기존 tls 인증서 secret으로 생성

  • base64 인코딩된 문자열을 추가
cat <<EOF > tls.yaml
apiVersion: v1
kind: Secret
metadata:
  name: argocd-tls-secret
data:
  tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUU1RENDQTh5Z0F3SUJBZ0lVTGp6eGlXQmRxbDhtRlpOQVlqdkwvSzhaTkhBd0RRWUpLb1pJaHZjTkFRRU4KQlFBd1h6RUxNQWtHQTFVRUJoTUNTMUl4RGpBTUJnTlZCQWdNQlhObGIzVnNNUTR3REFZRFZRUUhEQVZ6Wlc5MQpiREVPTUF3R0ExVUVDZ3dGWlhSbFkyZ3hEREFLQmdOVkJBc01BMlZ1WnpFU01CQUdBMVVFQXd3SmRHRnVlblV1CmJHRmlNQjRYRFRJMU1EY3lPVEF4TkRjeU4xb1hEVE0xTURjeU56QXhORGN5TjFvd2FURUxNQWtHQTFVRUJoTUMKUzFJeERqQU1CZ05WQkFnTUJWTmxiM1ZzTVE0d0RBWURWUVFIREFWVFpXOTFiREVNTUFvR0ExVUVDZ3dEUlc1bgpNUkV3RHdZRFZRUUxEQWhRWlhKemIyNWhiREVaTUJjR0ExVUVBd3dRWVhKbmIyTmtMblJoYm5wMUxteGhZakNDCkFpSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnSVBBRENDQWdvQ2dnSUJBTEFuVnZoMHcybXAzK3ZiSU0wZ2xmRmoKUkhCQWx1eSs2bHJQL2tpZ28yemxmalQ5ZjZhYllMZUlPZ2hPSkpzZHltekU4OUpZY3YxejdKaHJFYVhyUTArNwpMOUlvZHRqMUlOb05TMlZ1MEFWaVp1UGc5RDJhUG5SVDVKdkJ5bk1XZ1VwcWcxcWpwVVcxeHdabDJsNTNGNUl6CkxZYTZLQ2d4N2graU5kTXFGWlBDQ1F6ZUVMVmlhMEluTUZsUyttN3dmSGtpdFlza0tvZ3Fmd0xDbnlCUWdsa0oKYmtzbGNreWRIU0g0OW5Wa3kwQVhDclR1QkJoaktiOHNNajVzSEYrbFh6emFLS2trRWJzV2xnbFd5UlFuUjRBSwpDMGRTcWFlVldiZ2R0UGdXOHNuUS80dUNZUVgvUnZYSWJ6aEljZ09hSHZUTTlOcG5POUl2cTB5OVJEOWNjN0hPCldVMlN1VnNWVzdkeVM4bkV3aEJmYm9nck94bkhQbUlwTWpYYzhXSUNxWDRJdzF3YzQzTDQ5S1RxdEN6UWxoZEgKQjh4bUVxb0s5dEw4dk9jZWd0N3haN0xjMjdnODBPZ2t4NUtRVllCOGljL29DSDF4dEJScTNhN0lwTFh4ZHoxdQpFaHkwSjRIVVM4TzFTU3NCTWo0Y0JCWTlyUEFaK2dhekNqUzdhQ09mZzhRcGJNa3FHSVFGcUVpTDcvU1drR0x6CmVvODVGNVhoR1Z4UjlJK3RpczFjZHBscXR0V2R3OGxMemxVdVZqcTNhZ0dlOGV2WGQ0OFFlL3pzUS91TlpYakoKdHVBdGVxU3NMTzM5S28wWUljOFhoZTQyU2ZZZE52TjBEM3c3bitKTGE4Q2pQNXFNVHM1MUlpZndSbDEzbm5NQwp5UHhIM3dLMTc4MmFQVGdrMzhGVEFnTUJBQUdqZ1kwd2dZb3dId1lEVlIwakJCZ3dGb0FVOE9zZXlsQ3FncmpyCmJobzNmS1oweUZ2Nm1iQXdDUVlEVlIwVEJBSXdBREFMQmdOVkhROEVCQU1DQlBBd0V3WURWUjBsQkF3d0NnWUkKS3dZQkJRVUhBd0V3R3dZRFZSMFJCQlF3RW9JUVlYSm5iMk5rTG5SaGJucDFMbXhoWWpBZEJnTlZIUTRFRmdRVQpRMk9jc0FDVXA1RjZSMjFHNnBjczNEN2c2Um93RFFZSktvWklodmNOQVFFTkJRQURnZ0VCQUovYndxOThxU2V0ClQ5ekVJODBXVEk5bUtOdGZKK0JnR0hNMjQ2clpCWmVMblZ2RStlRVJ2QVFJdmN1VzV0QmNncjJIVm5aT1VKYWkKOFVRSmRseGM4NXlXcy9OWXAwYkV5b3FSeE5kT3BhZm9HRllvKzJCL0ljSjFxNWxyei9IRFh4di9rYWRsMXFwVQprV3Nqb0JYR2k1T3U0TmtMV0JUT2N2SUwwYVl4TVVUUFdtYXBJZnMxKzkxbjJjVW5wVkpXSDBOSFlZQ0VxU01CClVQLzhhZDFTUS94OHhlL2xPcGJQZVh6eC9HNy8yb1FXYUxuajllakxmWVExMlkrVTRrS0JubGY5OUJTckNyc3UKZ25FRnBPMHZPbWZMb0RhL3UrdmFOWGVTbllHeHpLOWxrMTBGQXYvSWJnNU9MekFka0FqQ0xoOC9RV0czWnpJVgo4NVpZREdlVmVCVT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
  tls.key: LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1JSUpRd0lCQURBTkJna3Foa2lHOXcwQkFRRUZBQVNDQ1Mwd2dna3BBZ0VBQW9JQ0FRQ3dKMWI0ZE1OcHFkL3IKMnlETklKWHhZMFJ3UUpic3Z1cGF6LzVJb0tOczVYNDAvWCttbTJDM2lEb0lUaVNiSGNwc3hQUFNXSEw5Yyt5WQpheEdsNjBOUHV5L1NLSGJZOVNEYURVdGxidEFGWW1iajRQUTltajUwVStTYndjcHpGb0ZLYW9OYW82VkZ0Y2NHClpkcGVkeGVTTXkyR3VpZ29NZTRmb2pYVEtoV1R3Z2tNM2hDMVltdENKekJaVXZwdThIeDVJcldMSkNxSUtuOEMKd3A4Z1VJSlpDVzVMSlhKTW5SMGgrUFoxWk10QUZ3cTA3Z1FZWXltL0xESStiQnhmcFY4ODJpaXBKQkc3RnBZSgpWc2tVSjBlQUNndEhVcW1ubFZtNEhiVDRGdkxKMFArTGdtRUYvMGIxeUc4NFNISURtaDcwelBUYVp6dlNMNnRNCnZVUS9YSE94emxsTmtybGJGVnUzY2t2SnhNSVFYMjZJS3pzWnh6NWlLVEkxM1BGaUFxbCtDTU5jSE9OeStQU2sKNnJRczBKWVhSd2ZNWmhLcUN2YlMvTHpuSG9MZThXZXkzTnU0UE5Eb0pNZVNrRldBZkluUDZBaDljYlFVYXQydQp5S1MxOFhjOWJoSWN0Q2VCMUV2RHRVa3JBVEkrSEFRV1BhendHZm9Hc3dvMHUyZ2puNFBFS1d6SktoaUVCYWhJCmkrLzBscEJpODNxUE9SZVY0UmxjVWZTUHJZck5YSGFaYXJiVm5jUEpTODVWTGxZNnQyb0JudkhyMTNlUEVIdjgKN0VQN2pXVjR5YmJnTFhxa3JDenQvU3FOR0NIUEY0WHVOa24ySFRiemRBOThPNS9pUzJ2QW96K2FqRTdPZFNJbgo4RVpkZDU1ekFzajhSOThDdGUvTm1qMDRKTi9CVXdJREFRQUJBb0lDQUNpaEtrSXNURlkyeEZzV003NmNZWGxICnVDVmNBSE9pcFZORTNoWEtWMmRxbDIySmVzUG0ycXY2VThoT25jclpXRE0yU2phZUNBZkZrVENtb1c5dmtCcjMKeGRQbldXSTVSOWFEY254Mnpxd3ZRaVFWWXNCQ3IxME5iSkV3WlkyZUJ6d3V6UlUrNFlQdXBYVW9VUEd3N2xMZQpVd1hjTWg3elJVVXVtTk9YeFZwTFN1TVk1U214QmFSQWZicGNsVDY1WVR4ZmNSZ2l3MXljMEtiR1ZRV1RERDJWCkcwZGgzN2NrRmZBY0NGeVRYdjN0VXA3Z3R6a1l4aXc5K1dqRWJ0Ynd3Y0s3WHQyRVlFS1N0eEI0WC9DeURwL04Kc1VSR0lMTnlrenNRUHdscDRaNERBcTRlNkZvRncwdzFhdEhFZytlb3lMTVdBdlBORTlNckE0dXpxK1loWU4yagppYWdCZXAwTjJYSjc1QnpwSG9EVElKeitKNXdsK05Pdk1wVXd5amdDVG1UVHVvbVJTQjRyTWY5R0JQbFg1bW00CmQwRlhuZkl5N2RSYmgxWGFlTTdoMnFidzR2a2hxWURTQjd3NjUzSU0vUTZtSmNnQ0ozd2l3dDhIRmZnVlJ5YnEKTzRKSUxtd0FrS1Q5aS8xQjExemIxL0RlT2tGU3drU1QxWWQ5T3c5YURlL3Q3RW13WnpQbHNUSS9jSnZIWURQMwpkdEtQN3U1emxnVEpLMC9RWHFHZmRuR3l6dysvN3lSaUlPaVB6RHBDU2VRdStyOEhsYTNqMjZVYmlXd3lBejR6CkduWFF0eUpXTEhnNXNuc2RHbElyT0JXTnBJa0pXR0VRU2hsOEFia1N5Zkl3RlFnbDMrTnY5a0tJZEt3NGZoQVEKQnBiZERuVy9vVldtNUdOQ3h3ZkJBb0lCQVFEcmo1a2NLK1diSjQ4bW0yeEhXM1llUFA1d1Z5cGdFeURmakxEegpjZ3JjRFowQmFVaTN2cExqc2k3WVdvYUFKMHluMlhIM253Z3lwWFI1akdMaXRWck5VWEJKbGt3b3M5cElCcUhqCmwxSm8wZlJVU2o4aXA1aUl6bGt1eXR1TG5ocWQ0c0tzQ1JxNzRKU3UrYkFVa3pObmRpQTJmbEhjMkd6dHV2RWwKZnF4SUNlNmJaL2pmR1dnUm5pTWE2UUk1MGI4MG9BaGVRSmhxQTBqdHRrQjVVVDlwWFM1dGwzVTF2SVNma3R1OApHNWlpa0R4cmJiaUtYVGpGMDRXZEJZbk1xVEwrTUZQNk4vZlg1dG1UaDNlbXRpM1BjSkpHSXdQRUxDcVBYZUFhCkJHRXlEbzhTSEFqeS80THN6Q3g3SGxXM1hiakRIckFZc1RFVGV0ODRNMWpyR2NBN0FvSUJBUUMvY0NnZFc5UUoKMkFXRlhKOGNtelN1UEN2dFdUb0hYVGlkdnFVckZSc3doc0lJeVFRNVNUSGNONlgzTGw5d3dBNHVLMmpoT0ZPVwpWZnpmUWRYVlEweEduQnM1ZXNUeVErVisyazR1MElXcFBkdnQ1c2pwWUJ1RHgxeDZSQlovbW5oOEFlTTNVdFVnCmVCaWg1aWtQWE9FT2tqZC9wTVRuR3RadXhETVR6WHFCdWIveWVrbEZGbm14czIrK25Ldm8rUG93NHA4Z3VaMzUKRTZGMlF1WTFSRzFseVdUZTVYc2RNUDRRTXVTcnpBckU2V0NGVE5JTkFaWUM5Yy9jL0pwWElrb29sODUzZGh1aQpYaFo1MlhldFdUZGZucWtpdUhzRld4WStpTzhsOU5hM29MZDF5TGpGME82Nk84cVJzSVZDTm12VnZRTnZQY0k0CnVjM0xlc05ERlVuSkFvSUJBUUNMeGJZZEVETDZnRnVobGVHRzZjOUptL21CNFViRW9UVUZVSzhDbE8yNnF0MDUKcENaQTJQVEI1TTJGRlJudjJ1SFNTdVVrQUJwV0t2VFUxcWNxVEYvbnFtWU5WQUEydXBsUDJaZWZ1djlzTVFCZwpMM29NN3hORVFlU0xMbFZkSCtBOVJQc3NKMjdVZ2lyWE5GTDFzbTV5K3BXY29CR2xFRXA2T1UyemFObURHVm1hCm52UCtOVTRaL2hKb2VsQVd6TTAreGFLUmdwU3RldXVBR1g5aVBRSjZXNDhiK2gzVFY5djk3NTh3bTlOU3luRC8KY2FocGVXMGhmU1F3Q3NROFN6MTF0R2x2OUZ1OG9UOERHZ08yU1MwZmhIVlc1cG5xZ2laeTBVb1RSZndDUHI5SQpDSmlLejIvNVlDRVlvT1JObkcvd1h6b3dQSnVaS25SZkhhQ3FSNnBYQW9JQkFCeWJKTk5tUW1RS0xLRUYreHlxCk1KQU1tNy9Hd240Uk53R1RXRmo4dVdoaDZxS25id01rWmRmelZOQi8xSEVqc2JyQ2I5U2Z0eFhTMll0KzZmWUoKTFYrcnVnRzN6N0FuNXlZeWR0WldBSE1PdEV0elhmaEpqVEwrMmxuR3pObmFla0NGZzY5anFFZEd5dDkrWmdwTwpwYTZvdUxSUktiOGk2b0g0dlcwckdqQkNVbVZvVW9TSlhEdnFoVHNsYkNiTzlZdlNnVmJCaGRLUFZXUTNrUERLCnZkSWs2dmJIc2NMbDdFRDlhZUFtQ0VIdVlhYnBtTVdxeEFERFBJRllHYlFGZ3JGWUpka0NCQlVhSEIrdkdFd0YKOWRsSyt4a2VHZnZ0NVlBSXREdW12Mk1IR0FMNHNHdVcwZVZ3UTgvTFljNUlGWXNGeUhxWjd1ak5FdXhoOXNXUwphOGtDZ2dFQkFPTW01cVkwK0hTWk1wenFzZnNERUl6SE5PYW4vS1VPSGNxNnU4SXJKMWpYSkhpMXJ0SEdEYTFhCm1KbjhFdE9ueGU2bFd0Y2NGdmJFKzJxQ1lBcEpkRVVXYisyYTVRWkZveWdNL3JNcGRWcS91QjRBYUphTGVwTGEKUnRIRFA4SWgzU01YVS9YMGxNNnNOTFZielJNR2t3dHRlV1pDYzBSY3Z4N2VTbkczK3cvUE9pbUt4UlRpbVVDVQpmbm52L3VaY0FmQXEraXhSZURNNW5nbjZDcjdjdE9QWDNNZUFzWXNBdGRvNGQ5RS9EbWIyZnBIT242dWYrWThFCmVHcG5aanc3OGVXR0IvK2tZVjkwaENsWmNmZ29Vd2FCSVZmN2pjN3BvMWdORk1EY2hMbTc5UDY3bERoRUw3dW4KV0o1WnFodWxMeHUzMmMwNFUyRytkUUxiL3N1bTZmUT0KLS0tLS1FTkQgUFJJVkFURSBLRVktLS0tLQo=
type: kubernetes.io/tls
EOF
kubectl apply -f argocd-tls-secret -n argocd

argocd 웹페이지의 Installation 메뉴에서 설치 yaml 파일 정보를 가져옵니다.

installation.yaml sample

  • installation.yaml 파일 항목에서 아래 항목을 검색 후 server.insecure: “true”로 추가 혹은 변경
    • contour ingress에서 SSL offload를 한 후, argocd 로는 non-tls 통신을 하기 위함.
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cmd-params-cm
  namespace: argocd
data:
  # Contour가 TLS를 종료하므로, Argo CD 서버는 인바운드 트래픽을 HTTP로 처리할 수 있도록 --insecure 플래그를 추가합니다.
  server.insecure: "true"
  • installation.yaml 파일 항목에서 아래와 같이 kind: Servce 항목의 argocd-server에 대해서 아래와 같이 annotations을 추가합니다.
apiVersion: v1
kind: Service
metadata:
  name: argocd-server
  namespace: argocd
  annotations:
    # Contour가 gRPC (h2c) 프로토콜을 올바르게 프록시하도록 설정
    projectcontour.io/upstream-protocol.h2c: "443" # Argo CD 서버 컨테이너 포트
  • 설치된 contour Ingress 환경에 맞춰서 contour httpproxy 배포 yaml 파일을 구성합니다.

http-proxy.yaml

apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: argocd-proxy
spec:
  virtualhost:
    fqdn: argocd.tanzu.lab    # argocd fqdn을 입력합니다.
    tls:
#      passthrough: true
      secretName: argocd-tls-secret    # 사전에 생성한 tls secret name
  routes:
    - conditions:
        - prefix: /
        - header:
            name: Content-Type
            contains: application/grpc    # grpc에 대해서는 443 포트로 전달
      services:
        - name: argocd-server
          port: 443
          protocol: h2c # allows for unencrypted http2 connections
      timeoutPolicy:    # grpc session에 대해서는 idle 값을 길게 설정
        response: 1h
        idle: 600s
        idleConnection: 600s
    - conditions:    # 일반 http,https 접근에 대해서는 80포트로 전달
        - prefix: /
      services:
        - name: argocd-server
          port: 80
  • contour httpproxy를 배포합니다.
kubectl apply -f http-proxy.yaml -n argocd
  • installation yaml을 argocd namespace에 배포합니다.
kubectl apply -f installation.yaml -n argocd

admin 계정의 초기 password 확인

배포 이후, admin 계정의 초기 비밀번호를 확인

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

argoCD 로그인 및 Settings 메뉴

Password 변경

로그인 이후, password 업데이트를 진행

argocd CLI 도구 설치

https://github.com/argoproj/argo-cd/releases/tag/v3.0.12

wget https://github.com/argoproj/argo-cd/releases/download/v3.0.12/argocd-linux-amd64
  • 실행 권한을 부여하고, 파일을 실행 폴더로 이동합니다.
chmod +x argocd-linux-amd64
sudo mv argocd-linux-amd64 /usr/local/bin/argocd

argoCD cluster 추가/삭제/네임스페이스 설정

  # List all known clusters in JSON format:
  argocd cluster list -o json

  # Add a target cluster configuration to ArgoCD. The context must exist in your kubectl config:
  argocd cluster add example-cluster

  # Get specific details about a cluster in plain text (wide) format:
  argocd cluster get example-cluster -o wide

  # Remove a target cluster context from ArgoCD
  argocd cluster rm example-cluster

  # Set a target cluster context from ArgoCD
  argocd cluster set CLUSTER_NAME --name new-cluster-name --namespace '*'
  argocd cluster set CLUSTER_NAME --name new-cluster-name --namespace namespace-one --namespace namespace-two
  • argocd cluster 명령어를 사용해서, context를 인증 정보를 argocd에 추가합니다. context는 kubectl의 context와 동일합니다.
kubectl config use-context ml-tkc
# cluster 인증 정보를 argocd 서버에 추가합니다.
argocd cluster add ml-tkc

# argocd 서버의 context에 관리 namespace을 모두 허용합니다.
argocd cluster set ml-tkc --namespace '*'

# argocd 서버의 context에 관리 namespace을 추가합니다.
argocd cluster set ml-tkc --namespace ns1 ns2 ns3...

 

argocd 메뉴에서 논리적인 project를 추가할 수 있습니다.

Repository 추가

  • 로컬 리포지토리를 소유하고 있다면, 해당 리포지토리 연결 종류(HTTP/HTTPs, SSH … etc)와 선택 종류에 따른 Type을 정의합니다.

  • 아래와 같이 프로젝트를 선택하고 연결 종류에 따라 필요한 경로, 계정 정보, 셀프 인증서일 경우 인증서 정보등을 입력합니다.
  • 아래 예에서는 앱 배포 테스트를 위한 public github에 있는 개인 repository path만을 추가합니다.

  • 아래와 같이 추가된 리포지토리 연결 상태를 확인할 수 있습니다. 이제는 argocd를 사용하여, github 정보를 참조하고, 애플리케이션 배포 및 지속적인 변화 관찰을 통한 업데이트를 제공할 수 있습니다.

image.png

Application 배포

Github를 통해서 kustomize 유형으로 앱을 배포하고, 업데이트 방식을 진행합니다. 동일한 branch에 code을 업데이트해서 테스트도 가능하나, 테스트 사용자의 github 수정이 불가능한 것을 감안하여, branch main을 기준으로 v1, v2 image tag로 구분하여 진행합니다.

최초 3-tier application에 대한 v0.1 image를 배포 및 contour httpproxy를 통해서 서비스를 제공합니다. 사전에 contour가 구성되어 있어야 하며, external-dns를 통한 contour-httpproxy 유형에 대한 DNS 서버로 A-host 등록이 가능하거나, 혹은 httpproxy 배포 시 사용되는 fqdn에 대한 DNS 서버에서의 해당 contour로 배포된 envoy IP와 가상호스트의 FQDN에 대한 A-host 등록(혹은 테스트 수행 클라이언트에서 /etc/hosts 혹은 system32/driver/etc/hosts에 수동 등록)을 필요로 합니다.

현재 제공된 yaml 파일의 http-proxy에 대한 fqdn은 3ta.tanzu.lab 으로 되어 있습니다.

  • 네임스페이스를 생성하고, 권한을 부여합니다.
kubectl create namespace 3tier-app
kubectl label --overwrite ns 3tier-app pod-security.kubernetes.io/enforce=baseline

애플리케이션 생성을 진행합니다.

  • 애플리케이션 이름과 프로젝트를 선택하고, 동기화 정책을 설정합니다.
  • 자동으로 불일치 되는 리소스를 제거할 것인지와 같은 기타 옵션을 사용 정책에 맞춰서 설정합니다.(PRUNE RESOURCES, SELF HEAL)
    • prune resourses: 변경 반영 이후 불일치하는 리소스를 남기지 않고 제거
    • self heal: 리포지토리 정보와 불일치 발생 시 재 조정

  • 스크롤을 내리고, SOURCE 섹션을 진행합니다.
  • 앞서 생성한 github 리포지토리를 선택합니다.
  • Revision 항목의 HEAD 문자열을 백스페이스 키를 사용하여 삭제하고, HEAD 혹은 main 브랜치를 선택합니다. 기본 설정인 HEAD는 가장 최상위 레벨로서 HEAD 또한 하위 디렉토리 정보를 가져옵니다.

  • three-tier-app 애플리케이션이 위치한 Path(kustomization.yaml 파일을 인식합니다.)를 선택합니다.
  • DESTNATION 섹션으로 이동하여, ‘argocd cluster add’로 추가한 cluster 컨텍스트중 하나를 선택합니다.
  • 배포 대상 namespace를 정의합니다. 사전에 네임스페이스를 만들고 POD security 권한을 조정하길 권장합니다.

  • 정상적으로 Path 경로가 맞으며, kustomization.yaml 파일에 오류가 없을 경우에는 아래와 같이 Kustomize에 대한 정보 값이 표기가 됩니다.

  • CREATE 버튼을 클릭하여, 앱 배포를 진행합니다.

  • 배포 앱을 클릭하여, 상세 정보를 확인합니다.

지속적인 동기화

  • Branch 대상을 변경하거나, 동일 리포지토리 경로에서 yaml 정보를 업데이트할 경우 변경사항이 반영됩니다.
  • argocd는 기본 설정으로 매 3분 마다 리포지토리를 검사합니다.

테스트 유형 ONE: Rollout

배포된 애플리케이션의 개발자가 새로운 이미지 업로드에 따라, 새 버전의 image path를 지정합니다.

아래와 같이 github의 image path의 image tag를 변경합니다.

  • ap-deployment.yaml: 3ta-web:v0.1 → 3ta-web:v0.2

  • web-deployment.yaml: 3ta-ap:v0.1 → 3ta-ap:v0.2

 

  • ArgoCD 웹에서 관찰중 Auto Sync 설정에 따라서 업데이트 되는 것을 확인할 수 있습니다.

  • 웹브라우저에서 새로고침하여, 변경된 웹페이지를 확인할 수 있습니다.

Rollback

Kubernetes rollback 기능을 ArgoCD에서 수행할 수 있습니다.

  • v0.1 → v0.2로 변경 이후, “HISTORY AND ROLLBACK” 메뉴를 선택합니다.

  • 아래와 같이 v0.1에 해당하는 SOURCE를 선택하고, 3DOTs 메뉴를 클릭하여, Rollback을 수행합니다.
  • v0.1로 POD는 재 배포되며, GIT과의 Autosync는 Disabled 전환됩니다.

Kubernetes의 기본 전략은 기존 POD를 제거하고 새로운 POD를 배포하는 것입니다. 이는 Rolling UPDATE에 해당하며, kubectl rollout 명령어를 사용하거나 Deployment에 Strategy를 추가할 수 있습니다.

아래와 같은 Deployment가 있다고 가정할 경우, 최초 복제 수 3개로 배포한 이후, v0.2로 이미지 변경 작업 시, RollingUpdate 전략을 정의할 수 있습니다.

앞서서 진행한 테스트에서는 Replicas: 1 으로 최초 배포되어, 별도의 RollingUpdate 지정 없이 image TAG 변경만 진행하여 Rollout & RollBack 테스트가 진행되었습니다.

spec:
  replicas: 2
  selector:
    matchLabels:
      app: ap
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: ap
    spec:
      containers:
      - name: ap-container
#        image: harbor.tanzu.lab/library/3ta-ap:v0.1 # AP 이미지 (빌드 후 푸시 필요)
        # public git
        image: postout7979/3ta-ap:v0.2 # AP 이미지 (빌드 후 푸시 필요)

실 프로덕션 환경에서는 롤링 업데이트 사용 되어질 수 있으나, Blue-Green 업데이트 혹은 Canary 업데이트가 사용됩니다.

  • 업데이트에 따른 순서 예시
    • Deployment - POD1, POD2, POD3
    • → Rolling Update: Deployment - POD1, POD2 & NEW Deployment - POD4, POD5
    • → NEW Deployment: POD4, POD5, POD6
  • maxSurge
    • 롤링 업데이트를 위해 최대로 생성할 수 있는 파드 갯수
    • maxSurge를 높게 설정하면 롤링 배포를 빠르게 적용 가능
    • % 단위 또는 갯수 단위로 지정 가능
    • 설정하지 않을 경우 기본 값은 25%
  • maxUnavailable
    • 롤링 업데이트 중 최대로 삭제할 파드 갯수
    • maxUnavailable를 높게 설정하면 롤링 배포를 빠르게 적용 가능
    • 다만 한번에 많은 파드를 삭제할 경우 트래픽이 남아있는 소수의 파드로 집중될 수 있어 값을 적절히 설정 필요
    • % 단위 또는 갯수 단위로 지정 가능
    • 설정하지 않을 경우 기본 값은 25%

테스트 유형 TWO: Manually Canary Update

기존 서비스에 영향을 최소화하며, PRODUCTION 환경 적용을 위해서, Contour HTTPProxy를 통한 L7 워크로드 밸런싱으로 v0.1과 v0.2 서비스의 WEB, AP에 대한 weight balancing을 진행하는 테스트를 수행합니다.

  • 웹브라우저을 이용해서 3ta.tanzu.lab에 접속합니다.
  • 아이템을 추가합니다.

  • kustomization.yaml 파일을 수정합니다.
kind: Kustomization
resources:
  - db-pvc.yaml
  - db-secret.yaml
  - db-service.yaml
  - db-deployment.yaml
  - ap-service.yaml
  - ap-deployment.yaml
  - web-service.yaml
  - web-deployment.yaml
  - http-proxy.yaml
  - ap-service-v2.yaml
  - ap-deployment-v2.yaml
  - web-service-v2.yaml
  - web-deployment-v2.yaml
  • v0.1 및 v0.2 태그의 이미지를 모두 배포를 사전에 진행하였으며, 여기서는 httpproxy에 대한 정보를 변경하여 테스트를 진행합니다.
  • httpproxy.yaml 파일의 service를 web-service-v2 를 추가하고, weight를 조정합니다. 그리고, git commit를 완료합니다.
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: 3ta-proxy
spec:
  virtualhost:
    fqdn: 3ta.tanzu.lab
  routes:
    - conditions:
        - prefix: /
      services:
        - name: web-service
          port: 5000
          weight: 50
        - name: web-service-v2
          port: 5000
          weight: 50
  • 수동으로 SYNC를 해주거나, Auto-sync가 발생하기를 기다립니다.
  • REFRESH 버튼으로 새로고침을 해줍니다.

  • httpproxy가 업데이트 되었습니다.
  • 웹 브라우저에서 새로 고침을 하면, 삭제 버튼이 있는 페이지와 처음 배포한 없는 페이지를 오가는 것을 확인할 수 있습니다.

 

Canary 업데이트 - Argo Rollout

Arogo rollout controller는 deployment를 대체하여 컨테이너 배포를 대체합니다.

여기에는 어떻게 컨테이너를 단계별로 배포 및 업데이트 할 것인지와 같은 정책을 조정하는 기능을 제공합니다.

또한 인그레스, 서비스메시와 같은 다른 서비스와 통합을 제공합니다아래 링크는 carnary 유형 진행 시 롤아웃에 대한 설명입니다.

Canary - Argo Rollouts - Kubernetes Progressive Delivery Controller

아래와 같은 기능을 제공합니다.

Controller Features

  • Blue-Green update strategy
  • Canary update strategy
  • Fine-grained, weighted traffic shifting
  • Automated rollbacks and promotions
  • Manual judgement
  • Customizable metric queries and analysis of business KPIs
  • Ingress controller integration: NGINX, ALB, Apache APISIX
  • Service Mesh integration: Istio, Linkerd, SMI
  • Simultaneous usage of multiple providers: SMI + NGINX, Istio + ALB, etc.
  • Metric provider integration: Prometheus, Wavefront, Kayenta, Web, Kubernetes Jobs, Datadog, New Relic, Graphite, InfluxDB

클러스터에 argo-rollouts namespace을 생성하고, argo-rollouts 배포를 진행합니다.

kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

다른 네임스페이스를 사용 할 경우 installation.yaml에서 namespace 항목의 값을 변경해야 합니다.

kubectl plugin을 다운로드하여, /usr/local/bin 폴더에 이동시킵니다.

# 파일을 다운로드 합니다. ( linux 배포판으로 다운로드 파일명을 확인합니다.)
curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64

# 파일에 실행권한을 부여합니다.
chmod +x ./kubectl-argo-rollouts-linux-amd64

# sudo 명령어를 사용하여, 파일명을 변경하고, 실행 폴더로 이동시킵니다.
sudo mv ./kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts

명령어를 실행하여, 버전을 확인합니다.

kubectl-argo-rollouts version
kubectl-argo-rollouts: v1.8.3+49fa151
  BuildDate: 2025-06-04T22:15:54Z
  GitCommit: 49fa1516cf71672b69e265267da4e1d16e1fe114
  GitTreeState: clean
  GoVersion: go1.23.9
  Compiler: gc
  Platform: linux/amd64

Rollouts

롤아웃은 쿠버네티스 배포 객체와 동일한 쿠버네티스 워크로드 리소스입니다. 고급 배포 또는 점진적 전달 기능이 필요한 경우 배포 객체를 대체하기 위해 고안되었습니다. 롤아웃은 쿠버네티스 배포가 제공하지 않는 다음과 같은 기능을 제공합니다.

  • 블루-그린 배포
  • 카나리아 배포
  • 고급 트래픽 라우팅을 위한 인그레스 컨트롤러 및 서비스 메시와의 통합
  • 블루-그린 및 카나리아 분석을 위한 메트릭 제공자와의 통합
  • 성공 또는 실패한 지표에 따라 자동 프로모션 또는 롤백

Progressive Delivery

업계에서는 다양한 배포 전략을 설명하기 위해 일관된 용어를 사용해 왔지만, 이러한 전략의 구현 방식은 툴마다 다른 경향이 있습니다. Argo Rollouts의 작동 방식을 명확히 설명하기 위해 다양한 배포 전략 구현에 대한 설명을 제공합니다. Argo Rollouts는 Blue-Green과 Canary만 지원합니다.

Rolling Update

RollingUpdate이전 버전을 새 버전으로 천천히 교체합니다. 새 버전이 출시됨에 따라 애플리케이션의 전체 개수를 유지하기 위해 이전 버전의 크기가 줄어듭니다. 이는 배포 객체의 기본 전략입니다.

Recreate

배포 재생성은 새 버전을 실행하기 전에 이전 버전의 애플리케이션을 삭제합니다. 따라서 두 버전의 애플리케이션이 동시에 실행되는 일은 없지만, 배포 중 다운타임이 발생합니다.

Blue-Green deployment

블루-그린 배포(레드-블랙이라고도 함)는 애플리케이션의 새 버전과 이전 버전을 동시에 배포합니다. 이 기간 동안 애플리케이션의 이전 버전만 프로덕션 트래픽을 수신합니다. 이를 통해 개발자는 라이브 트래픽을 새 버전으로 전환하기 전에 새 버전에 대한 테스트를 실행할 수 있습니다.

Canary

카나리아 배포는 일부 사용자에게는 새 버전의 애플리케이션을 제공하고 나머지 트래픽은 이전 버전으로 전송합니다. 새 버전의 안정성이 검증되면 새 버전이 이전 버전을 점진적으로 대체할 수 있습니다. NGINX 및 Istio와 같은 인그레스 컨트롤러와 서비스 메시는 카나리아 배포를 위해 기본적으로 제공되는 것보다 더욱 정교한 트래픽 셰이핑 패턴을 지원합니다(예: 매우 세밀한 트래픽 분할 또는 HTTP 헤더 기반 분할).

전략에 대한 선택

일반적으로 Blue/Green은 시작하기 쉬운 전략이지만, 제약이 더 많습니다. Blue/Green 배포로 시작하여 지표와 애플리케이션에 대한 확신이 생기면 Canary로 전환하는 것이 좋습니다.

애플리케이션이 Canary를 처리할 수 있는지 여부도 확인해야 합니다.

Blue/Green은 한 번에 하나의 애플리케이션만 활성화되므로 항상 작동합니다. 모든 애플리케이션이 동시에 여러 버전을 병렬로 실행할 수 있는 것은 아닙니다(Canary가 하는 일이죠). 이는 특히 레거시 애플리케이션의 경우 Canary 배포를 도입하는 데 걸림돌이 될 수 있습니다.
Blue/Green은 트래픽 관리자 없이도 모든 기능을 활용할 수 있기 때문에 더 간단합니다. Canary도 트래픽 관리자 없이 작동할 수 있지만, 대부분의 고급 기능은 트래픽을 세밀하게 제어하는 방식을 전제로 합니다. 트래픽 관리자가 없는 경우 Blue/Green 배포의 모든 기능을 쉽게 활용할 수 있지만 Canary의 기본 기능만 사용할 수 있습니다.
Blue/Green은 대기열과 데이터베이스(작업을 가져오는 작업자)를 사용하는 서비스와도 호환됩니다. Argo Rollouts는 이해하지 못하는 연결(예: 바이너리/큐 채널)에 대한 트래픽 흐름을 제어하지 않습니다.

아키텍처 형상

롤아웃 컨트롤러를 제외한 다른 도구는 개별 설치를 필요로합니다.

ArgoCD rollouts은 Contour Ingress/HTTPProxy와 통합을 지원하지 않으며, 다음과 같은 트래픽 제어기를 지원합니다.

그러나, 현재 argolabs에서 contour와 통합 진행을 확인 및 사용할 수 있습니다.

https://github.com/argoproj-labs/rollouts-plugin-trafficrouter-contour

+++

기본 사용 유형(Traffic Shaping control 통합 없이 앱 배포에 집중합니다.)

  • Contour HTTPProxy에서 제어는 별도로 핸들링을 해야 합니다.

rollouts 샘플 yaml을 생성합니다.

cat << EOF > web-rollouts.yaml
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: web-rollout
spec:
  replicas: 10
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web-container
        image: postout7979/3ta-web:v0.1
        ports:
        - containerPort: 5000
        env:
        - name: AP_SERVER_URL
          value: "http://ap-service:5001/api/items"
        - name: PYTHONUNBUFFERED
          value: "1"
        livenessProbe:
          httpGet:
            path: /
            port: 5000
          initialDelaySeconds: 10
          periodSeconds: 15
        readinessProbe:
          httpGet:
            path: /
            port: 5000
          initialDelaySeconds: 5
          periodSeconds: 10
  minReadySeconds: 30
  revisionHistoryLimit: 3
  strategy:
    canary: #Indicates that the rollout should use the Canary strategy
      maxSurge: '25%'
      maxUnavailable: 0
      steps:
        - setWeight: 20
        - pause:
            duration: 1m # 1 minutes
        - setWeight: 40
        - pause:
            duration: 1m # 1 minutes
        - setWeight: 60
        - pause:
            duration: 1m # 1 minutes
        - setWeight: 80
        - pause: {} # indefinitely
EOF

duration 유형 샘플 예제

spec:
  strategy:
    canary:
      steps:
        - pause:
            duration: 10  # 10 seconds
        - pause:
            duration: 10s # 10 seconds
        - pause: { duration: 10m } # 10 minutes
        - pause: { duration: 10h } # 10 hours
        - pause: {} # pause indefinitely

v0.1 이미지의 web-rollouts.yaml을 배포합니다.

kubectl apply -f web-rollouts.yaml -n rollouts-demo

진행 사항을 확인합니다.

kubectl-argo-rollouts get rollout web-rollouts -n rollouts-demo --watch
Name:            web-rollout
Namespace:       rollout-demo
Status:          ✔ Healthy
Strategy:        Canary
  Step:          8/8
  SetWeight:     100
  ActualWeight:  100
Images:          postout7979/3ta-web:v0.1 (stable)
Replicas:
  Desired:       10
  Current:       10
  Updated:       10
  Ready:         10
  Available:     10

NAME                                    KIND        STATUS     AGE    INFO
⟳ web-rollout                           Rollout     ✔ Healthy  4m53s
└──# revision:1
   └──⧉ web-rollout-bcccf8475           ReplicaSet  ✔ Healthy  4m53s  stable
      ├──□ web-rollout-bcccf8475-4d7pc  Pod         ✔ Running  4m53s  ready:1/1
      ├──□ web-rollout-bcccf8475-4w268  Pod         ✔ Running  4m53s  ready:1/1
      ├──□ web-rollout-bcccf8475-8pfx5  Pod         ✔ Running  4m53s  ready:1/1
      ├──□ web-rollout-bcccf8475-9v4vh  Pod         ✔ Running  4m53s  ready:1/1
      ├──□ web-rollout-bcccf8475-b8vzr  Pod         ✔ Running  4m53s  ready:1/1
      ├──□ web-rollout-bcccf8475-d45r4  Pod         ✔ Running  4m53s  ready:1/1
      ├──□ web-rollout-bcccf8475-flvwm  Pod         ✔ Running  4m53s  ready:1/1
      ├──□ web-rollout-bcccf8475-snbq6  Pod         ✔ Running  4m53s  ready:1/1
      ├──□ web-rollout-bcccf8475-sqp4m  Pod         ✔ Running  4m53s  ready:1/1
      └──□ web-rollout-bcccf8475-ttcqb  Pod         ✔ Running  4m53s  ready:1/1

v0.2 이미지로 업데이트를 진행합니다.

  • namespace, rollout name, container name, image path:tag 를 입력합니다.
# 기본 예제
 kubectl-argo-rollouts set image {rollouts name} {container name}={imagepath:tag} -n {namespace}

# 샘플 예제
 kubectl-argo-rollouts set image web-rollout web-container=postout7979/3ta-web:v0.2 -n rollout-demo

다시 진행 사항을 확인합니다.

  • 앞서 설정한 시간에 맞춰서 진행되며, 최종 마지막 단계에서는 pause 상태를 설정대로 무한대로 대기 상태를 유지합니다.
kubectl-argo-rollouts get rollout web-rollouts -n rollouts-demo -w
Name:            web-rollout
Namespace:       rollout-demo
Status:          ॥ Paused
Message:         CanaryPauseStep
Strategy:        Canary
  Step:          1/8
  SetWeight:     20
  ActualWeight:  20
Images:          postout7979/3ta-web:v0.1 (stable)
                 postout7979/3ta-web:v0.2 (canary)
Replicas:
  Desired:       10
  Current:       10
  Updated:       2
  Ready:         10
  Available:     10

NAME                                     KIND        STATUS     AGE   INFO
⟳ web-rollout                            Rollout     ॥ Paused   12m
├──# revision:2
│  └──⧉ web-rollout-7fc5667698           ReplicaSet  ✔ Healthy  4m2s  canary
│     ├──□ web-rollout-7fc5667698-skxmp  Pod         ✔ Running  4m2s  ready:1/1
│     └──□ web-rollout-7fc5667698-zmbjb  Pod         ✔ Running  4m2s  ready:1/1
└──# revision:1
   └──⧉ web-rollout-bcccf8475            ReplicaSet  ✔ Healthy  12m   stable
      ├──□ web-rollout-bcccf8475-4d7pc   Pod         ✔ Running  12m   ready:1/1
      ├──□ web-rollout-bcccf8475-8pfx5   Pod         ✔ Running  12m   ready:1/1
      ├──□ web-rollout-bcccf8475-9v4vh   Pod         ✔ Running  12m   ready:1/1
      ├──□ web-rollout-bcccf8475-d45r4   Pod         ✔ Running  12m   ready:1/1
      ├──□ web-rollout-bcccf8475-flvwm   Pod         ✔ Running  12m   ready:1/1
      ├──□ web-rollout-bcccf8475-snbq6   Pod         ✔ Running  12m   ready:1/1
      ├──□ web-rollout-bcccf8475-sqp4m   Pod         ✔ Running  12m   ready:1/1
      └──□ web-rollout-bcccf8475-ttcqb   Pod         ✔ Running  12m   ready:1/1

dashboard를 로컬 클라이언트로 포워딩하여, 웹으로 확인할 수 있습니다.

kubectl argo rollouts dashboard --insecure-skip-tls-verify --port 8080

 

 

kubectl port-forwards 를 사용해서도 해당 service를 로컬 클라이언트로 전달할 수 있습니다. 서비스를 확인합니다.

로드밸런서나 인그레스와 연결하여 노출도 생각할 수 있습니다.

kubectl get service -n argo-rollout

pause 상태에서 수동으로 다음 단계로 넘어 가기 위한 명령어

  • duration이 무한대로 되어 있는 pause 단계에서 promote를 필요로 합니다.
  • 웹 UI 대시보드에서 promte를 진행하거나, 아래와 같이 명령어로 진행합니다.
# promote to the next step
kubectl-argo-rollouts promote <rollout>
# sample example
kubectl-argo-rollouts promote web-rollout -n rollout-demo

완전히 v0.2 이미지로 전환된 것을 확인할 수 있습니다.

이제는 ArgoCD에서 사용할 수 있도록, github의 kustomization.yaml 파일의 deployment를 rollout 파일로 대체 사용합니다. 이렇게 하면 우리는 자동화된 단계별 rollout 시나리오를 수행할 수 있습니다.

Contour HTTPProxy와는 traffic management가 통합되지 않음으로, NSX ALB Ingress를 사용하거나, 기타 service mesh등 다른 구성 요소와 통합될 수 있습니다.

티스토리툴바