Kubernetes & Cluster Orchestration

1. Overview

컨테이너 오케스트레이션 및 쿠버네티스(Container Orchestration & Kubernetes, COK)는 개별적으로 굴러가는 수많은 컨테이너들을 하나의 거대한 '지능형 기계 클러스터'로 묶어, 하드웨어 장애에도 굴하지 않고 24시간 서비스를 지속하게 만드는 분산 운영의 뇌입니다.

학습자는 단순한 배포를 넘어, 원하는 상태(Desired State)를 선언하면 시스템이 물리적으로 그 상태를 맞춰가는 **선언적 제어(Declarative Control)**의 수리적 사상을 배웁니다. 특히, 컨테이너 운영의 표준이 된 쿠버네티스의 구성 요소인 제어 평면(Control Plane)과 데이터 평면(Worker Nodes) 사이의 통신 물리학, 그리고 스케줄러가 가장 여유로운 서버를 육안이 아닌 수치로 찾아내는 기제에 대해 익힙니다. 이를 통해 '누가 서버를 껐니?'라는 질문 대신 "쿠버네티스가 알아서 살려놓았다"라고 말하는 하이엔드 자가 치유 인프라 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Declarative Resource Management: YAML/JSON 기반의 리소스 정의와 Reconciliation Loop
• Control Plane Architecture: API Server, etcd, Scheduler, Controller Manager의 물리적 협업
• Kubernetes Object Models: Pod, Service, ReplicaSet, Deployment의 기능과 관계 물리학
• Traffic Routing Physiology: Kube-proxy와 가상 서비스 IP($ClusterIP$)를 통한 통신 중개
• Self-healing Mechanics: Liveness/Readiness 프로브를 이용한 하드웨어 상태 복구

Out-of-Scope

• 퍼블릭 클라우드(EKS, GKE)의 콘솔 조작 GUI 상세 (인프라 조립 영역으로 위임)
• 서비스 메시(Istio 등)의 고도화된 트래픽 제어 (07-06-04 영역에서 전담)

Boundaries

• COK vs. CDM: 도커(07-06-02)가 '하나의 상자를 만드는 법'이라면, COK는 '수만 개의 상자를 산더미처럼 쌓고 관리하는 법'으로서 구분합니다.

3. Counterexample

• 단순히 "Kubectl 명령어 쓰기"라 설명하는 것은 COK 학습이 아닙니다. 왜 etcd가 전체 클러스터의 '단일 진실 저장소(SSOT)'로서 분산 합의(Raft)를 수행해야 하는지 수리 증명할 수 있어야 하며, 스케줄러가 노드의 CPU/RAM 파편화($Fragmentation$)를 막기 위해 어떤 수리적 가중치 알고리즘을 사용하는지 논증하지 못한다면 오케스트레이션의 핵심 실력을 갖추지 못한 것입니다.

4. Prerequisites

• Containerization & Docker Mechanics (Basic): 이미지 생성 및 컨테이너 격리 이해가 필수입니다. (07-06-02 CDM)
• Consensus Algorithms & Distributed Log (Recommended): Raft 혹은 합의 알고리즘 이해가 권장됩니다. (07-02-02 CAD)

5. Learning Map

1. The State Master: 내가 원하는 인프라의 청사진(Desired State)을 수리적으로 정의합니다.
2. The Watchman: 현재 하드웨어 상태와 청사진의 간극(Gap)을 무한히 감시하는 루프를 가동합니다.
3. Smart Placement: 비어있는 하드웨어 구석을 찾아 컨테이너를 물리적으로 밀어 넣는 수순을 익힙니다.
4. Infinite Uptime: 서버가 죽어도 1초 만에 유령처럼 다른 노드에서 부활하는 자가 치유 공학을 완성합니다.

6. Learning Topics

Basic

Core: 쿠버네티스 아키텍처와 객체 정의 (K8s Foundations)

• Why to Learn: 클러스터 통제의 전체 구조를 파악해 장애 지점을 물리적으로 정확히 짚기 위해서입니다.
• What to Learn:
  • Master vs Worker: 명령을 내리는 뇌와 명령을 수행하는 팔다리의 하드웨어 분리
  • API Server: 클러스터의 모든 소통이 통과하는 유일한 물리 관문
  • Pod: 컨테이너 한 개 이상이 모여 IP와 볼륨을 공유하는 최소 물리 단위
• How to Learn:
  • YAML 파일을 통해 'Pod 3개 띄우기'를 선언하고, 실제 하드웨어 노드들에 어떻게 뿌려지는지 관찰 실습
  • 개별 객체의 상태 값이 etcd에 수치로 저장되는 과정 분석
• Implement: 서비스를 정의하고 팟에 연결하는 기초 Service 명세서

Recommended

Core: 선언적 제어와 화해 루프 (Reconciliation Loop)

