13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[태그:] GitOps

  • [k8s] Argo CD 멀티 클러스터 GitOps 도입 사례: 운영 노하우와 도전 과제

    [k8s] Argo CD 멀티 클러스터 GitOps 도입 사례: 운영 노하우와 도전 과제

    [인프라] Argo CD 멀티 클러스터 GitOps 도입 사례: 운영 노하우와 도전 과제

    안녕하세요, 13년차의 서버실 운영자입니다. 오늘은 제가 직접 겪었던 경험을 바탕으로 Argo CD 멀티 클러스터 GitOps 도입 사례에 대해 이야기해볼까 합니다. 쿠버네티스(Kubernetes)를 운영하다 보면 자연스럽게 여러 클러스터를 관리해야 하는 상황에 부딪히게 되죠. 개발, 스테이징, 프로덕션 환경을 분리하거나, 재해 복구(Disaster Recovery)를 위해 지리적으로 분산된 클러스터를 운영하는 경우도 많고요. 처음엔 각각의 클러스터에 배포하는 것도 정말 힘들었는데, 이 모든 것을 효율적으로 관리하려니 골머리가 지끔했었습니다. 혹시 이런 경험 있으신가요?

    저도 처음엔 수동 배포와 스크립트의 늪에서 헤맸습니다. 그러다 GitOps(깃옵스)라는 개념을 접하고, 특히 Argo CD(아르고 CD)가 이 문제를 해결해 줄 수 있다는 걸 알게 되었죠. 특히 여러 클러스터를 한 곳에서 관리할 수 있는 Argo CD 멀티 클러스터 기능은 정말 반가웠습니다. 오늘은 이 기능을 도입하면서 제가 겪었던 삽질과 노하우, 그리고 얻었던 운영 효율성에 대해 솔직하게 풀어보려 합니다.

    Argo CD 멀티 클러스터 GitOps 아키텍처 다이어그램

    Argo CD 멀티 클러스터 GitOps의 전체 아키텍처 다이어그램입니다. 중앙의 Argo CD 컨트롤 플레인이 여러 쿠버네티스 클러스터에 애플리케이션을 배포하고 관리하는 모습을 보여줍니다.

    GitOps와 Argo CD, 그리고 멀티 클러스터 관리

    먼저, GitOps(깃옵스)가 뭔지 간단히 짚고 넘어가 보겠습니다. 쉽게 말하면, Git(깃) 저장소를 진리의 원천(Source of Truth)으로 삼아 인프라와 애플리케이션 배포를 관리하는 방식이에요. 모든 변경 사항은 Git에 기록되고, Git의 상태와 실제 클러스터의 상태를 일치시키는 것이 핵심입니다. 이렇게 하면 누가 언제 무엇을 변경했는지 추적하기 쉽고, 문제가 생겼을 때 이전 상태로 되돌리기도(Rollback) 훨씬 수월하죠.

    그리고 Argo CD(아르고 CD)는 이런 GitOps 원칙을 쿠버네티스 환경에서 구현하도록 도와주는 선언적(Declarative) GitOps 지속적 배포(Continuous Delivery) 도구입니다. Git 저장소에 정의된 상태를 주기적으로 감지해서 쿠버네티스 클러스터의 실제 상태와 비교하고, 다르면 Git의 상태에 맞춰 동기화(Sync)해줍니다. 정말 편리하더라고요.

    그렇다면 멀티 클러스터 관리(Multi-Cluster Management)는 뭘까요? Argo CD는 한 개의 인스턴스로 여러 개의 쿠버네티스 클러스터에 배포를 관리할 수 있는 기능을 제공합니다. 메인 Argo CD가 설치된 클러스터(저는 이걸 컨트롤 플레인 클러스터(Control Plane Cluster)라고 부릅니다)에서 여러 타겟 클러스터(Target Cluster)들을 등록하고, 각각의 클러스터에 어떤 애플리케이션을 어떤 버전으로 배포할지 Git을 통해 지시하는 방식이에요. 덕분에 여러 환경에 동일한 애플리케이션을 일관성 있게 배포하고 관리하는 게 훨씬 쉬워졌습니다. 💡

    실전 구현: Argo CD 멀티 클러스터 환경 구축하기

    자, 이제 실제로 어떻게 구성했는지 살펴보겠습니다. 저는 세 개의 클러스터를 준비했는데, 하나는 Argo CD가 설치될 컨트롤 플레인 클러스터, 그리고 나머지 두 개는 애플리케이션이 배포될 타겟 클러스터입니다. 모든 클러스터는 kubeconfig(쿠브콘피그)를 통해 접근할 수 있도록 설정되어 있다고 가정하겠습니다.

    1. Argo CD 설치 및 타겟 클러스터 등록

    먼저, 컨트롤 플레인 클러스터에 Argo CD를 설치합니다. 이건 공식 문서에 잘 나와 있으니 간단하게 넘어갈 테고, 핵심은 타겟 클러스터를 Argo CD에 등록하는 것입니다. Argo CD CLI를 사용하면 정말 간단하게 등록할 수 있어요.

    
    # Argo CD CLI 설치 (공식 문서 참고)
    # brew install argocd
    
    # Argo CD 로그인 (admin 계정 패스워드는 초기 설치 시 자동으로 생성됩니다)
    argocd login <ARGOCD_SERVER_IP_OR_HOSTNAME>
    
    # 타겟 클러스터 등록
    # kubeconfig에 등록된 클러스터 이름을 사용합니다.
    # 제 경우엔 dev-cluster와 prod-cluster라는 이름으로 등록되어 있었죠.
    argocd cluster add dev-cluster --name dev-cluster-region-a
    argocd cluster add prod-cluster --name prod-cluster-region-b
    
    # 등록된 클러스터 목록 확인
    argocd cluster list
    

    이렇게 하면 Argo CD가 해당 클러스터에 접근해서 애플리케이션을 배포할 수 있는 권한을 가지게 됩니다. 중요한 부분은 RBAC(Role-Based Access Control, 역할 기반 접근 제어) 설정인데, Argo CD가 타겟 클러스터에서 필요한 리소스(Deployment, Service 등)를 생성/수정/삭제할 수 있도록 적절한 권한을 부여해야 합니다. 저는 처음엔 이걸 놓쳐서 “왜 배포가 안 될까?” 한참 삽질했었습니다. ⚠️

    Argo CD UI 클러스터 목록 스크린샷

    Argo CD 웹 UI에 등록된 dev-cluster-region-a와 prod-cluster-region-b 클러스터의 목록과 상태를 보여주는 화면입니다. 모든 클러스터가 Healthy 상태로 나타나 있네요.

    2. Git 저장소 구조화: App of Apps 패턴

    멀티 클러스터 환경에서 Git 저장소를 효율적으로 관리하는 방법 중 하나는 App of Apps 패턴(App of Apps Pattern)입니다. 하나의 최상위 Argo CD Application이 여러 하위 Application들을 관리하는 방식이에요. 저는 다음과 같이 Git 저장소를 구성했습니다.

    
    .
    ├── applications/
    │   ├── base/ # 공통 애플리케이션 정의 (예: Ingress Controller, Cert Manager)
    │   └── microservices/ # 마이크로서비스별 애플리케이션 정의
    ├── clusters/
    │   ├── dev-cluster-region-a/ # 개발 클러스터별 설정
    │   │   └── root-app.yaml
    │   └── prod-cluster-region-b/ # 프로덕션 클러스터별 설정
    │       └── root-app.yaml
    └── environments/
        ├── dev/ # 개발 환경별 값 (values.yaml for Helm)
        └── prod/ # 프로덕션 환경별 값 (values.yaml for Helm)
    

    각 클러스터 폴더 안의 `root-app.yaml`은 해당 클러스터에 배포될 모든 하위 애플리케이션을 정의하는 최상위 Argo CD Application입니다. 예를 들어 `dev-cluster-region-a/root-app.yaml`은 다음과 같이 작성할 수 있죠.

    
    # clusters/dev-cluster-region-a/root-app.yaml
    apiVersion: argoproj.io/v1alpha1
    kind: Application
    metadata:
      name: dev-cluster-root-app
      namespace: argocd
    spec:
      project: default
      source:
        repoURL: https://github.com/my-org/my-gitops-repo.git # 본인의 Git 저장소 URL
        targetRevision: HEAD
        path: applications # 하위 애플리케이션 정의들이 있는 경로
      destination:
        server: https://kubernetes.default.svc # 이 Application은 Argo CD가 설치된 클러스터에 적용
        namespace: argocd # Argo CD가 Application 리소스를 관리하는 네임스페이스
      syncPolicy:
        automated:
          prune: true
          selfHeal: true
        syncOptions:
          - CreateNamespace=true
    

    그리고 `applications/` 경로 안에는 실제 배포될 애플리케이션들의 정의가 들어갑니다. 예를 들어, `applications/microservices/my-service.yaml`은 다음과 같을 수 있어요. 여기서 ApplicationSet(애플리케이션셋)을 사용하면 여러 클러스터에 동일한 애플리케이션을 배포하는 것이 훨씬 유연해집니다.

    
    # applications/microservices/my-service.yaml
    apiVersion: argoproj.io/v1alpha1
    kind: ApplicationSet
    metadata:
      name: my-service-all-clusters
      namespace: argocd
    spec:
      generators:
      - list:
          elements:
          - cluster: dev-cluster-region-a # Argo CD에 등록된 클러스터 이름
            url: https://kubernetes.default.svc # 타겟 클러스터의 API 서버 URL
            name: dev
          - cluster: prod-cluster-region-b
            url: https://kubernetes.default.svc
            name: prod
      template:
        metadata:
          name: my-service-{{name}} # 클러스터 이름에 따라 Application 이름이 생성됩니다 (예: my-service-dev, my-service-prod)
          namespace: default
        spec:
          project: default
          source:
            repoURL: https://github.com/my-org/my-app-helm-charts.git # 애플리케이션 Helm 차트 저장소
            targetRevision: 1.0.0
            path: my-service
            helm:
              values: |
                replicaCount: 2
                image:
                  tag: "1.0.0-{{name}}" # 환경별 이미지 태그 (예: 1.0.0-dev, 1.0.0-prod)
                ingress:
                  host: my-service.{{name}}.example.com
          destination:
            server: "{{url}}" # 위에서 정의된 타겟 클러스터의 URL
            namespace: default
          syncPolicy:
            automated:
              prune: true
              selfHeal: true
            syncOptions:
              - CreateNamespace=true
    

    위 `ApplicationSet` 예시는 `list` 제너레이터를 사용해서 `dev`와 `prod` 두 환경에 `my-service`를 배포하도록 정의하고 있습니다. 각 환경에 맞는 `values`를 `helm` 섹션에서 오버라이드(Override)할 수 있어서 정말 유용해요. 저는 Helm(헬름) 차트를 주로 사용하는데, Kustomize(커스터마이즈)나 일반 YAML도 물론 지원합니다.

    ⚠️ 삽질 경험과 운영 노하우

    Argo CD 멀티 클러스터를 운영하면서 몇 가지 정말 잊지 못할 경험들이 있습니다. 독자분들은 저와 같은 실수를 반복하지 않으시길 바라며 몇 가지 중요한 팁을 공유합니다.

    1. RBAC 권한 문제

    가장 흔하고 고통스러운 문제예요. Argo CD가 타겟 클러스터에 배포할 때, 필요한 권한이 없어서 배포가 실패하는 경우가 정말 많습니다. Argo CD를 등록할 때 부여하는 권한은 ServiceAccount(서비스 어카운트)를 통해 부여되는데, 이 서비스 어카운트가 타겟 클러스터에서 ClusterRole(클러스터 롤)과 ClusterRoleBinding(클러스터 롤 바인딩)을 통해 적절한 권한을 가지고 있는지 반드시 확인해야 합니다. 저는 처음엔 `admin` 권한을 무심코 줬다가 보안 팀에게 한소리 듣고, 나중에는 필요한 최소한의 권한만 부여하도록 변경했습니다. 💡

    
    # 예시: Argo CD ServiceAccount에 필요한 ClusterRoleBinding 부여 (타겟 클러스터에서 실행)
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRoleBinding
    metadata:
      name: argocd-manager-role-binding
    subjects:
    - kind: ServiceAccount
      name: argocd-manager # Argo CD가 사용하는 ServiceAccount 이름
      namespace: argocd # Argo CD가 설치된 네임스페이스
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: cluster-admin # 임시로 전체 권한 부여. 실제 운영에서는 더 세분화된 Role을 사용하세요.
    

    실제 운영에서는 `cluster-admin` 대신 `edit`이나 `view` 같은 기본 Role을 조합하거나, 특정 리소스에 대한 `get`, `list`, `watch`, `create`, `update`, `patch`, `delete` 권한을 명시적으로 부여하는 커스텀 ClusterRole을 만들어서 사용하는 게 훨씬 안전합니다.

    2. 네트워크 연결 및 방화벽

    Argo CD 컨트롤 플레인 클러스터에서 타겟 클러스터의 API 서버에 접근할 수 있어야 합니다. 만약 클러스터들이 서로 다른 네트워크에 있거나, 방화벽(Firewall) 정책이 엄격하다면 연결 문제가 발생할 수 있죠. 저는 회사 보안 정책 때문에 VPC 피어링(VPC Peering)이나 VPN(Virtual Private Network) 설정을 통해 연결을 확보해야 했어요. 핑(Ping) 테스트나 `kubectl`로 직접 연결해보면서 연결성을 확인하는 것이 정말 중요합니다.

    3. 시크릿 관리(Secret Management)

    여러 클러스터에 배포되는 애플리케이션들은 데이터베이스 비밀번호나 API 키 같은 민감한 정보(Secret)들을 필요로 합니다. 이걸 Git에 그대로 올릴 수는 없겠죠. 저는 External Secrets Operator(외부 시크릿 오퍼레이터)와 Vault(볼트)를 연동해서 사용하거나, Sealed Secrets(실드 시크릿)를 활용해서 시크릿을 안전하게 관리했습니다. Git에 암호화된 형태로 저장하고, 각 클러스터에서 복호화해서 사용하는 방식이에요. 이 부분은 보안상 정말 중요하니 깊이 있게 고민해야 합니다.

    4. 설정 드리프트(Configuration Drift)

    GitOps의 핵심은 Git 저장소의 상태와 실제 클러스터의 상태가 일치해야 한다는 거예요. 그런데 운영 중에 누군가 클러스터에서 직접 리소스를 수정해서 Git과 클러스터의 상태가 달라지는 설정 드리프트(Configuration Drift)가 발생할 수 있습니다. Argo CD는 이런 드리프트를 감지하고 자동으로 동기화(Self-Heal)하거나, 수동으로 동기화할 수 있는 기능을 제공합니다. 하지만 근본적으로는 클러스터에 직접 접근해서 변경하는 것을 정책적으로 금지하고, 모든 변경은 Git을 통해서만 이루어지도록 강제하는 게 중요합니다.

    🎉 Argo CD 멀티 클러스터 도입 후기 및 성과

    숱한 삽질 끝에 Argo CD 멀티 클러스터 GitOps 환경을 성공적으로 구축하고 운영하게 되었습니다. 그 결과는 정말 놀라웠어요.

    • 배포 일관성 및 안정성 향상: 개발, 스테이징, 프로덕션 클러스터에 동일한 버전의 애플리케이션을 일관된 방식으로 배포할 수 있게 되었습니다. 수동 작업으로 인한 휴먼 에러(Human Error)가 정말 줄었죠.
    • 배포 속도 단축: Git에 코드를 푸시(Push)만 하면 Argo CD가 자동으로 감지하고 배포를 시작합니다. CI/CD 파이프라인(Pipeline)과 연동하여 개발자들이 훨씬 빠르게 변경 사항을 적용할 수 있게 되었어요.
    • 쉬운 롤백(Rollback): 문제가 발생했을 때, Git의 이전 커밋(Commit)으로 되돌리는 것만으로 애플리케이션을 이전 상태로 쉽게 롤백할 수 있습니다. 비상 상황에서 정말 큰 도움이 되더군요.
    • 운영 가시성 확보: Argo CD UI를 통해 모든 클러스터의 애플리케이션 상태를 한눈에 확인할 수 있게 되었습니다. 어떤 애플리케이션이 어느 클러스터에 어떤 버전으로 배포되어 있는지 파악하기가 정말 쉬워졌어요.
    Argo CD UI 멀티 클러스터 애플리케이션 상태 대시보드

    Argo CD 웹 UI에서 dev-cluster와 prod-cluster에 배포된 여러 애플리케이션들의 동기화 상태와 Health 상태를 한눈에 보여주는 대시보드 화면입니다. 모든 애플리케이션이 Sync’d and Healthy 상태를 나타내고 있네요.

    Argo CD 멀티 클러스터 도입 전후 비교

    구분 도입 전 (수동/스크립트 기반) 도입 후 (Argo CD 멀티 클러스터 GitOps)
    배포 방식 클러스터별 수동 `kubectl` 적용 또는 쉘 스크립트 실행 Git 커밋 기반 자동 동기화 (선언적)
    배포 일관성 환경별 설정 차이 발생 가능성 높음, 휴먼 에러 빈번 Git을 통한 일관된 설정 적용, 휴먼 에러 최소화
    롤백 용이성 이전 상태 복구 어려움, 시간 소요 Git 커밋 되돌리기로 빠르고 안정적인 롤백
    운영 가시성 각 클러스터에 개별 접근하여 상태 확인 단일 Argo CD UI에서 모든 클러스터 및 애플리케이션 상태 확인
    보안 및 감사 수동 변경 이력 추적 어려움 Git 변경 이력을 통한 완벽한 감사 추적

    위 표에서 보시는 것처럼, Argo CD 멀티 클러스터 GitOps는 인프라 운영 방식에 혁신적인 변화를 가져다주었습니다. 특히 여러 클러스터를 관리해야 하는 복잡한 환경에서는 그 진가가 더욱 빛을 발하더군요.

    마무리하며: 배운 점과 다음 도전 과제

    오늘은 제가 Argo CD 멀티 클러스터 GitOps를 도입하면서 겪었던 과정과 노하우, 그리고 얻었던 성과에 대해 이야기해봤습니다. 처음엔 낯선 개념과 복잡한 설정 때문에 막막하기도 했지만, 한번 구축하고 나니 인프라 운영의 질이 한 단계 높아지는 걸 체감할 수 있었습니다. 특히 쿠버네티스 멀티 클러스터 관리에 대한 고민이 많으셨던 분들께 저의 Argo CD GitOps 사례가 작은 도움이 되었으면 좋겠어요.

    물론 아직 도전 과제는 남아있습니다. 예를 들어, 프로그레시브 딜리버리(Progressive Delivery)를 위해 Argo Rollouts(아르고 롤아웃)과 연동하거나, 더 복잡한 클러스터 간 의존성을 관리하는 방법, 그리고 비용 최적화와 같은 부분은 앞으로도 계속 고민하고 실험해봐야 할 영역입니다. 💡

    저처럼 GitOps 도입 후기를 찾고 계셨던 분들이라면, Argo CD를 적극적으로 검토해보시길 추천합니다. 직접 해보면 생각보다 어렵지 않고, 얻는 이점은 훨씬 크다는 걸 느끼실 겁니다. 다음번에는 더 깊이 있는 주제로 찾아오겠습니다. 긴 글 읽어주셔서 감사합니다! 궁금한 점이 있다면 언제든지 댓글로 남겨주세요.

  • [k8s] Kustomize와 Helm, K8s 설정 관리 도구 실측 성능 비교

    [k8s] Kustomize와 Helm, K8s 설정 관리 도구 실측 성능 비교

    Kustomize와 Helm, K8s 설정 관리 도구 실측 성능 비교: 어떤 놈이 더 빠를까요?

    안녕하세요, 13년차 서버실 지킴이입니다. 오늘도 여전히 복잡한 인프라의 세계 속에서 삽질하고 계실 독자분들을 위해 제 경험을 풀어볼까 합니다. 😅

    Kubernetes(쿠버네티스, 이하 K8s) 환경에서 애플리케이션을 배포하고 관리하다 보면, YAML 파일의 홍수에 빠지는 경험, 다들 있으실 겁니다. 이 수많은 설정 파일들을 어떻게 효과적으로 관리할까? 바로 여기서 Kustomize(커스터마이즈)와 Helm(헬름) 같은 K8s 설정 관리(Configuration Management) 도구들이 등장하죠.

    두 도구 모두 강력한 기능을 제공하지만, 실제 운영 환경에서는 ‘과연 어떤 도구가 더 빠르고 효율적일까?’ 하는 고민을 많이 하게 됩니다. 특히 CI/CD 파이프라인에서 빌드 시간이 길어지면 개발자의 생산성에도 영향을 미치거든요. 그래서 오늘은 제가 직접 두 도구를 사용해보면서 느꼈던 Kustomize vs Helm 성능 비교와 최적화 전략에 대해 이야기해볼게요. 멘토처럼 솔직한 경험담과 함께요! 💡

    Kubernetes 설정 관리를 위한 Kustomize와 Helm 워크플로우 비교 다이어그램

    –>

    Kubernetes 설정 관리를 위한 Kustomize와 Helm 워크플로우 비교 다이어그램

    1. Kustomize와 Helm, 넌 누구냐? 🤔

    먼저 두 도구가 정확히 어떤 역할을 하는지, 개념부터 확실히 잡고 가볼까요?

    1.1. Kustomize: K8s 네이티브 설정 템플릿

    Kustomize는 Kubernetes 네이티브 설정 관리(Kubernetes native configuration management) 도구입니다. 쉽게 말해, K8s가 YAML 파일을 처리하는 방식과 매우 유사하게 동작해요. 템플릿 엔진을 사용하지 않고, 기존 YAML 파일(Base)에 덧붙이는(Overlay) 방식으로 설정을 변경합니다.

    • 선언적(Declarative): 최종 상태를 선언하는 방식이라 직관적입니다.
    • 패치(Patch) 기반: 원본 파일을 직접 수정하지 않고, 필요한 부분만 덮어쓰는 형식이에요.
    • 경량화(Lightweight): K8s 내부에 통합되어 별도의 바이너리 설치 없이 kubectl 명령어에 포함되어 있습니다. (kubectl kustomize 또는 kustomize build)

    1.2. Helm: K8s의 패키지 매니저

    Helm은 K8s를 위한 패키지 매니저(Package Manager)입니다. 마치 Ubuntu의 apt나 CentOS의 yum처럼, K8s 애플리케이션을 차트(Chart)라는 형태로 패키징하고 배포하며 관리할 수 있게 해줘요.

    • 템플릿 엔진(Templating Engine): Go 템플릿(Go Template) 문법을 사용하여 YAML 파일을 동적으로 생성합니다. values.yaml 파일로 변수를 주입하죠.
    • 릴리즈(Release) 관리: 배포된 애플리케이션의 버전을 관리하고, 업그레이드 및 롤백을 쉽게 할 수 있습니다.
    • 의존성 관리(Dependency Management): 다른 차트를 하위 차트(subchart)로 포함시켜 복잡한 애플리케이션 스택을 한 번에 배포할 수 있어요.

    2. 실전 구현: 어떻게 비교할까? 🛠️

    두 도구의 성능을 비교하려면, 동일한 조건에서 최대한 유사한 작업을 수행하게 해야겠죠? 제가 홈랩에서 간단한 웹 애플리케이션을 배포하면서 비교했던 방법을 공유해볼게요.

    2.1. Kustomize로 YAML 빌드하기

    먼저 Kustomize는 kustomization.yaml 파일을 작성하여 여러 YAML 파일을 조합하고 패치합니다. 예를 들어, 개발 환경과 운영 환경에 따라 리소스의 replica 수나 이미지 태그를 다르게 적용하는 시나리오를 가정해봅시다.

    # base/deployment.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: my-app
    spec:
      replicas: 1
      template:
        spec:
          containers:
          - name: my-app
            image: my-repo/my-app:1.0.0
    
    # overlays/dev/kustomization.yaml
    apiVersion: kustomize.config.k8s.io/v1beta1
    kind: Kustomization
    resources:
    - ../../base
    patches:
    - path: patch-dev.yaml
    
    # overlays/dev/patch-dev.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: my-app
    spec:
      replicas: 2 # 개발 환경은 2개로
    
    

    이렇게 구성된 Kustomize 프로젝트는 다음 명령어로 최종 YAML을 생성합니다.

    time kustomize build overlays/dev > dev-app.yaml
    

    time 명령어를 붙여서 실행 시간을 측정하는 거죠. 간단하죠? ⏱️

    2.2. Helm으로 차트 렌더링하기

    Helm은 차트 디렉토리 구조와 values.yaml 파일을 사용해서 YAML을 렌더링합니다. 마찬가지로 개발 환경과 운영 환경에 따라 설정을 다르게 해볼게요.

    # my-app-chart/templates/deployment.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: {{ .Release.Name }}-{{ .Chart.Name }}
    spec:
      replicas: {{ .Values.replicaCount }}
      template:
        spec:
          containers:
          - name: {{ .Chart.Name }}
            image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
    
    # my-app-chart/values.yaml (기본값)
    replicaCount: 1
    image:
      repository: my-repo/my-app
      tag: 1.0.0
    
    # my-app-chart/values-dev.yaml (개발 환경 오버라이드)
    replicaCount: 2
    image:
      tag: 1.0.0-dev
    

    Helm 차트는 다음 명령어로 최종 YAML을 렌더링합니다.

    time helm template my-app my-app-chart -f my-app-chart/values-dev.yaml > dev-app-helm.yaml
    

    마찬가지로 time 명령어로 렌더링 시간을 측정합니다. 💡

    Kustomize 오버레이와 Helm 차트 values.yaml 파일 구조 시각화

    –>

    Kustomize 오버레이와 Helm 차트 values.yaml 파일 구조 시각화

    3. 주의사항과 삽질 경험 ⚠️

    단순히 time 명령어를 쓰는 것만으로는 완벽한 비교가 어렵더라고요. 제가 겪었던 삽질 경험을 토대로 몇 가지 주의사항을 공유합니다.

    3.1. Helm 복잡성과 의존성 관리 오버헤드

    Helm은 Go 템플릿을 사용하고, 복잡한 의존성 관리(Dependency Management) 기능을 제공합니다. 차트 내에 수많은 하위 차트(subchart)가 있거나, 템플릿 로직이 복잡해질수록 렌더링 시간이 기하급수적으로 늘어날 수 있어요. 제가 처음엔 너무 많은 헬름 차트를 한 번에 묶었다가 렌더링에만 수십 초씩 걸려서 깜짝 놀랐거든요. 😅

    반면 Kustomize는 단순히 YAML 파일을 병합하고 패치하는 방식이라, 상대적으로 오버헤드가 적습니다. 하지만 패치 파일이 너무 많아지거나, 복잡한 jsonPatch를 사용하면 가독성이 떨어지고 디버깅이 어려워지는 단점이 있습니다.

    3.2. 캐싱(Caching)과 컨테이너 환경

    CI/CD 파이프라인에서 실행할 때는 도커 컨테이너 환경에서 실행하는 경우가 많죠. 이때 도구 바이너리 로딩 시간이나 컨테이너 이미지 크기도 성능에 영향을 줄 수 있습니다. Helm은 별도의 바이너리가 필요하고, Kustomize는 kubectl에 통합되어 있거나 단독 바이너리를 사용합니다. 아주 미세한 차이지만, 빌드 횟수가 많아지면 무시할 수 없는 요소가 됩니다.

    3.3. ‘실측’의 의미: 실제 배포까지의 시간

    단순히 YAML 파일을 생성하는 시간뿐만 아니라, K8s API 서버에 리소스를 배포하고 적용하는 시간까지 고려해야 진정한 실측 성능(Real-world Performance)이라고 할 수 있습니다. kubectl apply -f 또는 helm upgrade --install 명령어가 실제로 얼마나 걸리는지도 함께 측정해봐야 합니다.

    4. 검증 및 결과: 무엇이 더 빠를까? 🚀

    결론부터 말씀드리면, ‘케바케(Case by Case)’입니다. 😅 하지만 제가 여러 프로젝트에서 직접 사용해보고 측정해본 결과, 다음과 같은 일반적인 경향을 발견했습니다.

    4.1. Kustomize의 장점 (대규모 프로젝트 초기 빌드/변경)

    • 빠른 빌드 시간: 단순 YAML 병합 및 패치 방식이라 템플릿 엔진의 오버헤드가 없습니다. 수백 개의 리소스가 있어도 빌드 자체는 상당히 빠르게 완료되는 편입니다.
    • K8s 네이티브 통합: kubectl 명령어에 포함되어 있어 별도의 도구 설치 및 관리 부담이 적습니다.
    • 예측 가능한 결과: 템플릿 로직이 없어 결과 YAML이 직관적이고 예측하기 쉽습니다.

    4.2. Helm의 장점 (복잡한 템플릿/패키징)

    • 강력한 템플릿 기능: Go 템플릿을 활용해 복잡한 조건부 로직이나 반복문 등을 구현하기 용이합니다.
    • 패키지 관리의 용이성: 재사용 가능한 차트 형태로 애플리케이션을 배포하고 관리하는 데 최적화되어 있습니다. 외부 차트를 쉽게 가져다 쓸 수 있고요.
    • 릴리즈 히스토리 관리: 배포된 애플리케이션의 버전 관리와 롤백이 매우 편리합니다.

    4.3. 성능에 영향을 미치는 주요 요인

    어떤 도구를 쓰든 다음 요소들이 성능에 큰 영향을 줍니다.

    1. 생성되는 YAML 리소스의 수: 많을수록 처리 시간이 길어집니다.
    2. Helm 차트의 복잡성: 템플릿 내의 조건문, 반복문, 함수 호출 등이 많을수록 렌더링 시간이 길어집니다.
    3. Kustomize 패치의 수와 복잡성: 너무 많은 패치나 복잡한 jsonPatch는 처리 시간을 늘릴 수 있습니다.
    4. 의존성(Dependency) 관리: 특히 Helm에서 서브 차트의 수가 많아지면 초기 로딩 및 렌더링 오버헤드가 발생합니다.
    5. 실행 환경의 성능: CI/CD 에이전트의 CPU, 메모리, 디스크 I/O도 영향을 미칩니다.

    제가 실제 측정해보니, 리소스 수가 적을 때는 두 도구 간의 빌드 시간 차이가 미미했지만, 수백 개 이상의 리소스를 다루거나 Helm 차트의 템플릿 로직이 복잡해질수록 Helm의 렌더링 시간이 Kustomize의 빌드 시간보다 눈에 띄게 길어지는 경향을 보였습니다. ⚠️

    Kustomize와 Helm 빌드 시간 측정 및 성능 비교 결과

    –>

    Kustomize와 Helm 빌드 시간 측정 및 성능 비교 결과

    5. K8s 설정 관리 최적화 전략 ⚙️

    결국 중요한 건 ‘어떤 도구가 절대적으로 빠르냐’가 아니라, ‘어떤 도구를 어떻게 사용해서 우리 환경에 최적화하느냐’입니다.

    • Kustomize 최적화:
      • 베이스(Base) 재사용: 공통된 설정은 베이스로 만들고, 오버레이는 최소한의 변경만 하도록 구성합니다.
      • 패치 최소화: 불필요하게 작은 단위로 패치를 나누기보다, 응집도 있는 패치를 사용합니다.
      • GitOps 워크플로우: Kustomize는 GitOps와 궁합이 좋습니다. Flux CD나 Argo CD 같은 도구와 함께 사용하면 변경 사항을 자동으로 감지하고 적용할 수 있어요.
    • Helm 차트 최적화:
      • 템플릿 복잡성 줄이기: Go 템플릿 내의 복잡한 로직을 최소화하고, 필요한 경우 별도의 스크립트나 도구로 전처리하는 것을 고려합니다.
      • 서브 차트 의존성 관리: 꼭 필요한 경우에만 서브 차트를 사용하고, 불필요한 의존성은 제거합니다. 서브 차트가 많으면 관리가 어려워지더라고요.
      • --atomic, --wait 옵션 활용: 배포 시 안정성을 높이지만, 이 옵션들이 배포 시간을 늘릴 수 있다는 점을 인지하고 적절히 사용해야 합니다.
      • 캐싱 활용: CI/CD 환경에서 Helm dependency update 등의 과정을 캐싱하여 시간을 절약할 수 있습니다.

    저는 개인적으로 간단하고 직관적인 애플리케이션은 Kustomize를, 복잡한 의존성을 가진 상용 솔루션이나 여러 마이크로서비스를 묶어 배포해야 할 때는 Helm을 선호하는 편입니다. 두 도구를 혼용(Hybrid)하여 사용하는 방법도 좋은 전략이 될 수 있어요. 예를 들어, Helm 차트를 Kustomize의 베이스로 사용하고, 그 위에 환경별 패치를 적용하는 방식이죠. 🤯

    Kustomize와 Helm의 주요 기능 및 장단점 비교 인포그래픽

    –>

    Kustomize와 Helm의 주요 기능 및 장단점 비교 인포그래픽

    6. 마무리: 우리의 삽질은 계속된다! 🎉

    오늘은 Kustomize와 Helm이라는 두 가지 강력한 K8s 설정 관리 도구의 성능 비교와 최적화 전략에 대해 이야기해봤습니다. 어느 한쪽이 ‘무조건 최고다’라고 말하기는 어렵고, 각자의 장단점과 사용 환경에 따라 선택이 달라질 수 있다는 점이 핵심입니다.

    저도 처음엔 ‘어떤 게 더 좋지?’ 하면서 벤치마크 숫자놀음에 집착했었는데요, 결국 중요한 건 ‘우리 팀의 워크플로우에 얼마나 잘 맞고, 유지보수가 쉬우며, 안정적인가’ 하는 점이더라고요. 성능 측정은 그 판단을 돕는 하나의 지표일 뿐입니다. 여러분도 직접 사용해보면서 자신만의 최적의 방법을 찾아보시길 바랍니다. 혹시 더 좋은 Helm 차트 최적화나 Kustomize 장점 활용 팁이 있다면 댓글로 공유해주세요! 다음 글에서는 Kustomize와 Helm을 GitOps 환경에서 연동하는 방법에 대해 더 깊이 다뤄볼 예정입니다. 기대해주세요! 😉

  • [Kubernetes] External Secrets Operator 보안 강화 체크리스트 10가지

    [Kubernetes] External Secrets Operator 보안 강화 체크리스트 10가지

    [Kubernetes] External Secrets Operator 보안 강화 체크리스트 10가지

    안녕하세요, 13년차의 서버실 주인장입니다. 오늘은 Kubernetes(쿠버네티스) 환경에서 민감한 정보를 안전하게 관리하는 데 필수적인 External Secrets Operator(외부 시크릿 연동 오퍼레이터, 이하 ESO)의 보안을 어떻게 더 튼튼하게 만들 수 있는지, 제가 직접 겪고 배운 경험들을 바탕으로 10가지 체크리스트를 공유하려고 합니다. 사실 저도 처음엔 Kubernetes Secret(쿠버네티스 시크릿)에 직접 값을 넣다가, GitOps(깃옵스) 환경에서 시크릿 노출 문제 때문에 엄청 고민했었거든요. 그때 External Secrets Operator를 만나고 나서 ‘이거다!’ 싶었죠. 하지만 편리함 뒤에는 항상 보안이라는 그림자가 따라붙는 법입니다. ESO를 잘 쓰는 것만큼, 안전하게 쓰는 것이 중요하더라고요.

    Kubernetes 클러스터에서 데이터베이스 비밀번호, API 키 같은 민감한 정보들을 안전하게 보관하고 관리하는 건 인프라 엔지니어의 숙명과도 같습니다. 특히 GitOps를 도입하면 모든 설정이 Git(깃) 저장소에 코드 형태로 관리되는데, 여기에 시크릿이 그대로 노출되면 정말 큰일 나잖아요? ESO는 이런 문제의 훌륭한 해답이 되어주지만, 그 자체로 또 다른 보안 고려사항을 만들어냅니다. 제가 홈랩에서 이것저것 실험하면서, 그리고 실제 서비스에 적용하면서 얻은 노하우들을 지금부터 하나씩 풀어볼게요. 혹시 이런 고민 해보신 적 있으신가요? 그렇다면 이 글이 큰 도움이 될 겁니다. 💡

    Kubernetes External Secrets Operator와 외부 시크릿 저장소 연동 아키텍처 다이어그램: Kubernetes 클러스터 내의 ESO가 AWS Secrets Manager, HashiCorp Vault 등 외부 시크릿 저장소와 안전하게 통신하며 시크릿을 동기화하는 구조를 보여줍니다.

    External Secrets Operator, 왜 중요할까요?

    External Secrets Operator는 쉽게 말해 Kubernetes 클러스터와 외부 시크릿 저장소(Secret Store)를 연결해주는 다리 역할을 합니다. AWS Secrets Manager, HashiCorp Vault, Azure Key Vault, Google Secret Manager 같은 전문 시크릿 관리 서비스에 저장된 민감 정보를 Kubernetes Secret 리소스(Resource)로 동기화(Synchronize)해주는 거죠. 이렇게 하면:

    • ✅ 시크릿 중앙 관리: 모든 시크릿을 한 곳에서 관리할 수 있어서 일관성을 유지하고 감사(Audit)하기가 편해집니다.
    • ✅ Git 노출 방지: Git 저장소에는 ExternalSecret 리소스의 정의만 있고, 실제 민감한 값은 들어가지 않으니 보안 위험이 줄어듭니다.
    • ✅ 보안 기능 활용: 외부 시크릿 저장소가 제공하는 강력한 암호화, 접근 제어, 감사 로깅 등의 기능을 그대로 활용할 수 있어요.

    이런 장점들 때문에 많은 분들이 ESO를 사용하시는데요, 중요한 건 이 편리함을 누리면서도 보안을 놓치지 않는 겁니다. 제가 13년 동안 Kubernetes와 인프라를 다루면서 깨달은 External Secrets Operator 보안 강화 체크리스트 10가지를 지금부터 공유합니다!

    External Secrets Operator 보안 강화 체크리스트 10가지

    자, 이제 본론입니다. 제가 직접 써보고 효과를 본 핵심 보안 설정들을 하나씩 짚어볼게요.

    1. SecretStore(시크릿 저장소) 권한 최소화 (Principle of Least Privilege)

    가장 기본 중의 기본이죠. ESO가 외부 시크릿 저장소에 접근할 때 사용하는 계정(예: AWS IAM Role, Vault AppRole)에는 필요한 최소한의 권한만 부여해야 합니다. 예를 들어, 특정 Path(경로)나 Prefix(접두사)에 해당하는 시크릿만 읽을 수 있도록 제한하는 거죠. 제가 예전에 실수로 모든 시크릿을 읽을 수 있는 권한을 줬다가 등골이 서늘했던 기억이 있습니다. ⚠️

    apiVersion: external-secrets.io/v1beta1
    kind: SecretStore
    metadata:
      name: aws-secrets-manager
    spec:
      provider:
        aws:
          service: SecretsManager
          region: ap-northeast-2
          auth:
            jwt:
              serviceAccountRef:
                name: external-secrets-sa
          # 특정 시크릿만 접근하도록 IAM 정책에서 제한
          # 예시: arn:aws:secretsmanager:ap-northeast-2:123456789012:secret:my-app/*
    

    2. SecretStore 백엔드 인증 방식 강화

    외부 시크릿 저장소와의 인증은 강력한 방식을 사용해야 합니다. 클라우드 환경에서는 IRSA(IAM Roles for Service Accounts)나 Workload Identity(워크로드 아이덴티티) 같은 방식을 활용해서 Kubernetes Service Account(서비스 어카운트)에 IAM Role(아이덴티티 및 접근 관리 역할)을 연결하는 게 가장 안전합니다. 자격 증명(Credentials)을 파일로 관리하거나 환경 변수에 직접 넣는 방식은 피해야 해요. Vault(볼트)를 쓴다면 AppRole(앱 역할)이나 Kubernetes Auth Method(쿠버네티스 인증 방식)를 추천합니다.

    3. ExternalSecret Scope(범위) 제한 및 네임스페이스 분리

    ExternalSecret 리소스는 특정 Kubernetes Namespace(네임스페이스)에 배포되어야 합니다. 또한, ClusterSecretStore를 사용하더라도 ExternalSecret 자체는 해당 네임스페이스에만 영향을 미치도록 설계해야 합니다. 각 애플리케이션이나 팀별로 별도의 네임스페이스를 사용하고, 그 안에 필요한 ExternalSecret만 정의하는 것이 모범 사례입니다. 이렇게 하면 한 곳에서 문제가 생겨도 다른 곳으로 전파되는 걸 막을 수 있어요.

    4. 데이터 전송 및 저장 중 암호화 (Encryption in Transit/At Rest)

    이건 ESO 자체보다는 외부 시크릿 저장소의 역할이 더 큽니다. 외부 시크릿 저장소가 제공하는 암호화 기능을 반드시 활성화해야 합니다. 대부분의 클라우드 서비스는 기본적으로 저장 중 암호화(Encryption at Rest)를 제공하지만, 전송 중 암호화(Encryption in Transit)도 TLS(전송 계층 보안) 등을 통해 보장되는지 확인해야 합니다. ESO와 외부 시크릿 저장소 간의 통신은 HTTPS(보안 하이퍼텍스트 전송 프로토콜) 기반으로 이루어지므로, 이 부분은 크게 걱정할 필요는 없지만, 클라우드 설정 단계에서 한 번 더 확인해두면 좋습니다.

    5. RBAC(Role-Based Access Control) 설정 강화

    Kubernetes RBAC을 이용해서 누가 ExternalSecret 리소스를 생성, 수정, 삭제할 수 있는지 명확하게 정의해야 합니다. 개발팀은 자신의 네임스페이스 내에서 ExternalSecret을 관리할 수 있지만, 다른 네임스페이스의 리소스에는 접근할 수 없도록 제한하는 거죠. ExternalSecret 리소스를 직접 수정할 수 있다는 건, 결국 어떤 시크릿을 Kubernetes Secret으로 가져올지 결정할 수 있다는 의미이기 때문에 강력한 접근 제어가 필요합니다.

    # 예시: 특정 네임스페이스에서 ExternalSecret을 관리할 수 있는 Role
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: external-secrets-manager
      namespace: my-app-namespace
    rules:
    - apiGroups: ["external-secrets.io"]
      resources: ["externalsecrets"]
      verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
    
    ExternalSecret 리소스의 보안 설정 예시 YAML

    ExternalSecret 리소스의 보안 설정 예시 YAML: ExternalSecret 정의에서 SecretStore 참조, 시크릿 키 매핑 등 보안과 관련된 주요 설정 요소들을 강조하여 보여줍니다.

    6. Secret Rotation(시크릿 주기적 교체) 자동화

    아무리 강력한 시크릿이라도 오래 사용하면 위험이 커집니다. 외부 시크릿 저장소가 제공하는 시크릿 교체(Rotation) 기능을 적극 활용해서 데이터베이스 비밀번호나 API 키를 주기적으로 자동으로 바꿔주세요. ESO는 동기화된 시크릿이 외부 저장소에서 변경되면 자동으로 Kubernetes Secret도 업데이트해주기 때문에, 이 부분이 정말 편하더라고요. 수동으로 하다가 깜빡해서 서비스 장애를 냈던 경험이 있다면, 이 자동화가 얼마나 소중한지 아실 겁니다. 🎉

    7. Audit Logging(감사 로깅) 활성화 및 모니터링

    누가, 언제, 어떤 시크릿에 접근했는지, 그리고 어떤 변경이 있었는지 꼼꼼하게 기록하고 모니터링해야 합니다. 외부 시크릿 저장소의 감사 로그 기능(예: AWS CloudTrail, Vault Audit Devices)을 활성화하고, 이를 중앙 로깅 시스템(예: ELK Stack, Splunk)으로 수집하여 비정상적인 접근 시도를 탐지할 수 있도록 설정해야 합니다. ESO 자체 로그도 중요한 단서가 될 수 있으니 항상 주의 깊게 살펴보세요.

    8. Deprecation(폐기) 정책 수립 및 불필요한 시크릿 정리

    사용하지 않는 시크릿은 더 이상 존재할 필요가 없습니다. 불필요한 시크릿은 잠재적인 공격 벡터(Attack Vector)가 될 수 있으므로, 주기적으로 검토하고 삭제하는 정책을 수립해야 합니다. 애플리케이션 배포 주기나 서비스 생명 주기(Life Cycle)에 맞춰 시크릿도 함께 관리하는 것이 중요합니다.

    9. 최신 버전 유지 및 보안 패치 적용

    ESO와 외부 시크릿 저장소 모두 항상 최신 버전으로 유지하고, 보안 패치가 나오면 빠르게 적용해야 합니다. 오픈소스 프로젝트인 ESO는 꾸준히 개선되고 보안 취약점이 발견되면 패치되거든요. 제가 예전에 마이너 버전 업데이트를 미루다가 특정 기능이 제대로 작동하지 않아 삽질했던 기억이 있네요. 😅 물론 업데이트 전에는 테스트 환경에서 충분히 검증해야 합니다!

    10. GitOps 워크플로우 통합 및 검증

    ExternalSecret 리소스 정의를 Git에 저장하고 CI/CD(지속적 통합/지속적 배포) 파이프라인을 통해 배포하는 GitOps 워크플로우를 완벽하게 통합하고 검증해야 합니다. Git 저장소에 민감 정보가 포함되지 않도록 하는 것은 물론, Pull Request(풀 리퀘스트) 검토 프로세스를 강화하여 ExternalSecret 변경 사항에 대한 보안 검토를 필수화해야 합니다. 이렇게 하면 휴먼 에러(Human Error)로 인한 보안 사고를 줄일 수 있습니다.

    ⚠️ 삽질 경험 공유: 외부 시크릿 연동 오류와 권한 문제

    제가 ESO를 처음 도입했을 때 가장 많이 겪었던 삽질은 바로 권한 문제였습니다. AWS Secrets Manager와 연동하는데, 분명히 IAM Role을 잘 설정했다고 생각했는데도 계속 Permission Denied(권한 거부) 에러가 뜨더라고요. 한참을 헤매다가 결국 발견한 건, Service Account에 연결된 IAM Role의 정책(Policy)이 특정 시크릿에 대한 secretsmanager:GetSecretValue 액션을 허용하지 않고 있었다는 겁니다. 🤯

    이걸 해결하려면 AWS IAM 콘솔에서 해당 Role의 권한을 꼼꼼히 확인하고, 필요한 시크릿 ARN(Amazon Resource Name)과 액션을 명시적으로 추가해야 했어요. 특히, 시크릿 이름에 와일드카드(*)를 사용할 때는 정말 신중해야 합니다. 최소 권한 원칙을 지키는 게 생각보다 어렵지만, 이 과정을 통해 저는 IAM 정책 디버깅 능력을 키울 수 있었습니다. 여러분도 꼭 로그를 꼼꼼히 확인하고, 에러 메시지를 구글링하기 전에 권한부터 다시 한번 살펴보세요!

    ✅ 검증 및 결과 확인

    위 체크리스트를 적용한 후에는 반드시 제대로 작동하는지 확인해야겠죠? 저는 주로 다음 명령어로 시크릿 동기화 상태를 확인합니다.

    # ExternalSecret 리소스 상태 확인
    kubectl get externalsecrets -n my-app-namespace
    
    # 동기화된 Kubernetes Secret 확인
    kubectl get secrets my-app-secret -n my-app-namespace -o yaml
    
    # External Secrets Operator 컨트롤러 로그 확인
    kubectl logs -f -l app.kubernetes.io/name=external-secrets -n external-secrets
    

    externalsecrets 리소스의 Status 필드를 보면 동기화 성공 여부와 마지막 동기화 시간을 알 수 있어요. 만약 에러가 있다면 컨트롤러 로그에서 자세한 내용을 확인할 수 있습니다. 모든 시크릿이 안전하게 동기화되고, 불필요한 권한이 없는지 주기적으로 검토하는 것이 중요합니다. 드디어 제가 원하는 대로 시크릿이 안전하게 동기화되는 걸 봤을 때, 그 성취감이란! 🎉

    External Secrets Operator를 통한 시크릿 동기화 확인 결과

    External Secrets Operator를 통한 시크릿 동기화 확인 결과: kubectl get externalsecrets와 kubectl get secrets 명령의 터미널 출력으로 ESO가 외부 시크릿을 Kubernetes 시크릿으로 성공적으로 동기화했음을 보여줍니다.

    마무리하며: 안전한 Kubernetes 시크릿 관리, 이제 시작입니다!

    오늘은 Kubernetes External Secrets Operator의 보안을 강화하기 위한 10가지 체크리스트를 제가 경험하면서 깨달은 내용들을 함께 나누어봤습니다. 시크릿 관리는 인프라 보안의 핵심 중 하나이며, ESO는 이를 효율적으로 도와주는 강력한 도구입니다. 하지만 어떤 도구든 올바르게, 그리고 안전하게 사용하는 것이 중요하죠. 제가 오늘 공유한 내용들이 여러분의 Kubernetes 환경을 더 안전하게 만드는 데 도움이 되었으면 좋겠습니다.

    핵심은 최소 권한 원칙, 강력한 인증, 주기적인 관리, 그리고 철저한 모니터링입니다. 이 네 가지를 항상 염두에 두시고, 오늘 알려드린 체크리스트를 여러분의 환경에 맞춰 적용해보세요. 처음엔 좀 번거롭게 느껴질 수도 있지만, 한 번 세팅해두면 나중에 훨씬 더 안정적이고 안전한 운영이 가능할 겁니다. 혹시 궁금한 점이 있다면 댓글로 남겨주시고요! 다음 글에서는 ESO와 Admission Controller(어드미션 컨트롤러)를 연동해서 시크릿 접근을 더 세밀하게 제어하는 방법에 대해 다뤄볼 예정입니다. 기대해주세요!

    External Secrets Operator 보안 강화 10가지 체크리스트 요약 인포그래픽

    External Secrets Operator 보안 강화 10가지 체크리스트 요약 인포그래픽: 최소 권한, 강력한 인증, 암호화, RBAC 등 10가지 주요 보안 강화 요소를 아이콘과 함께 시각적으로 요약하여 보여줍니다.

  • [Cloud] Flux CD 마이그레이션 경험기: Argo CD와 비교하며

    [Cloud] Flux CD 마이그레이션 경험기: Argo CD와 비교하며

    13년차 인프라 엔지니어의 GitOps 전환기: Flux CD 마이그레이션과 Argo CD 비교

    안녕하세요! 13년차 인프라 엔지니어입니다. 오늘은 많은 분들이 관심을 갖고 계신 Flux CD 마이그레이션 경험에 대해 얘기해볼까 합니다. 기존에 Argo CD를 쓰다가 Flux CD로 전환을 고민 중이신 분들이나 이제 막 GitOps를 시작하려는 분들께 제 경험이 도움이 되길 바랍니다. 저도 처음에는 두 도구 사이에서 정말 많이 고민했거든요. 😅

    쿠버네티스 환경에서 애플리케이션 배포를 자동화하는 GitOps는 이제 선택이 아닌 필수가 되어가고 있습니다. Git 저장소를 단일 진실 공급원(Single Source of Truth)으로 삼아 인프라와 애플리케이션의 상태를 관리하는 방식인데요. 이 GitOps 워크플로우를 구현하는 데 핵심적인 역할을 하는 도구가 바로 Argo CD와 Flux CD입니다. 오늘은 이 두 도구를 비교하며, 제가 Flux CD v2로 마이그레이션하면서 겪었던 실제 경험과 배운 점들을 솔직하게 공유해볼게요.

    GitOps 아키텍처 개요 다이어그램: Git 저장소, GitOps 컨트롤러, 쿠버네티스 클러스터 간의 동기화 흐름

    GitOps의 기본적인 흐름과 도구의 역할을 보여주는 아키텍처 다이어그램입니다.

    1. GitOps와 CI/CD 도구, 왜 이렇게 중요할까요?

    개발자라면 누구나 ‘배포’라는 단어에 복잡한 감정을 느낄 겁니다. 빠르고 정확하게 배포하고 싶지만, 현실은 늘 예상치 못한 문제들로 가득하죠. 수동 배포는 실수를 유발하기 쉽고, 스크립트 기반 자동화는 관리 포인트가 자꾸 늘어납니다. GitOps는 이런 고민을 해결해주는 강력한 방법론입니다. Git 저장소를 통해 인프라와 애플리케이션의 상태를 선언적으로 관리하기 때문에, 누가 언제 무엇을 바꿨는지 명확하게 추적할 수 있고, 문제가 생기면 이전 상태로 롤백하기도 쉬워요. 롤백? 네, Git 커밋 하나면 끝입니다! 🎉

    이런 GitOps 환경을 구축할 때 Argo CD와 Flux CD는 대표적인 선택지입니다. 두 도구 모두 Git 저장소의 상태와 쿠버네티스 클러스터의 실제 상태를 동기화하는 역할을 하지만, 동작 방식이나 기능, 설정 방법 등에서 확실히 달라요. 제가 Flux CD로 마이그레이션하게 된 배경도 이런 차이점들과 저희 팀의 특정 요구사항 때문이었습니다.

    2. Argo CD vs Flux CD: 핵심 개념 비교

    마이그레이션 얘기를 시작하기 전에, 두 도구의 기본적인 차이를 짚고 넘어가겠습니다. 쉽게 말해, Argo CD는 Pull 방식에 집중하고, Flux CD는 GitOps Toolkit이라는 모듈식 접근 방식을 사용합니다.

    Argo CD는 클러스터 내부에 설치되어 Git 저장소를 주기적으로 폴링(polling)하며 변경 사항을 감지합니다. 사용자는 Argo CD UI나 CLI를 통해 Git 저장소와 클러스터의 동기화 상태를 쉽게 확인하고 관리할 수 있죠. 다양한 Git provider와의 통합이 잘 되어 있고, 사용자 친화적인 웹 UI가 강점입니다.

    반면 Flux CD는 GitOps Toolkit이라는 여러 컴포넌트(Source Controller, Kustomize Controller, Helm Controller, Notification Controller 등)로 구성돼 있어요. 각 컴포넌트가 특정 역할을 수행하며, 필요한 컴포넌트만 선택적으로 구성할 수 있습니다. Flux CD는 Git 저장소를 주기적으로 폴링하기보다는 Git hook이나 내부 Controller를 통해 변경 사항을 감지하는 방식을 선호하며, 좀 더 세밀한 제어가 가능하다는 특징이 있어요. 특히 Flux CD v2부터는 이런 모듈식 아키텍처가 훨씬 강화됐습니다.

    구분 Argo CD Flux CD (v2)
    아키텍처 단일 컨트롤러 기반 모듈식 GitOps Toolkit (Source, Kustomize, Helm Controller 등)
    설정 방식 Application CRD, UI, CLI Kustomization/HelmRelease CRD, CLI
    동기화 방식 주기적 폴링 (기본), Git hook 지원 Git hook (권장), 주기적 폴링
    UI 풍부하고 사용자 친화적인 웹 UI CLI 중심, 웹 UI는 제한적 (지속 개선 중)
    확장성/유연성 높음 매우 높음 (모듈식)
    학습 곡선 비교적 완만함 초기 학습 곡선 있음 (GitOps Toolkit 이해 필요)
    Flux CD v2 GitOps Toolkit 구성 요소 다이어그램: Source, Kustomize, Helm Controller 등 모듈 설명

    Flux CD v2의 핵심 컴포넌트인 GitOps Toolkit의 구조를 나타내는 다이어그램입니다.

    3. Flux CD v2 마이그레이션 여정: 삽질과 깨달음 😅

    저희는 기존에 Argo CD를 잘 사용하고 있었어요. 하지만 몇 가지 이유로 Flux CD v2로의 전환을 결정했습니다. 첫째, 클러스터의 상태를 좀 더 세밀하게 제어하고 싶다는 생각이 들었어요. Flux CD의 모듈식 아키텍처가 이런 요구를 충족해줄 수 있다고 판단했거든요. 둘째, Helm Chart 관리를 더 효율적으로 하고 싶었는데, Flux CD의 Helm Controller가 이를 잘 지원한다는 정보를 얻었습니다.

    마이그레이션 단계는 크게 다음과 같았습니다.

    1. Flux CD 설치 및 기본 설정: 먼저 클러스터에 Flux CD v2를 설치했어요. bootstrapping 과정을 통해 Git 저장소와 연결하고, 초기 동기화 설정을 완료합니다. 이때 Git 저장소의 디렉토리 구조나 접근 권한 등을 꼼꼼히 확인해야 했습니다.
    2. 기존 Argo CD 애플리케이션 전환: Argo CD에서 관리하던 Kubernetes Manifests (YAML 파일)나 Helm Charts를 Flux CD가 인식할 수 있는 형태로 변경했습니다. 저는 주로 Kustomize를 사용하고 있었기 때문에, Flux CD의 Kustomization Controller가 참조할 수 있도록 Git 저장소 구조를 조정하는 작업이 필요했어요.
    3. Helm Chart 관리 전환: Argo CD에서 Helm Release를 사용했다면, Flux CD의 Helm Controller를 사용하도록 설정 파일을 변경합니다. Helm Chart의 `values.yaml` 파일 관리 방식이나 Release 이름, 네임스페이스 등을 Flux CD의 `HelmRelease` CRD(Custom Resource Definition)에 맞게 수정해야 했어요. 이 과정에서 몇 가지 오타와 설정 누락으로 배포가 실패하는 경험도 했습니다. ⚠️
    4. 동기화 방식 검토 및 적용: Git hook을 사용할지, 주기적인 폴링을 사용할지 결정하고 설정했어요. 보안과 효율성을 고려했을 때 Git hook이 낫다고 판단하여, Git Provider (GitHub/GitLab 등)와 Flux CD 간의 Webhook 설정을 진행했습니다.
    5. 검증 및 테스트: 모든 설정이 완료된 후, 실제 애플리케이션 배포 및 업데이트를 반복적으로 테스트했습니다. 변경 사항이 제대로 Git에 반영되고, Flux CD가 이를 감지하여 클러스터에 적용하는지, 롤백은 잘 되는지 등을 꼼꼼히 확인했어요.
    Flux CD CLI를 이용한 Git 저장소 부트스트랩 및 초기 설정 화면

    Flux CD CLI를 사용하여 Git 저장소와 클러스터를 연결하고 초기 설정을 진행하는 과정의 일부입니다.

    4. ⚠️ 주의사항 및 트러블슈팅 경험

    마이그레이션 과정에서 몇 가지 예상 밖의 문제들을 겪었어요. 여러분도 이런 상황에 마주칠 수 있으니 미리 알아두시면 좋을 겁니다.

    • Git 저장소 구조 및 권한 문제: Flux CD는 Git 저장소의 특정 경로를 바라보고 동기화합니다. 처음에는 Git 저장소 구조를 Argo CD 방식 그대로 사용하려다 보니 Flux CD가 파일을 제대로 찾지 못하더라고요. Git 저장소 구조를 Flux CD가 이해하기 쉬운 형태로 재구성하는 게 중요했습니다. 또한 Git 저장소에 대한 클러스터의 접근 권한 (SSH Key 또는 Access Token) 설정이 올바르지 않으면 동기화 자체가 실패합니다.
    • HelmRelease CRD 설정 오류: Helm Chart를 관리할 때 `HelmRelease` CRD의 필드 이름을 잘못 입력하거나, 필수 값을 누락하는 경우가 있었어요. 예를 들어, `chart.spec.version` 대신 `chart.version`으로 잘못 입력한다거나, `releaseName`을 지정하지 않아 예상치 못한 이름으로 Helm Release가 생성되는 등의 문제가 발생했습니다. Flux CD의 공식 문서를 옆에 끼고 설정하는 걸 추천합니다.
    • Controller 간의 의존성 문제: Flux CD v2는 여러 Controller가 협력하여 동작합니다. Source Controller가 Git 저장소에서 소스를 가져오면, Kustomize Controller나 Helm Controller가 이를 받아 실제 리소스를 생성/업데이트하는 식이죠. Source Controller에 문제가 생기면 후속 Controller들도 제대로 동작하지 않아요. Flux CD의 각 Controller 상태를 `flux get kustomization`, `flux get helmrelease` 같은 명령어로 자주 확인하는 습관이 중요합니다.
    • 네임스페이스 (Namespace) 관리: Argo CD에서는 Application CRD에 네임스페이스를 지정하는 방식이 Flux CD의 `HelmRelease`나 `Kustomization` CRD와 조금 달라요. 기존 Argo CD에서 여러 네임스페이스에 걸쳐 리소스를 관리하고 있었다면, Flux CD에서는 각 CRD에 네임스페이스를 명확히 지정해주거나, Git 저장소 구조를 네임스페이스별로 분리하는 전략이 필요했습니다.

    가장 큰 삽질은 아마 Helm Chart의 `values.yaml`을 GitOps 방식으로 관리하면서 발생했던 버전 충돌 문제였어요. Git 저장소에서 Helm Chart를 가져오고, 이를 Kustomize로 패치하는 과정에서 버전 관리가 꼬여버렸거든요. 결국에는 Flux CD의 **`HelmRelease` CRD 내에서 `valuesFrom` 필드를 활용하여 Git 파일 참조 방식을 명확히 지정**해주고, Kustomize를 통한 패치보다는 `HelmRelease` 자체에서 값을 관리하는 방식으로 변경했어요. 이게 가장 큰 깨달음 중 하나였습니다. 💡

    Flux CD CLI를 이용한 동기화 상태 및 리소스 정보 확인 화면

    Flux CD의 CLI 명령어로 확인한 동기화 상태 및 리소스 정보를 보여주는 화면입니다.

    5. Flux CD 마이그레이션 결과: 뭐가 달라졌나? ✅

    Flux CD v2로 성공적으로 마이그레이션한 후, 저희는 몇 가지 긍정적인 변화를 경험했어요.

    • 향상된 모듈성과 유연성: GitOps Toolkit 덕분에 필요한 기능만 선택적으로 활성화하고 설정할 수 있게 됐어요. 이건 클러스터 리소스 사용량을 최적화하는 데도 도움이 되더라고요.
    • 강력해진 Helm Chart 관리: Helm Controller를 통해 Helm Chart 버전을 관리하고, `values.yaml`을 GitOps 방식으로 선언적으로 관리하는 게 훨씬 수월해졌어요.
    • 세밀한 제어 기능: Git hook을 통한 실시간 동기화, Controller별 상태 확인 등 이전보다 클러스터 상태를 더 세밀하게 제어하고 모니터링할 수 있게 됐습니다.
    • 개발팀의 GitOps 경험 개선: Git 저장소에 대한 변경 사항이 자동으로 클러스터에 반영되는 경험은 개발팀의 만족도를 높였어요. Pull Request를 통해 변경 사항을 리뷰하고 머지하는 과정이 자연스럽게 CI/CD 파이프라인으로 통합됐거든요.

    물론, Argo CD의 풍부한 웹 UI가 제공하는 편함은 Flux CD에서는 조금 줄어들었어요. 하지만 CLI의 발전과 커뮤니티의 노력으로 많은 부분이 개선되고 있고, 저희 팀은 CLI 중심의 워크플로우에 금방 익숙해졌습니다. 오히려 **CLI의 강력한 자동화 가능성** 덕분에 더 많은 부분을 스크립트로 관리할 수 있게 된 점을 긍정적으로 보고 있어요.

    Flux CD 마이그레이션 이후 CI/CD 파이프라인의 성공률 및 배포 속도 개선 지표를 시각화한 그래프입니다.

    6. 마무리하며: Flux CD와 함께하는 GitOps 여정

    Flux CD로의 마이그레이션은 분명 쉽지 않은 과정이었어요. Argo CD와는 다른 철학과 구조를 가지고 있었기에, 새로운 학습이 필요했고 예상치 못한 문제들과도 많이 씨름했거든요. 하지만 결과적으로 저희 팀은 GitOps 환경을 더욱 견고하고 효율적으로 구축할 수 있었습니다.

    핵심은 각 도구의 철학을 이해하고, 우리 환경에 맞는 방식을 선택하는 것입니다.

    • 단순하고 직관적인 GitOps 환경을 원하고, 풍부한 웹 UI가 중요하다면 Argo CD가 좋은 선택이 될 거예요.
    • 세밀한 제어, 모듈성, 그리고 강력한 Helm/Kustomize 통합을 원한다면 Flux CD v2가 매력적인 대안이 될 겁니다.

    아직 GitOps를 도입하지 않으셨거나, CI/CD 도구 전환을 고민하고 계신다면, 오늘 제가 나눈 경험이 조금이라도 도움이 되었으면 좋겠어요. 다음 글에서는 Flux CD의 특정 기능 (예: Policy as Code, Observability)에 대해 더 깊이 파고드는 내용을 다룰 예정이니 기대해주세요!

    궁금한 점이 있다면 언제든지 댓글로 남겨주세요. 함께 성장하는 엔지니어들이 되겠습니다! 감사합니다. 😊

  • [k8s] Helm 차트 관리의 진화: GitOps 시대의 베스트 프랙티스 분석

    [k8s] Helm 차트 관리의 진화: GitOps 시대의 베스트 프랙티스 분석

    안녕하세요, 13년차의 서버실입니다. 제가 처음 쿠버네티스(Kubernetes)를 접했을 때를 생각하면, 마치 새로운 대륙을 발견한 콜럼버스처럼 설레면서도 막막했던 기억이 나네요. 특히 애플리케이션 배포와 관리는 정말이지 끝없는 숙제 같았어요. 처음엔 kubectl apply -f 명령어로 YAML(야믈) 파일을 직접 하나하나 적용했었죠. 그러다 Helm(헬름, 쿠버네티스 패키지 매니저)을 만나고 나서야 비로소 숨통이 트이는 느낌이었습니다.

    Helm은 복잡한 쿠버네티스 애플리케이션을 패키징하고 배포하는 데 정말 혁신적인 도구였어요. 그런데 시간이 지나고 관리해야 할 차트(Chart)가 늘어나면서, 또 다른 고민이 생기더라고요. ‘이 많은 차트들을 어떻게 효과적으로 관리하고, 배포 이력을 추적하며, 안정적으로 운영할 수 있을까?’ 하는 문제였습니다. 수동으로 helm upgrade를 반복하는 건 실수 투성이였고, CI/CD(지속적 통합/지속적 배포) 파이프라인에 Helm 명령어를 넣는 것도 생각보다 손이 많이 갔거든요. ⚠️

    그러던 와중에 GitOps(깃옵스, Git 기반 운영 방식)라는 개념을 접하게 됐습니다. ‘아, 이거다!’ 싶었죠. 인프라와 애플리케이션의 상태를 Git 리포지토리(Repository)에 코드 형태로 정의하고, 이 Git을 유일한 진실의 원천(Single Source of Truth)으로 삼아 자동으로 클러스터 상태를 동기화하는 방식. 오늘은 이 GitOps 시대에 Helm 차트를 어떻게 하면 스마트하게 관리할 수 있는지, 제가 직접 홈랩에서 겪었던 경험과 함께 베스트 프랙티스(Best Practice)를 분석해 보려고 합니다. 여러분의 쿠버네티스 배포 여정에 이 글이 작은 등불이 되기를 바랍니다!

    GitOps 기반 Helm 차트 관리 아키텍처 개요 다이어그램

    GitOps 기반 Helm 차트 관리의 전체적인 아키텍처를 보여줍니다. 개발자가 Git에 변경사항을 푸시하면, GitOps 오퍼레이터(예: Flux CD)가 이를 감지하여 쿠버네티스 클러스터에 Helm 차트를 배포하는 흐름입니다.

    Helm과 GitOps, 그 관계를 파헤치다

    먼저 핵심 개념들을 잠시 짚고 넘어가 볼까요? 이미 잘 아시는 분도 많겠지만, 혹시 처음 접하는 분들을 위해 쉽게 설명해 드릴게요.

    • Helm (헬름): 쿠버네티스 패키지 매니저예요. 복잡한 애플리케이션을 차트(Chart)라는 패키지 형태로 정의하고, 이를 쉽게 설치, 업데이트, 삭제할 수 있도록 도와줍니다. 마치 리눅스의 apt나 yum처럼이죠. Deployment, Service, Ingress(인그레스, 외부 트래픽 진입점) 등 여러 쿠버네티스 리소스(Resource)들을 하나의 묶음으로 관리할 수 있게 해줘요.
    • GitOps (깃옵스): 쉽게 말해, Git을 중심으로 모든 것을 운영하는 방식입니다. 애플리케이션 코드뿐만 아니라, 인프라 구성(Infrastructure as Code)까지 전부 Git 리포지토리에 저장하고 관리합니다. 그리고 Git 리포지토리의 변경 사항이 감지되면, GitOps 에이전트(Agent)가 자동으로 쿠버네티스 클러스터에 배포하거나 상태를 동기화(Reconciliation)하는 구조예요. 사람이 직접 명령어를 입력할 필요 없이, Git에 커밋(Commit)만 하면 배포가 이뤄지는 거죠. 🎉

    그럼 Helm과 GitOps가 만나면 어떤 시너지를 낼까요? 기존에는 Helm 명령어를 CI/CD 파이프라인에서 실행하거나, 개발자가 직접 터미널에서 입력해서 배포했었죠. 하지만 GitOps를 도입하면, Helm 차트의 설정 파일(values.yaml)이나 차트 자체의 버전 변경을 Git에 커밋하는 것만으로 배포가 자동으로 트리거(Trigger)됩니다. ‘선언적(Declarative)’으로 상태를 정의하고, ‘자동으로 동기화(Automated Synchronization)’되는 거죠. 이 덕분에 배포의 투명성, 안정성, 감사(Audit) 용이성이 크게 향상됩니다. 제가 직접 해보니, 이게 진짜 편하더라고요!

    실전! GitOps 기반 Helm 차트 관리 구현: Flux CD를 중심으로

    홈랩에서 다양한 GitOps 툴을 실험해 봤는데, 개인적으로는 Flux CD(플럭스 CD)가 Helm 차트 관리에 참 잘 맞았어요. 물론 Argo CD(아르고 CD)도 훌륭한 대안이고요. 오늘은 Flux CD를 활용해서 GitOps 기반 Helm 차트 관리 환경을 구축하는 방법을 단계별로 설명해 드릴게요. 따라오시면 여러분도 쉽게 구현하실 수 있을 겁니다.

    1. Flux CD 설치 및 초기 설정

      먼저 쿠버네티스 클러스터(Cluster)에 Flux CD를 설치해야 합니다. Flux CLI(커맨드 라인 인터페이스)를 사용하면 정말 쉽게 설치할 수 있어요.

      
      # Flux CLI 설치 (macOS 기준, 다른 OS는 공식 문서 참고)
      brew install fluxcd/tap/flux
      
      # Flux CD 초기화 및 Git 리포지토리 연동
      # 여기서 your-git-repo는 GitOps 설정을 저장할 리포지토리 주소입니다.
      # --branch main은 기본 브랜치를 main으로 설정하는 것이고요.
      # --path clusters/my-cluster는 Flux가 모니터링할 Git 리포지토리 내 경로입니다.
      flux bootstrap git \
        --owner=<your-git-username> \
        --repository=<your-git-repo> \
        --branch=main \
        --path=clusters/my-cluster \
        --personal
              

      위 명령어를 실행하면 Flux CD가 필요한 컨트롤러(Controller)들을 쿠버네티스 클러스터에 설치하고, 지정된 Git 리포지토리와 연동합니다. 이제 Git 리포지토리 clusters/my-cluster 경로에 변경 사항이 생기면 Flux CD가 자동으로 감지하게 됩니다. ✅

    2. Git 리포지토리 구조 잡기

      GitOps의 핵심은 Git 리포지토리 구조를 잘 잡는 것입니다. 저는 보통 이런 식으로 구성합니다.

      
      .
      ├── clusters/
      │   └── my-cluster/ # Flux CD가 모니터링할 경로
      │       ├── flux-system/ # Flux CD가 생성한 리소스 (자동 관리)
      │       └── applications/ # 배포할 애플리케이션 HelmRelease 정의
      │           ├── nginx/
      │           │   └── nginx-helmrelease.yaml
      │           └── prometheus/
      │               └── prometheus-helmrelease.yaml
      └── helm-charts/ # 직접 만든 Helm 차트 (선택 사항, 외부 차트 사용 시 필요 없음)
          └── my-app/
              ├── Chart.yaml
              ├── values.yaml
              └── templates/
                  └── ...
              
    3. Helm 차트 정의 및 배포 (HelmRepository, HelmRelease)

      이제 애플리케이션을 배포해 볼까요? 예를 들어, 안정적인 Nginx(엔진엑스) Ingress Controller(인그레스 컨트롤러)를 배포한다고 가정해 봅시다. Flux CD에서는 HelmRepository와 HelmRelease라는 커스텀 리소스(Custom Resource)를 사용합니다.

      먼저 Helm 차트 저장소(Repository)를 정의합니다. Nginx Ingress Controller의 공식 Helm 저장소를 추가하는 HelmRepository 리소스입니다.

      
      # clusters/my-cluster/applications/nginx/nginx-helmrepository.yaml
      apiVersion: source.toolkit.fluxcd.io/v1beta2
      kind: HelmRepository
      metadata:
        name: ingress-nginx
        namespace: flux-system # Flux CD 시스템 네임스페이스
      spec:
        interval: 1h0m0s # 1시간마다 저장소 업데이트 확인
        url: https://kubernetes.github.io/ingress-nginx
              

      이 파일을 Git 리포지토리의 clusters/my-cluster/applications/nginx/ 경로에 저장하고 커밋(Commit)하면, Flux CD가 이를 감지하여 쿠버네티스 클러스터에 HelmRepository 리소스를 생성합니다. Flux CD는 이 저장소를 주기적으로 스캔하여 최신 차트 정보를 가져오게 됩니다. 💡

      Flux CD HelmRelease를 이용한 쿠버네티스 차트 배포 흐름

      Flux CD가 Git 리포토리의 HelmRelease 정의를 읽어 쿠버네티스 클러스터에 Helm 차트를 배포하는 과정을 시각화한 다이어그램입니다.

      다음으로, 실제로 Nginx Ingress Controller를 배포할 HelmRelease 리소스를 정의합니다. 여기에 어떤 차트를 어떤 버전으로, 어떤 값(values)으로 배포할지 상세하게 명시합니다.

      
      # clusters/my-cluster/applications/nginx/nginx-helmrelease.yaml
      apiVersion: helm.toolkit.fluxcd.io/v2beta1
      kind: HelmRelease
      metadata:
        name: ingress-nginx
        namespace: ingress-nginx # Nginx Ingress Controller가 배포될 네임스페이스
      spec:
        interval: 5m0s # 5분마다 상태 동기화 확인
        chart:
          spec:
            chart: ingress-nginx # HelmRepository에 정의된 차트 이름
            version: ">=4.0.0 <5.0.0" # 차트 버전 범위 지정
            sourceRef:
              kind: HelmRepository
              name: ingress-nginx # 위에서 정의한 HelmRepository 이름
              namespace: flux-system
        values: # values.yaml 내용과 동일
          controller:
            replicaCount: 2
            service:
              type: LoadBalancer
            nodeSelector:
              kubernetes.io/os: linux
          defaultBackend:
            enabled: true
              

      이 파일도 Git 리포지토리에 저장하고 커밋하면, Flux CD는 HelmRepository에서 차트를 가져와 이 HelmRelease 정의에 따라 Nginx Ingress Controller를 클러스터에 배포하게 됩니다. 와, 정말 깔끔하게 배포되는 거 보니까 속이 다 시원하더라고요! 이제 배포에 대한 모든 변경사항은 Git에서만 이뤄지게 됩니다. 🚀

    삽질 대잔치! 겪었던 문제와 해결 과정

    물론 이렇게 깔끔하게 설명했지만, 제가 이걸 처음 세팅할 때는 삽질 좀 했습니다 ㅎㅎ. 특히 몇 가지 문제로 머리를 싸맸던 기억이 나네요. 여러분은 저 같은 실수 하지 마시라고 몇 가지 팁을 공유해 드립니다. ⚠️

    • HelmRelease 동기화 실패:

      처음에는 Git에 커밋했는데도 클러스터에 아무런 변화가 없어서 당황했어요. 알고 보니 HelmRepository의 interval이나 HelmRelease의 interval 설정이 너무 길거나, Git 리포지토리 경로를 잘못 지정한 경우가 많았습니다. Flux CD의 로그를 꼼꼼히 확인하고, flux reconcile kustomization <kustomization-name> 명령어로 수동 동기화를 시도하면서 문제를 찾아냈습니다.

      
              # Flux CD Kustomization 상태 확인 (Git 리포지토리 동기화 상태)
              flux get kustomizations
      
              # Flux CD HelmRelease 상태 확인
              flux get hr -A # 모든 네임스페이스의 HelmRelease 확인
              
    • imagePullSecrets 적용 문제:

      프라이빗 레지스트리(Private Registry)에 있는 이미지를 사용해야 할 때, imagePullSecrets(이미지 풀 시크릿)을 ServiceAccount(서비스 어카운트)에 연결해야 하잖아요? 이걸 HelmRelease의 values에 직접 넣어도 되지만, 보안상 좋지 않거나 모든 ServiceAccount에 적용하고 싶을 때가 있습니다. 이럴 땐 Kustomize(커스터마이즈)를 활용하여 ServiceAccount에 imagePullSecrets를 패치(Patch)하는 방식으로 해결했습니다. Flux CD는 Kustomization 리소스도 지원해서, Helm과 Kustomize를 함께 사용하는 것도 가능합니다. (이건 다음 기회에 더 자세히 다뤄볼게요!)

    • 차트 버전 범위 지정 오류:

      HelmRelease에서 version: ">=4.0.0 <5.0.0"처럼 버전을 지정할 때, 세밀하게 지정하지 않으면 예상치 못한 마이너 버전 업데이트로 인해 문제가 생길 수 있습니다. 너무 넓은 범위보다는 안정성이 검증된 특정 버전이나, 패치 버전까지만 허용하는 것이 좋습니다.

    드디어! GitOps로 배포된 Helm 차트 확인

    이제 모든 설정이 완료되고 Git에 커밋까지 했다면, Flux CD가 자동으로 배포를 진행했을 겁니다. 배포가 제대로 되었는지 확인해 봐야겠죠? kubectl 명령어로 확인하면 됩니다.

    
    # Flux CD가 관리하는 Kustomization 리소스 상태 확인
    kubectl get kustomizations -n flux-system
    
    # Flux CD가 관리하는 HelmRelease 리소스 상태 확인
    kubectl get helmreleases -n ingress-nginx
    
    # Nginx Ingress Controller 파드(Pod) 확인
    kubectl get pods -n ingress-nginx
    

    helmreleases의 상태가 Ready이고, pods가 모두 Running 상태라면 성공입니다! 🎉 정말 깔끔하게 배포된 걸 보니까 속이 다 시원하더라고요. 이제 어떤 변경이든 Git 리포지토리에 반영하는 것만으로 배포가 자동으로 이뤄집니다. 롤백(Rollback)도 Git에서 이전 커밋으로 되돌리는 것만으로 가능하니, 얼마나 안정적이고 편리한지 몰라요.

    Kubernetes 클러스터에서 kubectl 명령어를 사용하여 Flux CD의 HelmRelease와 관련된 리소스들이 성공적으로 배포되고 실행 중인 상태를 보여주는 터미널 화면입니다.

    마무리하며: Helm GitOps, 더 나은 미래를 향해

    오늘은 13년차 인프라 엔지니어의 시선으로 Helm 차트 관리의 진화, 특히 GitOps 시대의 베스트 프랙티스를 Flux CD를 중심으로 알아봤습니다. 제가 직접 경험해 보니 GitOps는 단순히 도구를 사용하는 것을 넘어, 인프라 운영 방식 자체를 혁신하는 패러다임(Paradigm)이라는 생각이 들었습니다.

    GitOps 기반 Helm 차트 관리는 다음과 같은 장점들을 가져다줍니다.

    • 생산성 향상: 수동 작업 감소, 자동화된 배포.
    • 안정성 증대: Git을 통한 단일 진실의 원천, 쉬운 롤백.
    • 투명성 및 감사 용이성: 모든 변경 이력이 Git에 기록.
    • 협업 강화: 코드 리뷰(Code Review)를 통한 변경 사항 검증.
    전통적인 Helm 관리 방식과 GitOps 기반 Helm 관리 방식 비교표

    전통적인 Helm 관리 방식과 GitOps 기반 Helm 관리 방식을 주요 특징(자동화, 롤백, 투명성 등)별로 비교하는 인포그래픽 형태의 표입니다.

    물론 GitOps를 도입하는 것이 마냥 쉽지만은 않습니다. 초기 설정의 복잡성, Git 리포지토리 관리 전략 수립, 그리고 팀원들의 새로운 워크플로우(Workflow) 적응 등 넘어야 할 산들이 분명히 존재합니다. 하지만 그 모든 노력을 감수할 만큼의 가치가 충분하다고 저는 확신합니다. 결국 GitOps는 인프라 운영의 투명성과 안정성을 극대화하고, 개발팀과 운영팀 간의 협업을 더욱 매끄럽게 만드는 데 크게 기여할 겁니다.

    다음 글에서는 Flux CD의 고급 기능이나 다른 GitOps 툴인 Argo CD(아르고 CD)와의 비교, 또는 Kustomize를 활용한 Helm 차트 오버레이(Overlay) 방법에 대해서도 다뤄볼 예정입니다. 계속해서 “13년차의 서버실”에 많은 관심 부탁드립니다. 궁금한 점이나 여러분의 경험담이 있다면 댓글로 남겨주세요! 함께 고민하고 성장해 나가는 것이 저의 기쁨입니다. 😊

  • [k8s] ArgoCD로 멀티 클러스터 GitOps 배포 자동화 완벽 가이드

    [k8s] ArgoCD로 멀티 클러스터 GitOps 배포 자동화 완벽 가이드

    ArgoCD로 멀티 클러스터 GitOps 배포 자동화 완벽 가이드

    안녕하세요, 13년차 서버실 지킴이입니다. 오늘도 어김없이 여러분의 인프라 여정에 도움이 될 만한 꿀팁을 들고 왔습니다. 혹시 여러 쿠버네티스 클러스터를 운영하면서 배포 때문에 머리 아팠던 경험 있으신가요? 개발, 스테이징, 운영 환경이 각각 다른 클러스터에 존재하거나, 온프레미스와 클라우드를 넘나드는 하이브리드 환경에서 일관된 배포를 유지하는 게 정말 쉽지 않거든요. 저도 처음엔 수동 배포 지옥에서 헤매던 시절이 있었죠. 클러스터마다 kubectl 명령어를 치고, YAML 파일을 수정하고, 휴먼 에러로 인해 서비스 장애를 겪었던 아찔한 순간들도 많았고요. 😱

    하지만 GitOps(깃옵스)를 만나고, 특히 ArgoCD(아르고CD)를 활용하면서 이런 배포 스트레스가 확 줄었습니다. 오늘은 저처럼 멀티 클러스터 환경에서 배포 자동화에 목마른 분들을 위해, ArgoCD로 GitOps를 구현하고 여러 클러스터에 애플리케이션을 자동으로 배포하는 멀티 클러스터 GitOps 배포 자동화 방법을 완벽하게 가이드해 드리려고 합니다. 제가 직접 삽질하며 터득한 경험들을 솔직하게 공유할 테니, 끝까지 따라오시면 분명 큰 도움이 될 겁니다! 자, 그럼 시작해 볼까요?

    ArgoCD를 활용한 멀티 클러스터 GitOps 배포 아키텍처는 위와 같이 구성될 수 있습니다. 하나의 ArgoCD 인스턴스가 여러 쿠버네티스 클러스터에 애플리케이션을 배포하고 관리하는 모습이죠. Git을 중심으로 모든 클러스터의 상태를 동기화하는 핵심 아이디어를 담고 있습니다.

    1. GitOps와 ArgoCD, 그리고 멀티 클러스터 배포, 이게 뭔가요?

    본격적인 실전에 앞서, 핵심 개념들을 짚고 넘어가는 게 중요하겠죠? 제가 늘 강조하는 부분인데, 도구를 잘 쓰는 것도 중요하지만, 그 도구가 왜 필요하고 어떤 철학을 담고 있는지 이해하는 게 진짜 실력입니다.

    • GitOps (깃옵스): 쉽게 말해, Git을 유일한 진실의 원천(Single Source of Truth)으로 삼아 인프라와 애플리케이션 배포를 자동화하는 운영 방식이에요. 모든 설정과 배포 상태를 Git 리포지토리에 코드로 관리하고, Git에 변경사항이 푸시되면 자동으로 인프라에 반영되도록 하는 거죠. 개발자들이 코드 관리하듯이 인프라를 관리한다고 생각하시면 됩니다. 일관성, 버전 관리, 감사 추적(Audit Trail)이 가능하다는 엄청난 장점이 있어요.

    • ArgoCD (아르고CD): 이 친구는 GitOps를 쿠버네티스(Kubernetes) 환경에서 구현해주는 선언적(Declarative) GitOps 지속적 배포(Continuous Delivery) 툴입니다. Git 리포지토리에 정의된 원하는 상태(Desired State)와 실제 쿠버네티스 클러스터의 현재 상태(Live State)를 끊임없이 비교하고, 만약 다르면 Git에 정의된 상태로 클러스터를 동기화(Sync)시켜 줍니다. 마치 클러스터 상태를 감시하는 파수꾼 같다고 할까요? 정말 든든한 친구더라고요.

    • 멀티 클러스터 배포 (Multi-Cluster Deployment): 여러 개의 쿠버네티스 클러스터에 동일하거나 다른 애플리케이션을 배포하고 관리하는 시나리오를 말합니다. 개발, 스테이징, 운영 환경을 분리하거나, 재해 복구(DR)를 위해 지리적으로 분산된 클러스터를 운영할 때 주로 사용하죠. ArgoCD는 하나의 중앙 인스턴스에서 여러 클러스터를 관리할 수 있어서, 멀티 클러스터 환경에서 배포를 중앙 집중화하고 자동화하는 데 아주 탁월한 솔루션입니다.

    2. 실전 구현: ArgoCD로 멀티 클러스터 GitOps 환경 구축하기

    자, 이제 이론은 충분히 봤으니, 저와 함께 직접 만들어 볼 시간입니다. 제가 홈랩에서 여러 번 시도하면서 가장 효율적이라고 생각했던 방법으로 안내해 드릴게요. 따라만 하시면 됩니다! 💡

    2.1. 사전 준비물 (Prerequisites)

    시작하기 전에 몇 가지 준비물이 필요합니다.

    • 쿠버네티스 클러스터 2개 이상: 하나는 ArgoCD를 설치할 ‘컨트롤 플레인 클러스터’로, 나머지는 애플리케이션을 배포할 ‘타겟 클러스터’로 사용할 겁니다. (저는 KIND나 K3s로 쉽게 구성했어요.)
    • kubectl: 쿠버네티스 클러스터를 제어하는 CLI 도구.
    • Helm (선택 사항): 쿠버네티스 패키지 매니저. ArgoCD 설치에 Helm을 사용하진 않지만, 애플리케이션 배포에 유용할 수 있습니다.
    • Git 리포지토리: 배포할 애플리케이션의 YAML 파일들을 저장할 공간 (GitHub, GitLab, Bitbucket 등).

    2.2. 단계 1: ArgoCD 설치 (컨트롤 플레인 클러스터)

    먼저 ArgoCD를 설치할 클러스터에 ArgoCD를 배포합니다. 이 클러스터가 모든 배포의 중앙 통제실 역할을 하게 됩니다.

    1. ArgoCD 네임스페이스 생성

      kubectl create namespace argocd
    2. ArgoCD 설치 YAML 적용

      kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

      이 명령은 ArgoCD의 모든 컴포넌트(API 서버, 컨트롤러, 레포 서버 등)를 설치합니다. 잠시 기다리면 파드들이 정상적으로 올라올 거예요.

    3. ArgoCD CLI 설치 (선택 사항이지만 강력 추천!)

      # macOS (Homebrew)
      brew install argocd
      
      # Linux (직접 다운로드)
      curl -sSL -o argocd-linux-amd64 https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
      sudo install -m 555 argocd-linux-amd64 /usr/local/bin/argocd
      rm argocd-linux-amd64
    4. 초기 비밀번호 확인 및 UI 접근

      ArgoCD API 서버의 초기 비밀번호는 컨트롤 플레인 클러스터의 argocd-initial-admin-secret 시크릿에 저장되어 있습니다.

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

      UI에 접근하려면 포트 포워딩(Port Forwarding)을 해줘야 합니다.

      kubectl port-forward svc/argocd-server -n argocd 8080:443

      이제 웹 브라우저에서 https://localhost:8080으로 접속한 후, 사용자명 admin과 위에서 확인한 비밀번호로 로그인하세요. 첫 로그인 후 비밀번호를 변경하는 것을 추천합니다.

    2.3. 단계 2: Git Repository 준비

    배포할 애플리케이션의 YAML 파일들을 Git 리포지토리에 준비해야 합니다. 저는 간단한 Nginx 배포 파일을 예시로 들어볼게요.

    my-gitops-repo/apps/nginx/deployment.yaml

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx-deployment
      labels:
        app: nginx
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: nginx:1.14.2
            ports:
            - containerPort: 80

    my-gitops-repo/apps/nginx/service.yaml

    apiVersion: v1
    kind: Service
    metadata:
      name: nginx-service
    spec:
      selector:
        app: nginx
      ports:
        - protocol: TCP
          port: 80
          targetPort: 80
      type: LoadBalancer # 또는 ClusterIP, NodePort

    이 파일들을 Git 리포지토리에 푸시해 주세요. (예: https://github.com/your-org/my-gitops-repo.git)

    2.4. 단계 3: 타겟 클러스터 등록 (ArgoCD에 연결)

    이제 ArgoCD가 애플리케이션을 배포할 타겟 클러스터들을 ArgoCD에 등록해야 합니다. ArgoCD CLI를 사용하면 아주 쉽게 등록할 수 있어요.

    1. ArgoCD CLI 로그인

      argocd login localhost:8080

      초기 비밀번호로 로그인합니다.

    2. 타겟 클러스터 등록

      현재 kubeconfig 파일에 정의된 클러스터 컨텍스트(Context)를 사용해서 등록합니다. 등록할 클러스터의 컨텍스트로 kubectl config use-context <TARGET_CLUSTER_CONTEXT> 명령어를 실행한 후, 아래 명령어를 실행하세요.

      argocd cluster add <TARGET_CLUSTER_CONTEXT>

      예를 들어, dev-cluster와 prod-cluster라는 컨텍스트가 있다면 각각 등록해 줍니다.

      이 명령은 ArgoCD가 타겟 클러스터에 접근할 수 있도록 필요한 RBAC 설정과 시크릿을 자동으로 생성해 줍니다. ⚠️ 권한 문제로 많이들 삽질하시는데, 이 단계에서 정확한 컨텍스트를 선택했는지 꼭 확인하세요.

    3. 등록된 클러스터 확인

      argocd cluster list

      등록된 클러스터 목록이 보이면 성공입니다! ArgoCD UI에서도 ‘Clusters’ 메뉴에서 확인할 수 있습니다.

    ArgoCD UI에서 클러스터가 성공적으로 등록되고 ApplicationSet이 여러 클러스터에 배포되는 모습을 시각적으로 확인할 수 있습니다. 각 클러스터별로 애플리케이션 상태를 한눈에 파악할 수 있죠.

    2.5. 단계 4: ApplicationSet으로 멀티 클러스터 배포 자동화

    이제 이 글의 핵심인 ApplicationSet(애플리케이션셋)을 활용해서 여러 클러스터에 Nginx 애플리케이션을 배포해 볼 시간입니다. ApplicationSet은 여러 개의 ArgoCD Application 리소스를 동적으로 생성해주는 컨트롤러입니다. 특히 멀티 클러스터 환경에서 빛을 발하죠!

    ApplicationSet을 사용하면, 등록된 모든 클러스터에 동일한 애플리케이션을 배포하거나, 클러스터별로 약간 다른 설정을 적용하여 배포할 수 있습니다. 여기서는 Cluster Generator를 사용해서 ArgoCD에 등록된 모든 클러스터에 Nginx를 배포하도록 해볼게요.

    my-gitops-repo/applicationsets/nginx-applicationset.yaml

    apiVersion: argoproj.io/v1alpha1
    kind: ApplicationSet
    metadata:
      name: multi-cluster-nginx
      namespace: argocd
    spec:
      generators:
      - clusters: {}
      template:
        metadata:
          name: '{{name}}-nginx' # 클러스터 이름 기반으로 Application 이름 생성
          namespace: argocd
        spec:
          project: default
          source:
            repoURL: https://github.com/your-org/my-gitops-repo.git # 본인의 Git 리포지토리 URL로 변경
            targetRevision: HEAD
            path: apps/nginx
          destination:
            server: '{{server}}'
            namespace: default
          syncPolicy:
            automated:
              prune: true
              selfHeal: true
            syncOptions:
              - CreateNamespace=true # 대상 클러스터에 네임스페이스가 없으면 생성

    위 YAML 파일을 Git 리포지토리에 푸시한 후, ArgoCD가 설치된 컨트롤 플레인 클러스터에 적용합니다.

    kubectl apply -n argocd -f my-gitops-repo/applicationsets/nginx-applicationset.yaml

    잠시 후 ArgoCD UI의 ‘Applications’ 메뉴로 이동해 보세요. 등록된 클러스터 개수만큼 <클러스터이름>-nginx 형태의 애플리케이션이 자동으로 생성되고, 배포가 시작되는 것을 확인할 수 있을 겁니다. 정말 신기하더라고요! 🎉

    3. 주의사항 및 트러블슈팅: 저의 삽질 경험담 ⚠️

    제가 13년간 인프라 엔지니어로 일하면서 깨달은 건, 새로운 기술을 도입할 때 늘 예상치 못한 문제가 터진다는 겁니다. ArgoCD도 예외는 아니었죠. 제가 겪었던 주요 삽질 경험과 해결 팁을 공유해 드립니다.

    • RBAC (Role-Based Access Control) 문제: 타겟 클러스터 등록 시 ArgoCD가 해당 클러스터에 접근할 권한이 없어서 배포가 실패하는 경우가 많았습니다. argocd cluster add 명령이 자동으로 RBAC를 설정해주지만, 때로는 특정 리소스에 대한 추가 권한이 필요할 수 있어요. ArgoCD 서버의 서비스 어카운트(Service Account)에 필요한 ClusterRoleBinding이 제대로 되어있는지 확인하고, 필요하다면 수동으로 추가해줘야 합니다.

      # 예시: ArgoCD 서비스 어카운트에 Cluster-Admin 권한 부여 (실제 운영에서는 최소 권한 원칙 준수)
      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRoleBinding
      metadata:
        name: argocd-manager-role-binding
      subjects:
      - kind: ServiceAccount
        name: argocd-argocd-application-controller
        namespace: argocd
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: ClusterRole
        name: cluster-admin # or a more specific role
    • Kubeconfig 파일 접근 권한: ArgoCD가 타겟 클러스터에 접근하려면 컨트롤 플레인 클러스터에서 타겟 클러스터의 API 서버에 네트워크적으로 연결이 가능해야 합니다. 방화벽, VPC 설정 등을 꼼꼼히 확인하세요. 특히 온프레미스와 클라우드 하이브리드 환경에서는 네트워크 경로 설정이 복잡해질 수 있습니다.

    • Sync Policy 설정: automated: prune: true와 selfHeal: true 옵션은 배포를 매우 편리하게 해주지만, 자칫 잘못하면 예상치 못한 변경이 즉시 반영될 수 있습니다. 특히 운영 환경에서는 신중하게 접근하고, 처음에는 수동 동기화(Manual Sync)로 시작하여 동작을 충분히 이해한 후 자동화하는 것을 추천합니다.

    • ApplicationSet Generator 문제: Cluster Generator를 쓸 때, Git 리포지토리의 경로(path)나 targetRevision, 그리고 destination의 server와 namespace 설정에 오타가 없는지 여러 번 확인해야 합니다. 변수({{name}}, {{server}}) 사용법도 헷갈리기 쉽더라고요.

    4. 검증 및 결과: 드디어 됐다! ✅

    이제 ArgoCD UI에서 모든 애플리케이션들이 Synced 상태인지 확인해 보세요. 각 클러스터에 배포된 Nginx 파드들도 kubectl get pods -n default 명령으로 확인하면 정상적으로 실행되고 있을 겁니다. 드디어 모든 클러스터에 배포가 완료됐네요! 이 맛에 GitOps 하는 거 아니겠습니까? 🎉

    여기서 끝이 아닙니다! GitOps의 진정한 가치는 Git 변경 사항이 자동으로 반영되는 데 있거든요. my-gitops-repo/apps/nginx/deployment.yaml 파일의 replicas 수를 2에서 3으로 변경하고 Git에 푸시해 보세요. ArgoCD가 변경 사항을 감지하고, 몇 초 내에 모든 타겟 클러스터의 Nginx 파드 개수가 3개로 자동으로 업데이트되는 것을 볼 수 있을 겁니다. 정말 편하더라고요!

    ArgoCD 대시보드에서 여러 클러스터에 배포된 애플리케이션들의 실시간 상태를 모니터링하는 화면입니다. 모든 애플리케이션이 정상적으로 동기화(Synced)된 것을 확인할 수 있습니다.

    5. 마무리: GitOps로 한 단계 더 성장하기

    오늘은 ArgoCD를 활용하여 멀티 클러스터 GitOps 배포 자동화를 구현하는 과정을 저의 경험을 바탕으로 상세하게 설명해 드렸습니다. 어떠셨나요? 처음엔 복잡해 보이지만, 한 번 구축해 놓으면 배포의 일관성, 속도, 안정성이 비약적으로 향상되는 것을 체감하실 수 있을 겁니다.

    멀티 클러스터 환경에서 ArgoCD와 GitOps는 정말 강력한 조합입니다. 수동 작업에서 벗어나 휴먼 에러를 줄이고, Git을 통한 완벽한 버전 관리와 감사 추적이 가능해지거든요. 무엇보다 인프라 엔지니어가 더 중요하고 전략적인 업무에 집중할 수 있도록 도와주는 멋진 도구라고 생각합니다.

    물론 초기 설정에 시간과 노력이 필요하고, GitOps 문화에 적응하는 과정도 필요합니다. 하지만 그 투자 가치는 충분하다고 제가 직접 보증합니다. 제 홈랩에서도 이 방식으로 다양한 서비스를 배포하고 있거든요. 😉

    다음번에는 오늘 배운 ArgoCD와 GitOps 개념을 확장해서, Helm Chart 통합, Kustomize 활용, 그리고 Argo Rollouts(아르고 롤아웃)를 이용한 블루/그린, 카나리 배포 전략까지 자동화하는 경험담을 들려드릴게요! 이 글이 여러분의 인프라 여정에 작은 이정표가 되었기를 바랍니다. 다음에 또 만나요!

    GitOps와 기존 배포 방식, 그리고 ArgoCD의 멀티 클러스터 관리 장점을 요약한 인포그래픽입니다. 어떤 점들이 개선되었는지 한눈에 파악할 수 있습니다.

  • [k8s] ArgoCD GitOps CI/CD 구축: 쿠버네티스 자동 배포 완벽 가이드

    배포가 두려운 분들께 — GitOps가 바꿔놓은 제 일상

    솔직히 말씀드리면, 저도 예전에는 배포가 제일 무서웠어요. 스테이징에서는 멀쩡하던 게 프로덕션에 올리면 왜인지 모르게 터지고, “누가 언제 뭘 바꿨지?” 하고 kubectl로 이것저것 뒤지다 보면 어느새 새벽 2시가 되어 있는 그런 날들이요. 쿠버네티스를 도입하고 나서도 한동안은 이 상황이 크게 달라지지 않았습니다. 오히려 배포 방법이 늘어나면서 혼란이 더 심해지기도 했고요.

    그러다가 ArgoCD를 알게 됐습니다. 처음엔 “또 새로운 툴이네” 하고 반신반의했는데, 막상 써보니까 진짜 다르더라고요. GitOps 방식으로 쿠버네티스 배포를 자동화하면, Git 저장소가 클러스터의 “진실의 원천(Source of Truth)”이 됩니다. 코드를 푸시하면 ArgoCD가 알아서 클러스터 상태를 맞춰주는 거예요. 오늘은 제가 홈랩과 실무에서 직접 구축하면서 겪은 경험을 바탕으로, ArgoCD를 활용한 CI/CD 파이프라인 구축 방법을 처음부터 끝까지 같이 살펴보겠습니다.

    ArgoCD GitOps 전체 아키텍처 — Git 저장소 변경이 쿠버네티스 클러스터에 자동 반영되는 흐름

    GitOps와 ArgoCD, 쉽게 이해하기

    GitOps란 뭔가요?

    GitOps를 한 문장으로 정리하면 이렇습니다. “인프라와 애플리케이션의 원하는 상태(Desired State)를 Git에 선언적으로 저장하고, 자동화 도구가 실제 상태를 그것에 맞게 유지하는 방식”이에요.

    쉽게 말해서, 예전에는 “지금 클러스터에 뭐가 떠 있지?”를 확인하려면 kubectl get 명령어를 직접 쳐봐야 했잖아요. GitOps를 쓰면 Git 저장소만 봐도 현재 클러스터 상태를 알 수 있어요. 변경 이력도 다 남고, 롤백도 git revert 한 방이면 되고요.

    기존 CI/CD 방식과 무엇이 다른가요?

    구분 기존 Push 방식 CI/CD GitOps (ArgoCD Pull 방식)
    배포 트리거 CI 파이프라인이 kubectl apply 직접 실행 ArgoCD가 Git 변경 감지 후 자동 동기화
    클러스터 접근 권한 CI 서버가 클러스터 자격증명 보유 ArgoCD만 클러스터 내부에서 관리
    상태 추적 파이프라인 로그 확인 필요 Git 커밋 히스토리 = 배포 이력
    드리프트(Drift) 감지 수동 확인 필요 ArgoCD가 실시간 감지 및 알림
    롤백 파이프라인 재실행 or 수동 Git revert + 자동 동기화

    특히 드리프트(Drift) 감지가 저한테는 정말 킬러 피처였어요. 누군가 실수로 kubectl로 직접 설정을 바꿔놔도, ArgoCD가 “어? Git이랑 다른데?” 하고 바로 잡아주거든요. 이게 얼마나 안심되는지 모릅니다.

    ArgoCD 설치 — 생각보다 간단합니다

    사전 준비

    • 쿠버네티스 클러스터 (v1.19 이상 권장)
    • kubectl 설치 및 클러스터 접근 설정 완료
    • Git 저장소 (GitHub, GitLab, Bitbucket 모두 가능)
    • ArgoCD CLI (선택사항이지만 있으면 편해요)

    1단계: ArgoCD 네임스페이스 및 설치

    ArgoCD 공식 설치 방법은 정말 간단합니다. 공식 매니페스트를 그대로 적용하면 되거든요.

    # ArgoCD 전용 네임스페이스 생성
    kubectl create namespace argocd
    
    # ArgoCD 공식 매니페스트 적용
    kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
    
    # 설치 완료 확인 (모든 Pod가 Running 상태가 될 때까지 대기)
    kubectl get pods -n argocd -w

    처음에 저도 이게 너무 간단해서 “이게 맞나?” 싶었는데, 맞습니다 ㅎㅎ. 잠시 기다리면 아래와 같이 Pod들이 뜨기 시작해요.

    NAME                                                READY   STATUS    RESTARTS   AGE
    argocd-application-controller-0                     1/1     Running   0          2m
    argocd-applicationset-controller-xxx                1/1     Running   0          2m
    argocd-dex-server-xxx                               1/1     Running   0          2m
    argocd-notifications-controller-xxx                 1/1     Running   0          2m
    argocd-redis-xxx                                    1/1     Running   0          2m
    argocd-repo-server-xxx                              1/1     Running   0          2m
    argocd-server-xxx                                   1/1     Running   0          2m

    2단계: ArgoCD UI 접근 설정

    기본적으로 ArgoCD 서버는 외부에 노출되어 있지 않아요. 로컬에서 테스트할 때는 포트 포워딩을 쓰고, 실제 운영 환경에서는 Ingress를 설정하는 게 좋습니다.

    # 로컬 테스트용 포트 포워딩
    kubectl port-forward svc/argocd-server -n argocd 8080:443
    
    # 초기 admin 비밀번호 확인
    kubectl -n argocd get secret argocd-initial-admin-secret \
      -o jsonpath="{.data.password}" | base64 -d; echo

    💡 팁: 초기 비밀번호는 반드시 첫 로그인 후 바꿔주세요. 그리고 argocd-initial-admin-secret은 비밀번호 변경 후 삭제하는 게 보안상 좋습니다.

    3단계: ArgoCD CLI 설치 (선택 권장)

    # macOS
    brew install argocd
    
    # Linux
    curl -sSL -o /usr/local/bin/argocd \
      https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
    chmod +x /usr/local/bin/argocd
    
    # CLI로 ArgoCD 서버에 로그인
    argocd login localhost:8080 --username admin --password <위에서-확인한-비밀번호> --insecure

    ArgoCD 웹 UI 대시보드 — 애플리케이션 동기화 상태와 헬스 체크 결과를 한눈에 확인

    첫 번째 Application 등록 — 실전 GitOps 시작

    Git 저장소 구조 준비

    ArgoCD를 쓸 때 저장소 구조를 어떻게 잡느냐가 은근히 중요하더라고요. 저는 앱 코드와 쿠버네티스 매니페스트를 분리하는 방식을 선호합니다.

    my-gitops-repo/
    ├── apps/
    │   ├── dev/
    │   │   ├── deployment.yaml
    │   │   ├── service.yaml
    │   │   └── kustomization.yaml
    │   └── prod/
    │       ├── deployment.yaml
    │       ├── service.yaml
    │       └── kustomization.yaml
    └── README.md

    예시로 사용할 간단한 Deployment와 Service 매니페스트입니다.

    # apps/dev/deployment.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: sample-app
      namespace: default
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: sample-app
      template:
        metadata:
          labels:
            app: sample-app
        spec:
          containers:
          - name: sample-app
            image: nginx:1.25
            ports:
            - containerPort: 80
            resources:
              requests:
                cpu: 100m
                memory: 128Mi
              limits:
                cpu: 200m
                memory: 256Mi
    # apps/dev/service.yaml
    apiVersion: v1
    kind: Service
    metadata:
      name: sample-app-svc
      namespace: default
    spec:
      selector:
        app: sample-app
      ports:
      - protocol: TCP
        port: 80
        targetPort: 80
      type: ClusterIP

    ArgoCD Application 생성

    이제 핵심입니다. ArgoCD에게 “이 Git 저장소의 이 경로를 이 클러스터에 배포해줘”라고 알려주는 Application 리소스를 만들어야 해요. YAML로 선언적으로 만드는 걸 추천합니다 — 이것 자체도 Git으로 관리하면 더 좋고요.

    # argocd-application.yaml
    apiVersion: argoproj.io/v1alpha1
    kind: Application
    metadata:
      name: sample-app-dev
      namespace: argocd
    spec:
      project: default
      source:
        repoURL: https://github.com/your-username/my-gitops-repo.git
        targetRevision: HEAD
        path: apps/dev
      destination:
        server: https://kubernetes.default.svc
        namespace: default
      syncPolicy:
        automated:
          prune: true        # Git에서 삭제된 리소스 자동 제거
          selfHeal: true     # 드리프트 감지 시 자동 복구
        syncOptions:
        - CreateNamespace=true
    # Application 생성
    kubectl apply -f argocd-application.yaml
    
    # 동기화 상태 확인
    argocd app get sample-app-dev
    
    # 수동 동기화 (처음 한 번)
    argocd app sync sample-app-dev

    여기서 selfHeal: true 옵션이 제가 아까 말씀드린 드리프트 자동 복구 기능이에요. 누군가 실수로 kubectl로 직접 replica 수를 바꿔도, ArgoCD가 Git에 선언된 값으로 되돌려줍니다. 처음에 이게 동작하는 걸 보고 “오오…” 했던 기억이 나네요.

    Private 저장소 연결

    실무에서는 당연히 Private 저장소를 쓰죠. SSH 키나 Personal Access Token으로 연결할 수 있어요.

    # HTTPS + Personal Access Token 방식
    argocd repo add https://github.com/your-username/my-gitops-repo.git \
      --username your-username \
      --password your-personal-access-token
    
    # SSH 키 방식
    argocd repo add [email protected]:your-username/my-gitops-repo.git \
      --ssh-private-key-path ~/.ssh/id_rsa

    CI 파이프라인과 연동 — 이미지 태그 자동 업데이트

    ArgoCD는 CD(Continuous Delivery) 도구입니다. CI(Continuous Integration)는 별도 도구를 써야 해요. 저는 GitHub Actions를 주로 쓰는데, 흐름은 이렇습니다.

    1. 개발자가 앱 코드를 main 브랜치에 push
    2. GitHub Actions가 Docker 이미지를 빌드하고 레지스트리에 push
    3. GitHub Actions가 GitOps 저장소의 이미지 태그를 새 버전으로 업데이트
    4. ArgoCD가 GitOps 저장소 변경을 감지하고 자동으로 클러스터에 배포
    # .github/workflows/deploy.yaml
    name: Build and Update GitOps Repo
    
    on:
      push:
        branches: [main]
    
    jobs:
      build-and-push:
        runs-on: ubuntu-latest
        steps:
        - name: Checkout app code
          uses: actions/checkout@v3
    
        - name: Set up Docker Buildx
          uses: docker/setup-buildx-action@v2
    
        - name: Login to Container Registry
          uses: docker/login-action@v2
          with:
            registry: ghcr.io
            username: ${{ github.actor }}
            password: ${{ secrets.GITHUB_TOKEN }}
    
        - name: Build and push
          uses: docker/build-push-action@v4
          with:
            push: true
            tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
    
        - name: Update GitOps repo image tag
          run: |
            git clone https://x-access-token:${{ secrets.GITOPS_TOKEN }}@github.com/your-username/my-gitops-repo.git
            cd my-gitops-repo
            # sed로 이미지 태그 업데이트
            sed -i "s|image: ghcr.io/your-username/sample-app:.*|image: ghcr.io/your-username/sample-app:${{ github.sha }}|"\
              apps/dev/deployment.yaml
            git config user.email "[email protected]"
            git config user.name "CI Bot"
            git add apps/dev/deployment.yaml
            git commit -m "chore: update image tag to ${{ github.sha }}"
            git push

    근데 여기서 주의할 점이 있어요. 앱 코드 저장소와 GitOps(매니페스트) 저장소를 분리하는 게 좋습니다. 같은 저장소에 두면 앱 코드 변경과 인프라 변경 이력이 섞여서 나중에 관리가 복잡해지더라고요. 처음에 같이 뒀다가 나중에 분리하는 삽질을 했었는데… 처음부터 분리하세요 ㅎㅎ.

    CI/CD 전체 파이프라인 흐름 — GitHub Actions가 이미지를 빌드하고 GitOps 저장소를 업데이트하면 ArgoCD가 자동 배포

    ⚠️ 삽질 모음 — 이것만 알면 시간 아낍니다

    1. OutOfSync 상태가 계속 유지되는 문제

    분명히 Git이랑 같은 내용인데 ArgoCD에서 계속 OutOfSync라고 뜨는 경우가 있어요. 대부분 리소스 정규화(normalization) 문제입니다. 쿠버네티스가 자동으로 추가하는 필드들(creationTimestamp, status 등)이 Git에 없는 거예요.

    # Application에 ignoreDifferences 추가로 해결
    spec:
      ignoreDifferences:
      - group: apps
        kind: Deployment
        jsonPointers:
        - /spec/replicas  # HPA가 관리하는 경우 replica 수 무시
      - group: ""
        kind: Service
        jsonPointers:
        - /spec/clusterIP

    2. Helm 차트 사용 시 values 파일 관리

    Helm을 ArgoCD와 함께 쓸 때 values 파일을 Git에 두면 됩니다.

    spec:
      source:
        repoURL: https://github.com/your-username/my-gitops-repo.git
        path: charts/my-app
        helm:
          valueFiles:
          - values-dev.yaml
          - values-secrets.yaml  # Sealed Secrets 등으로 암호화된 파일

    3. 시크릿(Secret) 관리 — 절대 Git에 평문으로 넣지 마세요

    이건 정말 중요해요. DB 비밀번호 같은 민감 정보를 실수로 Git에 넣는 사고가 생각보다 많이 일어납니다. 저는 Sealed Secrets나 External Secrets Operator를 씁니다.

    • Sealed Secrets: 공개키로 암호화된 SealedSecret 리소스를 Git에 저장, 클러스터 내 컨트롤러가 복호화
    • External Secrets Operator: AWS Secrets Manager, HashiCorp Vault 등 외부 시크릿 저장소와 연동

    4. ArgoCD 자체도 GitOps로 관리하기 — App of Apps 패턴

    ArgoCD Application 리소스가 많아지면 관리가 힘들어져요. 이럴 때 App of Apps 패턴을 씁니다. 루트 Application 하나가 다른 Application들을 관리하는 계층 구조예요.

    # root-application.yaml — 다른 Application들을 관리하는 루트
    apiVersion: argoproj.io/v1alpha1
    kind: Application
    metadata:
      name: root-app
      namespace: argocd
    spec:
      project: default
      source:
        repoURL: https://github.com/your-username/my-gitops-repo.git
        targetRevision: HEAD
        path: argocd-apps  # 이 폴더 안에 다른 Application YAML들이 있음
      destination:
        server: https://kubernetes.default.svc
        namespace: argocd
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

    ✅ 배포 결과 확인 및 검증

    모든 설정이 끝났으면 이렇게 확인하시면 됩니다.

    # ArgoCD CLI로 앱 상태 확인
    argocd app list
    
    # 상세 상태 확인
    argocd app get sample-app-dev
    
    # 동기화 이력 확인
    argocd app history sample-app-dev
    
    # kubectl로 직접 확인
    kubectl get pods -n default
    kubectl get svc -n default

    ArgoCD UI에서 애플리케이션 상태가 Synced / Healthy로 표시되면 성공입니다. 🎉

    이제 Git 저장소에서 deployment.yaml의 이미지 태그만 바꿔서 커밋하면, 몇 분 안에 (기본 polling 주기는 3분) 클러스터에 자동으로 반영되는 걸 볼 수 있어요. 처음에 이게 자동으로 되는 걸 보고 “드디어 됐다!” 하고 혼자 좋아했던 기억이 납니다 ㅎㅎ.

    # 롤백도 이렇게 간단합니다
    argocd app rollback sample-app-dev 
    
    # 또는 Git에서 revert 후 push하면 ArgoCD가 자동으로 처리

    ArgoCD 애플리케이션 상세 화면 — Synced/Healthy 상태와 쿠버네티스 리소스 트리 시각화

    자주 묻는 질문 (FAQ)

    Q. ArgoCD는 무료인가요?

    네, ArgoCD는 오픈소스(Apache 2.0 라이선스)로 완전 무료입니다. CNCF(Cloud Native Computing Foundation) 졸업 프로젝트이기도 하고요.

    Q. Flux와 ArgoCD 중 어떤 걸 써야 하나요?

    둘 다 GitOps 도구이지만, ArgoCD는 UI가 풍부하고 직관적이라 팀에서 처음 GitOps를 도입할 때 진입 장벽이 낮습니다. Flux는 더 경량이고 CLI 친화적이에요. 저는 팀 협업 환경에서는 ArgoCD를, 단독 운영이나 자동화 중심이면 Flux를 추천합니다.

    Q. 여러 클러스터를 관리할 수 있나요?

    가능합니다. ArgoCD 하나로 여러 쿠버네티스 클러스터를 등록하고 관리할 수 있어요. argocd cluster add 명령어로 추가하면 됩니다.

    마무리 — GitOps, 한 번 맛보면 못 돌아갑니다

    ArgoCD와 GitOps를 도입하고 나서 제 일상이 꽤 달라졌어요. 배포가 무서운 이벤트에서 그냥 평범한 Git 커밋 하나로 바뀌었달까요. 팀원들도 “내가 뭘 배포했는지” Git 로그만 보면 바로 알 수 있으니 커뮤니케이션 비용도 줄었고요.

    물론 처음 셋업할 때 시크릿 관리나 멀티 클러스터 권한 설정 같은 부분에서 삽질이 좀 있긴 합니다. 근데 그 초기 투자를 하고 나면 이후에는 정말 편해요.

    오늘 다룬 내용을 정리하면 이렇습니다.

    • ✅ GitOps 개념과 기존 CI/CD 방식의 차이 이해
    • ✅ ArgoCD 설치 및 초기 설정
    • ✅ Application 리소스로 Git 저장소와 클러스터 연결
    • ✅ GitHub Actions와 연동한 완전 자동화 파이프라인 구축
    • ✅ 자주 겪는 문제와 해결법

    다음 글에서는 ArgoCD ApplicationSet을 활용해서 여러 환경(dev/staging/prod)을 템플릿 하나로 관리하는 방법을 다룰 예정입니다. App of Apps 패턴도 더 깊이 파볼 거고요. 이 글이 도움이 됐다면 댓글로 알려주세요! 궁금한 점도 편하게 물어봐 주시고요. 😊

  • [k8s] ArgoCD 멀티 클러스터 배포 전략: GitOps로 K8s 여러 환경을 효과적으로 관리하기

    [k8s] ArgoCD 멀티 클러스터 배포 전략: GitOps로 K8s 여러 환경을 효과적으로 관리하기

    ArgoCD 멀티 클러스터 배포 전략: GitOps로 K8s 여러 환경을 효과적으로 관리하기

    안녕하세요, 13년차의 서버실 주인장입니다. 오늘은 인프라 엔지니어라면 한 번쯤은 고민해봤을 주제, 바로 ArgoCD 멀티 클러스터 배포 전략에 대해 이야기해보려고 합니다. 개발, 스테이징, 프로덕션은 기본이고, DR(재해 복구)이나 여러 리전(Region)에 걸쳐 수많은 쿠버네티스(Kubernetes) 클러스터를 운영하다 보면, “이걸 어떻게 하면 효율적으로 관리할 수 있을까?”라는 질문에 부딪히게 되죠. 저도 예전에 수많은 클러스터들을 수동으로 관리하면서 밤샘 삽질 꽤나 했거든요. 수동 배포는 휴먼 에러의 온상이었고, 클러스터 간 설정 불일치는 늘 제 발목을 잡았습니다. 그러다 GitOps(깃옵스)라는 개념과 ArgoCD(아르고CD)를 만나면서 비로소 광명을 찾았다고 할까요? 오늘은 제가 홈랩과 실제 운영 환경에서 겪었던 경험을 바탕으로, ArgoCD를 이용해 여러 쿠버네티스 환경을 GitOps 방식으로 효과적으로 관리하는 노하우를 공유해드리겠습니다.

    그림 1: ArgoCD 멀티 클러스터 배포의 전체 아키텍처 개요

    GitOps와 ArgoCD, 그리고 멀티 클러스터 관리의 핵심

    먼저 핵심 개념부터 짚고 넘어갈까요? GitOps(깃옵스)는 쉽게 말해, Git(깃)을 인프라 및 애플리케이션 배포의 단일 진실 공급원(Single Source of Truth)으로 사용하는 운영 방식입니다. 모든 클러스터 설정, 애플리케이션 매니페스트 등을 Git 리포지토리에 저장하고, 변경 사항은 Git을 통해서만 적용하는 거죠. 이렇게 하면 누가 언제 무엇을 변경했는지 Git 기록으로 명확하게 남고, 필요하면 언제든 이전 상태로 롤백(Rollback)할 수 있습니다.

    그리고 이 GitOps를 쿠버네티스 환경에서 가장 강력하게 구현해주는 도구가 바로 ArgoCD(아르고CD)입니다. ArgoCD는 선언형 GitOps CD 도구로, Git 리포지토리에 정의된 상태와 실제 쿠버네티스 클러스터의 상태를 지속적으로 비교하고, 불일치하면 자동으로 동기화해줍니다. 마치 클러스터의 ‘자율 주행’ 시스템 같다고 할까요? 제가 직접 써보니까, 배포 파이프라인의 복잡성을 확 줄여주면서도 안정성은 훨씬 높아지더라고요.

    ArgoCD 멀티 클러스터 관리는 이를 더 확장해, 하나의 중앙 ArgoCD 인스턴스가 여러 개의 원격 쿠버네티스 클러스터(Remote Kubernetes Clusters)에 애플리케이션을 배포하고 관리하는 것을 의미합니다. 중앙 ArgoCD 서버에 원격 클러스터들을 등록하면, ArgoCD는 각 클러스터에 접근하여 Git에 정의된 애플리케이션들을 배포하고 동기화 상태를 유지합니다. 복잡한 Jenkins 파이프라인이나 스크립트 없이도, Git만 잘 관리하면 여러 클러스터를 일관된 상태로 유지할 수 있게 되는 거죠. 이거 진짜 편하더라고요!

    실전 구현: ArgoCD로 여러 쿠버네티스 환경 관리하기

    자, 그럼 이제 실제 어떻게 구성하는지 단계별로 알아볼까요? 제가 홈랩에서 여러 클러스터를 구성하면서 가장 효과적이었던 방법을 공유합니다.

    1. 중앙 ArgoCD 인스턴스 설치 (Central Cluster)

    가장 먼저, 모든 것을 관장할 중앙 쿠버네티스 클러스터에 ArgoCD를 설치해야 합니다. 저는 주로 `argocd` 네임스페이스에 설치하는데, 설치 방법은 공식 문서가 워낙 잘 되어 있으니 참고해주세요. Helm(헬름)이나 Kustomize(커스터마이즈)를 사용하면 쉽게 설치할 수 있습니다.

    kubectl create namespace argocd
    kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argocd/stable/manifests/install.yaml
    
    # ArgoCD CLI 설치 (macOS 예시)
    brew install argocd
    

    2. 원격 클러스터 등록하기

    이제 ArgoCD가 관리할 원격 쿠버네티스 클러스터들을 등록해야 합니다. ArgoCD는 `kubectl` 컨텍스트를 활용하여 클러스터를 추가할 수 있습니다. 각 클러스터에 접속할 수 있는 권한이 있는 상태에서 다음 명령어를 실행하면 됩니다.

    # 현재 kubectl 컨텍스트 목록 확인
    kubectl config get-contexts
    
    # 원격 클러스터 컨텍스트로 전환 (예: my-remote-cluster)
    kubectl config use-context my-remote-cluster
    
    # ArgoCD에 클러스터 등록
    argocd cluster add my-remote-cluster --name <클러스터_이름> # --name 옵션으로 ArgoCD UI에 표시될 이름 지정
    

    이 명령어를 실행하면 ArgoCD는 해당 클러스터에 argocd-manager 서비스 어카운트(Service Account)와 필요한 RBAC(Role-Based Access Control) 권한을 자동으로 생성합니다. 처음엔 권한 문제로 좀 헤맸는데, 이 서비스 어카운트 방식이 제일 깔끔하더라고요. 여러 클러스터를 등록했다면, ArgoCD UI에서 다음과 같이 등록된 클러스터 목록을 확인할 수 있습니다.

    그림 2: ArgoCD UI에 등록된 멀티 쿠버네티스 클러스터 목록

    3. Git 리포지토리 구성 전략

    GitOps의 핵심인 Git 리포지토리를 어떻게 구성하느냐가 중요합니다. 저는 주로 모노레포(Monorepo) 방식을 선호합니다. 모든 클러스터의 설정과 애플리케이션 매니페스트를 하나의 리포지토리에 모아두면 관리하기가 훨씬 수월하더라고요. 추천하는 디렉토리 구조는 다음과 같습니다.

    . 
    ├── clusters/
    │   ├── dev/
    │   │   └── cluster-config.yaml
    │   ├── stage/
    │   │   └── cluster-config.yaml
    │   └── prod/
    │       └── cluster-config.yaml
    └── applications/
        ├── my-app/
        │   ├── base/
        │   │   ├── deployment.yaml
        │   │   └── service.yaml
        │   └── overlays/
        │       ├── dev/
        │       │   └── kustomization.yaml
        │       │   └── values.yaml
        │       ├── stage/
        │       │   └── kustomization.yaml
        │       │   └── values.yaml
        │       └── prod/
        │           └── kustomization.yaml
        │           └── values.yaml
        └── another-app/
            └── ...
    

    clusters/ 디렉토리에는 각 클러스터별로 필요한 기본 설정(예: 네임스페이스 생성, RBAC 설정 등)을 담고, applications/ 디렉토리에는 배포할 애플리케이션의 매니페스트를 저장합니다. 특히 Kustomize(커스터마이즈)를 활용하여 base와 overlays 구조를 만들면, 클러스터별로 다른 설정을 유연하게 적용할 수 있습니다. 예를 들어, my-app/base에 공통적인 배포 스펙을 정의하고, my-app/overlays/prod에서 프로덕션 환경에 필요한 리소스 제한(Resource Limit)이나 레플리카(Replica) 수를 오버라이드(Override)하는 식이죠.

    4. ApplicationSet 활용: 동적인 애플리케이션 배포

    여러 클러스터에 동일한 애플리케이션을 배포해야 할 때, ArgoCD의 ApplicationSet(애플리케이션셋)은 정말 빛을 발합니다. ApplicationSet은 여러 ArgoCD Application(애플리케이션)을 동적으로 생성해주는 컨트롤러(Controller)입니다. 저는 주로 Git Generator(깃 제너레이터)를 사용하는데, 특정 Git 경로에 있는 디렉토리 목록을 읽어서 각 디렉토리마다 Application을 생성하도록 합니다.

    예를 들어, applications/my-app/overlays/ 디렉토리 아래에 dev, stage, prod 디렉토리가 있다면, ApplicationSet이 이 세 디렉토리를 각각의 클러스터에 배포할 Application으로 인식하게 만들 수 있습니다.

    apiVersion: argoproj.io/v1alpha1
    kind: ApplicationSet
    metadata:
      name: all-my-apps
    spec:
      generators:
      - git:
          repoURL: https://github.com/my-org/my-gitops-repo.git # 본인의 Git 리포지토리 URL
          revision: HEAD
          directories:
          - path: applications/*/overlays/* # 이 경로 아래의 모든 디렉토리를 찾아서 Application 생성
      template:
        metadata:
          name: '{{ path[2] }}-{{ path[4] }}' # 예: my-app-dev
          labels:
            app.kubernetes.io/part-of: '{{ path[2] }}'
        spec:
          project: default
          source:
            repoURL: https://github.com/my-org/my-gitops-repo.git
            targetRevision: HEAD
            path: '{{ path }}'
          destination:
            server: https://kubernetes.default.svc # ArgoCD에 등록된 클러스터의 API 서버 URL
            namespace: '{{ path[2] }}' # 예: my-app
          syncPolicy:
            automated:
              prune: true
              selfHeal: true
            syncOptions:
              - CreateNamespace=true
    

    위 예시에서 {{ path[2] }}와 {{ path[4] }}는 Git 경로를 기준으로 동적으로 값을 가져오는 변수입니다. 이렇게 ApplicationSet을 사용하면, 새로운 클러스터나 애플리케이션 환경이 추가될 때마다 Application 매니페스트를 일일이 만들 필요 없이, Git에 디렉토리만 추가하면 ArgoCD가 알아서 감지하고 배포해줍니다. 이 부분에서 정말 많은 시간을 절약할 수 있더라고요!

    ArgoCD 멀티 클러스터 배포 중 주의할 점들: ⚠️ 제가 겪었던 삽질 모음

    아무리 좋은 도구라도 삽질은 피할 수 없는 법이죠. 제가 ArgoCD 멀티 클러스터를 구성하면서 겪었던 주요 문제점들과 해결책을 공유합니다. 혹시 이런 경험 있으신가요?

    1. 권한 문제 (RBAC Hell): argocd cluster add 명령어가 클러스터에 argocd-manager 서비스 어카운트를 생성하지만, 때로는 특정 리소스에 대한 권한이 부족할 때가 있습니다. 특히 CRD(Custom Resource Definition)를 배포하거나 특정 오퍼레이터(Operator)를 사용할 때 권한 에러가 발생하곤 합니다. 💡 해결책: 에러 메시지를 꼼꼼히 확인하고, 필요한 권한(Role, ClusterRole)을 추가로 부여하거나, 가장 간단하게는 cluster-admin 권한을 일시적으로 부여하여 문제가 해결되는지 확인해볼 수 있습니다. 하지만 운영 환경에서는 최소 권한 원칙(Principle of Least Privilege)을 지키는 것이 중요합니다. 저도 처음엔 클러스터 등록이 자꾸 실패해서 몇 시간을 날렸는지 몰라요.

    2. 네트워크 문제: 중앙 ArgoCD 인스턴스가 원격 클러스터의 API 서버에 접근하지 못하는 경우가 있습니다. 방화벽(Firewall), 보안 그룹(Security Group), VPC(Virtual Private Cloud) 설정 등이 원인일 수 있습니다. 💡 해결책: ArgoCD 서버가 실행되는 Pod에서 원격 클러스터의 API 서버 IP 주소와 포트로 telnet이나 curl을 시도하여 연결성을 확인해보세요. 저도 한번은 사설망 연결 문제로 고생 좀 했습니다. ㅎㅎ

    3. Helm Values 오버라이드 복잡성: ApplicationSet과 Helm(헬름) 차트(Chart)를 함께 사용할 때, 클러스터별로 다른 values.yaml 파일을 관리하는 것이 복잡해질 수 있습니다. 💡 해결책: Kustomize의 patches 기능을 활용하여 Helm Chart의 특정 값을 오버라이드하거나, ApplicationSet의 parameters 기능을 이용해 클러스터별로 다른 값을 주입하는 방식을 사용해보세요. 이 과정에서 Git 리포지토리 구조를 잘 설계하는 것이 핵심입니다.

    4. Git Sync 지연 및 캐시 문제: Git 리포지토리에 변경 사항을 푸시(Push)했는데, ArgoCD가 즉시 감지하지 못하거나 오래된 캐시 데이터를 사용하는 경우가 있습니다. 💡 해결책: ArgoCD UI에서 수동으로 Sync(동기화)를 시도하거나, Git Webhook(웹훅)을 설정하여 Git 변경 이벤트 발생 시 ArgoCD가 즉시 알림을 받고 동기화를 시작하도록 구성하는 것이 좋습니다. 그래도 안 되면 ArgoCD 서버 Pod를 재시작해보는 것도 한 방법이더라고요.

    검증 및 결과: 🎉 이제 편안하게 관리해볼까요?

    모든 설정이 완료되고 나면, ArgoCD UI는 마치 잘 정돈된 지휘소처럼 느껴질 겁니다. 등록된 모든 클러스터와 그 위에 배포된 애플리케이션들의 상태를 한눈에 볼 수 있죠. Git에 코드 푸시하고 잠시 후 ArgoCD 대시보드를 보면, 모든 클러스터에 배포가 쫙~ 완료되어 있는 걸 볼 수 있습니다. 이 쾌감이란!

    새로운 클러스터에 애플리케이션을 배포해야 할 때도, ApplicationSet을 통해 정의된 Git 리포지토리 구조에 맞게 단순히 새로운 오버레이(Overlay) 디렉토리와 Kustomization 파일을 추가하고 Git에 커밋(Commit)하기만 하면 됩니다. ArgoCD가 이를 감지하고 자동으로 새로운 Application을 생성하고 배포해줍니다. 인프라 변경 관리의 일관성과 자동화 수준이 비약적으로 향상되는 순간이죠.

    그림 3: ArgoCD UI에서 확인하는 멀티 클러스터 애플리케이션 동기화 상태

    ArgoCD 멀티 클러스터 배포의 장점과 한계

    제가 13년 동안 다양한 인프라 환경을 경험하면서 느낀 ArgoCD 멀티 클러스터 배포의 장점과 한계를 정리해봤습니다.

    장점 ✅ 한계 ⚠️
    일관성 유지: 모든 클러스터가 Git에 정의된 동일한 상태를 따르므로, 환경 간 불일치를 최소화합니다. 초기 설정 복잡성: Git 리포지토리 구조, ApplicationSet 설정 등 초기 구성에 학습 곡선이 존재합니다.
    배포 자동화: Git 변경 사항이 자동으로 감지되어 배포되므로, 수동 작업으로 인한 오류를 줄입니다. GitOps 모델 이해 필요: 개발/운영 팀 모두 GitOps 워크플로우에 대한 이해와 적응이 필요합니다.
    빠른 복구 (Disaster Recovery): Git에 모든 설정이 있으므로, 장애 발생 시 새로운 클러스터에 빠르게 복구할 수 있습니다. 중앙 ArgoCD 인스턴스 의존성: 중앙 ArgoCD 서버에 장애가 발생하면 모든 클러스터 배포에 영향을 미칠 수 있습니다 (HA 구성으로 보완 가능).
    버전 관리 및 감사: 모든 변경 이력이 Git에 남아 누가 언제 무엇을 변경했는지 추적하기 용이합니다. 시크릿(Secret) 관리: Git에 민감 정보를 직접 저장하기 어려우므로, Vault(볼트) 등 별도의 시크릿 관리 솔루션과 연동해야 합니다.

    마무리: 💡 ArgoCD 멀티 클러스터 배포, 지금 시작해볼까?

    오늘은 ArgoCD를 활용한 멀티 쿠버네티스 클러스터 배포 전략에 대해 제가 직접 경험하고 삽질하며 얻은 노하우를 공유해드렸습니다. GitOps는 단순히 배포 도구를 넘어, 인프라 운영 패러다임을 혁신하는 강력한 방법론이라고 생각합니다. 13년차 엔지니어로서, 이 정도 자동화는 이제 선택이 아니라 필수라고 생각합니다. 처음엔 좀 어렵고 헷갈릴 수 있지만, 한번 구축하고 나면 정말 편안하고 안정적인 인프라를 운영할 수 있을 거예요.

    여러분도 이 글을 통해 ArgoCD 멀티 클러스터 환경 구축에 자신감을 얻으셨기를 바랍니다. 다음 글에서는 ArgoCD의 고가용성(High Availability, HA) 구성이나 외부 시크릿 관리 도구(예: HashiCorp Vault)와의 연동 등 좀 더 심화된 주제를 다뤄볼까 합니다. 궁금한 점이나 공유하고 싶은 삽질 경험이 있다면 언제든지 댓글로 남겨주세요!

    그림 4: ArgoCD 멀티 클러스터 배포의 핵심 요약 및 다음 단계

  • [k8s] Flux CD GitOps 파이프라인 구축: 안정적인 쿠버네티스 배포 자동화

    [k8s] Flux CD GitOps 파이프라인 구축: 안정적인 쿠버네티스 배포 자동화

    안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 많은 인프라 엔지니어분들이 한 번쯤은 고민해봤을 주제, 바로 쿠버네티스(Kubernetes) 배포 자동화에 대해 이야기해보려고 합니다. 특히 GitOps(깃옵스) 방법론과 그 구현체 중 하나인 Flux CD(플럭스 CD)를 활용한 파이프라인 구축 경험을 공유해 드릴게요.

    혹시 이런 경험 있으신가요? 개발팀에서 “배포해주세요!” 요청이 들어오면, kubectl apply -f 명령어를 조심스럽게 입력하면서, “혹시나 다른 설정이 덮어씌워지는 건 아닐까?”, “이전 버전으로 되돌리려면 어떻게 해야 하지?” 같은 걱정을 했던 순간 말이죠. 저는 셀 수 없이 많습니다. 수동 배포는 휴먼 에러의 온상이었고, 배포하다 새벽을 맞이하는 일도 비일비재했거든요. 이런 삽질을 거듭하다가 GitOps를 만나고 나서야 비로소 안정적인 배포의 빛을 보게 되었습니다. 제 홈랩에서도 여러 서비스를 GitOps로 관리하고 있는데, 정말 편하더라고요!

    GitOps 파이프라인은 Git 저장소를 ‘진리의 단일 출처(Single Source of Truth)’로 삼아, 쿠버네티스 클러스터의 상태를 Git에 선언된 대로 유지하는 방식입니다. 간단히 말해, Git에 저장된 설정 파일이 곧 클러스터의 현재 상태여야 한다는 거죠.

    GitOps와 Flux CD, 정말 좋은 이유

    처음 GitOps라는 개념을 들었을 때는 “어차피 Git에 YAML 파일 올리는 건 똑같은데, 뭐가 다르지?” 싶었어요. 근데 실제로 써보니 이 방식이 가진 장점이 정말 많더라고요. 제가 느낀 가장 큰 장점들을 꼽아보면 이렇습니다.

    • 일관성(Consistency): 모든 설정이 Git에 있으니, 개발, 스테이징, 운영 환경 간의 차이를 최소화할 수 있어요. “제 환경에서는 잘 되는데요?” 하는 말이 확 줄어듭니다.
    • 감사 및 추적(Auditability & Traceability): Git 커밋(Commit) 기록 자체가 변경 이력이 되니까요. 누가, 언제, 무엇을 변경했는지 명확하게 알 수 있죠. 문제 발생 시 롤백(Rollback)도 Git으로 너무나 쉽습니다.
    • 안정성(Reliability): Git에 선언된 상태와 클러스터의 실제 상태가 다르면, GitOps 에이전트가 자동으로 클러스터를 Git의 상태로 되돌립니다. 마치 자가 치유(Self-healing) 능력 같달까요?
    • 생산성(Productivity): 수동 작업이 줄어들고 자동화되면서, 엔지니어는 더 중요한 일에 집중할 수 있게 됩니다.

    이런 GitOps의 철학을 구현하는 대표적인 도구가 바로 Flux CD입니다. Flux CD는 쿠버네티스 클러스터 내에서 동작하는 컨트롤러(Controller)들의 집합인데요, 주기적으로 Git 저장소를 감시하다가 변경 사항이 감지되면 자동으로 클러스터에 적용해주는 역할을 합니다. 주요 컴포넌트로는 Source Controller(소스 컨트롤러), Kustomize Controller(커스터마이즈 컨트롤러), Helm Controller(헬름 컨트롤러) 등이 있습니다.

    Flux CD GitOps 파이프라인 구축 실전 가이드

    자, 그럼 이제 제 홈랩에서 Flux CD를 어떻게 구축했는지, 단계별로 자세히 알려드릴게요. 저도 처음엔 공식 문서를 보면서 여러 번 헤맸는데, 이 가이드가 여러분의 삽질 시간을 줄여주길 바랍니다!

    1단계: 사전 준비 및 Flux CLI 설치

    먼저, 쿠버네티스 클러스터에 접근 가능한 환경과 kubectl, git이 설치되어 있어야 합니다. 저는 로컬 PC에 flux CLI(Command Line Interface)를 설치하는 것부터 시작했어요.

    # Flux CLI 설치 (macOS 기준)
    brew install fluxcd/flux/flux
    
    # 설치 확인
    flux --version
    # flux version 2.x.x (최신 버전으로 설치됩니다)
    
    # 클러스터에 Flux CD가 설치될 네임스페이스 생성 (선택 사항)
    kubectl create namespace flux-system
    

    flux-system 네임스페이스는 Flux CD 컨트롤러들이 배포될 기본 공간입니다. 따로 지정하지 않으면 기본으로 이 네임스페이스에 설치되죠.

    2단계: Git 저장소 준비

    Flux CD는 Git 저장소를 바라보며 작동하기 때문에, 쿠버네티스 설정 파일(YAML)들을 저장할 Git 저장소가 필요합니다. 저는 GitHub에 gitops-k8s-homelab이라는 프라이빗(Private) 저장소를 만들었어요. 저장소 안에는 다음과 같은 구조로 파일을 구성할 예정입니다.

    gitops-k8s-homelab/
    ├── clusters/
    │   └── my-cluster/
    │       ├── flux-system/
    │       │   └── gotk-components.yaml
    │       │   └── gotk-sync.yaml
    │       └── apps/
    │           └── my-app/
    │               └── kustomization.yaml
    ├── apps/
    │   └── my-app/
    │       ├── deployment.yaml
    │       ├── service.yaml
    │       └── ingress.yaml
    └── README.md
    

    clusters/my-cluster/flux-system 경로에는 Flux CD 자체의 설정 파일들이, clusters/my-cluster/apps 경로에는 클러스터에 배포할 애플리케이션들을 정의하는 Kustomization 파일들이 들어갈 겁니다. 실제 애플리케이션 YAML 파일들은 apps/my-app 경로에 두고요.

    3단계: Flux CD 부트스트랩 (Bootstrap)

    이제 가장 중요한 단계입니다. flux bootstrap github 명령어를 사용해서 Flux CD를 쿠버네티스 클러스터에 설치하고, Git 저장소와 연결하는 작업을 수행합니다. 이 명령 한 방으로 Flux CD가 클러스터에 필요한 모든 컴포넌트를 배포하고, 지정된 Git 저장소를 바라보도록 설정해줍니다. 저는 GitHub를 사용했으니 github 옵션을 사용했어요.

    # 환경 변수 설정 (개인 GitHub 토큰과 사용자명으로 대체하세요!)
    export GITHUB_TOKEN="YOUR_GITHUB_TOKEN" # Personal Access Token
    export GITHUB_USER="YOUR_GITHUB_USERNAME"
    
    # Flux CD 부트스트랩 실행
    flux bootstrap github \
      --owner=${GITHUB_USER} \
      --repository=gitops-k8s-homelab \
      --branch=main \
      --path=clusters/my-cluster \
      --personal
    

    이 명령을 실행하면 Flux CD가 클러스터에 설치되고, clusters/my-cluster 경로를 기준으로 Git 저장소의 내용을 동기화하기 시작합니다. --personal 옵션은 개인 저장소에 주로 사용하고, 조직(Organization) 저장소의 경우 --owner를 조직명으로 지정하고 SSH 키 방식으로 인증하는 것이 일반적입니다. 저는 홈랩이라 개인 토큰으로 편하게 작업했어요.

    부트스트랩이 완료되면, Git 저장소의 clusters/my-cluster/flux-system 경로에 Flux CD 자체의 Kustomization 파일들이 자동으로 생성되어 커밋되는 것을 볼 수 있습니다. 이게 바로 Flux CD가 스스로를 GitOps 방식으로 관리하는 모습이죠. 신기하더라고요!

    4단계: 애플리케이션 배포를 위한 Kustomization 정의

    이제 클러스터에 배포할 애플리케이션을 정의하고 Flux CD가 이를 인식하도록 설정할 차례입니다. 먼저, apps/my-app 경로에 간단한 NGINX 애플리케이션을 정의하는 YAML 파일들을 만듭니다.

    # apps/my-app/deployment.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: my-nginx-app
      labels:
        app: my-nginx-app
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: my-nginx-app
      template:
        metadata:
          labels:
            app: my-nginx-app
        spec:
          containers:
          - name: nginx
            image: nginx:latest
            ports:
            - containerPort: 80
    ---
    # apps/my-app/service.yaml
    apiVersion: v1
    kind: Service
    metadata:
      name: my-nginx-app-service
    spec:
      selector:
        app: my-nginx-app
      ports:
      - protocol: TCP
        port: 80
        targetPort: 80
      type: ClusterIP
    

    그리고 이 애플리케이션을 클러스터에 배포하도록 지시하는 Kustomization 파일을 clusters/my-cluster/apps/my-app/kustomization.yaml 경로에 생성합니다.

    # clusters/my-cluster/apps/my-app/kustomization.yaml
    apiVersion: kustomize.toolkit.fluxcd.io/v1
    kind: Kustomization
    metadata:
      name: my-nginx-app
      namespace: flux-system
    spec:
      interval: 1m0s
      sourceRef:
        kind: GitRepository
        name: flux-system
      path: ./apps/my-app
      prune: true
      validation: client
    

    이 파일들을 Git 저장소에 커밋(Commit)하고 푸시(Push)합니다.

    git add .
    git commit -m "Add my-nginx-app and kustomization"
    git push origin main
    

    Flux CD는 clusters/my-cluster/flux-system/gotk-sync.yaml 파일에 정의된 Kustomization에 의해 clusters/my-cluster 경로를 1분마다 동기화합니다. 그러면 방금 추가한 clusters/my-cluster/apps/my-app/kustomization.yaml 파일이 클러스터에 적용되고, 이 Kustomization이 다시 apps/my-app 경로의 NGINX 애플리케이션을 클러스터에 배포하게 됩니다. 이 모든 과정이 자동으로 이뤄지는 거죠!

    ⚠️ 삽질 경험 & 트러블슈팅 팁

    제가 Flux CD를 사용하면서 겪었던 몇 가지 삽질과 해결 팁을 공유해 드릴게요. 여러분은 저처럼 헤매지 마시라고요! ㅎㅎ

    • 동기화 지연 문제: Git에 변경사항을 푸시했는데, 클러스터에 바로 적용이 안 되는 경우가 있습니다. Kustomization 리소스의 interval 값이 기본 10분으로 설정되어 있거나, 네트워크 문제 등으로 Git 저장소에 접근이 안 되는 경우가 많았어요. 급할 때는 다음 명령어로 강제 동기화를 시도합니다.
      flux reconcile kustomization my-nginx-app --with-source
      

      이 명령은 해당 Kustomization과 그 소스 GitRepository를 즉시 동기화하도록 Flux CD에 지시합니다.

    • Git Repository 구조 설계: 처음에는 모든 YAML 파일을 한 폴더에 때려 넣었는데, 나중에 애플리케이션이 많아지고 환경이 복잡해지면서 관리가 힘들어지더라고요. clusters/[클러스터이름]/[환경]/apps/[앱이름] 같은 계층적인 구조나, clusters와 apps를 분리하는 구조로 가져가는 것이 훨씬 효율적입니다. 저는 지금 clusters와 apps를 분리해서 관리하고 있어요.
    • 시크릿(Secret) 관리: 데이터베이스 비밀번호 같은 민감한 정보는 Git에 평문으로 올릴 수 없죠. 저는 SOPS(Secrets OPerationS)를 사용해서 Git 저장소에 암호화된 시크릿을 저장하고, Flux CD가 배포 시 자동으로 복호화하도록 설정했습니다. EKS(Elastic Kubernetes Service) 같은 클라우드 환경에서는 KMS(Key Management Service)를 연동해서 SOPS를 사용하는 것이 일반적입니다.
    • CRD(Custom Resource Definition) 적용 순서: 때로는 특정 컨트롤러나 미들웨어의 CRD가 먼저 클러스터에 적용되어야만 해당 리소스를 배포할 수 있습니다. 예를 들어, Istio(이스티오)나 Cert-Manager(서트 매니저) 같은 도구들이 그렇죠. 이런 경우, Kustomization의 dependsOn 필드를 사용하거나, healthChecks를 설정하여 의존성을 명확히 해주는 것이 중요합니다.

    ✅ 배포 결과 확인 및 검증

    이제 모든 설정이 잘 적용되었는지 확인해볼 시간입니다. flux get kustomizations 명령어로 Flux CD가 관리하는 Kustomization 리소스들의 상태를 확인할 수 있습니다.

    flux get kustomizations
    NAME            REVISION        SUSPENDED   READY   MESSAGE                                         LAST ACTIVITY
    flux-system     main/a1b2c3d4   False       True    Kustomization reconciled successfully           2026-05-15T10:00:00Z
    my-nginx-app    main/e5f6g7h8   False       True    Kustomization reconciled successfully           2026-05-15T10:01:00Z
    

    READY 상태가 True이고 MESSAGE에 성공 메시지가 보인다면, Flux CD가 정상적으로 작동하고 있다는 뜻입니다. 이제 쿠버네티스 클러스터에 NGINX 애플리케이션이 잘 배포되었는지 확인해볼까요?

    kubectl get deployment my-nginx-app
    NAME           READY   UP-TO-DATE   AVAILABLE   AGE
    my-nginx-app   2/2     2            2           5m
    
    kubectl get service my-nginx-app-service
    NAME                     TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
    my-nginx-app-service     ClusterIP   10.96.100.123   <none>        80/TCP    5m
    

    🎉 드디어 성공입니다! my-nginx-app 배포가 정상적으로 2개의 레플리카(Replica)로 동작하고 있는 것을 확인할 수 있네요. 이제 Git 저장소의 apps/my-app/deployment.yaml 파일에서 replicas 수를 3으로 변경하고 푸시해보세요. 잠시 후 Flux CD가 이를 감지하고 자동으로 클러스터의 레플리카 수를 3으로 업데이트할 겁니다. 이 경험을 하고 나면 GitOps의 매력에서 헤어 나올 수 없을 거예요!

    GitOps는 이렇게 Git에 대한 변경만으로 클러스터의 상태를 관리할 수 있게 해줍니다. 저는 이 편리함 덕분에 홈랩에서 새로운 서비스를 배포할 때마다 kubectl 명령어를 직접 입력할 일이 거의 없어졌어요. 모든 변경사항은 Git에 기록되니, 누가 어떤 변경을 했는지도 명확하게 알 수 있고요. 정말 안정적이고 편리한 배포 파이프라인이 구축된 거죠.

    마무리하며: GitOps와 Flux CD, 현대 인프라의 필수 도구

    오늘은 13년차 인프라 엔지니어의 경험을 바탕으로 Flux CD GitOps 파이프라인 구축에 대해 상세히 이야기해봤습니다. 쿠버네티스 배포 자동화는 현대 인프라에서 선택이 아닌 필수가 되어가고 있습니다. 특히 GitOps는 그 중심에서 안정성, 일관성, 생산성이라는 세 마리 토끼를 동시에 잡을 수 있게 해주는 강력한 방법론이라고 생각합니다.

    물론 처음에는 GitOps 개념이나 Flux CD 사용법이 낯설고 어렵게 느껴질 수 있습니다. 저도 그랬거든요. 하지만 한 번 제대로 구축하고 나면, 인프라 관리의 패러다임이 확 바뀌는 것을 경험하실 수 있을 겁니다. 마치 수동으로 서버를 한 대 한 대 설치하다가 프로비저닝(Provisioning) 자동화를 접했을 때의 충격과 비슷하다고 할까요?

    다음 글에서는 오늘 다루지 못한 Helm Chart(헬름 차트)를 Flux CD로 관리하는 방법이나, 멀티 클러스터(Multi-cluster) 환경에서의 GitOps 전략, 그리고 SOPS를 이용한 시크릿 관리 등 좀 더 심화된 주제들을 다뤄볼 예정입니다. 이 글이 여러분의 쿠버네티스 여정에 작은 도움이 되었기를 바랍니다!

    궁금한 점이나 저의 삽질 경험에 대한 질문이 있으시면 언제든지 댓글 남겨주세요! 저도 계속 배우고 성장하는 중이거든요. 😊

  • [k8s] ArgoCD 프로덕션 환경 GitOps 베스트 프랙티스: 안정적인 배포와 보안 강화

    [k8s] ArgoCD 프로덕션 환경 GitOps 베스트 프랙티스: 안정적인 배포와 보안 강화

    ArgoCD 프로덕션 환경 GitOps 베스트 프랙티스: 안정적인 배포와 보안 강화

    안녕하세요, 13년차 인프라 엔지니어입니다. 오늘은 쿠버네티스(Kubernetes) 배포의 핵심 툴 중 하나인 ArgoCD와 GitOps에 대해 이야기해보려고 해요. 사실 제가 처음 인프라 엔지니어를 시작했을 때는 배포라고 하면 SSH로 서버에 접속해서 스크립트 돌리고, 수동으로 설정을 변경하고, 문제가 터지면 눈으로 찾아 헤매는 게 일상이었거든요. 그러다 쿠버네티스 세상이 열리고 CI/CD 파이프라인이 중요해지면서, 더 안정적이고 효율적인 배포 방식에 대한 갈증이 커졌습니다.

    수많은 삽질 끝에 제가 정착한 방법이 바로 GitOps였습니다. 그리고 그 중심에는 ArgoCD가 있었죠. 처음엔 이게 뭔가 싶었는데, 막상 써보니까 ‘아, 이거 진짜 편하고 안전하네!’ 싶더라고요. 프로덕션 환경에서 ArgoCD를 안정적으로 운영하고 GitOps 보안을 강화하기 위한 저만의 경험과 베스트 프랙티스를 공유해볼까 합니다. 혹시 쿠버네티스 배포 때문에 밤잠 설치고 계신 분들이 있다면, 이 글이 조금이나마 도움이 되었으면 좋겠네요. 💡

    ArgoCD와 GitOps의 전체 아키텍처는 위 그림처럼 구성됩니다. Git을 중심으로 모든 것이 돌아가는 모습을 보실 수 있어요.

    왜 ArgoCD와 GitOps인가요? – 삽질 끝에 찾은 안정성

    저도 처음에는 Jenkins 같은 전통적인 CI/CD 툴로 쿠버네티스 배포를 시도했어요. 하지만 배포 스크립트 관리도 어렵고, 배포 이력 추적도 쉽지 않더라고요. 특히 긴급 롤백(Rollback) 상황에서는 정말 아찔한 경험도 많았습니다. 😱

    GitOps는 쉽게 말해, Git을 인프라의 ‘단 하나의 진실된 소스(Single Source of Truth)’로 삼는 운영 방식입니다. 모든 인프라와 애플리케이션의 상태를 Git 리포지토리(Repository)에 코드(Code)로 저장하고, Git에 변경사항이 푸시(Push)되면 자동으로 인프라에 반영하는 방식이죠. ArgoCD는 이 GitOps 철학을 쿠버네티스 환경에서 구현해주는 강력한 선언적(Declarative) GitOps 지속적 배포(Continuous Delivery) 툴입니다.

    ArgoCD는 쿠버네티스 클러스터(Cluster) 내부에서 동작하면서, Git 리포지토리의 상태와 실제 클러스터의 상태를 계속 비교합니다. 만약 두 상태가 다르면, Git 리포지토리의 상태(원하는 상태)로 클러스터의 상태를 동기화(Sync)하려고 시도하죠. 이걸 풀 기반(Pull-based) 배포라고 하는데, 기존의 푸시 기반(Push-based) CI/CD 방식보다 훨씬 안정적이고 보안에도 유리합니다. 직접 써보니, 이 방식이 정말 믿음직하더라고요. ✅

    ArgoCD와 GitOps, 쉽게 이해하기

    복잡하게 생각할 것 없이, GitOps는 우리가 늘 쓰던 Git으로 인프라도 관리하자는 이야기입니다. 애플리케이션 코드를 Git으로 관리하듯이, 쿠버네티스 매니페스트(Manifest) 파일들도 Git에 넣고 관리하는 거죠. 이렇게 하면 다음과 같은 장점들이 생깁니다.

    • 버전 관리(Version Control): 모든 변경 이력이 Git에 남으니, 누가 언제 무엇을 바꿨는지 명확하게 알 수 있습니다.
    • 롤백(Rollback) 용이: 문제가 생기면 Git 커밋(Commit)을 되돌리는 것만으로 이전 상태로 쉽게 돌아갈 수 있습니다.
    • 감사(Auditing) 및 보안 강화: 모든 변경이 Git을 통해 이루어지므로, 승인된 변경만 반영될 수 있도록 워크플로우(Workflow)를 구축하기 좋습니다.
    • 단일 진실 공급원(Single Source of Truth): 개발, 운영팀 모두 Git만 보면 현재 인프라 상태를 파악할 수 있습니다.

    ArgoCD는 이 GitOps를 쿠버네티스에서 실현시켜주는 컨트롤러(Controller)입니다. 주요 특징은 다음과 같아요.

    • 선언적(Declarative) 관리: 원하는 상태를 YAML 파일로 선언해두면, ArgoCD가 알아서 그 상태를 유지합니다.
    • 자동 동기화(Automatic Synchronization): Git 리포지토리의 변경을 감지하고 자동으로 클러스터에 반영할 수 있습니다.
    • 시각적인 UI: 웹 UI를 통해 애플리케이션의 배포 상태, 리소스(Resource) 현황, 동기화 이력 등을 한눈에 확인할 수 있습니다. 저처럼 눈으로 확인해야 직성이 풀리는 사람에겐 정말 최고더라고요.
    • 다양한 배포 전략 지원: 롤링 업데이트(Rolling Update), 카나리 배포(Canary Deployment), 블루/그린 배포(Blue/Green Deployment) 등 다양한 배포 전략을 연동하여 구현할 수 있습니다.

    프로덕션 환경을 위한 ArgoCD 설정 팁

    이제 본격적으로 프로덕션 환경에서 ArgoCD를 효과적으로 사용하는 베스트 프랙티스를 공유해볼게요. 제가 직접 겪으면서 터득한 노하우들이니, 꼭 참고하시면 좋겠습니다.

    1. Git Repository 구조화: Monorepo vs. Multirepo

    Git 리포지토리를 어떻게 구성할지는 GitOps 전략의 첫 단추입니다. 크게 모노레포(Monorepo)와 멀티레포(Multirepo) 두 가지 방식이 있어요.

    • 모노레포(Monorepo): 모든 애플리케이션과 인프라 설정 파일을 하나의 Git 리포지토리에 저장하는 방식입니다. 초기 설정이 간단하고, 모든 것을 한곳에서 관리할 수 있다는 장점이 있습니다.
    • 멀티레포(Multirepo): 각 애플리케이션이나 환경별로 별도의 Git 리포지토리를 사용하는 방식입니다. 팀별 권한 분리나 대규모 서비스 운영에 유리할 수 있습니다.

    저 같은 경우, 초기에는 모노레포로 시작했다가 규모가 커지면서 멀티레포 형태로 전환했어요. 하지만 ArgoCD를 통해 여러 애플리케이션을 관리할 때는 애플리케이션별 Git 리포지토리 + 인프라 설정용 Git 리포지토리를 분리하는 방식이 가장 효율적이라고 느꼈습니다. 프로덕션 환경에서는 GitOps 보안과 관리의 용이성을 위해 인프라 설정과 애플리케이션 코드를 분리하는 것을 추천합니다.

    예시: 인프라 설정 Git 리포지토리 구조

    ├── applications # ArgoCD Application 정의
    │   ├── app1.yaml
    │   ├── app2.yaml
    │   └── ...
    ├── environments
    │   ├── dev
    │   │   ├── kustomization.yaml
    │   │   ├── namespace.yaml
    │   │   └── ...
    │   ├── stage
    │   │   ├── kustomization.yaml
    │   │   └── ...
    │   └── prod
    │       ├── kustomization.yaml
    │       └── ...
    └── base # 공통 설정
        ├── deployment.yaml
        ├── service.yaml
        └── ...
    

    위 다이어그램은 제가 주로 사용하는 Git Repository 구조를 시각적으로 보여줍니다. 환경별로 설정을 분리하고, 공통 설정은 base에 두는 방식이에요.

    2. 환경별 분리 및 Kustomize/Helm 활용

    개발(dev), 스테이징(stage), 프로덕션(prod) 환경은 각각 다른 설정(리소스 요구 사항, 환경 변수 등)을 가집니다. 이를 효과적으로 관리하려면 Kustomize나 Helm을 적극적으로 활용해야 합니다.

    • Kustomize: 기존 YAML 파일을 수정하지 않고 덮어쓰기(Overlay) 방식으로 환경별 설정을 관리하는 데 매우 유용합니다. base 디렉터리에 공통 설정 파일을 두고, 각 환경별 overlays 디렉터리에서 필요한 부분만 변경하는 방식은 정말 깔끔하죠.
    • Helm: 재사용 가능한 쿠버네티스 애플리케이션 패키징(Packaging) 도구입니다. 데이터베이스(Database)나 메시지 큐(Message Queue)처럼 공통적으로 사용되는 미들웨어(Middleware)를 배포할 때 매우 편리합니다. 저도 처음엔 Helm이 좀 어렵게 느껴졌는데, 익숙해지니 없으면 안 되는 존재가 되더라고요.

    ArgoCD 애플리케이션 정의에서 Kustomize나 Helm을 소스(Source)로 지정하면, ArgoCD가 알아서 해당 툴을 사용해서 매니페스트를 렌더링(Rendering)하고 배포해줍니다. 🚀

    apiVersion: argoproj.io/v1alpha1
    kind: Application
    metadata:
      name: my-app-prod
      namespace: argocd
    spec:
      project: default
      source:
        repoURL: https://github.com/my-org/my-infra-gitops.git
        targetRevision: HEAD
        path: environments/prod/my-app # Kustomize overlay 경로
      destination:
        server: https://kubernetes.default.svc
        namespace: my-app-prod
      syncPolicy:
        automated:
          prune: true
          selfHeal: true
        syncOptions:
          - CreateNamespace=true
    

    3. Sync Options와 Health Checks

    ArgoCD의 syncPolicy는 배포의 안정성을 결정하는 중요한 부분입니다. 프로덕션 환경에서는 다음 옵션들을 신중하게 설정해야 합니다.

    • automated.prune: true: Git 리포지토리에서 삭제된 리소스를 클러스터에서도 자동으로 삭제합니다. 클러스터의 불필요한 리소스 잔여물을 방지해줍니다.
    • automated.selfHeal: true: 클러스터의 상태가 Git 리포지토리의 상태와 다를 경우, ArgoCD가 자동으로 Git의 상태로 되돌립니다. 누군가 수동으로 클러스터 설정을 변경했을 때 원래대로 복구해주는 강력한 기능이죠. GitOps의 핵심 정신과 일치하는 부분입니다.
    • syncOptions: - CreateNamespace=true: 해당 네임스페이스(Namespace)가 없으면 ArgoCD가 자동으로 생성하도록 합니다.
    • 커스텀 헬스 체크(Custom Health Checks): 애플리케이션이 단순히 배포되었다고 끝이 아닙니다. 실제로 정상 작동하는지 확인하는 헬스 체크가 중요하죠. ArgoCD는 기본적으로 Pod의 Readiness/Liveness Probe를 활용하지만, 경우에 따라 ConfigMap에 커스텀 헬스 체크를 정의하여 더 정교한 상태 감지를 할 수 있습니다.

    4. Rollback 전략

    아무리 잘 준비해도 문제는 발생하기 마련이죠. 이때 빠르고 안전하게 롤백하는 것이 중요합니다. ArgoCD 환경에서의 롤백은 크게 두 가지 방식이 있어요.

    1. Git Revert: 가장 권장되는 방식입니다. 문제가 발생한 커밋을 Git에서 되돌리면(Revert) ArgoCD가 이를 감지하고 자동으로 이전 상태로 클러스터를 동기화합니다. 이 방식은 Git의 변경 이력이 그대로 남으므로 감사 추적에도 유리합니다.
    2. ArgoCD UI 롤백: ArgoCD 웹 UI에서 특정 애플리케이션의 History and Rollback 탭을 통해 이전 동기화 지점(Sync Point)으로 롤백할 수 있습니다. 긴급 상황에서 빠르게 대처할 수 있는 방법이지만, Git의 변경 이력에는 남지 않으므로 나중에 Git Revert로 맞춰주는 게 좋습니다.

    저도 예전에 새벽에 긴급 롤백을 해야 했던 적이 있었는데, Git Revert 하나로 모든 상황이 깔끔하게 정리되었을 때의 안도감이란… 정말 겪어봐야 알 수 있습니다. 👍

    GitOps 보안 강화: ArgoCD 프로덕션 환경 보안 설정

    프로덕션 환경에서는 GitOps 보안이 최우선 고려사항입니다. ArgoCD를 통해 모든 것이 배포되므로, ArgoCD 자체의 보안 설정은 물론 주변 환경과의 연동도 중요합니다.

    1. RBAC (Role-Based Access Control)

    ArgoCD는 자체적인 RBAC(Role-Based Access Control)를 지원합니다. 이를 통해 누가 어떤 애플리케이션을 조회, 동기화, 삭제할 수 있는지 세밀하게 권한을 제어할 수 있어요. argocd-cm ConfigMap이나 argocd-rbac-cm ConfigMap을 수정하여 정책을 정의합니다.

    또한, ArgoCD 프로젝트(Project)를 활용하여 애플리케이션들을 논리적으로 묶고, 프로젝트별로 RBAC 정책을 적용하면 관리 효율성과 보안을 동시에 잡을 수 있습니다. 예를 들어, 개발팀은 dev-project에만 접근 가능하고, 운영팀은 prod-project에만 접근 가능하도록 설정하는 식이죠.

    # argocd-rbac-cm ConfigMap 예시
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: argocd-rbac-cm
      namespace: argocd
    data:
      policy.csv: |
        p, role:admin, applications, *, */*, allow
        p, role:dev, applications, get, dev-project/*, allow
        g, myuser, role:dev
      policy.default: role:readonly
    

    2. Secret Management (외부 Secret 연동)

    민감한 정보인 시크릿(Secret)을 Git 리포지토리에 평문으로 저장하는 것은 절대 금물입니다. 🙅‍♂️ GitOps 보안을 위해 외부 시크릿 관리 솔루션과 연동하는 것이 필수입니다.

    • Sealed Secrets: 클러스터에 배포된 컨트롤러가 시크릿을 암호화하고, Git에 암호화된 시크릿을 저장합니다. 암호화된 시크릿은 해당 클러스터에서만 복호화(Decrypt)될 수 있어 안전합니다. 제가 홈랩에서도 가장 즐겨 쓰는 방식이에요.
    • External Secrets Operator: AWS Secrets Manager, Azure Key Vault, Google Secret Manager, HashiCorp Vault 등 클라우드(Cloud) 기반 시크릿 관리 서비스와 연동하여 시크릿을 쿠버네티스 시크릿으로 동기화합니다. 프로덕션 환경에서는 이 방식이 가장 일반적입니다.

    어떤 방법을 선택하든, 절대 시크릿을 Git에 직접 올리는 일은 없어야 합니다! 이건 제가 정말 피땀 흘려 배운 교훈입니다. ⚠️

    3. Private Repository 접근

    대부분의 프로덕션 환경에서는 프라이빗 Git 리포지토리(Private Git Repository)를 사용합니다. ArgoCD가 이 리포지토리에 접근하려면 인증 정보가 필요하겠죠. 다음 방법들을 사용할 수 있습니다.

    • SSH 키(SSH Key): 가장 일반적이고 강력한 방법입니다. ArgoCD에 SSH 키를 등록하고, 해당 키를 사용하여 리포지토리에 접근합니다.
    • HTTPS with Username/Password 또는 Personal Access Token (PAT): Git 서비스에서 발급받은 PAT를 ArgoCD에 등록하여 사용할 수 있습니다. 보안상 일반적인 비밀번호보다는 PAT를 사용하는 게 좋습니다.

    인증 정보를 ArgoCD에 등록할 때는 쿠버네티스 시크릿으로 안전하게 관리해야 합니다. 당연한 이야기지만, 이걸 놓쳐서 문제가 되는 경우를 꽤 많이 봤거든요. 😅

    ArgoCD 트러블슈팅: 제가 겪었던 문제들 (그리고 해결책)

    13년차 엔지니어라고 해도 삽질은 피할 수 없는 운명이죠. ArgoCD를 쓰면서도 여러 번 머리를 쥐어뜯었습니다. 몇 가지 흔한 문제와 해결책을 공유해볼게요.

    • 문제: ImagePullBackOff 에러 (프라이빗 레지스트리)
      상황: 배포된 Pod에서 프라이빗 컨테이너 이미지 레지스트리(Private Container Image Registry)의 이미지를 당겨오지 못하고 ImagePullBackOff 에러가 발생하는 경우.
      해결: 해당 네임스페이스에 ImagePullSecrets를 제대로 설정했는지 확인해야 합니다. ArgoCD 애플리케이션이 배포될 때 이 시크릿이 같이 생성되도록 매니페스트에 포함하거나, 수동으로 시크릿을 생성하고 Pod Spec에 추가해야 합니다. 저는 주로 ArgoCD가 CreateNamespace=true와 함께 시크릿도 함께 배포하도록 설정합니다.

    • 문제: Resource is not available 또는 Failed to install CRD
      상황: 애플리케이션 배포 시 커스텀 리소스 정의(CRD: Custom Resource Definition)가 먼저 설치되어야 하는데, 순서가 맞지 않아 발생하는 에러.
      해결: ArgoCD의 Sync Waves 기능을 활용하면 배포 순서를 제어할 수 있습니다. CRD를 먼저 배포하고, 그 이후에 CRD를 사용하는 애플리케이션 리소스를 배포하도록 설정하는 거죠. 예를 들어, CRD는 sync-wave: "-1", 일반 리소스는 sync-wave: "0"으로 설정하면 됩니다. 이 기능을 알게 된 후로 정말 속이 시원했습니다. 🎉

    • 문제: 롤백 후에도 문제가 지속됨
      상황: Git Revert나 ArgoCD UI 롤백을 했는데도 애플리케이션이 정상 상태로 돌아오지 않는 경우.
      해결: 롤백 대상이 되는 커밋이 정말 이전의 ‘정상’ 상태를 가리키는지 확인해야 합니다. 때로는 환경 변수나 외부 의존성(예: 데이터베이스 스키마 변경) 때문에 롤백만으로는 해결되지 않을 수 있거든요. 이럴 때는 문제 발생 시점을 정확히 파악하고, 관련된 모든 변경사항(Git, DB 스키마, 외부 서비스 설정 등)을 함께 되돌려야 합니다. 그리고 롤백 후 ArgoCD UI에서 애플리케이션의 Health 상태와 Events 탭을 꼼꼼히 확인하는 습관을 들이는 게 좋습니다.

    결과 및 검증: 안정적인 배포, 이제 Git만 바라봅니다.

    ArgoCD와 GitOps 베스트 프랙티스를 적용하고 나니, 정말 배포 과정이 안정적이고 예측 가능해졌습니다. 더 이상 불안에 떨며 배포 버튼을 누를 필요가 없어졌죠. ✅

    배포가 완료되면 ArgoCD 웹 UI에서 각 애플리케이션의 상태를 한눈에 확인할 수 있습니다. 모든 리소스가 Healthy 상태이고, Synced 상태인지 확인하는 것이 중요해요. 혹시 OutOfSync 상태라면, 어떤 리소스가 Git과 다른지 명확하게 보여주므로 문제 파악이 매우 쉽습니다. 이 시각적인 피드백(Feedback) 덕분에 트러블슈팅 시간도 대폭 줄었습니다.

    ArgoCD UI에서 모든 애플리케이션이 건강하고(Healthy) 동기화(Synced)된 상태를 보여주는 화면입니다. 이 화면을 볼 때마다 뿌듯하더라고요!

    실제로 저는 홈랩에서 여러 서비스를 ArgoCD로 관리하고 있는데, Git에 커밋만 하면 알아서 배포가 되고, 문제가 생겨도 Git Revert 한 번으로 해결되는 경험은 정말 혁신적이었습니다. CI/CD 파이프라인의 완성도를 높이는 데 ArgoCD가 결정적인 역할을 했다고 생각합니다.

    ArgoCD GitOps를 프로덕션 환경에 적용하기 위한 핵심 베스트 프랙티스를 요약한 인포그래픽입니다.

    마무리: GitOps 여정, 계속됩니다

    오늘은 ArgoCD 프로덕션 환경 GitOps 베스트 프랙티스에 대해 저의 경험을 바탕으로 이야기해봤습니다. 안정적인 배포와 GitOps 보안 강화를 위해 Git 리포지토리 구조화, 환경별 설정 관리, Sync Policy, 롤백 전략, RBAC, 시크릿 관리 등 다양한 측면을 다루었네요.

    처음에는 복잡하게 느껴질 수도 있지만, 한 번 제대로 구축해두면 개발팀과 운영팀 모두에게 엄청난 효율성과 안정성을 가져다줄 겁니다. 저도 아직 배워야 할 것이 많고, 계속해서 새로운 기술을 실험하고 있습니다. 이 글이 여러분의 쿠버네티스 배포 여정에 작은 등불이 되기를 바랍니다. 궁금한 점이나 공유하고 싶은 삽질 경험이 있다면 언제든지 댓글로 남겨주세요! 다음에는 ArgoCD와 함께 CI/CD 파이프라인을 더욱 자동화하는 방법에 대해 다뤄보겠습니다. 그때까지 모두 즐거운 서버실 라이프 즐기시길 바랍니다! 😊