I got IT

K8S 환경에서 CI/CD 구축하기 - 2 본문

AWS/EKS

K8S 환경에서 CI/CD 구축하기 - 2

joshhoxy 2025. 3. 30. 07:05

※ 해당 글은 CloudNet@ gasida 님의 EKS 스터디 내용을 참고하여 작성하였습니다.
이전 글 K8S 환경에서 CI/CD 구축하기 - 1 에 이은 내용입니다.

3️⃣ gogs 리포에 push 합니다.

git add . && git commit -m "Add nginx helm chart" && **git push -u origin main**

 

 

Argo CD Application 생성

 

1️⃣ argocd server에서 애플리케이션 생성

애플리케이션 메뉴에서 create application 버튼을 클릭합니다.

이후 애플리케이션 구성 페이지에서 다음과 같이 설정을 지정합니다.

  • GENERAL
    • App Name : dev-nginx
    • Project Name : default
    • SYNC POLICY : Manual
      • AUTO-CREATE NAMESPACE : 클러스터에 네임스페이스가 없을 시 argocd에 입력한 이름으로 자동 생성
      • APPLY OUT OF SYNC ONLY : 현재 동기화 상태가 아닌 리소스만 배포
    • SYNC OPTIONS : AUTO-CREATE NAMESPACE(Check)
    • PRUNE PROPAGATION POLICY
      • foreground : 부모(소유자, ex. deployment) 자원을 먼저 삭제함
      • background : 자식(종속자, ex. pod) 자원을 먼저 삭제함
      • orphan : 고아(소유자는 삭제됐지만, 종속자가 삭제되지 않은 경우) 자원을 삭제함
  • Source
    • Repo URL : 설정되어 있는 것 선택
    • Revision : HEAD
    • PATH : nginx-chart
  • DESTINATION
    • Cluster URL : <기본값>
    • NAMESPACE : dev-nginx
  • HELM
    • Values files : values-dev.yaml

application을 생성하면 다음과 같이 대시보드에 새로운 위젯이 생성됩니다. 해당 위젯을 클릭하면 다음과 같이 configmap, svc, deployment 등의 리소스가 표시되는 것을 확인할 수 있습니다.

 

2️⃣ 쿠버네티스에서 관련 리소스 확인

#
kubectl get applications -n argocd

kubectl describe applications -n argocd dev-nginx

# 상태 모니터링
kubectl get applications -n argocd -w

# 반복 접속 시도
while true; do curl -s --connect-timeout 1 http://127.0.0.1:30000 ; date ; echo "------------" ; sleep 1 ; done
  • 애플리케이션의 status가 missing 인 이유?

Argo CD가 Git 저장소에는 존재하는 리소스 정의(YAML) 를 클러스터에는 찾을 수 없을 때 발생하는 상태입니다. 즉 “Git에는 있는데, 클러스터에는 없어요” 라는 의미입니다.

 

3️⃣ Sync 하기

파드 한대가 떴음을 확인할 수 있습니다.

해당 애플리케이션은 cli로도 생성할 수 있습니다.

argocd의 애플리케이션 manifest를 확인해 봅니다.

kubectl get applications -n argocd
**kubectl get applications -n argocd -o yaml | kubectl neat**

 

⚠️ GitOps 방식(?)을 무시하고 K8S(Live)를 수정 시도해보기

argocd로 배포된 애플리케이션은 멱등성이 있기 때문에 k8s 자체에서 수정을 시도하면 안됩니다. 이를 확인해보기 위해 고의적으로 해당 방식으로 해보도록 하겠습니다.

동작 확인을 위해서 반복 접속

while true; do curl -s --connect-timeout 1 http://127.0.0.1:30000 ; date ; echo "------------" ; sleep 1 ; done

configmap (dev-nginx) 클릭

LIVE MANIFEST 에 EDIT 클릭 후 index.html 내용 추가 → SAVE

하지만 Git에 없던 정보는 DIFF 차이점이 발견되지 않습니다.

해당 변경 내용은 실제 클러스터에 반영이 되는 것을 확인할 수 있습니다.

또한 반대로도 kubectl로 configmap을 변경해도 LIVE MANIFEST에 반영이 되는 것을 확인할 수 있습니다. LIVE MANIFEST는 쿠버네티스 리소스를 실시간으로 추적하여 해당 상태를 보여주는 것입니다.

 

