kubeadm 클러스터 NotReady, SystemdCgroup, sysctl 세 줄: 막혔던 곳 정리

우분투 24.04 VM 3대(master 1 + worker 2)에 kubeadm으로 쿠버네티스 v1.34 클러스터를 세웠다.
CKA 준비하면서 kubeadm은 여러 번 해봤는데, 이번엔 가이드가 한 줄로 넘어가는 지점을 왜 그렇게 해야 하는지까지 따라가 봤다.
막힌 곳은 세 군데였다.

1. sysctl: 공식 문서는 한 줄, 가이드는 세 줄

공식 문서(Container Runtimes)는 net.ipv4.ip_forward = 1 한 줄만 최소 필수로 둔다.
서드파티 가이드 대부분은 여기에 bridge-nf-call-iptables, bridge-nf-call-ip6tables 두 줄을 더 넣으라고 한다.
차이의 이유는 최신 CNI가 br_netfilter와 bridge sysctl을 스스로 처리하는 경우가 많아져서다.
나는 세 줄 다 넣었다. 켜져 있어서 손해 볼 게 없고, CNI가 안 챙기는 경우에도 안전하다.
bridge-nf-call-iptables가 꺼져 있으면 Service 라우팅과 네트워크 정책이 에러 없이 조용히 어긋난다.

2. containerd의 SystemdCgroup = true

우분투에서 cgroup의 주인은 systemd다.
kubelet과 컨테이너 런타임은 같은 cgroup 드라이버를 써야 하므로 containerd도 systemd로 맞춘다.
설정 파일이 없으면 containerd config default로 만들고, runc options 아래 SystemdCgroup을 true로 바꾼 뒤 재시작.
안 맞추면 파드가 안 뜨거나 노드가 불안정해지는데, 에러 메시지가 불친절해서 원인 찾기가 오래 걸린다.

3. kubeadm init 성공 후 NotReady

노드끼리 핑은 되는데 NotReady였다.
원인은 노드 네트워크가 아니라 파드 네트워크가 아직 없어서다. init 직후엔 CNI가 없으니 정상 상태다.
Flannel을 깔았고, init 때 준 --pod-network-cidr=10.244.0.0/16은 Flannel 기본 대역에 맞춘 값이다.
이 둘이 어긋나면 파드 네트워크가 제대로 안 뜬다.
Flannel과 CoreDNS가 Running으로 올라오면 노드가 Ready로 바뀌고, worker join 뒤 3노드가 전부 Ready가 됐다.

세 곳은 따로 노는 게 아니라 커널(sysctl) → 런타임 cgroup(containerd) → 파드 네트워크(CNI) 순으로 이어져 있었다.
각 단계 명령어와 확인 방법, 공식 문서 근거는 원문에 정리해 뒀다.

👉 kubeadm 클러스터 구축 중 막히는 세 곳: sysctl, containerd SystemdCgroup, NotReady(CNI)
https://progreneur.com/blog/kubeadm-cluster-sysctl-cgroup-notready