🤖 ChatGPT가 그려준 K8S Component 관련 이미지

---

1. Kubernetes Cluster Architecture

먼저 Kubernetes 클러스터의 큰 구조를 살펴보자.

┌────────────────────── Control Plane ──────────────────────┐
│                                                          │
│                     kube-apiserver                       │
│                      /    |     \                        │
│                     /     |      \                       │
│                  etcd  scheduler  controller-manager     │
│                                                          │
└──────────────────────────────────────────────────────────┘
                            │
                            │ Kubernetes API
                            ▼
┌────────────────────── Worker Node ────────────────────────┐
│                                                          │
│                        kubelet                            │
│                           │                              │
│                           ▼                              │
│                   Container Runtime                      │
│                           │                              │
│                           ▼                              │
│                          Pod                             │
│                                                          │
│                       kube-proxy                         │
│                   Service Networking                     │
│                                                          │
└──────────────────────────────────────────────────────────┘

Control Plane에는 대표적으로 다음 컴포넌트가 존재한다.

kube-apiserver
etcd
kube-scheduler
kube-controller-manager

Worker Node에서는 대표적으로 다음 컴포넌트가 동작한다.

kubelet
container runtime
kube-proxy

Kubernetes 공식 문서에서도 API Server, etcd, Scheduler, Controller Manager를 Control Plane Component로, kubelet과 kube-proxy 등을 Node Component로 구분한다.

처음에는 다음처럼 이해하면 쉽다.

Control Plane은 클러스터의 상태를 관리하고 판단하며, Worker Node는 실제 애플리케이션을 실행한다.

이제 각 컴포넌트를 하나씩 살펴보자.

---

2. kube-apiserver

Kubernetes의 모든 요청이 모이는 중앙 인터페이스

kube-apiserver는 Kubernetes API를 제공하는 Control Plane Component다.

Kubernetes 공식 문서에서는 API Server를 다음과 같이 설명한다.

API Server는 API Object의 데이터를 검증하고 구성하며 REST 요청을 처리한다.

또한 Kubernetes의 shared state에 접근하기 위한 frontend 역할을 하며 다른 컴포넌트들이 이를 통해 상호작용한다.

쉽게 말하면,

Kubernetes 내부의 중앙 통신 창구

라고 볼 수 있다.

예를 들어 다음 명령을 실행했다고 하자.

kubectl apply -f deployment.yaml

kubectl이 직접 etcd에 접근해서 Deployment를 저장하지 않는다.

kubectl
   │
   ▼
kube-apiserver
   │
   ▼
etcd

요청은 먼저 Kubernetes API Server로 전달된다.

---

API 요청은 바로 저장되지 않는다

API 요청을 조금 더 세분화하면 다음과 같은 과정을 거친다.

Request
   │
   ▼
Authentication
   │
   ▼
Authorization
   │
   ▼
Admission Control
   │
   ▼
Validation
   │
   ▼
Persist

Authentication

누가 요청했는가?

사용자 또는 ServiceAccount 등의 신원을 확인한다.

Authorization

이 사용자가 해당 작업을 수행할 권한이 있는가?

RBAC 같은 권한 관리가 여기에 연결된다.

Admission Control

인증과 인가 이후 요청을 추가적으로 검사하거나 변경한다.

따라서 API Server를 단순히 "REST API 서버"라고만 외우기보다는 다음처럼 이해하는 것이 좋다.

Client
   │
   ▼
kube-apiserver
   │
   ├─ Authentication
   ├─ Authorization
   ├─ Admission
   └─ Validation

---

API Server가 Pod를 실행하는 것은 아니다

여기서 중요한 점이 있다.

kube-apiserver는 Pod를 직접 실행하지 않는다.

API Server의 책임은 다른 Kubernetes Component들이 클러스터의 상태를 읽고 변경할 수 있도록 API를 제공하는 것이다. Kubernetes 공식 문서에서도 다른 컴포넌트가 shared state와 상호작용하는 frontend라고 설명한다.

한 줄 정리

kube-apiserver
= Kubernetes Cluster의 Front Door

---

3. etcd

Kubernetes Cluster State를 저장하는 Key-Value Store

etcd는 Kubernetes가 사용하는 consistent and highly-available key-value store다.

Kubernetes 공식 문서는 etcd를 Kubernetes의 모든 cluster data를 저장하는 backing store로 설명한다.

즉, Kubernetes의 현재 상태를 저장하는 데이터베이스에 가깝다.