하지만 DESIRED MANIFEST에서는 아무런 사항도 변경이 되지 않기 때문에 argocd를 rollout하면 위 사항들이 원복이 됩니다. 따라서 반드시 모든 수정과배포는 desired state 를 반영하는 src 인 리포지토리에서 수정해야 합니다.이를 GitOps에서는 SSOT라고 합니다. 반드시 단일 진실 공급원(Single Source Of Trush, SSOT)

 

gogs repo 코드 수정하여 반영하기

위에서 설명한 SSOT를 실제로 해봅니다.

 

4️⃣ 1.26.2 로 업데이트(코드 수정) 후 반영 확인

#
VERSION=1.26.2

cat > nginx-chart/VERSION <<EOF
$VERSION
EOF

cat > nginx-chart/values-dev.yaml <<EOF
indexHtml: |
  <!DOCTYPE html>
  <html>
  <head>
    <title>Welcome to Nginx!</title>
  </head>
  <body>
    <h1>Hello, Kubernetes!</h1>
    <p>DEV : Nginx version $VERSION</p>
  </body>
  </html>

image:
  repository: nginx
  tag: $VERSION

replicaCount: 2
EOF

cat > nginx-chart/values-prd.yaml <<EOF
indexHtml: |
  <!DOCTYPE html>
  <html>
  <head>
    <title>Welcome to Nginx!</title>
  </head>
  <body>
    <h1>Hello, Kubernetes!</h1>
    <p>PRD : Nginx version $VERSION</p>
  </body>
  </html>

image:
  repository: nginx
  tag: $VERSION

replicaCount: 2
EOF

cat > nginx-chart/Chart.yaml <<EOF
apiVersion: v2
name: nginx-chart
description: A Helm chart for deploying Nginx with custom index.html
type: application
version: 1.0.0
appVersion: "$VERSION"
EOF

git add . && git commit -m "Update nginx version $(cat nginx-chart/VERSION)" && git push -u origin main

 

반영 확인 - gogs

 

반영 확인 - argo cd 서버

소스코드가 변경되고 나서 argo cd 서버가 감지하기 까지는 최대 3분이 걸릴 수가 있습니다. (아르고 체크 주기가 3분이기 때문)

따라서 수동으로 리프레시를 해서 변화상태를 감지하도록 합니다. 변화 상태가 감지되면 OutofSync로 상태가 변합니다.

 

sync 버튼 누르기

sync 버튼을 누르면 다음과 같이 nginx 에 반영된 것을 확인 가능합니다.

실습 자원 지우기

실습 자원 삭제 확인 모니터링

watch -d kubectl get all -n dev-nginx -o wide

아르고 서버에서 delete application

 

ArgoCD 선언형 으로 배포

선언적으로 배포하는 방식에 대한 자료는 공식문서를 참고바랍니다. ArgoCD Declarative Setup - Project, applications(ArgoCD App 자체를 yaml로 생성), ArgoCD Settings - Docs

 

1️⃣ Finalizer란?

  1. 리소스 정리 보장: 애플리케이션 삭제 시 관련 리소스가 남지 않도록 보장합니다. 이는 GitOps 워크플로우에서 선언적 상태를 유지하는 데 중요합니다.
  2. 의도치 않은 삭제 방지: finalizer가 없으면 실수로 Argo App을 삭제해도 K8S 리소스가 남아 혼란이 생길 수 있습니다. finalizer는 이를 방지합니다.
  3. App of Apps 패턴 지원: 여러 애플리케이션을 계층적으로 관리할 때, 상위 애플리케이션 삭제 시 하위 리소스까지 정리되도록 합니다.

⇒ 아르고 에서 앱을 삭제할 때 k8s 리소스 삭제를 보장합니다.

 

2️⃣ dev-nginx App 생성 및 Auto SYNC

apiVersion: argoproj.io/v1alpha1 아르고 프로젝트를 직접 생성합니다.

#
echo $MyIP

cat <<EOF | kubectl apply -f -
apiVersion: argoproj.io/v1alpha1
kind: **Application**
metadata:
  name: **dev-nginx**
  namespace: argocd
  **finalizers**:
  **- resources-finalizer.argocd.argoproj.io**
spec:
  project: default
  **source**:
    helm:
      valueFiles:
      - **values-dev.yaml**
    path: **nginx-chart**
    repoURL: **http://$MyIP:3000/devops/ops-deploy**
    targetRevision: HEAD
  **syncPolicy**:
    **automated**:
      **prune: true**
    syncOptions:
    - CreateNamespace=true
  **destination**:
    namespace: **dev-nginx**
    server: https://kubernetes.default.svc