• Why to Learn: 사람이 직접 개입하지 않아도 시스템이 스스로 정상을 유지하게 만들기 위함입니다.
• What to Learn:
  • Control Loops: "지켜보고, 비교하고, 반영하라"는 수리적 알고리즘
  • Controller Manager: 노드, 레플리카, 엔드포인트 등을 관리하는 수십 개의 물리 루프
  • Eventual Convergence: 결국엔 내가 원한 상태로 수렴(Converge)하는 시스템의 성질
• How to Learn:
  • 실행 중인 Pod 하나를 강제로 삭제했을 때, 컨트롤러가 이를 인지하고 다시 띄우는 물리적 시간 지연 측정 실습
  • 리소스 할당량($Limits$)이 실제 하드웨어 자원을 어떻게 묶어두는지 수리 분석
• Implement: 특정 조건을 감시하다가 위반 시 알림을 보내는 가상 CustomController 로직

Practical

Core: 서비스 탐색과 트래픽 제어 (K8s Networking)

• Why to Learn: 유동적으로 변하는 Pod들의 IP 속보 속에서 끊김 없는 물리 통신을 하기 위해서입니다.
• What to Learn:
  • ClusterIP: 내부 POD들이 서로를 찾기 위한 가상 하드웨어 접점
  • Kube-proxy: IP 테이블을 조작하여 패킷을 분산시키는 하부 물리학
  • DNS Service Discovery: 이름을 부르면 IP를 뱉어내는 매핑 수리 장치
• How to Learn:
  • Pod가 재생성되어 IP가 바뀌어도 'Service' 이름을 통한 통신이 성공함을 물리 로그로 확인 실습
  • iptables 규칙이 클러스터 내의 수천 개 노드에 전파되는 시간 산출
• Implement: 외부 트래픽을 내부 서비스로 유도하는 LoadBalancer 타입 서비스 구성

Advanced

Core: 고가용성 클러스터와 쿼럼 (HA Control Plane)

• Why to Learn: 오케스트레이터 자체가 죽었을 때 발생하는 전체 인프라 마비를 물리적으로 방어하기 위함입니다.
• What to Learn:
  • HA Master: 홀수 개의 마스터 노드를 구성해야 하는 수리적 필연성
  • etcd Clustering: 분산 DB의 데이터 정합성을 위한 쿼럼 물리학
  • Node Pressure: 하드웨어 리소스 부족 시 우선순위(Priority)에 따른 POD 축축출(Eviction) 기제
• How to Learn:
  • 3대의 마스터 노드 중 한 대를 껐을 때 클러스터의 쓰기 명령($kubectl apply$)이 여전히 성공하는지 검증 실습
  • etcd의 응답 지연이 하드웨어 확장성($Scalability$)에 미치는 파괴적 영향 분석
• Implement: 노드 상태를 집계하고 임계점 도달 시 POD를 다른 노드로 이사시키는 EvictionStrategy 기획

7. Terminology

8. References

Primary

• [P2] SWEBOK v4.0 - Software Construction / Runtime Efficiency (Resource management) — Hardware context.
• [P5] SFIA v9 - IT Infrastructure (Infrastructure build and configuration / High-availability) — Competency context.

Secondary

• [Kubernetes up and Running] Brendan Burns et al. — The definitive introduction.
• [The Kubernetes Book] Nigel Poulton — Practical guide to orchestration.

Industry

• [Kubernetes Documentation: Components of Kubernetes] — Official architectural map.
• [Google Cloud: GKE Best Practices] — Production-grade K8s operations.

9. Final Checklist

Primary

• '모놀리스' 인프라를 '쿠버네티스'로 옮겼을 때, 하드웨어 관리 포인트가 '개별 장비'에서 '추상화된 리소스'로 어떻게 물리적으로 바뀌는지 설명 가능한가? (P5)
• '선언적 리소스 관리' 방식이 장애 시 시스템의 '복구 속도($RTO$)'를 어떻게 수리적으로 단축시키는지 기술할 수 있는 가? (P5)

Secondary

• 'etcd'의 합의 알고리즘 실패 상황에서 클러스터의 '읽기'와 '쓰기' 작업이 각각 물리적으로 어떤 제약을 받는지 소통 가능한가?
• **팟(Pod)**이 동일 노드 내의 다른 컨테이너와 '네트워크 네임스페이스'를 공유함으로써 얻는 물리적 통신 이점을 논증할 수 있는 가?

Industry

• 서비스 운영 중 '노드 수'를 늘리지 않고 'POD'만 늘렸을 때 발생하는 클러스터 '포화도(Saturation)' 임계점을 수치로 제안할 수 있는 가? (SFIA)
• '헬름(Helm)' 같은 패키지 도구가 분산 리소스의 물리적 배포 선후 관계를 어떻게 수리적으로 제어하는지 분석할 수 있는 가?