GitOps Cookbook 8장: 고급 주제

8.0 들어가며

GitOps의 기본 구조는 “Git 선언 → 자동 동기화 → 상태 유지”지만, 실제 운영환경에서는 보안, 멀티클러스터, 승인 흐름, 점진적 배포 등 복잡한 요구가 생긴다.
이 장에서는 Argo CD를 중심으로 이런 고급 주제를 다룬다.

---

8.1 민감한 데이터 암호화 (복원된 시크릿)

GitOps와 봉인된 시크릿

GitOps의 핵심 원칙은 “모든 설정을 Git에 저장한다”지만, 문제는 시크릿(Secret)이다.
비밀번호, 토큰, 인증서 등을 그대로 Git에 넣을 수는 없다. 이를 안전하게 관리하기 위해 다음 세 가지 접근법이 사용된다.

1. Sealed Secrets (Bitnami)
   • 쿠버네티스 Secret을 암호화된 형태로 Git에 저장.
   • Sealed Secrets Controller가 클러스터에서 자동 복호화.
   • Git에는 복호화 불가능한 공개키 기반 암호문만 남는다.
2. SOPS (Mozilla SOPS)
   • YAML 내 특정 필드를 GPG/AES/KMS로 암호화.
   • Argo CD는 SOPS 플러그인을 통해 복호화 가능.
   • Git에는 암호화된 YAML만 저장, 배포 시 자동 복호화.
3. External Secret Operator (ESO)
   • Secret을 Git에 저장하지 않고 AWS Secrets Manager, GCP Secret Manager, Vault 등 외부 저장소에서 직접 불러온다.
   • Git에는 “이 Secret을 가져와라”는 선언만 저장.

---

8.1 민감한 데이터 암호화 (복원된 시크릿)

GitOps는 모든 쿠버네티스 선언을 Git으로 관리한다는 원칙을 가진다.
하지만 문제는 언제나 Secret이다.
비밀번호, API 토큰, 인증서 등은 그대로 Git에 저장할 수 없다.
이를 해결하기 위해 GitOps 환경에서는 암호화된 시크릿 관리 기법을 사용한다.

---

8.1.1 Sealed Secrets 개요

Sealed Secrets는 Bitnami에서 만든 쿠버네티스용 시크릿 암호화 솔루션으로,
“암호화된 Secret을 Git에 저장하고, 클러스터에서만 복호화되는 구조”를 제공한다.

핵심 아이디어는 다음과 같다:

1. 클러스터에 Sealed Secrets Controller를 설치하면,
   내부적으로 공개키/비공개키 쌍을 생성한다.
2. 개발자는 kubeseal CLI를 사용해 Secret YAML을 공개키로 암호화한다.
3. 이 암호화된 결과(SealedSecret)를 Git에 커밋한다.
4. Argo CD는 Git에서 SealedSecret 리소스를 읽어 클러스터에 배포한다.
5. Controller가 비공개키로 복호화하여 실제 Secret 리소스를 생성한다.

즉, Git에는 복호화 불가능한 암호문만 남고, 복호화는 클러스터 내부에서만 일어난다.
이로써 GitOps 원칙(선언형 관리) + 보안성(Secret 노출 방지) 두 가지를 동시에 만족시킨다.

---

8.1.2 Sealed Secrets 설치

# Sealed Secrets Controller 설치
kubectl apply -f https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.25.0/controller.yaml

설치 후 다음 리소스가 생성된다:

• sealed-secrets 네임스페이스
• sealed-secrets-controller Pod
• tls 키 쌍 (controller 내부에서 자동 생성됨)

---

8.1.3 kubeseal CLI 사용 예시

1. 일반 Secret 생성
2. kubectl create secret generic my-secret \ --from-literal=password='s3cr3t' \ --dry-run=client -o yaml > my-secret.yaml
3. kubeseal로 암호화결과 예시:
4. apiVersion: bitnami.com/v1alpha1 kind: SealedSecret metadata: name: my-secret namespace: default spec: encryptedData: password: AgA3x...
5. kubeseal --format yaml < my-secret.yaml > my-sealedsecret.yaml
6. 이 파일(my-sealedsecret.yaml)을 Git에 커밋하고 Argo CD가 이를 동기화하도록 설정한다.
7. Argo CD Sync 시, Sealed Secrets Controller가 자동 복호화하여 실제 Secret 생성:
8. kubectl get secret my-secret -o yaml

