etcd 백업하고 복구 계획 세우기

목표

etcd 스냅샷을 실제로 뜨고 검증하고, 스냅샷이 담는 시점의 의미를 리소스 대조로 확인하고, 복구 절차를 문서로 남깁니다.

왜 중요한가

CKA 실기에서 etcd 백업은 거의 매번 나옵니다. 그런데 명령을 외우는 것만으로는 부족합니다. 이 실습이 강조하는 것은 스냅샷이 시점을 담는다는 사실입니다. 스냅샷을 뜬 뒤에 만든 리소스는 그 파일 안에 없고, 복구하면 사라집니다. 이 감각이 없으면 복구 후 "왜 어제 만든 게 없죠" 라는 사고가 납니다.

복구 계획을 글로 쓰게 하는 이유도 있습니다. 복구는 명령 한 줄이 아니라 순서입니다. 컨트롤 플레인을 내리고, 새 data-dir 에 풀고, 멤버 구성과 peer URL 을 맞추고, 다시 띄웁니다. 이 순서를 미리 써 두지 않으면 장애 한복판에서 만들게 되고, 그때 판단은 대체로 틀립니다.

이 환경의 etcd 는 127.0.0.1:2379 에서 돌고 있습니다. 실제 kubeadm 클러스터라면 여기에 --cacert, --cert, --key 세 옵션이 더 붙습니다.

단계

1. /root/cka-etcd/env.sh 를 만들어 ETCDCTL_API=3 과 ETCDCTL_ENDPOINTS=127.0.0.1:2379 를 자식 프로세스에 전달되도록 내보낸다.
2. etcd 엔드포인트 상태(또는 헬스) 출력을 /root/cka-etcd/status.txt 에 저장한다. 파일에 엔드포인트 주소가 보여야 한다.
3. 네임스페이스 cka-etcd 를 만들고 ConfigMap pre-backup 을 만든다. 데이터는 stage=before. 그 다음 cka-etcd 의 컨피그맵 목록을 /root/cka-etcd/before.txt 에 저장한다.
4. etcd 스냅샷을 /root/cka-etcd/snap.db 에 저장한다.
5. 그 스냅샷의 상태(메타데이터) 출력을 /root/cka-etcd/snap-status.txt 에 저장한다.
6. 스냅샷을 뜬 뒤에 ConfigMap post-backup (데이터 stage=after)을 cka-etcd 에 만들고, 컨피그맵 목록을 /root/cka-etcd/after.txt 에 저장한다. before.txt 에는 post-backup 이 없고 after.txt 에는 둘 다 있어야 한다.
7. /root/cka-etcd/restore-plan.md 에 복구 절차를 다섯 줄 이상, 200 바이트 이상으로 적는다. snapshot restore, --data-dir, --initial-cluster, peer 포트 2380, apiserver 라는 단어가 모두 들어가야 하고, 복구 중 컨트롤 플레인을 잠시 멈춘다는 내용도 있어야 한다.

참고

• etcdctl snapshot status 가 없다면 etcdutl snapshot status 를 써 보세요. 최신 etcd 는 오프라인 작업을 etcdutl 로 옮겼습니다.
• 스냅샷 파일은 bbolt 데이터베이스라 텍스트로 열어 봐도 의미가 없습니다. 크기와 status 출력으로 확인합니다.
• 흔한 실수 1: 6단계를 4단계보다 먼저 하는 것. 그러면 대조가 성립하지 않습니다.
• 흔한 실수 2: 복구 계획에 apiserver 를 멈추는 단계를 빠뜨리는 것. 살아 있는 apiserver 가 계속 쓰면 복구본과 어긋납니다.

단계 7개

1. etcdctl 환경변수 정리하기
2. 엔드포인트 상태 확인하기
3. 백업 기준점 만들기
4. 스냅샷 저장하기
5. 스냅샷 메타데이터 확인하기
6. 백업 이후 리소스와 대조하기
7. 종합: 복구 절차 문서로 남기기