Kubernetes & Cluster Orchestration

1. Overview

쿠버네티스와 클러스터 오케스트레이션(Kubernetes & Cluster Orchestration)은 컨테이너 수십 개를 띄워놓고 "이거 죽으면 어떡하지?"라며 벌벌 떨던 인간의 공포를 종식시키고, 수천 대의 서버를 마치 거대한 컴퓨터 1대처럼 통제하는 선언적(Declarative) 인프라의 제왕을 해부합니다.

학습자는 엔지니어가 직접 스크립트로 서버를 고치는 '명령형(Imperative)' 사고방식을 버리고, "나는 3개의 복제본을 원한다"고 소원(Desired State)만 빌면 쿠버네티스가 알아서 현실을 일치시켜 주는(Reconciliation) **컨트롤 플레인(Control Plane)**의 철학을 뜯어봅니다. 나아가 배를 의미하는 Pod부터, 이를 복제하는 ReplicaSet, 무중단 배포를 관장하는 Deployment로 이어지는 K8s 리소스의 진화 과정을 장악합니다. 마지막으로, 언제든 죽을 수 있는 Pod의 휘발성 IP 대신, 영구적인 간판을 달아주는 Service 메커니즘을 통해 쿠버네티스 네트워킹의 마법을 꿰뚫는 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Declarative vs Imperative: 선언적 상태(Desired State)와 제어 루프(Control Loop/Reconciliation).
• K8s Architecture: Control Plane (API Server, etcd, Scheduler) vs Data Plane (Kubelet, Kube-proxy).
• Core Workloads: Pod (최소 단위), ReplicaSet (복제), Deployment (배포 및 롤백).
• Networking Basics: ClusterIP (내부 통신), NodePort (외부 노출), LoadBalancer.

Out-of-Scope

• Service Mesh & Ingress: L7 라우팅 및 트래픽 세밀 제어 $\rightarrow$ 07-06-04 Service Mesh & Ingress 영역.
• StatefulSet & PV/PVC: 쿠버네티스 위에서 DB 상태 관리 $\rightarrow$ 스토리지 아키텍처 영역으로 위임 (본 문서는 Stateless 워크로드에 집중).

Boundaries

• Docker vs Kubernetes: 도커는 "컨테이너 1개를 예쁘게 포장하는 상자"입니다. 쿠버네티스는 "이 상자 10,000개를 수백 대의 화물선(Node)에 빈틈없이 구겨 넣고, 상자가 부서지면 0.1초 만에 새 상자를 찍어내는 크레인 시스템"입니다. 도커만 안다고 해서 분산 시스템을 구축할 수 없으며, 쿠버네티스는 도커를 부품으로 쓸 뿐(현재는 containerd) 전혀 차원이 다른 오케스트레이션 도구임을 명확히 구분합니다.

3. Counterexample

• 명령형(Imperative) 좀비 스크립트: 서버 A가 죽었습니다. 엔지니어가 쉘 스크립트를 짜서 "서버 A가 죽으면 서버 B에서 docker run을 실행해라"라고 명령형으로 인프라를 통제합니다. 만약 서버 B마저 죽으면? 스크립트는 에러를 뿜고 시스템은 붕괴합니다. 쿠버네티스는 "무슨 일이 있어도 3개를 유지해"라고 선언(YAML)만 하면, A, B가 죽든 데이터센터 절반이 날아가든 끝까지 남은 노드를 찾아 3개를 채워 넣는 끈질긴 제어 루프(Reconciliation)를 돕습니다. 이를 무시하고 절차적 스크립트에 의존하는 것은 쿠버네티스 철학의 완벽한 몰각입니다.
• Pod IP 맹신 (The Ephemeral Trap): A Pod가 B Pod에게 API를 쏘기 위해 10.0.1.5라는 B의 IP를 소스 코드에 하드코딩했습니다. 다음 날 B Pod가 에러가 나서 죽고 새로 태어났습니다. IP가 10.0.1.9로 바뀌었습니다. A는 영원히 B를 찾지 못하고 크래시가 납니다. 쿠버네티스의 Pod는 '가축(Cattle)'처럼 언제든 죽고 IP가 바뀌는 소모품임을 망각하고, 영구적인 DNS 간판 역할을 하는 Service 객체로 묶어(Label Selector) 통신하지 않은 네트워킹의 기본기 부족입니다.

4. Prerequisites

• 컨테이너 격리 원리 (Basic): 도커와 Linux Namespace. (07-06-02 Containerization)
• 부하 분산 메커니즘 (Basic): 로드 밸런싱의 기본. (07-03-03 Load Balancing)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 선언형 인프라의 마법 (The Declarative Mindset)

• Why to Learn: 서버가 죽을 때마다 알람을 받고 수동으로 서버를 켜던 야경꾼의 삶을 청산하고, 시스템이 스스로 치유(Self-healing)하도록 만들기 위함입니다.
• What to Learn:
  • Concepts: Imperative(명령형) vs Declarative(선언형), Desired State (희망 상태), Current State (현재 상태), Reconciliation Loop (조정 루프).
  • Skills: YAML 파일을 통한 인프라의 Desired State 정의.