예를 들어 다음과 같은 Kubernetes Object의 정보가 저장된다.

Pod
Deployment
Service
ConfigMap
Secret
Node
Namespace
...

우리가 다음과 같은 명령을 사용할 수 있는 것도 클러스터의 상태가 저장되어 있기 때문이다.

kubectl get pods
kubectl get deployments
kubectl get services

---

다른 컴포넌트들이 etcd에 직접 접근할까?

여기가 중요한 포인트다.

일반적으로 Scheduler, Controller Manager, kubelet 같은 Kubernetes Component는 API Server를 중심으로 클러스터 상태와 상호작용한다.

kubectl ─────────────┐
                    │
scheduler ───────────┤
                    │
controller-manager ──┼──▶ kube-apiserver ───▶ etcd
                    │
kubelet ─────────────┤
                    │
kube-proxy ──────────┘

특히 Kubernetes PKI 문서를 보면 Scheduler, Controller Manager, kubelet, kube-proxy 등이 API Server와 통신하기 위한 인증 정보를 사용하는 구조를 확인할 수 있다. 반대로 etcd에 접근하기 위한 Client Certificate는 API Server 측에 존재한다.

따라서 아키텍처를 공부할 때는 우선 다음 흐름을 기억하면 된다.

Component
    │
    ▼
kube-apiserver
    │
    ▼
etcd

---

왜 etcd Backup이 중요할까?

etcd에는 클러스터 상태가 저장된다.

따라서 etcd 데이터를 잃으면 Kubernetes Object 상태 역시 잃을 수 있다.

Kubernetes 공식 문서 역시 etcd를 사용할 경우 backup plan을 갖는 것을 강하게 권장한다.

그래서 CKA에서는 etcd의 개념뿐 아니라 다음 작업 역시 중요하다.

etcd snapshot save
etcd snapshot restore

한 줄 정리

etcd
= Kubernetes Cluster State Store

---

4. kube-controller-manager

Current State를 Desired State에 맞춘다

Kubernetes를 이해하는 핵심 개념 중 하나가 Desired State다.

예를 들어 Deployment를 다음과 같이 선언했다고 하자.

spec:
  replicas: 3

우리가 원하는 상태는 다음과 같다.

Desired State
Pod = 3

현재 Pod도 3개라면 문제가 없다.

Desired : 3
Current : 3

그런데 Pod 하나가 사라진다면?

Desired : 3
Current : 2

Desired State와 Current State 사이에 차이가 발생한다.

이 차이를 감지해서 현재 상태를 원하는 상태에 가깝게 만드는 역할을 수행하는 것이 Controller다.

Kubernetes 공식 문서의 정의가 이 개념을 매우 잘 설명한다.

Controller는 클러스터 상태를 감시하고 필요한 변경을 만들거나 요청하는 control loop다.

각 Controller는 현재 상태를 원하는 상태에 더 가깝게 이동시키려 한다.

이를 그림으로 표현하면 다음과 같다.

       Desired State
             │
             │ compare
             ▼
       Current State
             │
             ▼
        Controller
             │
             ▼
         Reconcile
             │
             └───────────────┐
                             │
                    다시 상태 확인

이것이 Kubernetes에서 자주 등장하는 Reconciliation Loop다.

---

Controller Manager는 Controller 하나가 아니다

kube-controller-manager라는 이름 때문에 하나의 Controller라고 생각하기 쉽다.

하지만 실제로는 Kubernetes에 포함된 여러 핵심 Control Loop를 하나의 프로세스에서 실행한다. 공식 문서에서도 Controller Manager를 core control loops를 포함하는 daemon이라고 설명한다.

예를 들어 다음과 같은 Controller들이 존재한다.

Node Controller
Job Controller
EndpointSlice Controller
ServiceAccount Controller
...

---

Controller와 Scheduler의 차이

두 컴포넌트의 역할을 구분해보자.

Pod가 3개 있어야 하는데 현재 2개뿐이다.

Controller의 생각은 다음에 가깝다.

"Pod가 하나 부족하다.
하나가 더 필요한 상태다."

새로운 Pod가 만들어졌다.

이번에는 Scheduler가 판단한다.

"이 Pod는 Worker Node 2에 배치하자."

즉,

Controller Manager
→ WHAT needs to happen

Scheduler
→ WHERE should it run

한 줄 정리

