복구 런북을 기준으로 클러스터를 다시 밀어보면서 초반에 빠진 부분들을 메모함.

문서만 볼 때는 괜찮아 보였는데, 실제로 VM을 지우고 다시 만들면서 보이는 것들이 있었음.

먼저 VM 정리 쪽.

기존 VM을 삭제하고 다시 만들 때 VM 디렉터리나 libvirt 쪽 잔여물이 남을 수 있음.

수동으로 하나씩 지우기보다 정리 스크립트가 필요해 보였음.

# libvirt VM 목록을 확인한다.
virsh list --all

# VM 디스크 볼륨이 남아 있는지 확인한다.
virsh vol-list --pool <pool-name>

SSH known_hosts 문제도 있었음.

VM을 같은 IP로 다시 만들면 SSH host key가 바뀌어서 중간자 공격 경고가 뜰 수 있음.

테스트 환경에서는 같은 IP에 새 VM을 계속 붙이니까 known_hosts 정리 절차가 필요함.

# 기존 SSH host key 기록을 확인한다.
ssh-keygen -F 192.168.200.42

# 재생성한 VM의 기존 host key 기록을 제거한다.
ssh-keygen -R 192.168.200.42

LB 서버 쪽도 빠진 부분이 보임.

문서에는 커널 파라미터 확인은 있었는데, 실제 적용 절차가 부족했음.

특히 HAProxy와 keepalived를 쓰려면 LB 서버의 네트워크 설정이 맞아야 함.

# LB 서버의 커널 파라미터를 확인한다.
sysctl net.ipv4.ip_nonlocal_bind
sysctl net.ipv4.ip_forward

필요한 설정은 문서에 명확히 넣어야 함.

net.ipv4.ip_nonlocal_bind=1
net.ipv4.ip_forward=1

LB 서버도 Ansible playbook으로 관리하는 쪽이 맞아 보였음.

초기에는 일부 작업을 수동으로 했는데, 재구축을 반복하려면 LB도 자동화 대상에 넣는 게 편함.

HAProxy 재구동도 playbook으로 정상 처리되지 않는 상황이 있었음.

결국 수동으로 재구동함.

# HAProxy 상태를 확인한다.
sudo systemctl status haproxy

# HAProxy를 수동으로 재시작한다.
sudo systemctl restart haproxy

# HAProxy가 정상 기동했는지 확인한다.
sudo systemctl status haproxy

control-plane join 명령도 따로 메모함.

# k8s-cp2를 control-plane 노드로 join한다.
sudo kubeadm join 192.168.200.48:6443 \
  --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash> \
  --control-plane \
  --certificate-key <certificate-key>

worker join 형식도 같이 정리.

# worker 노드를 클러스터에 join한다.
sudo kubeadm join 192.168.200.48:6443 \
  --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash>

containerd registry 설정도 귀찮은 부분이 있었음.

/etc/containerd/config.toml에서 config_path를 맞추고, /etc/containerd/certs.d 아래 registry 설정을 넣는 흐름.

이건 나중에 GitLab에 도메인과 HTTPS를 붙이는 방향으로 정리하는 게 낫다고 봄.

# containerd 설정에서 registry config_path를 확인한다.
grep -n "config_path" /etc/containerd/config.toml

초반 복구 런북은 너무 요약하면 실제 복구 때 의미가 떨어짐.

한 번에 보기 좋은 요약도 필요하지만, 재구축할 때는 빠진 명령이나 조건이 있으면 바로 막힘.