• How to Learn:
  • 1단계: 명령형의 파국: "온도 1도 올려, 온도 1도 내려." 밖이 갑자기 추워지면 사람이 직접 에어컨 온도를 계속 조절해야 합니다. 인간이 명령(명령형)하지 않으면 시스템은 환경 변화에 대처하지 못함을 해부합니다.
  • 2단계: 선언형(Desired State): "실내 온도 24도 유지해."(YAML) 밖이 영하 10도든 영상 40도든 에어컨(K8s)이 알아서 난방을 켜든 냉방을 켜든 현재 상태를 희망 상태로 일치(Reconciliation)시킵니다. 노드가 통째로 날아갔을 때 쿠버네티스가 인간의 개입 없이 Pod를 다른 노드에 살려내는 기적을 뜯어봅니다.
• Implement: Reconciliation 루프 시뮬레이터. 파이썬 while True 루프. desired_state = 3 (Pod 3개). 1초마다 랜덤하게 current_state를 1~2개로 깎아내림(장애 모사). 루프 안에서 current_state < desired_state를 감지하여 3개로 복구(Heal)시키는 Reconcile 로그를 무한 출력하는 데모.

Recommended

Core Topic 02: 뇌와 근육의 완벽한 분리 (Control Plane vs Data Plane)

• Why to Learn: 쿠버네티스가 도대체 어떻게 수천 대의 물리 서버를 하나의 거대한 시스템처럼 통제하는지, 그 두뇌와 말단 신경계의 구조를 꿰뚫기 위함입니다.
• What to Learn:
  • Concepts: Control Plane (API Server, etcd, Scheduler, Controller Manager), Data Plane / Worker Node (Kubelet, Kube-proxy, Container Runtime).
  • Skills: 컴포넌트 간 통신 흐름(API Server 중심)을 이해하여 노드 다운 시 복구 시나리오 추적.
• How to Learn:
  • 1단계: 뇌 (Control Plane): etcd는 쿠버네티스의 모든 기억(상태)이 저장되는 유일한 뇌하수체입니다. API Server는 외부의 모든 명령을 받는 유일한 입(Mouth)이자 방어막입니다. Scheduler는 새 Pod가 생길 때 "어느 노드가 램이 제일 많이 남았지?"를 계산하여 배정하는 두뇌의 역할을 해부합니다.
  • 2단계: 근육 (Worker Node): 각 물리 서버마다 Kubelet이라는 스파이(에이전트)가 심어져 있습니다. 뇌(API Server)가 "거기 Pod 하나 띄워"라고 명령하면, Kubelet이 도커(Runtime)를 시켜 컨테이너를 올리고, 살아있는지 계속 찔러보며(Health Check) 뇌에 보고하는 말단 신경계의 역학을 뜯어봅니다.
• Implement: API Server 중심의 아키텍처 다이어그램 그리기(CLI). 유저가 kubectl apply를 치면 $\rightarrow$ API Server가 인증 후 $\rightarrow$ etcd에 기록 $\rightarrow$ Controller가 변화 감지 후 Pod 객체 생성 $\rightarrow$ Scheduler가 노드 할당 $\rightarrow$ Kubelet이 컨테이너 실행으로 이어지는 6단계 텍스트 릴레이 시뮬레이션.

Practical

Core Topic 03: 가축의 진화, Pod와 Deployment (Pod to Deployment)

• Why to Learn: 컨테이너 1개를 덜렁 띄우는 나약함을 벗어나, 수십 개의 복제본을 유지하고 버전 업데이트 시 다운타임 0초(Zero-downtime)를 달성하는 K8s 워크로드를 장악하기 위함입니다.
• What to Learn:
  • Concepts: Pod (고래의 배), ReplicaSet (복제 컨트롤러), Deployment (롤링 업데이트/롤백), Labels & Selectors (견출지).
  • Skills: Deployment YAML을 작성하여 Rolling Update(무중단 배포)와 Rollback 전략 실행.
• How to Learn:
  • 1단계: 가장 나약한 세포, Pod: K8s는 컨테이너를 직접 다루지 않고 'Pod'라는 껍데기로 감쌉니다. Pod 1개를 띄우면, 죽었을 때 다시 안 살아납니다(휘발성). 이를 ReplicaSet으로 감싸면, "죽으면 반드시 살려낸다"는 불사(Immortality)의 속성을 부여받음을 해부합니다.
  • 2단계: 진화의 끝, Deployment: V1 코드를 V2로 업데이트해야 합니다. ReplicaSet만으로는 무중단 배포가 어렵습니다. 이 위에 Deployment를 덮어씌웁니다. V2 Pod를 하나 띄우고(Ready), V1 Pod를 하나 죽이는 행위를 반복(Rolling Update)하여 유저가 배포를 전혀 눈치채지 못하게 하는 궁극의 릴리즈 전략을 뜯어봅니다.