kube-controller-manager
= Desired State로 수렴시키는 Control Loop 집합

---

5. kube-scheduler

Pod를 어느 Node에서 실행할지 결정한다

Pod가 만들어졌다고 바로 Worker Node에서 실행되는 것은 아니다.

먼저 어느 Node에서 실행할지 결정해야 한다.

그 역할을 하는 것이 kube-scheduler다.

Kubernetes 공식 문서는 Scheduling을 다음과 같이 설명한다.

Pod를 Node와 연결해 kubelet이 실행할 수 있도록 하는 과정이다.

Scheduler는 Scheduling Queue에 있는 Pod마다 배치 가능한 Node를 찾는다. 이때 Pod의 제약 조건과 사용 가능한 리소스 등을 고려한다.

                 Pod
                  │
                  ▼
           kube-scheduler
                  │
        ┌─────────┼─────────┐
        ▼         ▼         ▼
     Node A    Node B    Node C
       X          O         O
                  │
                  ▼
               Node B

---

Scheduler는 어떤 조건을 볼까?

CKA에서 특히 다음 요소들을 Scheduling과 연결해서 알아둘 필요가 있다.

Resource Requests

resources:
  requests:
    cpu: 500m
    memory: 256Mi

Node가 Pod의 Resource Request를 수용할 수 있어야 한다.

nodeSelector

nodeSelector:
  disktype: ssd

특정 Label을 가진 Node를 선택하도록 제한한다.

Node Affinity

Node Label 등을 기반으로 더 다양한 배치 조건을 표현할 수 있다.

Pod Affinity / Anti-Affinity

특정 Pod와 가까이 배치하거나 서로 떨어뜨려 배치할 수 있다.

Scheduler는 새로운 Pod를 Scheduling할 때 Pod의 Affinity / Anti-Affinity Rule을 현재 Cluster State와 함께 평가한다.

Taints / Tolerations

특정 Node에서 일반적인 Pod가 Scheduling되지 않도록 제한할 수 있다.

공식 문서에서도 Scheduler가 Taint를 확인하며, matching Toleration을 가진 Pod가 해당 Node에 Scheduling될 수 있다고 설명한다.

---

Scheduler가 Pod를 실행하는 것은 아니다

Scheduler가 하는 일은 다음까지다.

Pod
 │
 └────▶ Worker Node 2

즉 Placement를 결정한다.

실제로 Worker Node에서 Pod 실행을 담당하는 것은 kubelet이다.

한 줄 정리

Scheduler = WHERE

kubelet   = RUN

---

6. kubelet

Worker Node의 Agent

kubelet은 각 Node에서 동작한다.

Kubernetes 공식 문서에서는 kubelet을 매우 명확하게 정의한다.

kubelet은 각 Node에서 실행되는 primary node agent다.

Scheduler가 다음과 같이 결정했다고 하자.

nginx-pod
     │
     ▼
worker-node-2

이제 Worker Node 2에서 누군가 실제 Pod를 실행시켜야 한다.

그 역할을 담당하는 것이 kubelet이다.

kube-apiserver
      │
      ▼
    kubelet
      │
      ▼
Container Runtime
      │
      ▼
     Pod

---

kubelet이 직접 Container를 만드는 것은 아니다

조금 더 정확하게 보면 kubelet은 Container Runtime을 이용한다.

대표적으로 다음과 같은 Runtime이 있다.

containerd
CRI-O

그리고 kubelet과 Container Runtime 사이에는 CRI(Container Runtime Interface)가 존재한다.

Kubernetes 공식 문서에서는 CRI를 kubelet과 Container Runtime 사이의 주요 통신 프로토콜로 설명한다. 또한 CRI를 통해 kubelet이 다양한 Container Runtime을 사용할 수 있다.

kubelet
   │
   │ CRI
   ▼
Container Runtime
   │
   ▼
Container

---

CKA Troubleshooting과 kubelet

CKA에서 Node 관련 문제를 만났다면 kubelet은 중요한 확인 대상이다.

예를 들어 kubelet 상태를 확인할 수 있다.

systemctl status kubelet

로그는 다음과 같이 확인할 수 있다.

journalctl -u kubelet

kubelet은 Node의 핵심 Agent이기 때문에 kubelet에 문제가 발생하면 해당 Node에서 Pod Lifecycle 관리에 문제가 생길 수 있다.

한 줄 정리

kubelet
= Node에서 Pod 실행을 책임지는 Agent

---

