[CKA] 36. Backup & Restore

Date

2025/01/07

Backup & Restore

데이터 손실, 클러스터 장애 등의 이유로 백업과 복구가 필요하다. 백업을 통해 빠른 복구가 가능하며, 서비스의 연속성을 유지할 수 있다. 쿠버네티스 클러스터에서 백업해야 할 요소들은 다음과 같다:

•

Resource Configuration - 다양한 애플리케이션들은 definition file을 통해 배포된다

•

ETCD Cluster - ETCD 클러스터는 클러스터와 관련된 모든 정보가 저장된다

•

Persistent Volumes - 애플리케이션이 PV로 구성되면 또다른 백업 후보가 된다

Resource Configuration

Declarative

Configuration을 저장하기 위해선 선언적 접근(Declarative approach)을 위한 정의 파일을 생성해야 한다. Object definition file은 나중에 재사용하기 쉽고, 다른 사람과 공유가 가능하다. 이러한 파일들은 Github 같은 소스 코드 리포지토리에 저장하는 것이 적절하다. 이 백업 솔루션을 통해 클러스터 전체를 잃어도, configuration file을 적용해 애플리케이션을 다시 배포할 수 있다.

Query the kube-apiserver

누군가 정보를 기록하지 않고 명령적 접근(Imperative)으로 개체를 만드는 경우도 있다. 이러한 상황 때문에 Resource Configuration을 백업하는 더 나은 방법은 Kube-apiserver를 쿼리하는 것이다.

kubectl을 통해 kube-apiserver를 쿼리하거나 apiserver에 직접 액세스함으로써 클러스터에 생성된 모든 개체에 대한 리소스 구성을 복사해 저장할 수 있다.

kubectl get all --all-namespaces -o yaml > all-deploy-services.yaml
Bash
복사

kubectl을 통해 모든 pod, deploy, service를 가져와 yaml 파일로 저장할 수 있다. 하지만 이 외에도 고려해야 할 리소스 그룹이 많은데, 이 때 사용하는 것이 VELERO이다. ARK라고 불렸었던 VELERO는 HeptIO에서 제공하는 툴로, 쿠버네티스 API를 통해 클러스터의 백업을 가져올 수 있다.

ETCD

ETCD Cluster는 클러스터 자체에 관한 정보와 노드 및 클러스터 내부에서 생성된 모든 리소스를 저장한다. 따라서 위에서의 리소스를 백업하는 것 대신 ETCD 서버 자체를 백업하는 방법을 택할 수 있다.

Data Directory

ETCD는 마스터 노드에 호스트되어 있으며, 모든 데이터가 저장될 장소를 --data-dir에 명시해놓는다. 해당 디렉토리가 백업 툴로 백업할 수 있도록 구성할 수 있는 디렉토리이다.

Snapshot - backup

ETCD는 내장(built-in) 스냅샷 솔루션을 가지고 있다. etcdctl snapshot save를 통해 데이터베이스 스냅샷을 찍을 수 있다. 스냅샷은 .db 이름을 붙이며 스냅샷 파일은 현재 위치한 디렉토리에 생성된다. 전체 경로를 명시하면 다른 디렉토리에 생성할 수 있다. 백업의 상태 확인은 etcd snapshot status 명령어를 이용한다.

# snapshot 저장
ETCDCTL_API=3 etcdctl snapshot save snapshot.db

# 백업 상태 확인
ETCDCTL_API=3 etcdctl snapshot status snapshot.db
Bash
복사

스냅샷을 찍을 때는 인증서 파일과 etcd 클러스터로의 엔드포인드, CA 인증서, etcd 서버 인증서, 키를 지정해야 한다.

ETCDCTL_API=3 etcdctl snapshot save snapshot.db \
 --endpoints=https://127.0.0.1:2379 \
 --cacert=/etc/etcd/ca.crt \
 --cert=/etc/etcd/etcd-server.crt \
 --key=/etc/etcd/etcd-server.key
Bash
복사

Snapshot - restore

스냅샷으로 클러스터를 복원시키기 위해선 먼저 kube-apiserver 서비스를 중단시켜야 한다. 복원 과정에서는 ETCD Cluster를 재시작해야 하는데 kube-apiserver가 etcd에 의존하기 때문이다. kube-apiserver를 중지시켰다면 백업 파일의 경로인 snapshot.db 파일 경로를 설정하여 etcd snapshot restore 명령을 실행한다. --data-dir 을 통해 데이터 디렉토리를 지정할 수 있다. 기본 값은 /var/lib/etcd이며, 새로 생성하지 않으면 덮어 씌워진다. 이후로는 데몬 리로드와 서비스 재시작을 한 후, kube-apiserver를 실행시키면 클러스터가 원래 상태로 돌아온다.

# kube-apiserver 서비스 중지
service kube-apiserver stop

# 스냅샷 복원
ETCDCTL_API=3 etcdctl snapshot restore snapshot.db \ 
 --data-dir /var/lib/etcd-from-backup
 
# 데몬 다시 로드
systemctl daemon-reload
# etcd 서비스 재시작
service etcd restart

# kube-apiserver 서비스 실행
service kube-apiserver start
Bash
복사

ETCD가 백업에서 복원할 때, 새로운 클러스터 구성을 초기화하고 etcd의 멤버들을 새로운 클러스터의 새로운 멤버로 설정한다. 이는 새로운 멤버가 기존 클러스터에 우연히 조인되는 것을 방지하기 위한 것이다.

여기서 “스냅샷을 통해 클러스터 복원을 한다면 기존 클러스터가 사라질텐데 왜 기존 클러스터에 조인될 수 있는 가능성이 있을까”라는 의문이 들었다. GPT에 의한 답으로는 기존 클러스터가 복원 과정에서 계속 작동할 수 있게 때문에 새로운 클러스터로 configuration을 초기화하는 것이라고 한다.

Summary

Resource Configuration

manifest 파일을 통해 배포한 객체들을 Github 등의 Source Code Repository에 저장하여 사용할 수 있다. 하지만 명령적 접근을 통해 생성된 객체들은 manifest 파일에 포함되지 않을 수 있으므로, 이를 위한 추가적인 백업 방법이 필요하다.

kube-apiver에 직접 쿼리하여 리소스를 백업하는 방법은 명령적 접근을 통해 생성된 객체들까지 전부 백업할 수 있다. 이는 ETCD에 접근하지 못하는 상황에서도 유용하며, Managed Kubernetes 환경에서 자주 발생할 수 있는 상황으로, 이 경우 kube-apiserver를 통해 리소스를 백업하는 것이 적합할 수 있다.

ETCD

ETCD는 클러스터의 모든 데이터를 데이터 디렉토리에 저장하며, 스냅샷을 통해 클러스터 전체 상태를 백업 및 복원할 수 있다. 복원을 진행하면 기존 클러스터는 사라지고 스냅샷에 의한 새로운 클러스터가 새로 생성된다.