티스토리 뷰

반응형

쿠버네티스 실습: 멀티클러스터 GitOps 및 DR 리전 복제 구축하기

앞선 글에서는 GitOps + Velero + Prometheus를 결합해
장애 발생 시 자동 복구·알림·상태 동기화가 가능한 셀프힐링(자동 복원) 클러스터를 완성했습니다.
이번 글에서는 한 단계 더 나아가, 멀티클러스터(Multi-Cluster) 구조를 구성하고
서로 다른 리전에 위치한 클러스터 간 GitOps + DR 복제를 구현합니다.


1) 왜 멀티클러스터인가?

단일 쿠버네티스 클러스터는 강력하지만,
아래와 같은 리스크를 피할 수 없습니다.

  • 노드 장애 → 서비스 전체 중단
  • 리전(Region) 장애 → 복원 불가
  • 데이터 센터 이슈 → SLA 위반

이 때문에 하나의 시스템을 여러 리전에 복제해 운영하는 Active-Standby 혹은 Active-Active 멀티클러스터 구조가 필요합니다.


2) 목표 구조

Region A (Primary Cluster)
│   ├── Argo CD (GitOps)
│   ├── Velero (백업)
│   ├── Prometheus (모니터링)
│   └── Fuelstation 서비스 운영
│
└──> S3/MinIO 백업 → Region B 로 복제

Region B (Secondary Cluster)
│   ├── Argo CD Agent (Git Sync)
│   ├── Velero Restore
│   └── Standby 서비스 구동 (자동 활성화)

핵심은 Git 상태의 일관성 + S3 백업 복제 + 자동 전환(Failover) 입니다.


3) 클러스터 환경 구성

3-1. 클러스터 생성 (예시: Kind or Minikube 2개)

kind create cluster --name cluster-a
kind create cluster --name cluster-b

3-2. kubeconfig 병합

kubectl config view --flatten > ~/.kube/config
kubectl config get-contexts

→ 두 클러스터(cluster-a, cluster-b)를 한 CLI에서 제어 가능.


4) Argo CD 멀티클러스터 등록

4-1. Primary 클러스터에 로그인

kubectl config use-context cluster-a

4-2. Secondary 클러스터 등록

argocd cluster add cluster-b

→ Argo CD가 cluster-b로 접근할 수 있는 kubeconfig를 자동 등록합니다.


5) GitOps 동기화 설정

fuelstation-dr-app.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: fuelstation-dr
  namespace: argocd
spec:
  project: default
  source:
    repoURL: 'https://github.com//fuelstation-gitops.git'
    targetRevision: main
    path: overlays/prod
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: team-a
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
  info:
  - name: DR Cluster
    value: cluster-b

argocd app create 명령으로 cluster-b 환경에도 동일한 앱을 생성합니다.

argocd app create fuelstation-dr \
  --repo https://github.com//fuelstation-gitops.git \
  --path overlays/prod \
  --dest-server https:// \
  --dest-namespace team-a

이제 Git 저장소 변경 → 두 클러스터 모두 자동 Sync 됩니다.


6) Velero 백업 복제

6-1. S3 버킷 복제 (Cross-Region)

AWS 예시:

aws s3 sync s3://velero-backup-region-a s3://velero-backup-region-b --delete

MinIO 예시:

mc mirror minio/velero-a minio/velero-b --overwrite --remove

6-2. Region-B 클러스터 복구 자동화

velero restore create dr-restore --from-backup full-backup-latest

→ Region-B에서 자동으로 동일한 리소스와 PVC가 재생성됩니다.


7) 자동 Failover 구성

7-1. Prometheus Alert 설정

Primary Region 응답 없음 시 Slack/Webhook 전송:

- alert: PrimaryClusterDown
  expr: up{cluster="region-a"} == 0
  for: 2m
  annotations:
    summary: "Primary Cluster unreachable"
    description: "Region A 클러스터 응답 없음 — DR 전환 시작"

7-2. Webhook → Cluster-B DR 전환 스크립트

