[CKA] Control Plane 장애 대응

kubeadm 클러스터의 API server, scheduler, controller manager, etcd는 보통 static Pod로 실행됩니다. API server가 응답하면 kube-system Pod부터 보고, 응답하지 않으면 노드에서 kubelet과 static Pod manifest를 확인합니다.

kubectl get pods -n kube-system
kubectl describe pod <component-pod> -n kube-system
kubectl logs <component-pod> -n kube-system --previous

systemctl status kubelet
journalctl -u kubelet
ls /etc/kubernetes/manifests

static Pod 확인

static Pod는 kubelet이 manifest 디렉터리를 감시하며 생성합니다. 이름에 노드 이름이 붙고 kubernetes.io/config.source: file annotation이 있다면 static Pod인지 확인할 수 있습니다.

grep staticPodPath /var/lib/kubelet/config.yaml
ls /etc/kubernetes/manifests

manifest의 명령이나 kubeconfig 경로가 틀리면 컴포넌트가 반복해서 실패합니다. kubectl delete로 제거해도 kubelet이 다시 만들기 때문에 manifest를 수정해야 합니다. kubelet이 변경을 감지하므로 일반적으로 kubectl replace는 필요하지 않습니다.

역할에 따라 원인 좁히기

Deployment의 replica 수를 유지하는 컴포넌트는 controller manager입니다. 새 Pod는 만들어졌지만 노드에 배치되지 않는다면 scheduler를 확인합니다.

kubectl logs -n kube-system <controller-manager-pod>
kubectl logs -n kube-system <scheduler-pod>

인증서, 디스크, 메모리, 포트도 함께 점검합니다.

openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates -issuer
df -h
free -m
sudo ss -nltp

공식 절차는 클러스터 문제 해결에서 확인할 수 있습니다.