🚀 쿠버네티스(Kubernetes) 핵심 구성요소와 상관관계

쿠버네티스를 처음 접하면 kube-apiserver, etcd, kubelet, scheduler 같은 이름들이 쏟아져 나옵니다.
“이게 다 뭐고, 서로 어떻게 연결되는 거야?”라는 생각이 드셨다면 이 글이 딱 맞습니다.

오늘은 쿠버네티스의 핵심 구성요소를 정리하고, 각 요소들이 어떻게 맞물려 돌아가는지를 직관적으로 이해할 수 있도록 풀어보겠습니다.

---

🧩 쿠버네티스 큰 그림

쿠버네티스는 크게 두 축으로 나눌 수 있습니다.

• 컨트롤 플레인(Control Plane) → 클러스터의 두뇌
• 워커 노드(Worker Node) → 실제 애플리케이션이 실행되는 손발

---

🧭 컨트롤 플레인 구성요소

구성요소	역할
kube-apiserver	모든 요청이 통과하는 게이트웨이. kubectl 명령도 여기로 들어옴
etcd	클러스터 상태를 저장하는 Key-Value DB
kube-scheduler	새 파드를 어떤 노드에 배치할지 결정
kube-controller-manager	파드 복제, 노드 상태 감시, 장애 복구 등 다양한 컨트롤러 실행
cloud-controller-manager	(선택) 클라우드 환경과 통합

---

⚙️ 워커 노드 구성요소

구성요소	역할
kubelet	해당 노드에서 파드가 정상 실행되도록 보장, 컨트롤 플레인과 통신
kube-proxy	네트워크 규칙 관리, 서비스 IP와 파드 간 트래픽 라우팅
컨테이너 런타임	Docker, containerd 등 실제 컨테이너 실행 담당

---

🔗 상관관계 흐름

1. 사용자 → API Server

   • kubectl apply 같은 명령이 들어오면 API Server가 이를 받아들임

2. API Server ↔ etcd

   • 클러스터 상태를 etcd에 저장하거나 읽어옴

3. Scheduler → API Server

   • 새 파드가 생성되면 어떤 노드에 배치할지 결정

4. Controller Manager → API Server

   • 파드 수를 맞추고, 노드 장애를 감지해 복구

5. API Server → Kubelet

   • 선택된 노드의 kubelet이 파드를 실행하도록 지시

6. Kubelet → Container Runtime

   • kubelet이 런타임에게 컨테이너 실행 요청

7. Kube-proxy

   • 서비스 IP를 통해 파드 간, 외부와의 네트워크 트래픽 연결

---

🧠 비유로 이해하기

• API Server = 회사 접수처 (모든 요청이 여기로 들어옴)
• etcd = 기록 보관소 (모든 상태 기록 저장)
• Scheduler = 인사팀 (누가 어느 부서에서 일할지 결정)
• Controller Manager = 운영팀 (인원 부족하면 충원, 문제 생기면 복구)
• Kubelet = 현장 관리자 (지시받은 일을 실제로 수행)
• Container Runtime = 직원 (실제 업무를 수행하는 컨테이너)
• Kube-proxy = 안내 데스크 (사람들이 올바른 부서/직원에게 연결되도록 라우팅)

---

✅ 정리

• 컨트롤 플레인은 두뇌, 워커 노드는 손발
• 모든 요청은 API Server를 거쳐 etcd에 기록
• Scheduler/Controller가 조율하고, kubelet이 실행
• kube-proxy가 네트워크를 연결

👉 이렇게 톱니바퀴처럼 맞물려 돌아가면서 쿠버네티스 클러스터는 안정적으로 동작합니다.

---

💡 다음 글에서는 이 구성요소들이 실제로 어떻게 동작하는지, kubectl get nodes, kubectl get pods 출력과 연결해서 실습 기반으로 해석하는 방법을 다뤄보겠습니다.