Kubernetes 아키텍처 이해

1. 이 글의 기준

Kubernetes는 개념을 나열해서 이해하는 구조가 아니다. 아키텍처를 하나의 기준으로 잡고 봐야 전체가 연결된다.

이 글은 다음 기준 하나로 설명한다.

Kubernetes는 “상태를 저장하고, 그 상태를 기준으로 결정과 실행을 분리하여 유지하는 시스템”이다

---

2. 전체 아키텍처 개요

 

 

Kubernetes는 크게 두 영역으로 나뉜다.

• Control Plane → 상태를 저장하고 “결정”
• Worker Node → 실제로 “실행”

이 둘은 API를 통해 연결되며, 모든 동작은 상태를 기준으로 이루어진다.

---

3. Control Plane: 상태 저장과 의사결정

• Control Plane은 클러스터의 “두뇌” 역할을 한다.
• 하지만 중요한 점은 직접 실행하지 않는다는 것이다.

3.1 API Server — 모든 흐름의 시작점

역할:

• 모든 요청의 단일 진입점
• 클러스터 상태 저장 및 조회
• 모든 컴포넌트 간 통신 인터페이스

동작 구조:

• 사용자가 YAML을 적용 → API Server로 전달
• API Server가 이를 검증 후 저장
• 다른 컴포넌트는 이 상태를 조회하거나 Watch

핵심 의미:

Kubernetes에서 “실제 상태”는 항상 API Server에 저장된 값이다

3.2 etcd — 상태 저장소

역할:

• 클러스터의 모든 상태를 저장하는 분산 키-값 저장소

저장되는 정보:

• Pod, Deployment, Node 상태
• 설정 정보
• 메타데이터

핵심 의미:

Kubernetes는 “상태 저장 시스템”이며 etcd가 그 중심이다

3.3 Scheduler — 실행 위치 결정

역할:

• 실행되지 않은 Pod을 어떤 Node에 배치할지 결정

동작 과정:

1. Node 후보 필터링 (리소스, 조건)
2. 후보 Node 점수 계산
3. 최적 Node 선택

핵심 의미:

Scheduler는 실행을 하지 않고 “위치만 결정”한다

3.4 Controller — 상태 유지 엔진

역할:

• 현재 상태와 원하는 상태를 비교하고 맞춤

동작 방식:

1. API Server에서 상태 조회
2. desired state와 비교
3. 차이 발생 시 수정 요청

예시:

• Pod 3개 유지 → 2개 → 1개 생성

핵심 의미:

Kubernetes의 자동 복구는 Controller에서 발생한다

---

4. Worker Node: 실행과 상태 반영

Worker Node는 Control Plane의 결정을 실제로 수행한다.

핵심 기준:

Worker Node는 판단하지 않고 “실행만 한다”

4.1 Kubelet — Node 에이전트

역할:

• API Server와 통신
• Pod 실행 요청 처리
• 상태를 Control Plane에 보고

동작:

• PodSpec 수신
• 컨테이너 실행 요청
• 상태 업데이트

핵심 의미:

Kubelet은 실행기가 아니라 “상태 동기화 역할”

4.2 Container Runtime — 실제 실행 계층

역할:

• 컨테이너 생성 및 실행
• 이미지 다운로드

예:

• containerd
• CRI-O

핵심 의미:

Kubernetes는 컨테이너를 직접 실행하지 않는다

4.3 Kube-proxy — 네트워크 계층

역할:

• Service → Pod 연결
• 트래픽 분산 처리

동작:

• Pod 변경 감지
• 네트워크 규칙(iptables 등) 업데이트

핵심 의미:

변하는 Pod을 안정적으로 연결하는 레이어

---

5. 전체 데이터 흐름

 

 

 

전체 흐름을 단계별로 보면 다음과 같다.

① Pod Create Request

• 사용자가 kubectl 또는 CI/CD를 통해 Pod 생성 요청을 API Server에 전달 
• 시작점 (Desired State 정의)

② Update Pod State

• API Server가 요청을 받아 Pod 상태를 etcd에 저장 (아직 Node 미할당 상태)
• “Pod이 존재한다”는 상태만 기록됨

③ Acknowledges the request

• API Server가 클라이언트에게 요청이 정상적으로 처리되었음을 응답
• 실제 실행이 아니라 “요청 수락” 단계

④ Detects an unassigned pod

• Scheduler가 API Server를 감시하다가 Node가 할당되지 않은 Pod 발견
• 스케줄링 대상 식별

⑤ Watch (Scheduler → API Server)