• Implement: 롤링 업데이트 시각화 스크립트. [V1, V1, V1] 상태에서 Deployment 버전 업 트리거. [V1, V1, V1, V2(new)] $\rightarrow$ [V1, V1, V2] $\rightarrow$ [V1, V2, V2] $\rightarrow$ [V2, V2, V2]로 서서히 교체되는 과정을 0.5초 간격 터미널 출력으로 보여주는 애니메이션.

Advanced

Core Topic 04: 사라진 IP를 찾아서, 서비스와 네트워킹 (K8s Networking)

• Why to Learn: K8s 환경에서 IP는 환상(Illusion)에 불과함을 깨닫고, 100번 죽어 IP가 100번 바뀌어도 클라이언트가 항상 똑같은 간판(Service)으로 접근할 수 있게 통신망을 세우기 위함입니다.
• What to Learn:
  • Concepts: K8s Service, ClusterIP (클러스터 내부용), NodePort (외부 노출용), LoadBalancer, Kube-proxy, iptables.
  • Skills: Label Selector를 통한 Service-Pod 맵핑 및 Cluster 내부 도메인(DNS) 기반 통신 구축.
• How to Learn:
  • 1단계: 휘발성 IP의 공포: '결제 Pod'가 3개 떠 있습니다(IP: 10.1, 10.2, 10.3). '주문 Pod'가 여기에 API를 쏘려면 이 IP들을 알아야 하는데, 5분 뒤에 Pod들이 스케일링되어 IP가 10.4, 10.5로 다 바뀝니다. 직접 통신의 참사를 해부합니다.
  • 2단계: 영구적인 간판 (Service): 쿠버네티스는 Service라는 가상의 객체(고정 IP와 DNS 보유)를 허공에 띄웁니다. 주문 Pod는 결제 Pod의 IP를 알 필요 없이, 그냥 http://payment-service라는 영구적인 이름만 찌르면 됩니다. 뒷단에서 kube-proxy가 이 트래픽을 가로채서 현재 살아있는 10.4, 10.5 중 하나로 로드밸런싱(Load Balancing) 해주는 마법을 뜯어봅니다.
• Implement: Label Selector 매칭 게임. Pod A(app=web, tier=frontend), Pod B(app=web, tier=backend). Service 객체의 Selector를 app=web으로 설정했을 때 A, B 모두 트래픽이 꽂히고, Selector에 tier=frontend를 추가하는 순간 iptables 규칙이 B를 차단하고 A에게만 트래픽을 보내는 논리적 라우팅 필터링 데모.

7. Terminology

8. References

Primary

• [P1] CS2023 - Software Engineering (SE) - Cloud Computing and Orchestration
• [P5] SFIA - IT Infrastructure (ITOP) - Orchestration and Automation

Secondary

• [Kubernetes in Action] Marko Luksa - Kubernetes Architecture and Core Concepts
• [Kubernetes Patterns] Bilgin Ibryam - Declarative Deployment and Service Discovery

Industry

• [Kubernetes Official Docs] - Kubernetes Components and Objects
• [Google Cloud Architecture Center] - Best practices for running Kubernetes

9. Final Checklist

Primary

• 쉘 스크립트로 장애 시 재시작을 구현하는 명령형(Imperative) 방식의 한계를 지적하고, 쿠버네티스의 선언형(Declarative) 제어 루프(Reconciliation)가 무한한 자가 치유(Self-healing)를 이루는 원리를 설명할 수 있는가?
• 쿠버네티스 클러스터에서 뇌 역할을 하는 컨트롤 플레인(API Server, etcd)과 근육 역할을 하는 데이터 플레인(Kubelet, Worker Node) 간의 역할 분담 및 통신 흐름을 아키텍처로 그릴 수 있는가?

Secondary

• 컨테이너를 직접 실행하지 않고 Pod라는 껍데기로 감싸는 이유를 설명하고, ReplicaSet을 거쳐 Deployment로 진화하며 롤링 업데이트(Rolling Update)와 무중단 배포가 달성되는 워크로드 계층을 논증할 수 있는가?
• "왜 쿠버네티스에서 Pod의 IP를 직접 하드코딩해서 통신하면 안 되는가?"라는 질문에, Pod의 휘발성(Ephemeral)과 이를 극복하는 Service(ClusterIP) 및 Label Selector의 매핑 역학으로 대답할 수 있는가?

Industry

• 데이터베이스(MySQL)와 같은 상태를 가진(Stateful) 애플리케이션을 K8s에 올릴 때, 일반적인 Deployment 대신 StatefulSet과 Persistent Volume(PV/PVC)을 붙여야만 데이터 증발과 스플릿 브레인(Split Brain)을 막을 수 있음을 평가할 수 있는가?
• 외부의 트래픽을 클러스터 내부의 Service로 끌고 들어오기 위해 NodePort를 열어두는 구식 방식의 포트 낭비를 지적하고, L7 라우팅을 담당하는 Ingress Controller와의 연동 필요성을 설계 관점에서 식별할 수 있는가?