IT/Kubernets

Velero vs Kasten K10, 뭘 쓸까

gfrog 2026. 9. 5. 09:16

쿠버네티스 백업 얘기를 하면 결국 이 두 개로 좁혀진다. 오픈소스로 시작한 Velero, 상용의 대표주자 Kasten K10. 최근 조사 자료를 보니 2026년 5월 기준 마인드셰어는 Kasten 33.9%, Velero 20.9% 정도로 Kasten이 앞서고 있는데, 흥미로운 건 둘 다 전년 대비 점유율이 살짝 빠졌다는 점이다. Kanister나 커스텀 오퍼레이터로 자체 구축하는 팀이 늘어난 영향으로 보인다.

우리 팀도 최근에 이 선택을 다시 했다. 원래 Velero + Restic으로 굴리다가 몇 가지 이유로 재검토가 필요했고, 그 과정에서 정리한 내용을 공유한다.

두 도구의 기본 성격 차이

Velero는 툴킷에 가깝다. velero backup create, velero restore create 같은 CLI 위주로 동작하고, 스케줄은 CronJob 형태로 CRD가 잡아준다. 볼륨 스냅샷은 CSI 스냅샷 API를 쓰거나 예전 방식대로 Restic/Kopia로 파일 레벨 백업을 뜬다. 아키텍처가 단순한 대신, 애플리케이션 정합성(consistency)이나 정책 관리 같은 건 직접 짜야 한다.

Kasten K10은 완성된 제품이다. 웹 UI가 있고, 정책 기반으로 백업/보관/복제/DR을 한 화면에서 관리한다. 데이터베이스 정합성 보장(Kanister blueprint), 랜섬웨어 방어(불변 백업), 멀티클러스터 대시보드까지 다 붙어 있다. 그래서 가격이 있다. 노드 수 기반 라이선스라 클러스터가 커질수록 부담이 커진다.

한 줄 요약: Velero는 조립식, Kasten은 완성품.

언제 Velero가 맞나

첫째, 스테이트리스 애플리케이션 위주 클러스터. PV가 있어도 대부분 로그나 캐시 성격이라 정합성이 크게 문제 안 되는 경우다. velero schedule create daily --schedule="0 3 * * *" --ttl 168h 정도로 끝나는 환경이라면 Kasten은 오버킬이다.

둘째, 팀에 K8s 운영 인력이 충분한 경우. Kanister blueprint를 직접 작성하거나, pre/post hook을 정교하게 짜서 DB 정합성을 확보할 수 있다면 Velero로도 상용 수준까지 갈 수 있다. 다만 이건 진짜 시간이 든다. 우리 팀에서 PostgreSQL WAL-G 연동 blueprint 하나 안정화하는 데만 2주 걸렸다.

셋째, 멀티 클라우드 환경. Velero는 AWS S3, GCS, Azure Blob, MinIO 등 오브젝트 스토리지 백엔드가 다양하고, 백업을 리전간/클라우드간 옮기는 것도 자유롭다. 벤더 락인 걱정이 없다.

넷째, 예산이 진짜 없을 때. 라이선스비 0원은 아무리 봐도 매력적이다.

# Velero 스케줄 예시 - 매일 3시, 7일 보관, CSI 스냅샷 포함
apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: daily-prod
spec:
  schedule: "0 3 * * *"
  template:
    ttl: 168h
    includedNamespaces:
      - prod-api
      - prod-worker
    snapshotVolumes: true
    defaultVolumesToFsBackup: false
    storageLocation: s3-primary

언제 Kasten이 맞나

첫째, 스테이트풀 워크로드가 많고 컴플라이언스 요구가 강한 경우. 금융권이나 의료 데이터를 다루는 팀이면 감사 대응, RBAC 세분화, 불변 백업(immutable backup)이 기본으로 필요한데, Velero로 이걸 다 맞추려면 별도 도구를 여러 개 붙여야 한다. Kasten은 이게 한 제품 안에 들어 있다.

둘째, 운영 인력이 얇은 팀. UI 기반으로 정책 만들고, 앱별 정합성은 Kanister blueprint가 이미 60개 넘게 기본 제공된다. PostgreSQL, MongoDB, MySQL, Cassandra, Kafka 대부분 커버된다. "누구든 화면 보고 복원 버튼 누를 수 있어야 한다"는 요구가 있다면 Kasten이다.

셋째, 멀티 클러스터 관리. K10 Multi-Cluster Manager로 여러 클러스터의 백업 상태를 한 곳에서 본다. 이걸 Velero로 하려면 대시보드부터 자체 구축이다.

넷째, 랜섬웨어/재해복구가 진지한 요구사항인 경우. S3 Object Lock 기반 불변 백업, 백업 데이터 무결성 검증, 어플리케이션 이동 복제(App Mobility) 같은 게 표준 기능이다.

실제로 우리는 뭘 골랐나

결론부터 말하면, 개발/스테이징은 Velero, 프로덕션 코어 클러스터는 Kasten으로 나눴다.

이유는 이렇다. 개발 클러스터는 그냥 매일 스냅샷 떠두고 사고 나면 롤백하는 정도면 충분하다. Velero + CSI 스냅샷으로 15분 안에 세팅 끝났다. 반면 프로덕션은 PostgreSQL, Redis Cluster, Kafka가 다 스테이트풀로 돌고 있는데, 각각 정합성 있는 백업을 짜려니 Kanister blueprint 튜닝만 몇 주째 잡고 있었다. 그 시간에 다른 걸 하는 게 낫다는 판단이었다.

라이선스 비용은 노드 수 기반이라 처음엔 부담됐지만, "장애 시 복구 시간 단축"과 "감사 대응 문서화 부담 감소"를 계산에 넣으니 손익분기가 생각보다 빨리 왔다. 특히 지난 분기 감사 때 백업 정책 증적을 K10 리포트로 그대로 뽑아 제출한 게 크게 도움됐다.

놓치기 쉬운 포인트 하나

두 도구 모두 백업 자체는 쉽지만 복원 리허설은 아무도 안 한다는 문제가 있다. Velero든 Kasten이든 백업이 성공했다는 로그만 보고 안심하기 쉬운데, 실제로 다른 네임스페이스나 다른 클러스터로 복원해서 앱이 뜨는지 검증하는 걸 정기적으로 안 하면 결국 재해 순간에 무너진다.

우리 팀은 매달 첫째 주 목요일에 "복원 훈련"을 도입했다. 랜덤으로 하나의 스테이트풀 앱을 골라서 격리된 네임스페이스에 복원해보고, 정합성 체크 후 결과를 위키에 남긴다. 도구 선택보다 이 프로세스가 훨씬 중요하다는 걸 최근에야 실감했다.

정리

  • 스테이트리스 위주 / 인력 여유 / 예산 타이트 → Velero
  • 스테이트풀 많음 / 컴플라이언스 요구 / UI 필요 → Kasten K10
  • 둘 다 있어도 됨. 클러스터 특성별로 나누는 것도 답이다.

혹시 Portworx PX-Backup이나 자체 Kanister 오퍼레이터로 굴리는 분 있으면 후기 공유 부탁드린다. 그쪽 이야기가 요즘 궁금하다.

저작자표시 비영리 동일조건 (새창열림)