kubectl --context cluster-b scale deploy fuelstation-backend --replicas=3
kubectl --context cluster-b scale deploy fuelstation-frontend --replicas=3

→ 장애 발생 시 Secondary 클러스터 자동 활성화.


8) 상태 확인

  • Cluster-A 장애 시 → Prometheus 알림 발생
  • Slack 메시지 수신
  • Cluster-B의 Argo CD 앱이 자동으로 Sync
  • Velero Restore 수행
  • 서비스 정상화 (5~10분 내)

9) 운영 모범 사례

구성 요소 Region A Region B 설명

Argo CD Controller + UI Agent 중앙 Git 상태 관리
Velero 백업 복원 S3 데이터 복제
Prometheus 주 모니터링 DR 모니터링 알림 이중화
Grafana 통합 대시보드 읽기 전용 상태 시각화
Git Repo 단일 main branch 동일한 상태 복제 SSOT 유지

10) 정리

  • 멀티클러스터 환경에서는 GitOps + Velero + Prometheus의 조합이 재해복구 표준 아키텍처
  • Region-A 장애 발생 시 Region-B가 자동으로 서비스 승계
  • Git 저장소가 모든 상태의 단일 진실 소스(Single Source of Truth)
  • 운영자는 배포, 복원, DR 상태를 Git과 Slack 대시보드만으로 관리 가능

다음 글에서는 이 멀티클러스터 인프라 위에 서비스 수준의 트래픽 분산(글로벌 Ingress + External-DNS + Cloud LoadBalancer) 를 적용해
리전 간 실시간 트래픽 전환(Geo Failover) 을 실습합니다.


 

쿠버네티스,멀티클러스터,GitOps,DisasterRecovery,ArgoCD,Velero,Prometheus,DR리전복제,DevOps,K8s실습

 


✅ 보완/강화 제안

  1. Argo CD의 멀티클러스터 지원 구조 (hub-spoke, 각 클러스터에 설치 등) 설명 추가
    • Argo CD 하나가 여러 클러스터를 관리할 수 있다는 공식 문서 내용. (argo-cd.readthedocs.io)
    • ApplicationSet 기능을 통해 여러 클러스터/네임스페이스에 동일 애플리케이션을 배포할 수 있다는 설명도 유용합니다. (Codefresh)
  2. DR 설계 시 고려해야 할 실제 데이터 복제 및 스토리지 연계 전략 강조
    • 백업 버킷을 리전 A → 리전 B로 복제하는 방식, 스토리지 지연(Latency)나 비용 문제 등.
  3. 장애 전환(Failover) 및 복귀(Restore) 플로우에 대한 기술적 주의사항 추가
    • 예: DNS 변경, 외부 로드밸런서 연계, StatefulSet 데이터 동기화 문제, 리소스 버전-상태 불일치 등.
  4. 보안·권한·RBAC 측면
    • 멀티클러스터 환경에서는 각 클러스터에 대한 접속 권한(Argo CD → 각 클러스터) 및 권한 분리(팀별, 클러스터별) 고려해야 합니다.
    • 예: “클러스터 B는 standby 역할만 갖고 있어야 한다” 등의 정책.
  5. 최신 기술 동향 반영
    • Argo CD Agent 방식, 클러스터 에이전트 설치형 등 최근 지원 구조. (Red Hat Developer)
    • 대규모 멀티클러스터 환경에서 ApplicationSet 활용 사례. (Reddit)

📚 참고할 최신 자료

  • “How to automate multi-cluster deployments using Argo CD” (Red Hat) – 멀티클러스터 배포 패턴 설명. (Red Hat Developer)
  • “ApplicationSet – Multicluster Deployment Made Easy with Argo CD” (Codefresh) – 대규모 클러스터 배포를 위한 기능 설명. (Codefresh)
  • “Cluster Management – Argo CD Operator Manual” – 클러스터 등록, 관리 관련 공식 문서. (argo-cd.readthedocs.io)

 

※ 이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2026/04   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30
글 보관함
반응형