쿠버네티스 실습: GitOps + Velero + Prometheus로 재해복구(Disaster Recovery, DR) 시스템 구축하기

쿠버네티스 실습: GitOps + Velero + Prometheus로 재해복구(Disaster Recovery, DR) 시스템 구축하기

앞선 글에서는 Argo CD 기반 GitOps 자동배포를 통해 "코드 푸시 → 자동 배포 → 상태 동기화"의 완전 자동화 파이프라인을 구축했습니다.
이제 실무 운영 환경에서 필수적으로 요구되는 재해복구(Disaster Recovery, DR) 전략을 다룹니다.
이번 글에서는 GitOps(Argo CD) + Velero + Prometheus를 결합해,
장애 발생 시 자동 백업 → 복구 → 알림 트리거링까지 이어지는 셀프 힐링 클러스터를 완성합니다.

---

1) DR(Disaster Recovery)란 무엇인가?

• **DR(재해복구)**란 시스템 장애, 노드 손실, 스토리지 오류, 인적 실수 등으로 인해
  서비스가 중단되었을 때 자동으로 복원할 수 있는 체계를 말합니다.
• 클라우드 환경에서는 단순한 백업이 아니라, **운영 상태 전체(리소스 + 데이터 + 설정)**의 복원이 핵심입니다.

DR 체계의 3대 목표

항목 의미 목표

RPO (Recovery Point Objective)	데이터 복구 기준 시점	데이터 손실 최소화
RTO (Recovery Time Objective)	서비스 복구 소요 시간	복구 시간 단축
SLO/SLA (Service Level Objective)	서비스 가용성 목표	99.9% 이상 유지

---

2) 전체 DR 구조

Git (Argo CD)
│
├── 선언적 상태 관리 (desired state)
│
├── Prometheus (모니터링)
│   └── 이상 감지 시 Alertmanager 호출
│
├── Alertmanager (Slack 등 알림)
│   └── Velero 백업 트리거 실행
│
└── Velero (백업/복구)
    ├── 정기 스케줄 백업
    └── Alert 기반 복구 실행

결국, Prometheus가 장애 감지 → 알림 전송 → Velero 복구 실행까지 연결하는 것이 핵심입니다.

---

3) Prometheus Alert → Velero 복구 자동화

반응형

3-1. Prometheus Alert 설정

alert-rules-dr.yaml

groups:
- name: dr-alerts
  rules:
  - alert: NamespaceDown
    expr: kube_namespace_status_phase{phase="Active"} == 0
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "네임스페이스 장애 감지"
      description: "Namespace가 비정상적으로 삭제되거나 비활성 상태입니다."

적용:

kubectl apply -f alert-rules-dr.yaml -n monitoring

---

3-2. Alertmanager → Webhook → Velero

Alertmanager는 Slack뿐 아니라 Webhook 호출도 가능합니다.
Webhook 리시버가 Velero 복구 스크립트를 실행하도록 연결합니다.

alertmanager.yaml

route:
  receiver: 'slack-and-webhook'

receivers:
- name: 'slack-and-webhook'
  slack_configs:
  - api_url: 'https://hooks.slack.com/services/XXX'
    channel: '#dr-alerts'
  webhook_configs:
  - url: 'http://velero-trigger-service.monitoring.svc.cluster.local:9000/restore'

---

4) Velero 복구 트리거 서버 구축

velero-trigger.js (간단한 Node.js API 서버 예시)

import express from 'express';
import { exec } from 'child_process';

const app = express();
app.use(express.json());

app.post('/restore', (req, res) => {
  console.log('Disaster Detected! Triggering Velero restore...');
  exec('velero restore create --from-backup full-backup-latest', (err, stdout, stderr) => {
    if (err) {
      console.error(`Restore failed: ${stderr}`);
      res.status(500).send('Restore failed');
      return;
    }
    console.log(`Restore triggered: ${stdout}`);
    res.status(200).send('Restore triggered successfully');
  });
});

