"노드 OS 이미지를 백업해 두자" 는 요구는 거의 항상 복구 수단 을 기대하고 나온다. 그런데 Kubernetes 에서 노드는 복구 대상이 아니라 재생성 대상이다. 클러스터 상태는 etcd 에 있고, 데이터는 노드 바깥 스토리지에 있다. 노드를 되살려도 클러스터가 되살아나지 않는다.
그래서 OS 이미지의 쓸모는 방향이 다르다. 같은 노드를 다시 빠르게 만들어 내기 위한 재료 로 쓴다. 이 관점으로 바꾸면 만드는 방법도 달라진다. 운영 중인 노드를 찍는 것이 아니라, 깨끗한 상태에서 표준 이미지를 만들어 두고 거기서 노드를 찍어 낸다.
노드마다 손으로 맞추던 것을 이미지 단계로 끌어올린다.
| 항목 | 예 |
|---|---|
| OS 기본 | 배포판 · 커널 버전 · 보안 패치 수준 |
| 커널·시스템 튜닝 | sysctl, limits.conf, THP, swap 설정 |
| 시간 | chrony 설정과 NTP 서버 |
| 런타임 | containerd · CRI-O 설치와 config.toml, 레지스트리 신뢰 인증서 |
| 네트워크 | 방화벽 규칙, 본딩 · MTU |
| 특수 노드 | GPU 드라이버, SR-IOV, 대용량 로컬 디스크 마운트 |
이미지는 환경별 수단으로 보관한다. vSphere 는 VM 템플릿, AWS 는 AMI, OpenStack 은 Glance 이미지다. 베어메탈이면 PXE 설치 프로파일이 같은 역할을 한다.
kubeadm join 은 이미지에 굽지 않는다. 노드 신원과 조인 토큰은 이미지에 들어가면 안 되는 값이다. 부팅 후 cloud-init 이나 Ansible 로 조인한다.
베어메탈에서 재설치가 오래 걸리거나, 변경 작업 직전 되돌릴 지점이 필요할 때는 스냅샷을 쓴다. 이때 지켜야 할 것이 있다.
kubelet 을 멈추고 찍는다. 도는 상태로 찍으면 /var/lib/kubelet 이 중간 상태로 굳는다.
systemctl stop kubelet
# 스냅샷 수행
systemctl start kubelet
복원한 뒤에는 다음 경로를 비운다. 전부 캐시이거나 그 시점의 파드 흔적이라, 그대로 두면 지금 클러스터 상태와 어긋난 채 kubelet 이 올라온다.
/var/lib/kubelet
/var/lib/containerd
/var/log/containers
/var/log/pods
컨트롤 플레인 노드는 더 조심한다. etcd 가 얹혀 있는 노드를 통째로 되돌리면 그 노드의 etcd 만 과거로 돌아가 멤버 사이의 정합성이 깨진다. 컨트롤 플레인은 스냅샷 되돌리기가 아니라 etcd 스냅샷 복원 절차를 쓴다.
노드 이미지는 백업 계획의 일부가 아니다. 실제로 백업해야 하는 것은 etcd · 선언 · 볼륨 세 가지이고, 그 내용은 아래 문서에 있다.