EOF

해당 리소스를 생성하면 아르고 서버에도 애플리케이션이 생성된 것을 확인할 수 있습니다.

 

kubectl 로 확인해보기

#
kubectl get applications -n argocd dev-nginx
kubectl get applications -n argocd dev-nginx -o yaml | kubectl neat
kubectl describe applications -n argocd dev-nginx
kubectl get pod,svc,ep,cm -n dev-nginx

#
curl http://127.0.0.1:30000

Argo CD App 삭제

kubectl delete applications -n argocd dev-nginx

같은 방식으로 prd 버전도 생성하고 삭제해 봅니다.

cat <<EOF | kubectl apply -f -
apiVersion: argoproj.io/v1alpha1
kind: **Application**
metadata:
  name: **prd-nginx**
  namespace: argocd
  **finalizers**:
  - resources-finalizer.argocd.argoproj.io
spec:
  destination:
    namespace: **prd-nginx**
    server: https://kubernetes.default.svc
  project: default
  source:
    helm:
      valueFiles:
      - **values-prd.yaml**
    path: **nginx-chart**
    repoURL: **http://$MyIP:3000/devops/ops-deploy**
    targetRevision: HEAD
  **syncPolicy**:
    **automated**:
      **prune: true**
    syncOptions:
    - CreateNamespace=true
EOF

#
kubectl get applications -n argocd prd-nginx
kubectl describe applications -n argocd prd-nginx
kubectl get pod,svc,ep,cm -n prd-nginx

#
curl http://127.0.0.1:30000

# Argo CD App 삭제
**kubectl delete applications -n argocd prd-nginx**

 

Argo CD - Webhook 사용

Repo(ops-deploy) 에 Webhook 를 통해 Argo CD 에 즉시 반영 trigger하여 k8s 배포 할 수 있게 설정해 봅니다. - Docs

 

gogs에서 웹훅 추가

 

💡시나리오: 배포되어있는 nginx 서버에 개발 repo의 코드를 수정하여 반영(배포)

 

dev-nginx App 생성 및 Auto SYNC

cat <<EOF | kubectl apply -f -
apiVersion: argoproj.io/v1alpha1
kind: **Application**
metadata:
  name: **dev-nginx**
  namespace: argocd
  **finalizers**:
  - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  **source**:
    helm:
      valueFiles:
      - **values-dev.yaml**
    path: **nginx-chart**
    repoURL: **http://$MyIP:3000/devops/ops-deploy**
    targetRevision: HEAD
  **syncPolicy**:
    **automated**:
      **prune: true**
    syncOptions:
    - CreateNamespace=true
  **destination**:
    namespace: **dev-nginx**
    server: https://kubernetes.default.svc
EOF

 

Git(Gogs) 수정 후 ArgoCD 즉시 반영 확인

#
cd cicd-labs/ops-deploy/nginx-chart

# 레플리카 2->3
sed -i -e "s|replicaCount: 2|replicaCount: 3|g" values-dev.yaml
git add values-dev.yaml && git commit -m "Modify nginx-chart : values-dev.yaml" && git push -u origin main
watch -d kubectl get all -n dev-nginx -o wide

 

해당 코드 수정 후 gogs 리포에 푸시하자 바로 반영이 되는것을 확인할 수 있습니다.

 

아르고 서버에서 확인

 

이러한 방식으로 replica를 조절하며 테스트 해봅니다.

#
sed -i -e "s|replicaCount: 3|**replicaCount: 4**|g" **values-dev.yaml**
git add **values-dev.yaml** && git commit -m "Modify nginx-chart : values-dev.yaml" && **git push -u origin main**
watch -d kubectl get all -n dev-nginx -o wide

#
sed -i -e "s|replicaCount: 4|**replicaCount: 2**|g" **values-dev.yaml**
git add **values-dev.yaml** && git commit -m "Modify nginx-chart : values-dev.yaml" && **git push -u origin main**
watch -d kubectl get all -n dev-nginx -o wide

 

관련 리소스 삭제

**kubectl delete applications -n argocd dev-nginx**

 

CI/CD 자동화 해보기

이제 CI와 CD 모두를 연결한 CI/CD 를 자동화 해봅니다.

다시 한번 아키텍처를 리마인드 해봅니다.

 

