Stand Up k0s and Restore etcd

한국어 원문으로 표시합니다.

VM 안에 k0s 한 대가 실제로 떠 있고, 컨트롤 플레인 저장소가 etcd 입니다. 그래서 백업과 복구를 실제로 해 볼 수 있습니다.

인증 과정의 다른 실습이 도는 kwok 은 가짜 컨트롤 플레인이라 k0s backup 도 etcdctl 도 의미가 없습니다.

처음 뜨는 데 3분쯤 걸립니다.

k0s 클러스터의 구성을 확인하고, 백업 → 변경 → 복구 를 한 바퀴 돌려 복구가 실제로 무엇을 되돌리는지 눈으로 봅니다. 그리고 k3s 와의 차이를 정리합니다.

백업은 복구해 본 적이 있어야 백업입니다. 받아 두기만 하고 복구를 시험하지 않은 백업은 "있다고 믿는 것" 이지 백업이 아닙니다. 실제로 못 쓰는 백업이 드물지 않고, 그 사실은 언제나 최악의 순간에 드러납니다.

그리고 복구가 무엇을 되돌리는지 정확히 아는 것이 중요합니다. etcd 복구는 "클러스터를 그 시점으로 되돌리는 것" 입니다. 백업 이후에 만든 것은 전부 사라집니다. 이것을 모르면 복구 후에 "왜 어제 만든 것이 없냐" 는 두 번째 사고가 납니다.

이 실습은 그것을 일부러 만들어 봅니다. 백업하고, 그 뒤에 무언가를 만들고, 복구한 뒤 그것이 사라진 것을 확인합니다.

k0s status 와 노드 상태를 /root/k0s/status.txt 에 저장하세요.
저장소가 etcd 임을 k0s etcd member-list 로 확인해 /root/k0s/etcd.txt 에 저장하고, --single 모드였다면 왜 이것이 실패하는지도 적으세요.
이 클러스터의 서비스 대역을 확인해 /root/k0s/cidr.txt 에 저장하고, 왜 기본 대역을 쓰지 않았는지 적으세요.
canary 라는 ConfigMap(v=before)을 만든 뒤 k0s backup 으로 백업하고 /root/k0s/backup.txt 에 기록하세요.
백업 뒤에 ConfigMap 을 하나 더 만들고, 그 이름을 /root/k0s/disaster.txt 에 after_backup=<이름> 으로 적으세요. 복구하면 이것이 어떻게 될지 예상도 함께 적습니다.
k0s restore 로 복구하고 결과를 /root/k0s/restore.txt 에 저장하세요. canary 는 살아 있고 5번의 것은 사라져야 합니다.
k3s 와 k0s 의 차이를 /root/k0s/compare.md 에 정리하세요. 저장소·CNI·기본 구성요소가 들어가야 합니다.
/root/k0s/report.md 에 store=etcd, service_cidr_dns=, restore_verified= 세 줄과 설명을 쓰세요.

k0s 는 독립 kubectl 을 깔지 않습니다. k0s kubectl 로 쓰거나, 이 환경처럼 k0s 바이너리에 kubectl 심링크를 걸면 됩니다.
백업은 k0s backup --save-path /root 입니다. 복구는 k0s 를 멈춘 뒤 k0s restore <파일> 이고, 그 다음 다시 시작합니다.
복구 절차의 순서가 중요합니다. k0s stop → 기존 etcd 데이터 비우기 → k0s restore <파일> → k0s start 입니다.
가운데 단계를 빠뜨리면 복구 명령은 성공하는데 데이터가 그대로입니다. etcd 는 데이터 디렉터리가 이미 있으면 그것을 쓰고 스냅숏을 무시하기 때문입니다. 오류도 경고도 나오지 않아서, 복구했다고 믿게 되는 것이 가장 위험합니다.
흔한 실수 1: k0s install controller --single 로 세우고 etcd 실습을 하려는 것. 그 모드는 저장소가 kine(sqlite) 이라 k0s etcd 명령이 전부 거절됩니다.
흔한 실수 2: 복구 후 kubectl 이 응답할 때까지 기다리지 않고 바로 확인하는 것. 컨트롤 플레인이 다시 올라올 시간이 필요합니다.

무엇이 떠 있는가

k0s status 와 노드 상태를 /root/k0s/status.txt 에 저장하세요.

k0s status 는 역할과 워크로드 여부를 알려 줍니다. Workloads: true 는 이 컨트롤러가 워커 역할도 겸한다는 뜻입니다.

저장소는 무엇인가

저장소가 etcd 임을 k0s etcd member-list 로 확인해 /root/k0s/etcd.txt 에 저장하고, --single 모드였다면 왜 이것이 실패하는지도 적으세요.

k0s etcd member-list 가 성공하면 etcd 입니다. kine(sqlite) 이면 'wrong storage type' 으로 거절합니다.

왜 기본 대역을 쓰지 않았나

이 클러스터의 서비스 대역을 확인해 /root/k0s/cidr.txt 에 저장하고, 왜 기본 대역을 쓰지 않았는지 적으세요.

이 VM 은 쿠버네티스 클러스터 안에서 돕니다. 호스트가 준 DNS 서버 주소와 겹치면 어떻게 되는지 생각해 보세요.

백업을 뜬다

canary 라는 ConfigMap(v=before)을 만든 뒤 k0s backup 으로 백업하고 /root/k0s/backup.txt 에 기록하세요.

복구를 검증하려면 '백업 시점에 무엇이 있었는지' 표식이 필요합니다. ConfigMap 하나면 충분합니다.

백업 뒤에 무언가를 만든다

백업 뒤에 ConfigMap 을 하나 더 만들고, 그 이름을 /root/k0s/disaster.txt 에 after_backup=<이름> 으로 적으세요. 복구하면 이것이 어떻게 될지 예상도 함께 적습니다.

복구는 클러스터를 백업 시점으로 되돌립니다. 그 뒤에 만든 것이 어떻게 될지 예상해 적으세요.

복구가 무엇을 되돌리는가

k0s restore 로 복구하고 결과를 /root/k0s/restore.txt 에 저장하세요. canary 는 살아 있고 5번의 것은 사라져야 합니다.

k0s stop → k0s restore <파일> → k0s start 순서입니다. 멈추지 않고 복구하면 도는 etcd 와 충돌합니다.

k3s 와 무엇이 다른가

k3s 와 k0s 의 차이를 /root/k0s/compare.md 에 정리하세요. 저장소·CNI·기본 구성요소가 들어가야 합니다.

저장소, CNI, 기본으로 들어오는 구성요소를 축으로 비교하세요. 어느 쪽이 더 좋은지가 아니라 어떤 상황에 무엇이 맞는지가 요점입니다.

무엇을 배웠나

/root/k0s/report.md 에 store=etcd, service_cidr_dns=, restore_verified= 세 줄과 설명을 쓰세요.

store=, service_cidr_dns=, restore_verified= 세 줄과 함께, 백업을 왜 복구해 봐야 하는지 적으세요.