app.listen(9000, () => console.log('Velero Trigger Service running on port 9000'));

Dockerfile 예시:

FROM node:20-alpine
WORKDIR /app
COPY . .
RUN npm install express
CMD ["node", "velero-trigger.js"]

배포 후 Service 생성:

kubectl apply -f velero-trigger-deployment.yaml -n monitoring

---

5) GitOps로 DR 상태 유지

Argo CD가 클러스터 리소스의 선언적 상태를 지속적으로 감시합니다.
만약 사람이 잘못 kubectl delete namespace team-a를 실행하더라도,
Argo CD는 즉시 Git 상태와 불일치를 감지하고 자동으로 복구합니다.

syncPolicy:
  automated:
    selfHeal: true
    prune: true

→ 이 기능은 Velero의 데이터 복구와 결합되어 애플리케이션 + 데이터 동시 복원을 완성합니다.

---

6) DR 테스트 시나리오

(1) 시뮬레이션 — 네임스페이스 삭제

kubectl delete namespace team-a

Prometheus → Alert 발생
→ Alertmanager → Webhook 호출
→ Velero Trigger API → velero restore create 실행
→ 클러스터 자동 복구

(2) Slack 알림 예시

[K8S DR ALERT] NamespaceDown
team-a 네임스페이스가 비정상 상태로 감지되었습니다.
Velero 복구가 자동으로 트리거되었습니다.

---

7) 고급 DR 운영 전략

구성 요소 역할 주기/설정

Velero Backup	전체 리소스 + PVC 백업	매일 새벽 3시
Prometheus Rule	이상 상태 감지	1분 주기
Alertmanager	Slack + Webhook 알림	즉시
Argo CD Self-Heal	선언적 상태 복원	실시간
Grafana Dashboard	DR 상태 시각화	즉시 반영

---

8) 정리

• GitOps + Velero + Prometheus를 결합하면, **재해복구(Disaster Recovery)**가 완전히 자동화됩니다.
• Argo CD가 리소스 상태를, Velero가 데이터를, Prometheus가 이상을 감시하여 상호 보완적 구조 형성.
• 클러스터 장애 발생 시 자동 복구 → Slack 알림 → Git 상태 복원으로 이어지는 셀프 힐링 클러스터(Self-Healing Cluster) 완성.

다음 글에서는 이 셀프힐링 인프라를 확장하여
멀티클러스터 환경(GitOps + Federation + DR 리전 복제) 구성까지 확장하는 실습을 진행하겠습니다.

---

 

쿠버네티스,GitOps,Velero,Prometheus,DisasterRecovery,ArgoCD,자동복구,DevOps,DR시스템,K8s실습

 

 

 

✅ 잘된 점

• Velero를 활용한 백업/복구 + Argo CD 기반 GitOps + Prometheus 알림을 하나의 재해복구(DR) 플로우로 엮은 흐름이 명확합니다.
• DR 개념(RPO, RTO)과 전체 흐름(백업→알람→복구)이 잘 설명되어 있습니다.
• 관련 툴들이 어떻게 상호작용하는지 (GitOps → 백업 → 알림 → 복구) 구조적으로 제시되어 좋습니다.

---

⚠️ 보완/수정할 사항

아래 항목들을 검토해서 글에 반영하시면 더욱 완성도가 올라갈 것입니다.

1. Velero 리스토어 동작 시점 설명 보완
   • Velero 백업/복구 동작 워크플로우에 대해 공식 문서에도 잘 나와 있는데, 예컨대 “백업 생성 → 복구 시 백업 스토리지 위치를 읽기 전용 모드로 전환 → 리스토어 실행 → 스토리지 모드 복구” 등의 단계가 있습니다. (velero.io)
   • 글 중에서는 단순히 velero restore create --from-backup로 끝나는 흐름이므로, “스토리지 읽기 전용 전환” 또는 “기존 리소스 정책(existing-resource-policy) 고려” 등 복구 시 유의사항을 한두 문장 더 넣으면 좋겠습니다. (예: “기존 리소스가 남아 있는 경우 덮어쓰기 설정이 필요하다” 등) (velero.io)