소스코드 업로드

dev-app 디렉토리 생성

cd ops-deploy
mkdir dev-app

도커 허브 연동 설정

# 도커 계정 정보
DHUSER=<도커 허브 계정>
*DHUSER=gasida*

# 버전 정보 **
VERSION=0.0.1

이미지에 버전정보 지정

cat > dev-app/VERSION <<EOF
$VERSION
EOF

timeserver deployment 작성

cat > dev-app/timeserver.yaml <<EOF
*apiVersion: apps/v1
kind: **Deployment**
metadata:
  name: **timeserver**
spec:
  **replicas: 2**
  selector:
    matchLabels:
      pod: timeserver-pod
  **template**:
    metadata:
      labels:
        pod: timeserver-pod
    spec:
      containers:
      - name: timeserver-container
        image: docker.io/**$DHUSER**/**dev-app:$VERSION**
        **livenessProbe**:
          initialDelaySeconds: 30
          periodSeconds: 30
          **httpGet**:
            **path: /healthz**
            port: 80
            scheme: HTTP
          timeoutSeconds: 5
          failureThreshold: 3
          successThreshold: 1
      **imagePullSecrets:
      - name: dockerhub-secret***
EOF

도커허브 이미지 정보와 도커 인증정보를 사용합니다.

timeserver service 작성

cat > dev-app/service.yaml <<EOF
*apiVersion: v1
kind: **Service**
metadata:
  name: timeserver
spec:
  selector:
    pod: timeserver-pod
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    **nodePort: 3000**0
  type: NodePort*
****EOF

 

push 확인

 

Repo(ops-deploy) 를 바라보는 ArgoCD App 생성

ops-deploy 를 desired state 대상으로 할 argocd app을 생성합니다.

cat <<EOF | kubectl apply -f -
apiVersion: argoproj.io/v1alpha1
kind: **Application**
metadata:
  name: **timeserver**
  namespace: argocd
  **finalizers**:
  - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  **source**:
    path: **dev-app**
    repoURL: **http://$MyIP:3000/devops/ops-deploy**
    targetRevision: HEAD
  **syncPolicy**:
    **automated**:
      **prune: true**
    syncOptions:
    - CreateNamespace=true
  **destination**:
    namespace: **default**
    server: https://kubernetes.default.svc
EOF

 

Repo(dev-app) 코드 작업

 

1️⃣ dev-app Repo에 VERSION 업데이트 시 → ops-deploy Repo 에 dev-app 에 파일에 버전 정보 업데이트 작업 추가

  • 기존 버전 정보는 VERSION 파일 내에 정보를 가져와서 변수 지정 : OLDVER=$(cat dev-app/VERSION)
  • 신규 버전 정보는 environment 도커 태그 정보를 가져와서 변수 지정 : NEWVER=$(echo ${DOCKER_TAG})
  • 이후 sed 로 ops-deploy Repo 에 dev-app/VERSION, timeserver.yaml 2개 파일에 ‘기존 버전’ → ‘신규 버전’으로 값 변경
  • 이후 ops-deploy Repo 에 git push ⇒ Argo CD App Trigger 후 AutoSync 로 신규 버전 업데이트 진행

아래는 dev-app 에 위치한 Jenkinsfile 로 젠킨스에 SCM-Pipeline(SCM:git) 으로 사용되고 있는 파일을 수정해서 실습에 사용합니다.

vi ~cicd-labs/dev-app/Jenkinsfile

