퀴즈: etcd 백업과 복구

문항 8개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

   1. 6시간치 변경
   2. 스냅샷 크기만큼
   3. 손실 없음
   4. 1시간치 변경

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

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