복구 런북을 기준으로 클러스터를 다시 밀어보면서 초반에 빠진 부분들을 메모함.
문서만 볼 때는 괜찮아 보였는데, 실제로 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
초반 복구 런북은 너무 요약하면 실제 복구 때 의미가 떨어짐.
한 번에 보기 좋은 요약도 필요하지만, 재구축할 때는 빠진 명령이나 조건이 있으면 바로 막힘.
