본문 바로가기
IT & Tech 정보

자동 롤백 전략 끝판왕 가이드: Helm + Kubernetes Liveness/Readiness 프로브

by 지식과 지혜의 나무 2025. 5. 26.
반응형




1. 서론: 왜 자동 롤백인가

대규모 마이크로서비스·지속 배포(CD) 환경에서는 기능 배포 중 작은 버그 하나가 전체 서비스 가용성을 무너뜨릴 수 있습니다. 수동 모니터링 → 수동 롤백은 피드백 루프가 너무 길어 고객 피해가 커집니다.
자동 롤백을 도입하면, 배포 중 문제 감지 즉시 이전 안정 버전으로 되돌려 가용성을 지키며:
• 리스크 최소화: 잘못된 릴리즈가 운영에 영향을 주기 전에 차단
• 운영 효율 극대화: 사람이 개입하지 않아도 자동 복구
• 피드백 단축: 배포 실패 시점부터 다음 릴리즈까지 걸리는 시간 단축

이 가이드에서는 Helm의 롤백 기능과 Kubernetes의 Liveness/Readiness Probe를 결합해 완전 자동화된 롤백 전략을 구현하는 ‘끝판왕’ 방법을 살펴봅니다.



2. 아키텍처 개요

Git Repo ──▶ CI/CD (GitHub Actions, Jenkins, ArgoCD) ──▶ Helm Upgrade  
                                                        │
                                                        ▼
                                              ┌──────────────────┐
                                              │ Kubernetes Cluster│
                                              │ ┌──────────────┐ │
                                              │ │ Deployment   │ │
                                              │ │ ┌─Pod────────┐│
                                              │ │ │App Container││
                                              │ │ └─Probes─────┘│
                                              │ └──────────────┘ │
                                              └──────────────────┘
                                                        │
                                     Probe Failure       │
                                     (readiness=false)   ▼
                                                  Automated Rollback
                                                  (Helm Rollback)

1. CI/CD 단계에서 helm upgrade 실행
2. Deployment 내 Pods에 readinessProbe 설정
3. Probe가 연속 실패 시 Deployment 상태가 Unavailable
4. CI/CD 시스템 또는 Kubernetes Operator가 실패 감지 → helm rollback 자동 실행



3. Helm을 활용한 롤백 전략 심화

3.1 Helm 기본 롤백

# 릴리즈 히스토리 확인
helm history myapp --namespace prod

# 마지막 성공 버전(REV)으로 롤백
helm rollback myapp <REV> --namespace prod

• helm history → helm rollback의 수동 흐름

3.2 자동 롤백을 위한 Helm Hook

# charts/myapp/templates/hooks.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: "{{ include "myapp.fullname" . }}-post-upgrade-test"
  labels:
    app.kubernetes.io/instance: "{{ .Release.Name }}"
  annotations:
    "helm.sh/hook": post-upgrade
    "helm.sh/hook-delete-policy": hook-succeeded,hook-failed
spec:
  template:
    spec:
      containers:
      - name: test
        image: {{ .Values.image.test }}
        command: ["sh", "-c", "./scripts/smoke_test.sh"]
      restartPolicy: Never
  backoffLimit: 0

• post-upgrade 후 smoke_test.sh 실행
• 실패 시 Job 상태=Failed → Helm은 릴리즈를 Failed로 표시
• CI/CD 스크립트에서 종료 코드 확인 후 자동 helm rollback

3.3 CI/CD에서의 자동 롤백

# GitHub Actions snippet
- name: Deploy with Helm
  run: |
    helm upgrade --install myapp ./charts/myapp --namespace prod
    if kubectl get job myapp-post-upgrade-test -n prod -o jsonpath='{.status.failed}' | grep -q '[1-9]'; then
      echo "Smoke test failed, rolling back..."
      helm rollback myapp
      exit 1
    fi

• post-upgrade Job 결과로 롤백 결정
• exit 1로 파이프라인 실패 처리



