← 목차
Week 2 · Phase 1 기초 다지기

K8s 아키텍처와
Control Plane

선언적(Declarative) 모델과 Master 5대 컴포넌트 — 그리고 1 Master + 2 Worker 클러스터를 직접 구축한다
학습 자료 · k8s-master-components · (참고) k8s-install.sh
산출물 · 동작하는 1 Master + 2 Worker 클러스터

학습 목표

이번 주에 반드시 체득할 4가지
  • 선언적 모델 — "무엇을 원하는가"를 선언하면 K8s가 알아서 맞춘다(Reconcile)
  • Master 5대 컴포넌트 — apiserver·etcd·scheduler·controller-manager·cloud-controller-manager의 역할을 설명한다
  • 클러스터 구축 — kubeadm으로 1 Master + 2 Worker를 직접 만든다
  • kubectl 기본 — context·kubeconfig 구조와 describe로 상태를 분석한다

선언적 모델 — 명령이 아니라 선언

K8s의 심장은 "원하는 상태(Desired State)"를 향한 끊임없는 조율
명령형 (X)

Imperative

  • "컨테이너를 지금 실행해"
  • 한 번의 동작, 상태 추적 없음
  • 죽으면 사람이 다시 살려야 함
  • → 규모가 커지면 관리 불가
선언형 (O)

Declarative

  • "Pod가 항상 3개 있어야 해"
  • 원하는 상태를 etcd에 기록
  • Controller가 현재≠원하는 상태면 자동 복구
  • → Self-Healing의 기반

Control Plane 5대 컴포넌트

모든 컴포넌트는 apiserver를 통해서만 etcd에 접근한다
MASTER NODE · CONTROL PLANE kube-apiserver 모든 요청의 진입점 · 인증/인가 유일하게 etcd와 직접 통신 etcd 분산 KV 저장소 · Source of Truth kube-scheduler Pod를 어느 노드에 둘지 결정 controller-manager 현재→원하는 상태로 조율(Reconcile) cloud-controller-manager 클라우드 제공자 연동(LB·볼륨)

공항으로 이해하는 Control Plane

각 컴포넌트를 공항 역할에 비유하면 직관적이다
  • kube-apiserver — 공항 안내 데스크: 모든 문의·요청이 반드시 거치는 창구
  • etcd — 운항 기록부: 클러스터의 모든 상태가 기록되는 유일한 원장
  • kube-scheduler — 게이트 배정 담당자: 새 Pod를 어떤 노드(게이트)에 붙일지 결정
  • controller-manager — 각 부서 관리자: 예정↔실제를 계속 비교하며 어긋나면 바로잡음
  • cloud-controller-manager — 외부 연결 담당: 클라우드 LB·스토리지 등 외부 서비스 연동

API 요청 처리 흐름

kubectl apply 한 번에 벌어지는 5단계
1 인증누구인가 2 인가권한 있나(RBAC) 3 Admission검증·변형 4 etcd 저장상태 영구 기록 5 Watch 알림scheduler·controller apiserver는 상태를 "직접 실행"하지 않는다 — etcd에 기록하고, 각 컨트롤러가 Watch로 받아 실제 상태를 맞춘다

라이브 실습 — 클러스터 구축 & 검증

kubeadm으로 직접 만들고 상태를 확인한다
# 실습 1: 클러스터 자동 설치 (1 Master + 2 Worker) $ chmod +x k8s-install.sh && ./k8s-install.sh # CNI: Antrea/Calico 선택 # 실습 2: 클러스터 상태 검증 $ kubectl get nodes -o wide $ kubectl get pods -n kube-system $ kubectl cluster-info # 실습 3: Control Plane을 Static Pod로 직접 확인 $ ls /etc/kubernetes/manifests/ $ sudo crictl ps | grep -E 'apiserver|etcd|scheduler|controller'

과제 & 토론

직접 깊이 파고들며 아키텍처를 몸에 익힌다
과제

제출 산출물

  • etcdctl로 /registry/pods/default 키 직접 조회
  • API Server 1분간 재시작 → 클러스터 동작 변화 관찰·기록
  • scheduler --v=4 로그로 Pod 배치 과정 추적
토론

생각해볼 질문

  • apiserver가 유일한 Single Source of Truth인 이유는?
  • etcd가 죽어도 클러스터가 즉시 멈추지 않는 이유는?(kubelet)
  • Scheduler와 Controller Manager의 책임 분리는?

체크리스트 & 다음 주

이걸 할 수 있으면 Week 2 완료
  • 5대 컴포넌트(apiserver·etcd·scheduler·controller-manager·cloud-controller-manager)의 역할을 설명할 수 있다
  • kubeadm으로 클러스터를 만들고 노드를 join할 수 있다
  • kubeconfig / context 구조를 이해한다
  • kubectl describe로 객체 상태를 분석할 수 있다
→
다음 주(Week 3) — Worker Node 컴포넌트와 Pod·Deployment 핵심 오브젝트, 3-tier 앱 배포와 롤링 업데이트·Probe를 다룹니다.