测验：k3s 数据存储与快照

설치 옵션 없이 k3s 서버 한 대를 설치하고 k3s etcd-snapshot save 를 실행했더니 etcd datastore disabled 로 실패했다. 가장 정확한 설명은?

• 스냅숏 디렉터리가 아직 없어서 서버가 요청을 거절했다
• etcd-snapshot 명령은 에이전트 노드에서만 실행할 수 있다
• 저장소가 kine 을 거친 SQLite 라서 내장 etcd 가 없어 서버가 거절했다
• 정기 스냅숏이 돌고 있어서 수동 스냅숏이 잠겨 있었다

SQLite 로 돌던 k3s 서버를 config.yaml 에 cluster-init: true 를 적고 재시작했다. 실측으로 확인되는 결과는?

• SQLite 내용이 etcd 로 옮겨져 기존 객체의 UID 가 유지되고 state.db 는 state.db.migrated 로 바뀐다
• 기존 데이터는 SQLite 에 남고 etcd 는 빈 클러스터로 새로 시작해 객체를 다시 만들어야 한다
• cluster-init 은 첫 설치 때만 읽히므로 재시작만으로는 아무것도 바뀌지 않는다
• SQLite 와 etcd 에 동시에 기록하는 이중 쓰기 모드로 바뀌어 둘 다 최신으로 유지된다

스냅숏 파일만 오브젝트 스토리지에 올려 두었는데 원래 서버 디스크가 통째로 사라졌다. 새 호스트에서 복원하려면 무엇이 더 필요한가?

• 사라진 노드의 kubelet 인증서를 새 호스트에 복사해 둔다
• 스냅숏을 만든 것과 정확히 같은 k3s 판을 새 호스트에 설치한다
• 사라진 서버의 state.db.migrated 파일을 함께 가져온다
• 원래 서버의 토큰을 --token 으로 넘긴다 — 토큰이 스냅숏 안의 기밀 부트스트랩 데이터를 풀기 때문이다

k3s server --cluster-reset --cluster-reset-restore-path=<스냅숏> 을 실행해 복원이 끝났다. 그 직후 디스크와 절차에 대해 옳은 것은?

• 현재 etcd 데이터는 곧바로 지워지고 스냅숏만 남으므로 이전 상태를 되찾을 방법이 없다
• 이전 etcd 데이터는 db/etcd-old-<시각> 으로 옮겨지고, 안내대로 --cluster-reset 없이 다시 시작해야 한다
• 복원 명령이 서비스까지 시작하므로 systemctl start 를 하면 두 번 뜬다
• reset-flag 파일을 손으로 지워야 k3s 가 다시 정상 기동한다

스냅숏을 뜬 뒤 ConfigMap after-snap 을 만들고 marker 의 값을 바꿨다. 그 스냅숏으로 복원한 뒤의 상태는?

• after-snap 은 남고 marker 만 스냅숏 시점 값으로 돌아간다 — 복원은 기존 객체만 되돌린다
• 둘 다 그대로 남는다 — 복원은 멤버십만 초기화하고 데이터는 건드리지 않는다
• after-snap 은 사라지고 marker 는 스냅숏 시점 값으로 돌아간다 — 스냅숏 이후의 변경이 모두 되감긴다
• after-snap 은 사라지지만 marker 는 바뀐 값을 유지한다 — 새로 만든 객체만 지운다

k3s etcd-snapshot save --name lab-before 로 뜬 수동 스냅숏에 대해 옳은 것은?

• 정기 스냅숏과 같이 5개가 넘으면 오래된 것부터 자동으로 지워진다
• 이름 앞부분만 lab-before 이고 노드 이름과 시각이 붙으며, 보관 개수 제한이 없어 직접 지워야 한다
• 이름이 정확히 lab-before 인 파일 하나로 저장되어 다음 save 가 덮어쓴다
• --etcd-snapshot-dir 을 주지 않으면 현재 작업 디렉터리에 저장된다