7. kube-proxy

Service Networking을 구현한다

Pod에는 각각 IP가 존재한다.

하지만 Pod는 생성되고 삭제되며 다시 생성될 경우 주소도 달라질 수 있다.

따라서 클라이언트가 개별 Pod IP를 직접 관리하는 것은 적합하지 않다.

Kubernetes에서는 이를 위해 Service라는 추상화를 제공한다.

                Service
                   │
        ┌──────────┼──────────┐
        ▼          ▼          ▼
      Pod A      Pod B      Pod C

전통적인 Kubernetes 구성에서 Service의 Virtual IP 메커니즘을 구현하는 핵심 컴포넌트가 kube-proxy다.

Kubernetes 공식 문서는 kube-proxy를 각 Node에서 실행되는 Kubernetes Network Proxy로 설명한다. 또한 Kubernetes API에 정의된 Service를 Node에 반영한다.

Service Networking 관련 공식 문서에서는 더 명확하게,

ExternalName을 제외한 Service의 Virtual IP 메커니즘 구현을 kube-proxy가 담당한다.

고 설명한다.

---

kube-proxy가 모든 Packet을 직접 Proxy하는 것은 아니다

이름 때문에 다음과 같은 구조를 떠올리기 쉽다.

Packet
   │
   ▼
kube-proxy process
   │
   ▼
Pod

하지만 kube-proxy의 핵심은 이것보다 Service를 구현하기 위한 Node의 Packet Forwarding Rule을 관리한다는 데 있다.

각 kube-proxy Instance는 Kubernetes Control Plane에서 Service와 EndpointSlice의 추가 및 제거를 감시한다.

개념적으로 보면 다음과 같다.

Service
   │
   ▼
kube-proxy
   │
   │ network rule 구성
   ▼
Node Networking
   │
   ▼
Backend Pod

따라서 kube-proxy를 공부할 때는 다음처럼 기억하는 것이 더 정확하다.

한 줄 정리

kube-proxy
= Service의 Virtual IP / Traffic Forwarding 구현

---

8. 하나의 Pod가 생성되는 과정

이제 여섯 컴포넌트를 하나의 흐름으로 연결해보자.

다음 명령을 실행했다고 가정한다.

kubectl apply -f deployment.yaml

그리고 Deployment에는 다음과 같이 선언되어 있다.

spec:
  replicas: 3

---

Step 1. kubectl → kube-apiserver

사용자의 요청이 Kubernetes API Server로 전달된다.

kubectl
   │
   ▼
kube-apiserver

API Server는 Kubernetes API의 Frontend로서 요청을 처리한다.

---

Step 2. API Object의 상태가 etcd에 저장된다

kube-apiserver
      │
      ▼
     etcd

etcd는 Kubernetes Cluster Data를 저장하는 backing store다.

---

Step 3. Controller가 Desired State를 맞춘다

사용자는 다음 상태를 원한다.

Desired Pod = 3

현재 Pod가 없다면 Controller가 차이를 발견한다.

Desired : 3
Current : 0

Controller는 Current State가 Desired State에 가까워지도록 필요한 변경을 요청한다.

개념적으로는 다음 과정이 발생한다.

Deployment
    │
    ▼
ReplicaSet
    │
    ▼
Pod

---

Step 4. Scheduler가 Node를 선택한다

생성된 Pod는 어느 Node에서 실행될지 결정되어야 한다.

Pod
 │
 ▼
Scheduler
 │
 ├── Node A
 ├── Node B  ← 선택
 └── Node C

Scheduler는 Pod의 조건과 Node의 가용 Resource 등을 바탕으로 적절한 Node를 결정한다.

---

Step 5. kubelet이 Pod를 실행한다

Node가 결정되면 해당 Node의 kubelet이 Pod 실행을 담당한다.

API Server
    │
    ▼
 kubelet
    │
    ▼
Container Runtime
    │
    ▼
   Pod

kubelet은 Node Agent이며 Container Runtime과 CRI를 통해 상호작용한다.

---

Step 6. Service가 있다면 kube-proxy가 네트워크를 구성한다

Service가 생성되어 있다면 kube-proxy는 Service와 EndpointSlice 정보를 감시하고 Service Virtual IP가 Backend로 연결될 수 있도록 필요한 네트워크 동작을 구현한다.

Client
   │
   ▼
Service
   │
   ▼
kube-proxy가 관리하는
Network Rules
   │
   ▼
Pod

