LabHub

쿠버네티스 배포판 — 직접 세운다 · k0s 로 세우고 복구하기 · 실습

k0s 를 세우고 etcd 를 복구한다

LabHub 에서 이어서 보기

이 실습은 진짜 k0s 에서 돕니다

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

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

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

목표

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

왜 중요한가

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

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

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

단계

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

참고

단계 8개

  1. 무엇이 떠 있는가
  2. 저장소는 무엇인가
  3. 왜 기본 대역을 쓰지 않았나
  4. 백업을 뜬다
  5. 백업 뒤에 무언가를 만든다
  6. 복구가 무엇을 되돌리는가
  7. k3s 와 무엇이 다른가
  8. 무엇을 배웠나