노드를 통째로 스냅샷 떠 두면 클러스터를 복구할 수 있는가. 답은 "서버는 복구되지만 클러스터는 복구되지 않는다" 이다. 쿠버네티스의 상태는 서버가 아니라 etcd 에 있고, 데이터는 노드 바깥의 스토리지에 있기 때문이다.
되는 것은 서버 복구다. OS 설정, 커널 파라미터, 패키지 상태, /var/lib/containerd 나 /var/lib/kubelet 의 손상 복구에는 쓸모가 있다.
안 되는 것은 다음과 같다.
| 한계 | 이유 |
|---|---|
| 클러스터 일관성이 없다 | 노드마다 스냅샷 시점이 달라 서로 맞지 않는다 |
| etcd 정합성이 깨진다 | 동작 중 스냅샷은 쓰기 중간 상태를 담는다 |
| 볼륨 데이터가 빠진다 | CSI 볼륨과 NFS · Ceph 는 노드 바깥에 있다 |
| 다른 클러스터로 옮길 수 없다 | 인증서와 노드 신원이 그 클러스터에 묶여 있다 |
파드는 복구 대상이 아니라 재생성 대상이다. 선언만 있으면 다시 만들어진다.
네임스페이스, 워크로드, 시크릿, CRD 가 전부 여기 있다.
ETCDCTL_API=3 etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
snapshot save /backup/etcd-$(date +%F).db
받은 스냅샷은 무결성을 확인해 둔다.
ETCDCTL_API=3 etcdctl snapshot status /backup/etcd-2026-09-20.db --write-out=table
etcd 스냅샷만으로는 복원되지 않는다. /etc/kubernetes/pki 아래의 CA 와 인증서를 함께 보관해야 한다. 이것이 빠지면 복원한 etcd 의 내용을 읽을 수 있는 API 서버를 다시 세울 수 없다.
kubectl get all,cm,secret,ing,pvc -A -o yaml > /backup/resources-$(date +%F).yaml
이 방식은 status 와 클러스터가 채워 넣은 필드까지 함께 담기므로 그대로 다시 적용하기 어렵다. 실무에서는 Helm values 와 Kustomize 오버레이를 Git 에 두는 것이 사실상의 선언 백업이고, 그편이 훨씬 낫다. GitOps 를 쓰고 있다면 이 항목은 이미 해결된 셈이다.
시크릿을 그대로 덤프하면 평문 자격증명이 파일로 남는다. 별도 암호화 보관소를 쓰거나 sealed-secrets 계열로 관리한다.
PV 의 데이터는 etcd 에도 선언에도 없다. 스토리지 방식에 따라 수단이 다르다.
| 스토리지 | 방법 |
|---|---|
| Longhorn | 볼륨 스냅샷 + S3 · NFS 백업 대상 설정 |
| Ceph · Rook | RBD 스냅샷, CephFS 스냅샷 |
| NFS | 서버 쪽 파일 백업 또는 스토리지 스냅샷 |
| 클라우드 블록 스토리지 | 제공자의 스냅샷 기능 |
CSI 드라이버가 지원하면 VolumeSnapshot 으로 쿠버네티스 안에서 다룰 수 있다.
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
name: data-snap
namespace: app
spec:
volumeSnapshotClassName: longhorn
source:
persistentVolumeClaimName: data
Velero 같은 도구는 선언 백업과 볼륨 스냅샷을 한 번에 묶고 네임스페이스 단위 복원을 지원한다. 상용 백업 제품도 대체로 같은 구조로 동작한다. 어떤 도구를 쓰든 확인해야 할 것은 같다.
백업은 복원해 본 적이 있을 때만 백업이다. 최소한 다음을 주기적으로 확인한다.