이렇게 하면 Secret은 Git에 평문으로 저장되지 않고, GitOps 파이프라인은 완전히 선언형으로 유지된다.

---

8.1.4 SOPS (Mozilla SOPS)

다른 접근으로는 SOPS가 있다.
SOPS는 YAML/JSON 내 특정 필드만 선택적으로 암호화할 수 있고,
GPG, AWS KMS, GCP KMS, Azure Key Vault 등을 백엔드로 활용한다.

sops --encrypt --in-place values.yaml

Argo CD는 SOPS 플러그인을 통해 Git에서 암호화된 파일을 읽고,
배포 직전에 복호화하여 매니페스트를 적용할 수 있다.
이 방식은 “파일 수준 암호화”로, 별도 CRD(SealedSecret) 없이 작동한다.

---

8.1.5 External Secrets Operator (ESO)

다음 단계의 보안 강화 방법은 시크릿을 Git에 두지 않는 것이다.
External Secrets Operator를 이용하면 Git에는 단순히 “이 Secret을 불러와라”는 선언만 저장하고,
실제 값은 외부 비밀저장소에서 가져온다.

예시:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-store
    kind: ClusterSecretStore
  target:
    name: db-credentials
  data:
    - secretKey: password
      remoteRef:
        key: secret/data/db
        property: password

Git에는 ExternalSecret만 저장되고,
실제 값은 HashiCorp Vault나 AWS Secrets Manager에서 자동 동기화된다.

---

8.1.6 결론

GitOps 환경에서 Secret 관리의 핵심은 “Git은 선언만, 실데이터는 보호된 영역에서”라는 원칙이다.
작은 규모에서는 Sealed Secrets이 가장 단순하고,
기업 환경에서는 Vault나 SOPS 기반으로 확장하는 것이 일반적이다.

이 8.1절에서 다룬 Sealed Secrets과 kubeseal은 GitOps의 첫 번째 보안 계층이다 —
코드형 선언을 유지하면서도 비밀정보가 Git에 남지 않게 만드는 기술적 기반이다.

---

8.2 ArgoCD의 시크릿 암호화

Argo CD와 외부 시크릿

(Argo CD + HashiCorp Vault + 외부 시크릿 통합)

Argo CD 자체도 Repo Credential, Cluster Credential, Helm Value 등 여러 시크릿을 다룬다.
이를 외부 Vault 시스템과 통합하면 보안성을 한 단계 높일 수 있다.

• HashiCorp Vault 연동
  • Argo CD의 argocd-repo-server에 Vault 플러그인을 설치.
  • Helm values나 Kustomize overlays 안에서 vault:// 형태로 변수 참조.
  • 배포 시점에 Vault에서 실시간으로 값이 주입됨.
  • Vault Agent Injector를 이용하면 Pod 실행 시점에도 자동 주입 가능.