4. Kubernetes Liveness & Readiness Probes 고급

4.1 Readiness Probe로 배포 불가 상태 감지

# charts/myapp/templates/deployment.yaml
readinessProbe:
  httpGet:
    path: /healthz/ready
    port: http
  initialDelaySeconds: 5
  periodSeconds: 10
  failureThreshold: 3

• failureThreshold=3 연속 실패 시 Pod는 Ready 상태→NotReady
• Deployment는 가용도(availableReplicas < desired) 판단

4.2 Liveness Probe로 롤백 트리거

livenessProbe:
  tcpSocket:
    port: metrics
  initialDelaySeconds: 30
  periodSeconds: 15
  failureThreshold: 4

• 컨테이너 비정상 시 Restart
• 반복 재시작(CrashLoopBackOff) 발생 시 Deployment 불안정 → 자동 롤백 로직 동작

4.3 Deployment 상태 감시

kubectl rollout status deployment/myapp -n prod --timeout=120s

• 타임아웃 발생 시 CI/CD 스크립트로 helm rollback 실행



5. CI/CD 파이프라인 예시

5.1 GitHub Actions

name: CD with Auto-Rollback

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Helm Upgrade
        run: helm upgrade --install myapp ./charts/myapp --namespace prod

      - name: Wait for Rollout
        run: |
          if ! kubectl rollout status deployment/myapp -n prod --timeout=2m; then
            echo "Rollout failed, rolling back..."
            helm rollback myapp
            exit 1
          fi

      - name: Verify Health
        run: |
          READY=$(kubectl get pods -l app=myapp -n prod \
                   -o jsonpath='{.items[*].status.containerStatuses[*].ready}')
          if echo "$READY" | grep -vq "true"; then
            echo "Pods not ready, rolling back..."
            helm rollback myapp
            exit 1
          fi

5.2 Jenkins Pipeline

pipeline {
  agent any
  stages {
    stage('Deploy via Helm') {
      steps {
        sh 'helm upgrade --install myapp ./charts/myapp --namespace prod'
      }
    }
    stage('Rollout Status') {
      steps {
        script {
          def status = sh(
            script: "kubectl rollout status deployment/myapp -n prod --timeout=120s",
            returnStatus: true
          )
          if (status != 0) {
            error "Rollout failed"
          }
        }
      }
    }
  }
  post {
    failure {
      sh 'echo "Deployment failed, rolling back..."'
      sh 'helm rollback myapp'
    }
  }
}




6. 고급 패턴 & “아, 이런 방법도”
1. Progressive Rollout + Rollback
• Deployment.strategy.rollingUpdate maxUnavailable=1 maxSurge=1
• kubectl rollout status로 단계별 모니터링 후 즉시 롤백
2. Canary Releases
• Helm Chart에 Argo Rollouts CRD 통합
• AnalysisTemplate와 Rollback Hook으로 자동 복귀
3. Custom Metrics 기반
• Prometheus Alert(for: 30s) 감지 → Alertmanager Webhook → CI/CD API로 helm rollback
4. Operator 활용
• FluxCD Image Automation combined with Helm Operator 오류→자동 롤백
5. Dry-Run 검증

helm upgrade --install myapp ./charts/myapp --namespace prod --dry-run --debug





7. 결론
• Helm Hook + post-upgrade Job 으로 강력한 롤백 트리거
• Liveness/Readiness Probes 로 배포 중 서비스 불안정 감지
• CI/CD 통합 을 통해 완전 자동 롤백 파이프라인 실현
• 고급 패턴(Canary, Metrics, Operator) 으로 복원력 극대화

“교과서론 절대 다루지 않는, 실리콘밸리·심천 IT기업 톱티어 엔지니어급 자동 롤백 전략”을 직접 구현해 보세요. 배포 위험은 0, 가용성은 100% 달성하는 그날까지!

반응형