Velero 도입 및 적용기(1)

in Dev on Kubernetes, Velero
Velero 도입 및 적용기(1)

블로그 댓글 기능을 고쳐두었습니다. 자유롭게 소통하고, 피드백 부탁드립니다.

Velero 도입 및 적용기를 두 개의 포스팅으로 나눠서 공유하고자 합니다. 이번 포스팅에서는 왜 Velero를 선정하게 되었는지 그리고 그 동작 방식을 살펴보고, 이어질 포스팅에서는 Velero를 설치하여 주기적으로 컴포넌트를 백업/복원하는 실습으로 구성하였습니다.

도입 배경

쿠버네티스 클러스터를 운영하다보면 휴먼 에러 또는 서버 장애 등으로 인해 구성 요소 백업이 절실한 시점을 한 번쯤 마주하게 됩니다. 저는 인증서 교체 작업을 진행하면서 upstream의 인그레스 설정을 잘못 건드리는 바람에 애를 먹었던 적이 있어요. 인그레스 설정이다보니 클러스터를 관리하는 웹 서비스가 먹통이 되었고, 덩달아 만료된 인증서 때문에kubectl 조차도 동작하지 않는 바람에 속수무책이었습니다. 다행히 서비스 중인 클러스터가 아니어서 큰 문제로 이어지지는 않았지만, 서비스 중인 운영계 자원에서 발생했다면 플랫폼에 미치는 영향도와 피해는 상당했을 것 같네요. 추후, 이런 일을 방지하고자 여러 백업 도구들을 검토하였고 최종적으로 Velero를 도입하기로 결정했습니다.

Why Velero?

먼저, 각 백업 도구들마다 제공하는 기능이 다르기 때문에 백업의 의미를 명확히 하는 과정이 선행되어야 합니다. 주기적으로 etcd 스냅샷만 남기는 백업이라면 클러스터 전반에 걸친 장애가 발생하더라도 보다 능동적으로 대처할 수 있다는 장점이 있습니다. 하지만, 저희 플랫폼은 이미 스토리지 스냅샷을 남겨두고 있고, DB는 이중화해두었으며. Redis도 Sentinel 구성을 해서 관리하고 있는 상황입니다.

그래서, Workload나 CRD, Configmap 등을 아우르는 컴포넌트 백업이 더욱 목적에 부합했습니다. 비록 Velero는 ETCD 장애시 복구 기능이 따로 없고, 네임스페이스 단위로 백업을 진행하기 때문에 미리 백업해두지 않은 부분에 대해서는 대응하기 쉽지 않지만, 단순히 데이터 복구만을 목적으로는 충분했거든요.

그리고, 무료 오픈소스 툴이라는 점도 무시할 수 없는 부분이었습니다. Kasten이나 Stash는 포탈을 통해 전체 클러스터를 관리할 수 있고 DB 백업을 지원하는 점에서 기능적으로는 부족함이 없었지만, 유료로 서비스를 제공하기 때문에 대규모 클러스터를 운영하는 입장에서는 큰 부담으로 다가왔습니다. 대체할 만한 다른 무료 툴이 없었던 것은 아닙니다. K8up은 Velero가 가지는 기능에 덧붙여 DB 백업도 가능하지만 백업/복구를 위해 yaml 파일을 수동으로 작성해서 적용해야 하며, 실제 어플리케이션에 백업과 관련한 annotation을 일일이 입력해줘야하는 큰 불편함이 있었습니다.

Velero 동작 방식

Velero 동작 방식

Velero는 기본적으로 각각의 작업(on-demand backup, scheduled backup, restore)은 CRD 형태로 구성되고, 그에 대응하는 컨트롤러가 올라가서 CRD에 정의해둔 작업을 수행합니다.

  • Workflow
    • Backup
      1. 사용자가 Velero CLI로 kubernetes API에 backup object 생성을 요청
      2. BackupController가 새롭게 추가된 backup object를 인지하고 validation을 진행
      3. validation이 완료되면 BackupController가 backup을 위한 데이터 수집을 kubernetes API에 요청
      4. BackupController가 수집한 backup file을 object storage에 저장
    • Restore
      1. 사용자가 Velero CLI로 K8s API에 restore object 생성을 요청
      2. RestoreController가 새롭게 추가된 restore object를 인지하고 validation을 진행
      3. RestoreController가 object storage에서 백업 데이터를 가져오고 백업 사전 작업 진행
      4. restore 프로세스가 시작되고 각 리소스를 한 번에 하나씩 복원
        • non-destructive restore 방식을 따름 = 클러스터 내의 어떠한 데이터도 복원 과정에서 삭제하지 않는다

참고