---

9. 전체 흐름 정리

                       kubectl
                          │
                          ▼
                  ┌──────────────┐
                  │ kube-apiserver│
                  └───────┬──────┘
                          │
             ┌────────────┼────────────┐
             │            │            │
             ▼            ▼            ▼
           etcd      Controller     Scheduler
        State 저장     Reconcile      Placement
                                       │
                                       ▼
                                  Worker Node
                                       │
                                       ▼
                                    kubelet
                                       │
                                      CRI
                                       │
                                       ▼
                               Container Runtime
                                       │
                                       ▼
                                      Pod

                             Service가 존재하면

                                  kube-proxy
                                       │
                                       ▼
                              Service Networking

이 구조에서 중요한 것은 각각의 책임을 구분하는 것이다.

kube-apiserver
→ 요청과 상태 접근의 중심

etcd
→ 상태 저장

kube-controller-manager
→ Desired State로 수렴

kube-scheduler
→ Node 선택

kubelet
→ Node에서 Pod 실행

kube-proxy
→ Service Networking

---

10. CKA에서 헷갈리기 쉬운 컴포넌트 비교

Component	핵심 질문	역할
kube-apiserver	클러스터에 어떻게 접근하는가?	Kubernetes API
etcd	상태를 어디에 저장하는가?	Cluster State
controller-manager	필요한 상태는 무엇인가?	Reconciliation
scheduler	어디에서 실행할까?	Pod Placement
kubelet	실제로 어떻게 실행할까?	Pod Lifecycle
kube-proxy	Service 트래픽은 어떻게 전달할까?	Service Networking

특히 다음 세 가지는 확실하게 구분하자.

Controller
"Pod가 하나 더 필요하다."

Scheduler
"그 Pod는 Node B에서 실행하자."

kubelet
"Node B에서 그 Pod를 실제로 실행하겠다."

---

11. Kubernetes Architecture의 핵심 — Reconciliation

컴포넌트 여섯 개를 공부했지만 Kubernetes의 동작 원리는 결국 하나의 흐름으로 정리할 수 있다.

Desired State
      │
      ▼
Current State 관찰
      │
      ▼
차이 확인
      │
      ▼
Reconcile
      │
      ▼
Desired State에 가까워짐
      │
      └──────── 다시 관찰

Kubernetes 공식 문서 역시 Controller를 현재 Cluster State를 Desired State에 가깝게 움직이는 Control Loop로 설명한다.

예를 들어 사용자가 다음과 같이 선언했다면,

replicas: 3

Kubernetes에서 중요한 것은 단순히 "Pod 세 개를 생성한다"가 아니다.

현재 Pod가 두 개가 되었다면 다시 세 개로 만들고,

Desired : 3
Current : 2

다시 세 개가 되면 아무것도 하지 않는 식으로,

Observe
   ↓
Compare
   ↓
Reconcile
   ↓
Observe

이 과정을 계속 반복한다.

그래서 Kubernetes Architecture를 이해할 때는 컴포넌트 이름을 외우는 것보다,

누가 상태를 저장하고, 누가 상태를 관찰하고, 누가 배치를 결정하고, 누가 실제로 실행하는가

를 구분하는 것이 더 중요하다.

이 구조를 이해하고 나면 이후 배우게 되는 Deployment, ReplicaSet, DaemonSet, StatefulSet, Scheduling, HPA 같은 개념도 하나의 흐름 안에서 이해할 수 있다.

---

CKA 한 줄 암기

마지막으로 시험용으로 가장 압축하면 다음과 같다.

kube-apiserver          = API
etcd                    = State
kube-controller-manager = Reconcile
kube-scheduler          = Placement
kubelet                 = Execution
kube-proxy              = Service Network

그리고 Pod 생성 흐름은 다음 순서로 기억한다.

kubectl
   ↓
API Server
   ↓
etcd
   ↓
Controller
   ↓
Scheduler
   ↓
kubelet
   ↓
Container Runtime
   ↓
Pod

단, 이 그림은 컴포넌트의 역할을 이해하기 위한 논리적인 흐름이다. Kubernetes의 실제 내부 동작이 각 컴포넌트가 위에서 아래로 직접 호출되는 하나의 동기식 파이프라인이라는 의미는 아니다. Controller, Scheduler, kubelet 등은 API Server를 통해 클러스터 상태를 관찰하고 각자의 Control Loop에 따라 독립적으로 동작한다.