Kubernetes 아키텍처를 설명하라: control plane vs worker node와 그 구성 요소들.

Question

IT Interview Practice · Accepted Answer

Kubernetes 클러스터에는 두 종류의 머신이 있다: **control plane**(결정을 내리고 상태를 저장하는 "두뇌")과 **worker node**(당신의 Pod가 실제로 실행되는 곳). 각각은 잘 정의된 소수의 구성 요소를 가진다.

## 큰 그림

```text
┌──────────────── CONTROL PLANE (the brain) ────────────────┐
│                                                            │
│   kube-apiserver ── the front door; ALL comms go through it│
│        │                                                   │
│   etcd ───────── key-value store: the cluster's SOURCE OF  │
│                  TRUTH (all objects & desired state)       │
│   kube-scheduler ── decides WHICH node a new Pod runs on   │
│   controller-manager ── runs control loops (reconcilers)   │
└──────────────────────────┬─────────────────────────────────┘
                           │ (apiserver)
   ┌───────────────────────┼───────────────────────┐
┌──┴─── WORKER NODE ──┐ ┌──┴─── WORKER NODE ──┐  ...
│ kubelet             │ │ kubelet             │
│ kube-proxy          │ │ kube-proxy          │
│ container runtime   │ │ container runtime   │
│  └ Pods (your apps) │ │  └ Pods (your apps) │
└─────────────────────┘ └─────────────────────┘
```

## Control plane 구성 요소

```text
kube-apiserver        단일 진입점. REST API를 노출하고; 객체를 검증하여
                      etcd에 영속화한다. kubectl, controller, kubelet은
                      오직 apiserver와만 통신한다.
etcd                  분산된 일관성 있는 key-value 저장소. 클러스터 상태 전체
                      (원하는 + 현재)를 보관. etcd 상실 = 클러스터 상실.
kube-scheduler        노드가 할당되지 않은 Pod를 감시하고 최적의 노드를 선택
                      (리소스 요청, affinity, taint 등에 기반).
kube-controller-      control loop를 실행: node controller, replication(ReplicaSet),
manager               deployment, job, endpoints 등. 각 루프가 실제 → 원하는 상태로.
cloud-controller-     (클라우드에서) 프로바이더와 통합: load balancer, route,
manager               노드 라이프사이클.
```

## Worker node 구성 요소

```text
kubelet          노드 에이전트. apiserver와 통신하고, runtime을 통해 컨테이너를
                 시작/중지하며, Pod & 노드 상태를 보고한다. 노드의 현실을
                 자신에게 할당된 Pod와 일치시킨다.
kube-proxy       노드의 네트워킹(iptables/IPVS)을 프로그래밍하여 Service 가상
                 IP가 올바른 Pod 엔드포인트로 로드 밸런싱되게 한다.
container runtime 실제로 컨테이너를 실행하는 소프트웨어 (containerd, CRI-O).
```

## "kubectl apply"가 시스템을 통해 흐르는 방식

```text
1. kubectl → kube-apiserver: "3개 replica짜리 Deployment를 원한다"
2. apiserver가 객체를 검증하고 etcd에 기록
3. controller-manager(deployment→replicaset controller)가 이를 보고 3개의 Pod 객체 생성
4. scheduler가 할당되지 않은 3개의 Pod를 보고 각각을 노드에 할당 (apiserver 통해 기록)
5. 각 노드의 kubelet이 자기 Pod를 보고 runtime에게 이미지 pull & 컨테이너 시작 지시
6. kube-proxy가 Service 네트워킹을 연결하여 트래픽이 새 Pod에 도달
모든 것이 apiserver가 중재하는 WATCH + RECONCILE 루프다.
```

```bash
kubectl get nodes                 # 노드 목록 (control-plane + worker)
kubectl get pods -n kube-system   # control-plane / 시스템 구성 요소 보기
kubectl get componentstatuses     # 핵심 control-plane 요소의 상태
```

## 왜 중요한가

control plane과 worker node 사이의 분리 — 그리고 각 구성 요소의 역할 — 을 이해하는 것은 Kubernetes를 블랙박스에서 추론하고 운영할 수 있는 시스템으로 바꾸는 일이므로, 미들급 이상의 엔지니어에게 핵심 지식이다. **control plane**은 결정을 내리는 두뇌다: **kube-apiserver**는 모든 구성 요소와 사용자가 통신하는 단일 정문이다; **etcd**는 클러스터 상태 전체를 보관하는 일관성 있는 key-value 저장소이자 진실의 원천이다(잃으면 클러스터를 잃는다); **scheduler**는 각 새 Pod가 어느 노드에 안착할지 결정한다; **controller-manager**는 실제 상태를 원하는 상태로 끊임없이 몰고 가는 조정 루프를 실행한다. 각 **worker node**에서 **kubelet**은 노드의 컨테이너를 자신에게 할당된 Pod와 일치시키는 에이전트이고, **kube-proxy**는 Service 가상 IP가 올바른 Pod로 라우팅되게 하는 네트워킹을 프로그래밍하며, **container runtime**(containerd, CRI-O)이 실제로 컨테이너를 실행한다. 단 한 번의 `kubectl apply`가 이 시스템을 통해 흐르는 방식 — apiserver에서 etcd로, controller가 객체 생성, scheduler가 Pod 배치, kubelet이 컨테이너 시작, kube-proxy가 네트워킹 연결, 모두 감시-조정 루프로 — 을 보면 플랫폼 뒤의 우아하고 일관된 설계가 드러난다. 이 사고 모델은 Pod가 왜 Pending에 멈춰 있는지(scheduler), 클러스터가 왜 응답이 없는지(apiserver/etcd), Service가 왜 라우팅하지 않는지(kube-proxy)를 디버깅하는 데 정확히 필요한 것이며, 실제 클러스터를 운영하고 문제 해결하는 데 없어서는 안 된다.

큰 그림

Control plane 구성 요소

Worker node 구성 요소

"kubectl apply"가 시스템을 통해 흐르는 방식

왜 중요한가

관련 질문