쿠버네티스 아키텍처

두 층: 컨트롤 플레인과 노드

┌──────────────── 컨트롤 플레인 (controlplane) ────────────────┐
│  kube-apiserver  ←→  etcd                                    │
│        ↑   ↑                                                 │
│  kube-scheduler   kube-controller-manager                    │
└────────┼─────────────────────────────────────────────────────┘
         │ (모든 대화는 API 서버를 거친다)
┌────────┴───────── 워커 노드 (node01, node02 …) ───────────────┐
│  kubelet  →  컨테이너 런타임(containerd)  →  파드(컨테이너)     │
│  kube-proxy (Service 규칙)     CNI 플러그인 (파드 네트워크)       │
└──────────────────────────────────────────────────────────────┘

컨트롤 플레인

노드

파드 하나가 생기기까지

kubectl create deployment web --image=nginx --replicas=2 를 치면:

1. kubectl → API 서버에 Deployment 생성 요청.
2. API 서버 → 인증·인가·검증 후 etcd 에 저장.
3. Deployment 컨트롤러(컨트롤러 매니저) → 이를 보고 ReplicaSet 을 만든다.
4. ReplicaSet 컨트롤러 → 파드 오브젝트 2개를 만든다(아직 노드 없음 = Pending).
5. 스케줄러 → 노드 배정이 안 된 파드를 보고, 조건에 맞는 노드를 골라 spec.nodeName 을 적는다.
6. 그 노드의 kubelet → 자기 노드에 배정된 파드를 보고 런타임에 컨테이너 생성을 요청한다. CNI 가 IP 를 준다.
7. kubelet 이 상태를 API 서버에 보고 → Running.

트러블슈팅은 이 사슬 중 어디서 끊겼는지 찾는 일입니다. 파드 오브젝트가 아예 없으면 3~4번(컨트롤러), nodeName 이 비어 있으면 5번(스케줄러), 노드는 정해졌는데 컨테이너가 안 뜨면 6번(kubelet·이미지·설정)입니다.

kubeadm 클러스터의 비밀: static pod

kubeadm 으로 설치한 클러스터에서 컨트롤 플레인 부품들은 static pod 로 돕니다.

ls /etc/kubernetes/manifests/
# etcd.yaml  kube-apiserver.yaml  kube-controller-manager.yaml  kube-scheduler.yaml

kubelet 은 설정(/var/lib/kubelet/config.yaml 의 staticPodPath)에 적힌 이 폴더를 감시하다가, 파일이 생기면 파드를 띄우고, 바뀌면 다시 띄우고, 지우면 내립니다. API 서버 없이도 kubelet 혼자 합니다. 그래서 API 서버 자체도 파드로 띄울 수 있습니다.

• kubectl get pods -n kube-system 에 보이는 kube-apiserver-controlplane 은 거울 파드(mirror pod) 입니다. 여기서 지워도 파일이 있는 한 다시 생깁니다.
• 컨트롤 플레인 설정을 바꾸려면 이 YAML 파일을 고칩니다. 저장하면 kubelet 이 알아서 다시 띄웁니다(1분쯤 걸릴 수 있음).
• 파일을 고쳤는데 부품이 안 살아나면? API 서버가 죽었다면 kubectl 이 안 되므로 crictl ps -a 와 crictl logs 로 봅니다.

cat /var/lib/kubelet/config.yaml | grep staticPodPath
# staticPodPath: /etc/kubernetes/manifests

중요한 파일 위치