pipeline {
    agent any
    environment {
        DOCKER_IMAGE = '<자신의 도커 허브 계정>/dev-app' // Docker 이미지 이름
        GOGSCRD = credentials('gogs-crd')
    }
    stages {
        stage('dev-app Checkout') {
            steps {
                 git branch: 'main',
                 url: 'http://<자신의 집 IP>:3000/devops/dev-app.git',  // Git에서 코드 체크아웃
                 credentialsId: 'gogs-crd'  // Credentials ID
            }
        }
        stage('Read VERSION') {
            steps {
                script {
                    // VERSION 파일 읽기
                    def version = readFile('VERSION').trim()
                    echo "Version found: ${version}"
                    // 환경 변수 설정
                    env.DOCKER_TAG = version
                }
            }
        }
        stage('Docker Build and Push') {
            steps {
                script {
                    docker.withRegistry('https://index.docker.io/v1/', 'dockerhub-crd') {
                        // DOCKER_TAG 사용
                        def appImage = docker.build("${DOCKER_IMAGE}:${DOCKER_TAG}")
                        appImage.push()
                        appImage.push("latest")
                    }
                }
            }
        }
        stage('ops-deploy Checkout') {
            steps {
                 git branch: 'main',
                 url: 'http://<자신의 집 IP>:3000/devops/ops-deploy.git',  // Git에서 코드 체크아웃
                 credentialsId: 'gogs-crd'  // Credentials ID
            }
        }
        stage('ops-deploy version update push') {
            steps {
                sh '''
                OLDVER=$(cat dev-app/VERSION)
                NEWVER=$(echo ${DOCKER_TAG})
                sed -i "s/$OLDVER/$NEWVER/" dev-app/timeserver.yaml
                sed -i "s/$OLDVER/$NEWVER/" dev-app/VERSION
                git add ./dev-app
                git config user.name "devops"
                git config user.email "a@a.com"
                git commit -m "version update ${DOCKER_TAG}"
                git push http://${GOGSCRD_USR}:${GOGSCRD_PSW}@<자신의 집 IP>:3000/devops/ops-deploy.git
                '''
            }
        }
    }
    post {
        success {
            echo "Docker image ${DOCKER_IMAGE}:${DOCKER_TAG} has been built and pushed successfully!"
        }
        failure {
            echo "Pipeline failed. Please check the logs."
        }
    }
}

 

모니터링 띄워놓고 push 해보기

# [터미널] 동작 확인 모니터링
while true; do curl -s --connect-timeout 1 http://127.0.0.1:30000 ; echo ; kubectl get deploy timeserver -owide; echo "------------" ; sleep 1 ; done

 

# git push : VERSION, server.py, Jenkinsfile
git add . && git commit -m "VERSION $(cat VERSION) Changed" && git push -u origin main

그러면 이전에 생성했던 SCM-Pipeline을 트리거 하게 되고 Jenkinsfile에서 변경한 내용인 sed 구문이 적용되어 ops-deploy의 트리거가 발동되어 파이프라인이 두번 동작 하게 됩니다.

파이프라인 실패 공유

image.png

❗여러 시도 끝에 배포에 성공했습니다. console output 을 통해 sed 구문에 문제가 있었던 것을 파악했습니다.

image.png

sed 뒤에 ‘’ 와 같은 구문은 BSD 계열의 문법이라고 합니다.

sed -i '' "s/$OLDVER/$NEWVER/" dev-app/timeserver.yaml
sed -i '' "s/$OLDVER/$NEWVER/" dev-app/VERSION

sed -i "s/$OLDVER/$NEWVER/" dev-app/timeserver.yaml
sed -i "s/$OLDVER/$NEWVER/" dev-app/VERSION

 

 

아르고 웹서버에서 배포가 된것을 확인합니다.

 

timeserver의 이미지가 0.0.3으로 변경된 것을 확인합니다.

 

이와 같은 방법으로 0.0.4, 0.0.5 버전까지 업데이트 해봅니다.

sed -i "s/0.0.3/0.0.4/" VERSION
sed -i "s/0.0.3/0.0.4/" server.py

git add . && git commit -m "VERSION $(cat VERSION) Changed" && git push -u origin main

 

ArgoCD 더 알아보기

 

ArgoCD Image Updater

 

ArgoCD 이미지 업데이트 기존 방식

Argo CD는 Git 저장소를 지속적으로 감시하여, 변경된 배포 설정 파일(YAML)을 감지하면 Kubernetes 클러스터에 자동으로 반영합니다.

CI 파이프라인에서 애플리케이션 이미지를 빌드하고, 버전 정보를 Git에 반영하면, Argo CD는 이를 감지하여 해당 이미지로 Kubernetes 리소스를 업데이트합니다.

 

ArgoCD 이미지 업데이터 방식

이 방식은 CI가 Git 설정파일을 직접 수정하지 않고, 이미지 빌드 후 레지스트리에만 푸시합니다.

Argo CD Image Updater가 Container Registry를 주기적으로 감시하여 새로운 태그가 감지되면 Git에 반영합니다. 이후 Argo CD는 Git의 변경을 감지하고, 클러스터에 자동 배포합니다.

이 방식은 기존의 CI가 sed, git push로 버전을 직접 조작하던 방식에서 → Argo CD + Image Updater가 Git 상태를 주도적으로 관리하는 구조로 전환된 형태입니다. 보안성, Git 상태 관리, 확장성 측면에서 유리하다고 볼 수 있습니다.

