Kubernetes 아키텍처 완전 정복 — Master/Worker 노드 구조

쿠버네티스가 어떤 식으로 컨테이너를 자동으로 띄우고, 죽으면 살리고, 트래픽을 흘려보내는지를 한 장의 지도로 그려본다.

들어가며

쿠버네티스(Kubernetes, K8s)를 공부할 때 가장 처음 부딪히는 벽은 "도대체 이 많은 컴포넌트가 왜 필요하고, 누가 누구를 호출하는가"이다. kubectl apply -f deployment.yaml 한 줄을 입력했을 때 내부에서는 API Server → etcd → Controller → Scheduler → Kubelet 으로 이어지는 정교한 협업이 일어난다.

이 글에서는 Kubernetes의 마스터-노드 구조와 각 컴포넌트의 역할을 정리하고, 마지막에는 "Pod 한 개가 생성되는 전체 흐름"을 단계별로 따라가 본다. Kubernetes 심화 시리즈의 첫 번째 글로, 이후 kubectl 명령어, YAML 작성법, 네트워킹, EKS 등으로 이어진다.

---

1. 왜 Kubernetes가 필요한가

쿠버네티스는 컨테이너를 쉽고 빠르게 배포·확장하고 운영을 자동화해 주는 오픈소스 플랫폼이다. 보통 k8s 또는 Kube 라고 줄여 부른다.

Kubernetes는 단순히 "컨테이너 오케스트레이터"가 아니라, "내가 원하는 상태(Desired State)"를 선언하면 클러스터를 거기에 맞춰주는 시스템이라고 생각하는 편이 이해가 빠르다.

핵심 특징 한눈에 보기

항목	설명
다양한 배포 방식	Deployment, StatefulSets, DaemonSet, Job, CronJob 등
Ingress	하나의 로드밸런서로 여러 서비스를 도메인·경로 기반 라우팅
Auto Scaling	HPA(Pod 수), VPA(Pod 리소스), CA(Node 수) 3종
Namespace & Label	클러스터를 논리적으로 분할 + 유연한 리소스 관리
RBAC	사용자별 CRUD 권한 부여 (AWS IAM 연동도 가능)
CRD	K8s 기본 기능 외 사용자 정의 리소스 확장
Federation/Multi-Cluster	여러 클라우드의 클러스터를 하나로 묶어서 사용

이미지 출처: CNCF Cloud Native Landscape (Notion 학습노트). Tistory 업로드 시 직접 첨부 권장.

서비스 메시(Istio), CI(Tekton, Spinnaker), 서버리스(Knative), 머신러닝(Kubeflow) 등 클라우드 네이티브 생태계 대부분이 Kubernetes 위에서 돌아간다. 그만큼 한 번 익혀두면 응용 범위가 넓다.

---

2. 핵심 개념 — Desired State

쿠버네티스에서 가장 중요한 단어는 단연 "원하는 상태(Desired State)" 이다.

Desired State 개념도 — 현재 상태와 원하는 상태의 차이를 컨트롤러가 메운다

K8s 의 모든 동작은 결국 이 한 줄로 요약된다.

현재 상태(Current State)를 모니터링하다가, 관리자가 선언한 원하는 상태(Desired State)와 다르면 메우기 위해 작업을 수행한다.

그래서 Kubernetes 사용자는 "무엇을 어떻게 실행하라"가 아니라 "이런 상태가 유지되었으면 좋겠다" 라고 선언한다.

"80 포트를 오픈한 nginx 컨테이너를 1개 유지해줘"

이것이 곧 YAML 파일이고, 컨테이너 운영의 명령형(Imperative) 패러다임이 선언형(Declarative) 패러다임으로 넘어가는 지점이다.

---

3. Kubernetes Object — 상태 관리의 단위

K8s는 상태를 관리하기 위한 대상을 Object로 정의한다. 기본적으로 수십 가지 오브젝트를 제공하고, CRD로 새로 추가하기도 쉽다.

자주 쓰는 핵심 오브젝트

오브젝트	역할
Pod	가장 작은 배포 단위. 1개 이상의 컨테이너 + 스토리지 + 네트워크 묶음
ReplicaSet	Pod 개수를 일정하게 유지하는 복제 관리자
Deployment	ReplicaSet을 통해 무중단 배포 등 다양한 전략 제공
Service	Pod에 안정적인 IP/DNS 제공, 내부 로드밸런서 + 서비스 디스커버리 역할
Volume	호스트 디렉터리 또는 EBS 등 외부 스토리지 마운트

Pod 구조 — 컨테이너 + 스토리지 + 네트워크의 묶음

Object Spec — YAML

