kubectl apply를 입력하면 잠시 뒤 Pod이 어딘가의 노드에서 뜹니다. 이 "잠시"의 뒤에서 여러 컴포넌트가 협력합니다. 쿠버네티스 아키텍처는 크게 결정을 내리는 컨트롤플레인과 실제로 컨테이너를 실행하는 워커 노드로 나뉩니다. 이 두 축과 각 컴포넌트의 역할을 알면 클러스터에서 무슨 일이 벌어지는지가 보입니다.
두 개의 평면 — 컨트롤플레인과 노드
컨트롤플레인은 "무엇을, 어디에 띄울지"를 정하는 두뇌이고, 워커 노드는 그 결정을 실행하는 손발입니다. 우리가 작성하는 YAML은 항상 컨트롤플레인의 API 서버로 들어가고, 실제 컨테이너는 노드의 kubelet이 띄웁니다.
| 평면 | 핵심 컴포넌트 | 역할 |
|---|---|---|
| 컨트롤플레인 | API Server | 모든 요청의 단일 입구, 검증·인증 |
| 컨트롤플레인 | etcd | 클러스터 상태를 저장하는 키-값 DB |
| 컨트롤플레인 | Scheduler | 새 Pod을 어느 노드에 둘지 결정 |
| 컨트롤플레인 | Controller Manager | 현재 상태를 원하는 상태로 수렴 |
| 워커 노드 | kubelet | 노드에서 Pod을 실제로 띄우고 감시 |
| 워커 노드 | kube-proxy | 노드 단의 Service 네트워크 라우팅 |
요청이 흐르는 순서
Pod 하나를 만들 때 컴포넌트들이 이어달리기를 합니다.
kubectl apply -f deployment.yaml
kubectl get pods -o wide
흐름은 이렇습니다. kubectl이 보낸 요청을 API Server가 받아 인증·검증한 뒤 etcd에 "이런 Pod이 필요하다"는 상태를 기록합니다. Scheduler가 아직 노드가 정해지지 않은 Pod을 발견하고 자원·제약을 따져 적합한 노드를 고릅니다. 그러면 그 노드의 kubelet이 자기에게 배정된 Pod을 보고 컨테이너 런타임에게 실행을 지시합니다. 마지막으로 kube-proxy가 Service로 들어온 트래픽을 그 Pod으로 연결합니다.
etcd와 컨트롤러 루프
핵심 원리 하나는 etcd가 "원하는 상태(desired state)"를 들고 있고, 컨트롤러들이 끊임없이 "현재 상태"와 비교해 차이를 메운다는 점입니다. 예를 들어 replicas: 3인데 Pod이 2개로 줄면, 컨트롤러가 그 차이를 감지해 1개를 새로 띄웁니다. 이 자가 치유(self-healing)가 쿠버네티스의 본질입니다.
kubectl get componentstatuses
kubectl get nodes
요점 정리
- 쿠버네티스는 결정하는 컨트롤플레인과 실행하는 워커 노드로 나뉜다.
- 모든 요청은 API Server라는 단일 입구를 거치고, 상태는 etcd에 저장된다.
- Scheduler가 노드를 고르고, 각 노드의 kubelet이 컨테이너를 실제로 띄운다.
- 컨트롤러가 원하는 상태와 현재 상태의 차이를 계속 메워 자가 치유한다.
각 컴포넌트를 직접 조회하며 클러스터가 어떻게 동작하는지 실습으로 확인하려면 쿠버네티스 트랙에서 시작하세요 — 회원가입 없이 무료로.