クイズ: etcdのバックアップと復旧

etcd 멤버를 3개로 늘려 쿼럼을 확보했습니다. 이 구성이 막아 주지 못하는 사고는?

• 한 노드의 네트워크 단절
• 네임스페이스를 실수로 삭제한 사고
• 한 멤버의 프로세스 크래시
• 컨트롤 플레인 한 대의 디스크 고장

etcdctl snapshot restore 가 --name, --initial-cluster, --initial-cluster-token 같은 플래그를 받는 이유는?

• 복구한 데이터 디렉터리를 기존 클러스터에 멤버로 다시 합류시키기 위해
• 복구는 사실상 새 etcd 클러스터 하나를 부트스트랩하는 작업이기 때문
• 스냅샷 파일의 해시와 멤버 구성이 일치하는지 검사하기 위해
• 새 멤버 이름과 피어 주소로 TLS 인증서를 다시 발급하기 위해

복구 절차에서 kube-apiserver 를 먼저 멈추는 이유로 가장 적절한 것은?

• kubelet 이 정적 파드를 재시작하지 못하게 하려고
• apiserver 가 etcd 데이터 디렉터리를 잠그기 때문
• 복구 중에도 들어오는 쓰기가 복구 결과와 뒤섞이는 것을 막기 위해
• apiserver 를 멈춰야 스냅샷을 뜰 수 있기 때문

snapshot status 결과에서 totalKey 가 유독 작게 나왔습니다. 가장 먼저 의심할 것은?

• 스냅샷을 저장한 디스크의 여유 공간이 부족해 뒷부분이 잘렸다
• 스냅샷이 전체가 아니라 일부만 담겼거나 잘못된 엔드포인트에서 떴다
• hash 계산 방식이 바뀌어 키 개수가 다르게 집계됐다
• etcd 버전이 낮아 일부 키스페이스가 스냅샷에서 빠졌다

복구 시 --data-dir 로 기존 /var/lib/etcd 를 지정하면 안 되는 이유는?

• restore 는 빈 디렉터리를 전제로 하며, 기존 경로를 주면 실패하거나 살아 있는 데이터를 훼손하기 때문
• 그 경로는 root 소유로 고정돼 있어 백업 사용자 계정으로는 쓰기 권한이 없기 때문
• 복구 디렉터리는 스냅샷 파일과 같은 파일 시스템에 있어야 하는데 그 조건을 깨기 때문
• etcd 가 그 경로를 자기 전용으로 예약해 두어 외부 도구의 쓰기를 거부하기 때문

정기 백업 CronJob 에 nodeSelector 와 tolerations 를 함께 넣는 이유는?

• 백업 파드를 컨트롤 플레인 노드 세 대에 고르게 나눠 배치하기 위해서
• etcd 는 컨트롤 플레인에만 있고 그 노드에는 테인트가 걸려 있어 둘 다 필요하기 때문
• CronJob 은 tolerations 가 없으면 어떤 노드에도 스케줄되지 않기 때문
• hostPath 볼륨을 쓰는 파드는 nodeSelector 로 노드를 고정해야 하기 때문

6시간마다 백업을 뜨는 정책에서 최악의 데이터 손실량은?

• 6시간치 변경
• 스냅샷 크기만큼
• 손실 없음
• 1시간치 변경

백업 스크립트가 항상 성공(OK)만 보고하고 있다면 가장 큰 문제는?

• 실패를 감지할 수 없어 사고 시점에야 백업이 쓸모없다는 것을 알게 된다
• 검증을 건너뛴 만큼 스냅샷 파일 크기가 회차마다 커진다
• 스냅샷의 revision 이 이전 회차와 같은 값에 머무른다
• 매 회차마다 전체 키를 다시 세느라 실행 시간이 길어진다