오브젝트의 명세는 YAML(또는 JSON)로 정의한다.

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
    - name: busybox
      image: busybox:1.25

이 YAML 한 장이 곧 "원하는 상태"이며, REST API로 클러스터에 전달된다.

---

4. 마스터-노드 아키텍처 한눈에 보기

쿠버네티스는 클러스터 전체를 관리하는 마스터(Master, Control Plane) 와 컨테이너가 실제로 배포되는 노드(Node, Worker) 로 구성된다.

Kubernetes 마스터-노드 구조도

4-1. Master — 클러스터의 두뇌

• 모든 명령은 마스터의 API 서버를 호출한다.
• 노드는 마스터와 통신하며 필요한 작업을 수행한다.
• 특정 노드의 컨테이너에 명령하거나 로그를 보고 싶을 때도, 노드에 직접 접속하지 않는다. 마스터에게 명령 → 마스터가 노드에 접속 → 결과를 다시 응답 하는 구조다.
• 다양한 모듈이 기능별로 분리(API Server, etcd, Scheduler, Controller, Cloud Controller)되어 있어 확장성이 높다.
• 마스터가 다운되면 클러스터 운영이 불가능하므로 이중화 구성이 필수.
• AWS EKS, GKE, AKS 같은 관리형 서비스에서는 클라우드 사업자가 마스터를 직접 관리한다.

4-2. Node — 컨테이너가 돌아가는 곳

• 마스터와 통신하며 Pod를 생성하고, 네트워크·볼륨을 설정한다.
• 실제 컨테이너가 떠 있는 서버. 수백, 수천 대로 수평 확장이 가능하다.
• 라벨(Label)을 이용해 "GPU 특화 노드", "SSD 스토리지 노드" 같이 목적을 부여할 수 있다.

4-3. Kubectl — 마스터로 들어가는 입구

• API 서버는 JSON / protobuf 기반 HTTP 통신을 지원하지만 그대로 쓰면 불편하다.
• 그래서 kubectl 이라는 CLI 도구를 사용한다.

# 자주 쓰는 기본 명령
kubectl cluster-info     # 클러스터 정보 확인
kubectl get nodes        # 클러스터 내 모든 노드 조회
kubectl run hello-minikube --image=hello-minikube  # 앱 배포

---

5. Master 구성 요소 자세히 보기

Master 컴포넌트 구성도

kube-apiserver — 모든 요청의 관문

• 마스터의 핵심 모듈. kubectl, 내부 모듈 등 모든 요청을 처리한다.
• 권한을 체크하여 요청을 거부할 수 있다.
• 실제 하는 일은 매우 단순하다. etcd에 상태를 저장/조회 하는 것.
• 노드의 컨테이너 로그를 가져오거나 명령을 전달하는 디버거 역할도 수행한다.

etcd — 분산 Key-Value 저장소

• RAFT 알고리즘 기반 분산 KV 저장소. 안정성·속도가 뛰어나다.
• 클러스터의 모든 설정과 상태가 etcd에 저장된다.
• 다른 모듈은 stateless 하게 동작하기 때문에 etcd만 잘 백업해두면 클러스터를 언제든 복구할 수 있다.
• etcd는 오직 API 서버와만 통신한다. (다른 모든 모듈은 API 서버를 거쳐서만 etcd 데이터에 접근)
• watch 기능이 있어, 상태가 바뀌면 즉시 트리거가 가능하다.
• 참고로 k3s 같은 초경량 배포판은 etcd 대신 SQLite를 사용하기도 한다.

kube-scheduler — 어느 노드에 할당할까?

• "할당되지 않은 Pod"를 발견하면 적절한 노드에 배치한다.
• 필요한 자원, 라벨, Affinity 등 다양한 조건을 평가한다.

kube-controller-manager — 상태를 맞추는 일꾼

• Deployment, ReplicaSet, Pod 등 거의 모든 오브젝트의 상태를 관리한다.
• 오브젝트별로 분업화되어 있다. Deployment는 ReplicaSet을 만들고, ReplicaSet은 Pod를 만들고, Pod는 Scheduler가 노드에 배정 하는 식.

cloud-controller-manager — 클라우드 연동 모듈

• AWS, GCP, Azure 등 클라우드 사업자별로 특화된 모듈.
• 노드 추가/삭제, ELB 연결, EBS 볼륨 부착 같은 작업을 수행한다.
• 클라우드 업체가 인터페이스에 맞춰 구현하면 되기 때문에 확장성이 좋다.

---

6. Node 구성 요소 자세히 보기

Node 컴포넌트 구성도

kubelet — 노드의 에이전트