• Argo CD Vault Plugin (AVP)
  • SOPS보다 단순하게 Vault 연동만 담당하는 플러그인.
  • Helm Chart나 YAML 내 ${vault:secret/data/myapp#key} 같은 문법 사용 가능.
  • 복호화된 결과는 Argo CD가 클러스터에 apply하기 직전에 주입.

이 구성을 통해 시크릿을 Git에 두지 않고, GitOps 파이프라인 내에서만 안전하게 해석하는 환경을 만든다.

---

8.3 애플리케이션 자동 배포 트리거 (Argo CD 웹훅)

기본적으로 Argo CD는 Git 변경을 주기적으로 폴링(기본 3분 주기)한다.
그러나 실시간 배포를 원한다면 Webhook 트리거를 연결해야 한다.

• Git Webhook 설정
  • GitHub, GitLab, Gogs 등에서 push 이벤트 발생 시
    Argo CD API Server의 /api/webhook 엔드포인트로 POST 전송.
  • 예시:
  • http://argocd.example.com/api/webhook Content-Type: application/json
• 자동 트리거 동작
  • push 이벤트 → Argo CD가 변경된 repo 감지 → 즉시 Sync.
  • syncPolicy.automated가 활성화되어 있으면 배포까지 자동 수행.

이 구조로 Git push → 자동 빌드 → Argo CD 자동 Sync까지 완전한 GitOps 루프가 완성된다.

---

8.4 여러 클러스터에 배포 (Multi-Cluster Deployment)

실제 운영 환경에서는 dev, staging, prod 클러스터가 물리적으로 분리되어 있는 경우가 많다.
Argo CD는 단일 서버에서 여러 클러스터에 동시 배포가 가능하다.

• 클러스터 등록이 명령은 대상 클러스터의 kubeconfig 정보를 Secret으로 등록한다.
• argocd cluster add <context-name>
• Application 분리
  • destination.server 필드에 클러스터 주소를 지정:
  • destination: server: https://cluster-dev.example.com namespace: dev
  • 같은 repo, 같은 chart를 여러 클러스터에 다른 values로 배포 가능.
• ApplicationSet Controller 활용
  • 여러 클러스터를 자동으로 탐색해 동일 Application을 생성.
  • 예: dev, staging, prod 클러스터 목록을 ConfigMap 또는 Git으로 관리.

이 구조는 중앙 Argo CD가 여러 클러스터를 제어하는 “Control Plane” 역할을 하게 만든다.

---

8.5 클러스터에 PR 배포 (Pull Request 기반 배포)

운영 환경에서는 단순 “push 자동 배포” 대신, PR 기반 승인형 배포(Approval Flow) 가 중요하다.

• PR 생성형 GitOps
  1. CI 단계(Tekton, GitHub Actions 등)가 새 이미지 버전을 빌드.
  2. Helm/Kustomize values의 이미지 태그를 변경하고 PR 생성.
  3. 리뷰/승인 후 merge 시점에 Argo CD가 Sync → 실제 배포.
• PR 미리보기 환경 (Preview Environment)
  • PR마다 ephemeral 네임스페이스를 만들고 해당 브랜치 코드를 배포.
  • Argo CD ApplicationSet의 PullRequest Generator 기능으로 자동화 가능.
  • PR이 닫히면 환경 자동 삭제.

이 방식은 승인, 감사, 실험(Preview)을 자연스럽게 GitOps 프로세스에 통합한다.

---

8.6 고급 배포기법 사용

이 절에서는 Argo CD 환경에서의 고급 배포 전략(Advanced Deployment Strategy) 을 다룬다.
단순히 kubectl apply 수준의 즉시 배포가 아니라,
무중단·점진적·안정적 배포를 목표로 하는 패턴들을 살펴본다.

대표적인 방법으로는 Blue-Green, Canary, 그리고 Service Mesh(Istio) 기반 트래픽 라우팅 방식이 있다.

---

8.6.1 Blue-Green Deployment

Blue-Green 배포는 두 개의 환경(Blue/Green)을 번갈아 사용하는 방식이다.

• 기존 버전(Blue)을 유지하면서, 새 버전(Green)을 동시에 띄운다.
• 서비스의 트래픽을 Blue에서 Green으로 전환(switch)하면, 다운타임 없이 새 버전이 적용된다.
• 문제가 발생하면 즉시 Blue로 되돌릴 수 있다(rollback).

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: green
---
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
    version: green  # ← blue에서 green으로 전환

이 패턴은 서비스 전환만으로 배포가 완료되므로, 속도와 안정성이 뛰어나다.
Argo CD에서는 이 과정을 Sync Wave와 Hook으로 세밀하게 제어할 수 있다.

---

8.6.2 Canary Deployment

Canary 배포는 새 버전의 일부 트래픽만 전송해 점진적으로 배포를 확장하는 기법이다.
예를 들어 트래픽의 10%만 새 버전으로 보내고, 모니터링 결과가 안정적일 때 50%, 100%로 확대한다.

이 전략은 Argo Rollouts에서 지원하는 핵심 기능이다.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp
spec:
  strategy:
    canary:
      steps:
      - setWeight: 10
      - pause: {duration: 60}
      - setWeight: 50
      - pause: {duration: 60}
      - setWeight: 100
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: nginx:1.27.0

Argo Rollouts Controller는 이 선언에 따라 Deployment를 생성/관리하며,
각 단계별로 Prometheus나 Datadog 메트릭을 모니터링해 자동으로 중단(fail) 또는 진행(success)시킨다.

---

8.6.3 Istio를 활용한 트래픽 기반 점진적 배포

Argo Rollouts는 Istio, NGINX, ALB, Traefik 등과 통합할 수 있다.
특히 Istio를 사용하면 HTTP 트래픽을 세밀하게 제어할 수 있다.

예시: Argo Rollouts + Istio VirtualService 연동

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - myapp.example.com
  http:
  - route:
    - destination:
        host: myapp
        subset: stable
      weight: 90
    - destination:
        host: myapp
        subset: canary
      weight: 10
---
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp
spec:
  strategy:
    canary:
      trafficRouting:
        istio:
          virtualService:
            name: myapp
            routes:
            - http
      steps:
      - setWeight: 10
      - pause: {duration: 60}
      - setWeight: 50
      - pause: {duration: 60}
      - setWeight: 100

이 구성에서 Argo Rollouts는 Istio의 VirtualService를 제어하면서
트래픽을 Canary 버전으로 점진적으로 전환한다.
Prometheus나 Istio metrics를 기반으로 에러율, 응답 시간 등을 자동 평가하여
불안정 시 즉시 이전 버전으로 복귀할 수도 있다.

이 구조는 운영 중단 없이 “실시간 트래픽 상태를 기반으로 한 배포 결정” 이 가능하다는 점에서
대규모 서비스 환경에 특히 유리하다.

---

8.6.4 Sync Wave / Hook 제어

Argo CD는 sync-wave와 hook 개념으로 리소스 배포 순서와 시점을 세밀하게 조정할 수 있다.

• Sync Wave: 리소스별 배포 순서 지정Wave 0 → Wave 1 → Wave 2 순서로 적용된다.
• metadata: annotations: argocd.argoproj.io/sync-wave: "1"
• Hooks: 특정 시점에 동작하는 스크립트 실행
  • PreSync, Sync, PostSync 단계에서 Job이나 Script 실행 가능
  • 예: DB Migration, Smoke Test, Notification 등

이 기능을 조합하면 배포 전후 검증 및 후처리를 Git 선언으로 관리할 수 있다.

---

8.6.5 고급 배포 전략 요약

전략 핵심 개념 도입 목적 주요 도구

Blue-Green	두 환경을 번갈아 사용	다운타임 없는 전환	Argo CD Hooks
Canary	점진적 트래픽 전환	안정성 검증	Argo Rollouts
Istio Traffic Routing	HTTP 레벨 세밀한 트래픽 제어	대규모 서비스 안정화	Istio + Rollouts
Sync Wave / Hook	순차적 리소스 배포	종속성 관리 및 검증	Argo CD Core

---

8.6.6 결론

고급 배포 전략의 핵심은 “점진적이고 검증 가능한 변경”이다.
Argo CD와 Istio, Argo Rollouts를 함께 사용하면
GitOps 환경에서도 완전한 Progressive Delivery를 구현할 수 있다.

이 조합을 통해 팀은 단순히 코드를 배포하는 것을 넘어,
실시간 트래픽 기반의 자동화된 배포 의사결정을 수행할 수 있다 —
즉, GitOps가 Continuous Deployment(지속 배포)를 넘어
Continuous Verification(지속 검증) 단계로 진화하는 것이다.

---

정리

8장은 GitOps를 실제 운영 환경으로 확장하기 위한 핵심 기능들을 다룬다.

• 시크릿과 민감 데이터의 암호화 (Sealed Secret, SOPS, ESO[Vault, External Secret)
• Vault와 Argo CD의 통합
• Webhook을 통한 실시간 자동 배포 트리거
• 멀티클러스터 제어 및 ApplicationSet을 통한 반복 배포
• PR 기반 승인형 배포 및 미리보기 환경 자동화
• Blue-Green / Canary /  Istio Traffic Routing / Sync Wave 등 고급 배포 전략

즉, 7장이 “GitOps의 기본 골격”이었다면, 8장은 보안·자동화·확장성·안정성을 실전 수준으로 끌어올리는 단계다.