• Scheduler가 API Server를 통해 새로운 Pod 상태를 지속적으로 감시
• Kubernetes의 핵심: polling이 아니라 watch 기반

⑥ Watch for bound pods

• Scheduler가 Pod을 Node에 할당하기 위해 상태 변화(스케줄 필요 여부)를 계속 확인
• 이 Pod을 어디에 배치할지 판단 준비

⑦ Kubelet gets the pod specs

• 선택된 Node의 kubelet이 API Server에서 PodSpec을 가져옴
• 이 Node에서 실행해야 할 작업 확인

⑧ Start container(s) in the pod

• kubelet이 Container Runtime에 요청하여 실제 컨테이너 실행
• 실행 단계 (Worker Node 영역)

⑨ Bind pod to node

Scheduler가 Pod과 Node를 연결 (binding)

• Pod → 특정 Node로 할당
• API Server에 반영

👉 “이 Pod은 이 Node에서 실행된다” 확정

 

⑩ Save Pod State

실행 결과가 다시 API Server → etcd에 저장

• 실행 상태
• 컨테이너 상태
• Pod 상태

👉 Current State 업데이트

---

6. 아키텍처를 하나로 묶으면

이 구조는 다음과 같이 정리된다.

• API Server / etcd → 상태 저장
• Scheduler → 위치 결정
• Controller → 상태 유지
• Kubelet / Runtime → 실행
• Kube-proxy → 연결

이 모든 과정은 하나의 루프로 반복된다.

---

7. 최종 핵심 정리

Kubernetes 아키텍처를 한 문장으로 정리하면

상태를 저장하고, 그 상태를 기준으로 결정과 실행을 분리하여 지속적으로 유지하는 시스템

 

구조적으로 보면:

• Control Plane → 판단
• Worker Node → 실행
• Controller → 보정

동작 방식으로 보면:

• 상태 기반
• 반복 루프
• 자동 유지

---

8. 마치며

• 이번 글에서는 Kubernetes를 개별 기능이 아니라 아키텍처 전체 흐름 기준으로 정리했다.
• 특히 Control Plane과 Worker Node를 분리해서 보고, 그 사이에서 상태가 어떻게 전달되고 유지되는지를 중심으로 이해하려고 했다.
• 처음에는 Pod, Deployment 같은 객체 단위로 접근했지만, 이 방식으로는 왜 Kubernetes가 그렇게 동작하는지 설명하기 어려웠다.

반대로 구조를 기준으로 보니 각 컴포넌트의 역할이 자연스럽게 연결됐다.

• API Server는 상태의 기준점이고
• Scheduler는 실행 위치를 결정하며
• Controller는 상태를 유지하고
• Worker Node는 이를 실제로 실행한다

이 흐름은 결국 하나로 정리된다.

“상태를 저장하고, 그 상태를 기준으로 계속 맞추는 구조”

 

• 또한 다이어그램을 기준으로 흐름을 따라가면서, Kubernetes가 단순히 명령을 실행하는 시스템이 아니라 상태를 중심으로 모든 컴포넌트가 느슨하게 연결된 구조라는 점이 명확해졌다.

이 관점을 기준으로 보면 이후 개념들도 다르게 보인다.

• Pod은 실행 단위가 아니라 상태의 결과이고
• Deployment는 상태를 유지하기 위한 정의이며
• Service는 변하는 실행 결과를 안정적으로 연결하기 위한 구조다

이번 글을 통해 Kubernetes를 “도구”가 아니라 구조와 흐름을 가진 시스템으로 이해하는 기준을 잡는 데 초점을 맞췄다.

---

9. 다음 글

이번 글에서는 Kubernetes를 Control Plane과 Worker Node로 나누어 구조 중심으로 정리했다.

• 어디에서 상태를 판단하는지
• 어디에서 실제 실행이 일어나는지

까지는 이해할 수 있다.

 

하지만 여기서 한 가지 질문이 남는다.

왜 Kubernetes는 상태를 계속 유지하는가

• Pod을 삭제했는데 왜 다시 생성되는지
• 컨테이너가 죽었는데 왜 자동으로 복구되는지
• Pod 개수를 왜 계속 유지하는지

이 동작들은 단순 기능이 아니라 구조 안에서 동작하는 메커니즘의 결과다.

 

다음 글에서는

• Desired State와 Current State의 차이
• Controller가 상태를 유지하는 방식
• Reconciliation Loop가 어떻게 동작하는지

를 기준으로 Kubernetes가 상태를 자동으로 유지하는 구조를 정리한다.

 

Kubernetes 상태 유지 구조 (Controller & Reconciliation Loop)