etcd 스냅샷 뜨고 검증하기

목표

살아 있는 etcd 의 상태를 확인하고, 스냅샷을 뜨고, 그 스냅샷이 실제로 쓸 수 있는 물건인지 기계적으로 검증하는 절차를 손에 익힙니다.

왜 중요한가

백업은 만드는 것보다 믿을 수 있게 만드는 것이 어렵습니다. 매일 도는 CronJob 이 매일 0바이트 파일을 남기고 있어도 아무 알람이 울리지 않는 시스템이 현실에는 아주 많습니다. 그래서 이 실습은 파일을 만드는 단계와 그 파일을 판정하는 단계를 나눕니다. snapshot status 가 돌려주는 revision, totalKey, hash 세 값은 각각 "언제 시점인가", "얼마나 담겼는가", "깨지지 않았는가"에 대한 답입니다. 이 셋을 스크립트가 읽어 OK 를 내도록 만들면, 백업의 성공 여부가 사람의 눈이 아니라 종료 코드로 표현됩니다. 또 하나, 쿼럼은 장애를 막아 주지만 오삭제를 막아 주지 못한다는 점을 멤버 수 계산과 함께 새겨 두세요. 멤버가 셋이든 다섯이든, 잘못된 삭제는 성실하게 전 멤버에 복제됩니다.

단계

1. etcdctl --endpoints=127.0.0.1:2379 endpoint health 의 출력을 /root/etcd/backup/out/health.txt 에 저장하세요. 파일 안에 healthy 와 엔드포인트 포트 2379 가 보여야 하고 unhealthy 라는 단어는 없어야 합니다.
2. etcdctl member list 출력을 /root/etcd/backup/out/members.txt 에 저장하세요(16진수 멤버 ID 와 2379/2380 주소가 포함돼야 합니다). 이어서 /root/etcd/backup/out/quorum.txt 에 members=<멤버 수> 와 quorum=<과반 수> 두 줄을 적으세요. 이 랩의 etcd 는 단일 멤버이므로 members=1, quorum=1 이 됩니다.
3. 스냅샷을 /root/etcd/backup/snap-01.db 로 저장하세요. 파일 크기가 20000 바이트 이상이어야 합니다.
4. snapshot status 를 JSON 형식으로 실행해 결과를 /root/etcd/backup/out/snap-01.json 에 저장하세요. revision 이 0보다 크고 totalKey 가 20보다 크며 hash 가 0이 아니어야 합니다.
5. /registry 접두어 아래 키 개수를 세어 숫자만 /root/etcd/backup/out/key-count.txt 에 넣으세요(20 이상이어야 합니다). 그리고 리소스 종류별 키 개수 상위 목록을 /root/etcd/backup/out/top-prefixes.txt 에 저장하세요. 이 파일에는 pods, configmaps, secrets, leases, events, namespaces 중 하나 이상의 이름이 들어 있어야 합니다.
6. 네임스페이스 etcd-lab 을 만들고 그 안에 ConfigMap etcd-lab-marker 를 data.owner=platform 으로 만드세요. 그다음 두 번째 스냅샷을 /root/etcd/backup/snap-02.db 로 뜨고 검증 결과를 /root/etcd/backup/out/snap-02.json 에 저장하세요. 두 번째 JSON 의 revision 이 첫 번째보다 커야 합니다.
7. /root/etcd/backup/cronjob.yaml 에 정기 백업 명세를 작성하세요. kind: CronJob, metadata.namespace: kube-system, spec.schedule: "0 */6 * * *" 입니다. 컨테이너의 command 는 리스트 형태이며 그 안에 snapshot save 와 --endpoints, --cacert, --cert, --key 네 플래그, 그리고 find 와 -mtime +7 을 쓴 삭제 명령이 모두 들어가야 합니다. 파드 명세에는 hostPath 가 /etc/kubernetes/pki/etcd 인 볼륨, 키에 control-plane 이 들어가는 nodeSelector, 그리고 tolerations 가 있어야 합니다. 볼륨은 모두 hostPath 형식으로 쓰세요.
8. /root/etcd/backup/verify.sh 를 실행 권한이 있는 스크립트로 만드세요. 인자로 받은 스냅샷이 정상이면 첫 줄에 OK <revision> <keys> 형식(공백 구분, 숫자 두 개)을 출력하고, 아니면 OK 로 시작하지 않는 줄을 출력해야 합니다. 이 스크립트로 snap-01.db 결과를 /root/etcd/backup/out/verify-01.txt 에, snap-02.db 결과를 /root/etcd/backup/out/verify-02.txt 에 저장하세요. 마지막으로 일부러 망가뜨린 파일을 하나 만들어 검증한 결과를 /root/etcd/backup/out/verify-bad.txt 에 남기세요.

참고

이 랩의 etcd 는 클라이언트 TLS 가 없어서 --cacert/--cert/--key 없이 붙습니다. 프로덕션에서는 세 플래그가 필수이며, 경로는 kubectl describe pod etcd-<노드> -n kube-system 의 실행 인자에 그대로 적혀 있습니다. 7번 단계에서 그 형태를 연습합니다.
snapshot status 는 요즘 etcdutl 로 옮겨졌습니다. etcdutl snapshot status <파일> -w json 이 권장 형태이고, etcdctl 로 해도 경고와 함께 동작합니다. 경고는 표준 오류로 나가므로 > 파일 리다이렉션에는 섞이지 않습니다.
키를 셀 때 --keys-only 출력에는 빈 줄이 섞입니다. /registry 로 시작하는 줄만 세야 정확합니다. 리소스 종류는 /registry/<종류>/... 의 두 번째 조각이므로 cut -d/ -f3 로 뽑아 sort | uniq -c | sort -rn 하면 됩니다.
망가진 파일은 짧은 쓰레기 파일을 하나 만들면 충분합니다. 진짜 스냅샷을 덮어쓰지 마세요.
흔한 실수 1: 6번에서 ConfigMap 을 만들기 전에 두 번째 스냅샷을 뜨는 것. 그러면 revision 이 늘지 않습니다.
흔한 실수 2: 8번 스크립트가 실패 경로에서도 OK 로 시작하는 줄을 내는 것. 그런 검증기는 검증을 하지 않는 것과 같습니다.
실습 파드는 실습마다 새로 뜨므로 앞 실습에서 만든 클러스터 상태는 남아 있지 않습니다. 필요한 오브젝트는 이 실습 안에서 직접 만드세요. 운영 절차를 기억이 아니라 런북과 매니페스트로 남겨야 하는 이유가 바로 이것입니다.

단계 8개

백업 전에 etcd 건강 상태 확인하기
멤버 목록과 쿼럼 계산하기
첫 스냅샷 뜨기
스냅샷을 JSON 으로 검증하기
etcd 안에 무엇이 얼마나 있는지 세기
변경을 만들고 두 번째 스냅샷 뜨기
정기 백업 CronJob 명세 쓰기
스냅샷 검증 스크립트 만들기