• 노드에 할당된 Pod의 생명 주기를 관리 한다.
• 컨테이너에 이상이 없는지 확인하면서 주기적으로 마스터에 상태를 보고한다.
• API 서버의 요청을 받아 컨테이너 로그를 전달하거나, 명령을 대신 실행하기도 한다.

kube-proxy — 노드의 네트워크 관리자

• kubelet이 Pod를 관리한다면, kube-proxy는 Pod로 들어오는 네트워크 트래픽을 관리한다.
• TCP/UDP/SCTP 스트림을 포워딩하고, 여러 Pod를 라운드로빈으로 묶어 서비스를 제공한다.
• 동작 방식은 시간이 지나면서 진화해 왔다.
1. userspace 모드: kube-proxy 자체가 프록시 서버처럼 동작
2. iptables 모드: iptables 규칙을 설정하여 커널이 직접 라우팅 (등록 규칙이 많아지면 성능 저하)
3. IPVS 모드: 최신 방식. 대규모 클러스터에서 더 빠르고 안정적

Container Runtime — 컨테이너 실행 엔진

• "컨테이너 = 도커"라고 생각해도 무방하지만, 쿠버네티스는 CRI(Container Runtime Interface) 를 구현한 다양한 런타임을 지원한다.
• 대표 런타임: containerd(사실상 표준), CRI-O, rkt.
• CRI 외에 CNI(Container Network Interface), CSI(Container Storage Interface) 까지 표준화되어 있어, 인터페이스만 구현하면 어떤 솔루션이든 끼울 수 있다.

---

7. Pod 한 개가 생성되는 전체 흐름

이제 모든 컴포넌트가 어떻게 협업하는지 한눈에 보자. 관리자가 ReplicaSet을 생성했을 때의 흐름이다.

ReplicaSet → Pod 생성 시퀀스

Step 1. kubectl

• 사용자가 ReplicaSet 명세를 YAML 로 정의하고 kubectl apply -f xxx.yaml 실행
• API 서버는 새로운 ReplicaSet 오브젝트를 etcd에 저장

Step 2. kube Controller (ReplicaSet Controller)

• ReplicaSet을 감시하다가 Label Selector 조건을 만족하는 Pod가 충분히 있는지 체크
• Pod가 부족하면 ReplicaSet의 Pod 템플릿을 참고해 새 Pod(미할당 상태) 를 생성 요청
• API 서버 → etcd 저장

Step 3. kube-scheduler

• "할당되지 않은(no assign) Pod" 가 있는지 체크
• 조건에 맞는 노드를 찾아 해당 Pod에 할당
• API 서버 → etcd 저장

Step 4. kubelet

• 자신의 노드에 할당되었지만 아직 생성되지 않은 Pod를 감지
• 명세를 확인해 컨테이너 런타임을 통해 실제 Pod 생성
• Pod 상태를 주기적으로 API 서버에 보고

핵심 포인트 — 모든 모듈은 서로 직접 통신하지 않는다

각 모듈은 서로를 알지 못한다. 오직 API 서버를 통해서만 상태를 공유한다. 이 구조 덕분에 모듈을 자유롭게 교체하거나 확장할 수 있고, 마스터의 일부가 죽어도 다른 모듈에 직접적인 영향을 주지 않는다.

같은 원리로 DaemonSet도 동작한다. DaemonSet Controller + Scheduler가 전체 노드에 Pod를 할당하면 각 노드의 kubelet이 자기 몫의 Pod를 만든다.

---

8. 정리 — 처음 입문자를 위한 한 장 요약

영역	컴포넌트	한 줄 역할
Master	kube-apiserver	모든 요청의 관문 + etcd 게이트웨이
Master	etcd	클러스터 상태의 단일 저장소
Master	kube-scheduler	미할당 Pod를 노드에 배치
Master	kube-controller-manager	오브젝트별 상태를 원하는 상태로 수렴
Master	cloud-controller-manager	클라우드 자원과 연동 (LB, Volume 등)
Node	kubelet	노드 위 Pod 생명 주기 관리 + 마스터 보고
Node	kube-proxy	Pod 네트워크 라우팅, Service 구현
Node	Container Runtime	실제 컨테이너 실행 (containerd, CRI-O 등)
Client	kubectl	사용자가 클러스터에 접근하는 CLI

마지막 한마디

쿠버네티스는 "선언된 상태를 향해 클러스터가 끊임없이 자가 치유(Self-healing)하는 시스템" 이다. 컴포넌트가 많아 보여도, 결국 모두 한 가지 일을 한다. etcd에 적힌 원하는 상태와 현재 상태의 차이를 메우는 것.

이 큰 그림 하나만 머릿속에 그려두면 다음 단계가 훨씬 쉬워진다.