ArgoCD App of Apps 패턴

https://malwareanalysis.tistory.com/478

 

 

App of Apps는 말 그대로 하나의 “루트 App”이 여러 개의 “하위 App”들을 정의하고 관리하는 Argo CD 배포 패턴입니다. 루트 App은 Git 저장소의 여러 Application 정의 파일들을 참조합니다. 이 루트 App이 동기화되면 하위 App들도 자동으로 생성 및 동기화됩니다.

 

app of apps 장점

1. 구성 관리의 계층화 (Hierarchy)

마이크로서비스 구조나 환경별(dev, prd) 분리 관리에 유리

2. GitOps 확장성

수십 개의 앱도 루트 App 하나로 일괄 관리 가능

대규모 팀이나 조직에서 서비스 분리를 쉽게 유지

3. 자동화된 앱 등록

하위 App을 Git에만 추가하면 루트 App이 이를 자동으로 생성

4. 버전, 팀, 도메인 별로 관리 용이

예: team-a-apps/, team-b-apps/ 등 디렉토리로 분리해 운영 가능

 

ArgoCD App of Apps 패턴 실습

#
cd cicd-labs
git clone https://github.com/argoproj/argocd-example-apps.git
tree argocd-example-apps

 

헬름 template으로 리소스 살펴보기

**helm template -f argocd-example-apps/apps/values.yaml argocd-example-apps/apps**

 

아르고 애플리케이션 배포하기 (declarative)

# you need to create and sync your parent app
**cat <<EOF | kubectl apply -f -**
apiVersion: argoproj.io/v1alpha1
kind: **Application**
metadata:
  name: **apps**
  namespace: argocd
  finalizers:
  - resources-finalizer.argocd.argoproj.io
**spec**:
  project: default
  **source**:
    **path**: **apps**
    **repoURL**: **https://github.com/argoproj/argocd-example-apps.git**
    targetRevision: HEAD
  **destination**:
    namespace: **argocd**
    server: https://kubernetes.default.svc
  **syncPolicy**:
    **automated**:
      **prune: true**
**EOF**

 

아르고 서버로 가보면 apps라는 이름의 application이 생성된 걸 볼 수 있습니다.

**kubectl get applications -n argocd --show-labels**

싱크 안맞는 녀석들을 싱크해줍니다. 애플리케이션 대시보드에서 라벨링을 걸어서 필터링 해줍니다.

잠시 뒤 싱크가 완성된 것을 확인할 수 있습니다.

 

ArgoCD App of Apps 을 삭제할때는 cascade 방식으로 삭제됩니다.

**kubectl delete applications -n argocd apps**

 

Argo Rollout

Argo Rollouts는 Kubernetes에서 고급 배포 전략(카나리, 블루-그린 등)을 지원하는 컨트롤러입니다. 기존 Deployment보다 더 세밀하게 트래픽 분할, 자동 중단/롤백, 모니터링 연동 등을 설정할 수 있게 해줍니다.

즉, 점진적이고 안전한 애플리케이션 배포를 도와주는 도구입니다.

Argo Rollouts 설치

# 네임스페이스 생성 및 파라미터 파일 작성
cd cicd-labs

kubectl create ns argo-rollouts
cat <<EOT > argorollouts-values.yaml
dashboard:
  enabled: true
  service:
    type: NodePort
    nodePort: 30003
EOT

# 설치: 2.35.1
helm install argo-rollouts argo/argo-rollouts --version 2.39.2 -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"
  • 노드포트 30003 번에 설치해줍니다.
  • helm version 2.39.2

현재 롤아웃 중인 서비스가 없기 때문에 loading 으로 표시됩니다.

 

롤아웃 해보기

  • 먼저, 롤아웃 리소스와 해당 롤아웃을 타겟으로 하는 Kubernetes 서비스를 배포합니다.
  • 이 가이드의 예제 롤아웃은 카나리아 업데이트 전략을 사용하여 트래픽의 20%를 카나리로 보내고, 이어서 수동 프로모션을 실시하며, 마지막으로 업그레이드의 나머지 기간 동안 점진적으로 자동 트래픽이 증가합니다.
  • 이 동작은 롤아웃 사양의 다음 부분에서 설명됩니다:
  • spec: replicas: 5 strategy: canary: steps: - setWeight: 20 - pause: {} - setWeight: 40 - pause: {duration: 10} - setWeight: 60 - pause: {duration: 10} - setWeight: 80 - pause: {duration: 10}

