1장: Kubernetes 운영의 성숙도와 GitOps의 등장

Kubernetes가 컨테이너 오케스트레이션의 표준으로 자리 잡은 지 이미 여러 해가 지났습니다. 초기에는 "Kubernetes를 어떻게 설치하고 사용하는가"가 핵심 관심사였다면, 이제는 "Kubernetes를 어떻게 안정적으로 운영하고 관리하는가"로 초점이 이동했습니다. 이 장에서는 Kubernetes 운영의 성숙도 모델을 정리하고, GitOps가 왜 운영의 핵심 패러다임이 되었는지 살펴보겠습니다.

Kubernetes 운영의 진화

운영 성숙도 모델

Kubernetes 운영은 다음과 같은 단계를 거쳐 성숙해 왔습니다.

Level 0: 수동 관리
  kubectl apply 직접 실행, 명령형 배포

Level 1: 스크립트 자동화
  CI 파이프라인에서 kubectl/helm 실행
  배포는 자동이지만 상태 관리는 수동

Level 2: 선언적 GitOps
  Git이 단일 진실 원천 (Single Source of Truth)
  클러스터 상태와 Git 상태의 자동 동기화

Level 3: 자율 운영
  GitOps + 오퍼레이터 + 정책 엔진
  자동 스케일링, 자동 복구, 자동 정책 적용

많은 조직이 Level 1에서 Level 2로 전환하는 단계에 있으며, 선도 조직은 Level 3을 구현하고 있습니다.

명령형 vs 선언적 배포

명령형(Imperative) 접근:

# CI 파이프라인에서 직접 실행
kubectl set image deployment/api api=myapp:v2
helm upgrade api ./charts/api --set image.tag=v2

이 방식의 문제점:

• 누가 언제 무엇을 변경했는지 추적이 어렵습니다
• CI 파이프라인이 클러스터에 직접 접근할 수 있는 강력한 권한이 필요합니다
• 배포 실패 시 이전 상태로 되돌리기 어렵습니다
• 클러스터의 실제 상태와 의도한 상태가 달라질 수 있습니다 (드리프트)

선언적(Declarative) 접근 — GitOps:

# Git 저장소에 원하는 상태를 선언
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: api
          image: myapp:v2  # 이 값을 변경하고 PR → 머지

GitOps 도구(ArgoCD, Flux)가 Git 상태와 클러스터 상태를 지속적으로 비교하고 자동 동기화합니다.

GitOps란 무엇인가

핵심 원칙

GitOps는 Git을 단일 진실 원천으로 사용하여 인프라와 애플리케이션을 선언적으로 관리하는 운영 패러다임입니다. Weaveworks(현재 CNCF에 기부)가 2017년에 제안한 이후 Kubernetes 생태계의 표준적인 운영 방식으로 자리 잡았습니다.

GitOps의 네 가지 핵심 원칙:

1. 선언적 (Declarative): 시스템의 원하는 상태를 선언적으로 기술합니다. "어떻게(how)"가 아닌 "무엇(what)"을 정의합니다.

2. 버전 관리와 불변성 (Versioned and Immutable): 모든 상태가 Git에 저장되어 버전 관리됩니다. 변경 이력이 자동으로 보존됩니다.

3. 자동 풀링 (Pulled Automatically): 에이전트가 Git 저장소를 지속적으로 감시하여 변경을 자동으로 풀(pull)합니다. CI 시스템이 클러스터에 푸시(push)하는 것이 아닙니다.

4. 지속적 조정 (Continuously Reconciled): 에이전트가 클러스터의 실제 상태와 Git의 원하는 상태를 지속적으로 비교하고, 차이가 있으면 자동으로 조정합니다.

Push 모델 vs Pull 모델

Push 모델 (전통적 CI/CD):
[개발자] → [Git] → [CI 서버] → kubectl apply → [클러스터]
                      ↑
           클러스터 접근 권한 필요 (보안 위험)

Pull 모델 (GitOps):
[개발자] → [Git] ← (감시) ← [GitOps Agent] ↔ [클러스터]
                               ↑
                    클러스터 내부에서 실행 (보안 강화)

Pull 모델에서는 GitOps 에이전트가 클러스터 내부에서 실행되므로, CI 서버에 클러스터 접근 권한을 부여할 필요가 없습니다. 이는 보안 관점에서 큰 이점입니다.

GitOps의 실질적 이점

감사 추적: 모든 변경이 Git 커밋으로 기록됩니다. 누가, 언제, 무엇을, 왜 변경했는지 완벽하게 추적 가능합니다.

롤백 용이성: 이전 상태로 되돌리려면 Git revert만 하면 됩니다. GitOps 에이전트가 자동으로 클러스터를 이전 상태로 복원합니다.

드리프트 감지와 자동 복구: 누군가 kubectl로 직접 클러스터를 변경하면(드리프트), GitOps 에이전트가 이를 감지하고 Git 상태로 자동 복원합니다.

멀티 클러스터 일관성: 동일한 Git 저장소를 여러 클러스터에 연결하면 일관된 상태를 유지할 수 있습니다.

협업 워크플로우: 인프라 변경도 코드 변경과 동일한 PR 리뷰 프로세스를 거칩니다.

GitOps 도구 생태계

ArgoCD

현재 가장 널리 사용되는 GitOps 도구입니다. CNCF Graduated 프로젝트로, 웹 UI 기반의 직관적인 관리 인터페이스를 제공합니다. 멀티 클러스터 관리, ApplicationSet을 통한 대규모 배포, Argo Rollouts와 연동한 프로그레시브 딜리버리를 지원합니다.

Flux

CNCF Graduated 프로젝트로, CLI 중심의 GitOps 도구입니다. Git 외에도 Helm, OCI 레지스트리, S3 등 다양한 소스를 지원합니다. Kustomization을 통한 선언적 설정과 이미지 자동 업데이트가 강점입니다.

선택 기준

이 시리즈에서 다룰 내용

이 시리즈는 Kubernetes 고급 운영과 GitOps를 체계적으로 다룹니다.

• 2~3장: ArgoCD와 Flux 심층 분석
• 4장: 멀티클러스터 관리 전략
• 5장: 커스텀 컨트롤러와 오퍼레이터 개발
• 6장: Karpenter를 이용한 차세대 노드 오토스케일링
• 7장: 비용 최적화와 리소스 관리
• 8장: Crossplane으로 인프라를 코드로 관리하기
• 9장: 보안 강화와 정책 관리
• 10장: 실전 프로젝트 — GitOps 기반 Kubernetes 플랫폼 구축

다음 장에서는 가장 인기 있는 GitOps 도구인 ArgoCD를 심층적으로 살펴보겠습니다.