2. GitOps + Velero + Prometheus 통합 흐름 설명에서 기술적 연결고리 보완
   • 글에서는 “Prometheus Alert → Webhook → Velero 복구 트리거” 흐름이 제시되어 있는데, 실제 구현 시 “Alertmanager → Webhook → 복구 서비스” 외에도 “Velero 메트릭을 Prometheus로 수집하고, 백업 실패 시 알람” 등도 권장됩니다. (qloudx.com)
   • 따라서 “Velero 메트릭 수집 및 실패 알림”이라는 항목을 추가하면 독자가 더 완전한 DR 시스템을 이해할 수 있습니다.
3. DR 전략에서 다중 클러스터 또는 리전 대비 설명
   • 단일 클러스터 백업/복구는 중요하지만, 실제 DR 대비에서는 “지역 레벨 오류, 리전 전체 장애”를 고려하는 것이 권장됩니다. 글에도 간단히 “다음 글에서 멀티클러스터…”라고 되어 있지만, 본문 중에도 한두 문장으로 미리 언급해주면 좋습니다. (Medium)
   • 예컨대 “만약 클러스터 A가 리전 장애로 완전 가동 불가능해진다면, 클러스터 B 또는 복구 대상 클러스터로의 복원 전략도 마련해야 한다”는 내용.
4. 용어 및 표기 통일성
   • 본문 중 “RPO (Recovery Point Objective) / RTO (Recovery Time Objective)”는 괜찮지만 “SLO/SLA (Service Level Objective)”라고 한 부분에서 실제로는 SLO(Specified Level of Objective) 또는 SLA(Service Level Agreement) 둘 중 하나를 쓰는 것이 일반적입니다. 독자를 위해 “SLA (서비스 수준 협약)” 정도로 간단히 표기해도 좋겠습니다.
   • 또한 “셀프 힐링 클러스터(Self-Healing Cluster)”라는 표현이 좋지만, 한글·영문 혼용이 약간 혼란을 줄 수 있으니 한쪽으로 통일하면 좋습니다.
5. 실습 명령어나 예시에서 최신 버전 및 플래그 반영 여부
   • Velero 설치나 Helm 설치 명령어에서 플래그(--use-volume-snapshots=false 등)가 환경에 따라 달라질 수 있는데, “환경에 따라 CSI 스냅샷 사용 여부 고려”라는 주석을 덧붙이면 좋습니다. (Devtron)
   • Prometheus 알림 규칙 예시에서 container_cpu_usage_seconds_total 지표 사용하고 있는데, 최신 쿠버네티스/CRI 환경에서는 container_cpu_usage_seconds_total가 deprecated 될 수 있으므로 “환경에 맞게 메트릭 이름 확인”이라는 주의문 추가도 추천됩니다.

---

💡 추가 아이디어

• “복구 체험(Drill) 주기: 백업만으로 끝내지 말고 주기적으로 복구 시뮬레이션를 한다”는 항목을 추가하면 운영자 입장에서 매우 중요한 포인트입니다. (Medium)
• 백업 저장소 보안 및 권한 관리(예: S3 버킷 암호화, 접근 권한 제한)도 운영 환경에서는 반드시 고려됩니다.
• “백업 제외 항목/필터링”과 “백업 보존 정책(TTL)”에 대해서도 간단히 언급하면 현실적인 운용 팁이 됩니다. (Velero에서는 --ttl 플래그로 지정 가능) (velero.io)
• “DNS/로드밸런서 변화가 있을 경우 복구 시 고려사항” (예: 복구 대상 클러스터의 서비스 IP가 바뀌는 경우) 등에 대한 림(Re-map) 정보도 유용합니다. (velero.io)

---