롤아웃할 서비스를 배포합니다.

kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/basic/rollout.yaml
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/basic/service.yaml

 

배포 리소스 확인

**kubectl get rollout --watch**
kubectl get rollout
kubectl describe rollout

 

웹화면에서 확인합니다. 우측 상단의 네임스페이스를 default로 설정합니다

 

해당 위젯을 클릭하면 다음과같이 배포 시나리오가 명세되어있습니다.

 

롤아웃 업데이트

간단하게 이미지를 업데이트 하여 rollout 동작을 확인합니다.

KUBE_EDITOR="nano" kubectl edit rollouts rollouts-demo

 

이미지만 yellow로 바꿔줍니다.

 

신규 파드를 모니터링 하고 상태가 괜찮다면 우측 상단의 promote를 하여 점진적으로 20% 씩 배포합니다.

 

실습 종료

지금까지 k8s 환경에서 ci/cd를 구현하는 실습을 해봤습니다.

실습 자원 삭제

간단하게 한줄로 실습 자원을 삭제합니다.

**docker compose down --volumes --remove-orphans && kind delete cluster --name myk8s**

 

도전과제

다음 포스팅에는 다음 중 한가지 주제로 포스팅 해보도록 하겠습니다.

도전과제1 : Jenkins 를 AWS EKS에 In-Cluster 에 설치(파드로 기동)해서 사용해보자 - KrBlog

도전과제2 : Gogs 를 AWS EKS에 In-Cluster 에 설치(파드로 기동)해서 사용해보자

도전과제3 : Gogs 대신 GitHub Private Repo 를 생성해서 사용해보자

도전과제4 : kind 대신 AWS EKS를 사용해서 실습 진행해보자

도전과제5 : Docker Hub 저장소 대신 AWS ECR 저장소를 사용해서 실습 진행해보자

도전과제6 : 디플로이먼트에 파드 컨테이너 이미지에 latest 사용해서 배포 후 이미지 버전 업데이트 후 적용 방안? (예. imagePullPolicy:Always) - Docs

도전과제7 : Multi-Arch(CPU) 컨테이너 이미지를 빌드할 수 있게 Jenkins Pipeline 을 작성(업데이트) 해보자

도전과제8 : Jenkins 에 Gogs Webhook 대신 범용 Webhook 플러그인를 사용해보자

도전과제9 ArgoCD 에 User 에 API Key 발급 후 ArgoCD API(SYNC/DELETE)를 호출하여 Trigger 동작 설정 - Docs

도전과제10 ArgoCD에 HPA를 포함하는 Sample Deployment 를 배포해보고 App 생성 시 추가 설정을 고려해보자

도전과제11 AWS EKS 환경에서 AWS ECR 과 GitHub Private Repo 를 사용하여 위 과정과 유사한 Full CI/CD를 구성해보자!

도전과제12 ArgoCD Image Updater 를 이용하여 dev-app Repo 에 컨테이너 이미지 버전 업그레이드 시 자동 동작 설정 해보기

도전과제13 Argo CD ApplicationSet 으로 배포해보기 - Docs , Generating Applications with ApplicationSet - Docs

도전과제14 ArgoCD Autopilot: ArgoCD 및 GitOps 환경 자동 구축해보기 - Docs , 장성필님 - krBlog , 악분님 (배경소개) - Blog

도전과제15 Argo Rollout 시, Ingress (or AWS ALB)나 Gateway API를 활용해보자 - Docs , Blog , Docs2 , ALB

도전과제16 Argo Rollout 에 분석을 통한 점진적 전환 ‘Analysis & Progressive Delivery’ 기능을 테스트 해보자 - Docs

도전과제17 [GitOps Bridge] Argo CD on Amazon EKS 배포를 해보자 - Link

도전과제18 [GitOps Bridge] ArgoCD Multi-Cluster Hub & Spoke - Link , Gitub

'AWS > EKS' 카테고리의 다른 글

K8s 시크릿 관리 with Vault  (0) 2025.04.13
EKS Upgrades  (0) 2025.04.06
K8S 환경에서 CI/CD 구축하기 - 1  (0) 2025.03.30
EKS Auto Mode  (0) 2025.03.23
EKS Security - OPA 로 정책 적용하기  (0) 2025.03.16
'AWS/EKS' Related Articles more