쿠버네티스 마스터 — 아키텍처·Control Plane

이 글은 쿠버네티스 마스터 노트 시리즈의 첫 번째 편입니다. 컨테이너 한두 개는 Docker로 충분하지만, 수백 컨테이너를 자동 관리하려면 오케스트레이션이 필요합니다. 그 표준이 Kubernetes (K8s).

이 시리즈 10편은 아키텍처·Pod·Workloads·Services·Config/Secret·Storage·Scaling·Security·Helm·실전까지. 1편의 목표 — K8s가 무엇인지, Control Plane 4 컴포넌트 손에 잡히게.

처음 K8s가 어렵게 느껴지는 이유

처음 이 단원이 어렵게 느껴지는 이유는 두 가지예요. 첫째, 컴포넌트 이름이 너무 많습니다. apiserver·etcd·scheduler·controller-manager·kubelet·kube-proxy… 한 번에 머리에 안 들어옵니다. 둘째, "왜 이 모든 게 필요한가" 막연합니다. Docker 하나면 안 되나?

해결법은 한 가지예요. "공장과 현장 직원" 비유로 묶는 것. Control Plane = 본사 관리부 (계획·지시·기록), Worker Node = 현장 작업장 (실제 컨테이너 돌아감). 본사는 무엇을 어디에 배치할지 결정, 현장은 그 결정대로 일함. 이 그림이 잡히면 컴포넌트 위치가 자연스럽게 보입니다.

K8s가 푸는 문제

Docker 단독의 한계

서버 1대: docker run nginx (수동)
        ↓
서버 다운 시: 어떻게 자동 복구?
부하 증가 시: 어떻게 자동 확장?
새 버전 배포: 어떻게 무중단?

수십·수백 컨테이너 환경에선 수동 관리 불가능.

K8s가 자동 처리

• 자가 치유 — 컨테이너 다운 시 자동 재시작
• 수평 확장 — 부하에 따라 자동 증감
• 롤링 업데이트 — 무중단 배포
• 서비스 디스커버리 — IP 변경 자동 추적
• 로드 밸런싱 — 자동 트래픽 분산
• 자원 관리 — CPU·메모리 효율 배치

여기서 정말 중요한 시험 함정 — K8s = "Desired State 시스템". 사용자가 "이 상태로 두라" 선언 → K8s가 계속 그 상태로 유지. 명령형 X, 선언형 O. 모든 동작의 기본 철학.

클러스터 큰 그림

┌─────────────────────────────────────────────┐
│  Control Plane (본사)                        │
│  ├── kube-apiserver  ← 모든 통신의 입구     │
│  ├── etcd            ← 클러스터 상태 DB    │
│  ├── kube-scheduler  ← Pod 배치 결정        │
│  └── controller-manager ← 상태 유지 로직   │
└─────────────────────────────────────────────┘
          ↕ (각 노드와 통신)
┌─────────────────────────────────────────────┐
│  Worker Nodes (현장)                         │
│  Node 1, 2, 3, ...                          │
│  각 노드:                                    │
│  ├── kubelet           ← 노드 에이전트      │
│  ├── kube-proxy        ← 네트워크 규칙      │
│  └── Container Runtime ← Docker/containerd  │
└─────────────────────────────────────────────┘

Control Plane — 4 컴포넌트

1. kube-apiserver — 모든 통신의 입구

kubectl → API Server → etcd
                    → Scheduler
                    → Controller Manager
모든 노드 → API Server

유일한 진실의 출입구. 인증·인가·검증 후 etcd에 저장.

여기서 시험 함정이 하나 있어요. API Server는 stateless. 상태는 모두 etcd에. API Server 여러 개 있어도 etcd가 단일 진실.

2. etcd — 클러스터 상태 DB

분산 키-값 저장소. 클러스터의 모든 상태:

• Pod·Service·Deployment 정의
• 노드 목록·상태
• ConfigMap·Secret
• 네트워크 정책

Raft 합의 알고리즘 → 정족수(과반) 합의로 일관성

여기서 정말 중요한 시험 함정 — etcd 손실 = 클러스터 손실. 정기 백업 필수. 운영 환경 = 3개 이상 노드 (HA).

3. kube-scheduler — Pod 배치 결정

새 Pod이 생기면 어느 노드에 배치할지 결정.

판단 기준:

• 노드 자원 (CPU·Memory 여유)
• 노드 라벨·셀렉터
• Affinity·Anti-Affinity
• Taint·Toleration
• Pod 우선순위

결정만 → kubelet이 실제 실행.

4. kube-controller-manager — 상태 유지 로직

여러 컨트롤러 묶음:

Controller	역할
Node Controller	노드 다운 감지
Replication Controller	Pod 수 유지
Endpoint Controller	Service ↔ Pod 연결
ServiceAccount Controller	기본 계정 생성
... 등 수십 개

각 컨트롤러는 무한 루프:

1. 현재 상태 조회 (API Server 통해 etcd)
2. Desired State와 비교
3. 차이 있으면 조정 (Pod 만들기·지우기)
4. 반복

여기서 시험 함정이 하나 있어요. Reconciliation Loop = K8s의 심장. "원하는 상태"를 향해 계속 조정. 한 번에 못 도달해도 점진적으로.

Worker Node — 3 컴포넌트

1. kubelet — 노드 에이전트

각 노드의 K8s 대리인.

역할:

• API Server에서 자기 노드 Pod 받음
• Container Runtime에 실행 명령
• Pod 상태 → API Server 보고
• Liveness·Readiness Probe 실행

kubelet ↔ API Server (통신)
       ↔ Container Runtime (실행)

2. kube-proxy — 네트워크 규칙

각 노드의 네트워크 처리.

역할:

• Service 트래픽 → Pod로 라우팅
• iptables 또는 IPVS 규칙 관리
• 노드 간 클러스터 네트워크

여기서 정말 중요한 시험 함정 — kube-proxy ≠ 네트워크 플러그인 (CNI). CNI는 Pod 네트워크 자체 (Calico·Flannel·Cilium), kube-proxy는 Service 라우팅.

3. Container Runtime — 실제 실행

컨테이너를 띄우는 엔진.

Runtime	설명
Docker	옛 표준 (K8s 1.24+ 직접 지원 X)
containerd	가벼운 표준
CRI-O	Red Hat 주도, OCI 표준

Kubernetes 1.24+ = containerd 또는 CRI-O 권장. Docker는 dockershim 제거.

kubectl — 사용자 도구

# 설치
brew install kubectl

# 현재 컨텍스트 확인
kubectl config current-context

# 노드 목록
kubectl get nodes

# 모든 Pod
kubectl get pods --all-namespaces

# Pod 상세
kubectl describe pod my-pod

# 로그
kubectl logs my-pod

# 명령 실행
kubectl exec -it my-pod -- bash

# YAML 적용
kubectl apply -f deployment.yaml

kubectl 동작 흐름

kubectl get pods
  ↓ HTTPS
API Server (인증·인가)
  ↓
etcd (조회)
  ↓
응답 → 출력

로컬 K8s — Minikube vs Kind vs k3d

Minikube — 가장 일반적

brew install minikube
minikube start --driver=docker
kubectl cluster-info

VM 기반. 표준 K8s.

Kind — 가벼움

brew install kind
kind create cluster

Docker 컨테이너 안에 K8s. 매우 빠름·CI 환경 좋음.

k3d — k3s 기반

brew install k3d
k3d cluster create

경량 K8s (k3s) 기반. 엣지·IoT용.

여기서 시험 함정이 하나 있어요. 로컬 환경마다 동작 미세 차이. Minikube = 표준, Kind = 빠름, k3d = 경량. 학습 = Minikube 권장.

첫 클러스터 띄우기

minikube start
kubectl get nodes
# NAME       STATUS   ROLES           AGE   VERSION
# minikube   Ready    control-plane   1m    v1.28.x

# 첫 Pod
kubectl run nginx --image=nginx
kubectl get pods
# NAME    READY   STATUS    RESTARTS   AGE
# nginx   1/1     Running   0          10s

# 접속 확인
kubectl port-forward nginx 8080:80
# http://localhost:8080 접속

API Object — 모든 것은 객체

K8s의 모든 리소스 = API 객체:

종류	의미
Pod	가장 작은 배포 단위
Deployment	Pod 묶음 + 롤링 업데이트
Service	Pod 접근 진입점
ConfigMap / Secret	설정·민감 정보
Volume	스토리지
Namespace	격리 단위

YAML로 정의:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: nginx
      image: nginx:1.25

apply:

kubectl apply -f my-pod.yaml

시험 직전 한 번 더 — 자주 헷갈리는 함정 모음

여기까지가 1편의 핵심입니다. 시험 직전 또는 실무에서 헷갈릴 때 다시 펼쳐 볼 수 있게 압축 노트로 마무리할게요.

• K8s = 컨테이너 오케스트레이션 표준
• Desired State 시스템 — 선언형, 명령형 X
• 자가 치유·수평 확장·롤링 업데이트·서비스 디스커버리·로드 밸런싱·자원 관리
• Control Plane (본사) = kube-apiserver / etcd / kube-scheduler / controller-manager
• kube-apiserver = 모든 통신의 유일 입구
• etcd = 클러스터 상태 DB (Raft 합의)
• etcd 손실 = 클러스터 손실 → 백업·HA 필수
• kube-scheduler = Pod 배치 결정
• controller-manager = 여러 컨트롤러, Reconciliation Loop
• Reconciliation Loop = K8s 심장
• Worker Node (현장) = kubelet / kube-proxy / Container Runtime
• kubelet = 노드 에이전트
• kube-proxy = Service 라우팅
• kube-proxy ≠ CNI (Pod 네트워크)
• Container Runtime — containerd / CRI-O (1.24+, Docker 직접 지원 X)
• kubectl = API Server와 HTTPS 통신
• 로컬 — Minikube (표준) / Kind (Docker 안, 빠름) / k3d (경량)
• API Object — Pod·Deployment·Service·ConfigMap·Secret·Volume·Namespace
• YAML 선언 → kubectl apply -f

시리즈 다른 편

• 1편 — 아키텍처·Control Plane (현재 글)
• 2편 — Pod
• 3편 — Workloads
• 4편 — Services·Networking
• 5편 — ConfigMap·Secret
• 6편 — Storage
• 7편 — Scaling·Scheduling
• 8편 — Security
• 9편 — Helm
• 10편 — 실전 (매니지드·GitOps·Observability)

공식 문서: Kubernetes Documentation / K8s Components 에서 더 깊이.

다음 글(2편)에서는 Pod — K8s의 가장 작은 단위, 컨테이너와의 관계, Pod 생명주기, 멀티 컨테이너 패턴까지 풀어 갑니다.