[책리뷰] Kubernetes Patterns

개요

2025년 8월부터 2026년 2월까지 진행한 쿠버네티스 스터디에서 《Kubernetes Patterns, 2nd Edition》을 교재로 사용했다. 이 책은 쿠버네티스 환경에서 반복적으로 등장하는 배포, 운영, 확장 문제를 패턴 형태로 정리한다.

https://www.oreilly.com/library/view/kubernetes-patterns-2nd/9781098131678/

Kubernetes Patterns, 2nd Edition

목차

1장 소개

[Part I] Foundational Patterns
2장 Predictable Demands
3장 Declarative Deployment
4장 Health Probe
5장 Managed Lifecycle
6장 Automated Placement

[Part II] Behavioral Patterns
7장 Job
8장 Cron Job
9장 Sidecar
10장 Adapter
11장 Ambassador

[Part III] Structural Patterns
12장 Init Container
13장 Shared Resource
14장 Specific Pod Patterns

[Part IV] Configuration Patterns
15장 Configuration
16장 Configuration Template
17장 External Configuration

[Part V] Security Patterns
18장 Identity
19장 Access
20장 Service Identity

[Part VI] Advanced Patterns
21장 Operator
22장 Elasticity (Autoscaling)
23장 Controller & Extensions
24장 Image Builder

주요 개념

1. 기본 패턴

선언적 배포(Declarative Deployment)
쿠버네티스에서는 “이렇게 실행하라”가 아니라 “이 상태가 되길 원한다”를 선언한다. 시스템은 이 선언을 기준으로 현재 상태를 지속적으로 맞추며, 장애나 재시작이 발생해도 사람이 개입하지 않아도 자동으로 원래 상태로 복구된다.

정상 상태 점검(Desired State Check)
실행 중인 상태가 선언한 내용과 달라졌는지를 계속 감시한다. 파드가 중단되거나 준비되지 않은 상태가 되면 이를 감지해 재시작하거나 다시 생성한다. 쿠버네티스의 자동 복구 특성은 이 메커니즘을 기반으로 한다.

수명주기 관리(Lifecycle Management)
애플리케이션이 언제 시작되고 언제 종료되며 어떻게 업데이트되는지를 플랫폼 수준에서 관리한다. 개발자는 신호 처리와 종료 시점만 맞추면 되고, 무중단 배포와 예측 가능한 종료는 쿠버네티스가 책임진다.

자동 배치와 스케줄링(Scheduling & Placement)
파드를 아무 노드에나 배치하지 않고 리소스 사용량, 노드 특성, 분산 조건을 기준으로 적절한 위치에 배치한다. 이는 안정성, 비용, 성능을 함께 고려하기 위한 기본 수단이다.

2. 행동 패턴

배치 잡 / 주기적 잡(Job / CronJob)
한 번 실행하고 끝나는 작업이나 정해진 주기로 반복되는 작업을 관리하기 위한 패턴이다. 백업, 정산, 데이터 정리 같은 운영 작업을 쿠버네티스 리소스로 다룰 수 있으며, 실패 시 재시도나 실행 이력 관리도 함께 처리한다.

데몬 / 싱글톤(DaemonSet / Singleton)
모든 노드에 반드시 실행되어야 하는 기능과 클러스터에 하나만 존재해야 하는 기능을 구분한다. 로그 수집기나 모니터링 에이전트는 데몬으로, 리더 역할 서비스는 싱글톤으로 구성한다. 이 구분 덕분에 확장 시에도 동작이 예측 가능하다.

스테이트풀 서비스(Stateful Service)
데이터처럼 상태를 가지는 서비스를 위한 패턴이다. 파드가 재시작되더라도 이름과 저장소가 유지되어야 하는 경우에 사용하며, 데이터베이스나 메시지 브로커처럼 정체성과 순서가 중요한 시스템에 적합하다.

서비스 디스커버리(Service Discovery)
서비스의 위치나 IP를 직접 관리하지 않고 이름으로 접근하게 만든다. 인스턴스 수가 바뀌어도 연결이 자동으로 유지되며, 네트워크 변경이 애플리케이션 코드에 영향을 주지 않는다.

3. 구조 패턴

초기화 컨테이너(Init Container)
애플리케이션이 실행되기 전에 반드시 필요한 작업을 먼저 수행한다. 설정 준비나 데이터 검증 같은 사전 조건을 분리함으로써 본 컨테이너는 자신의 역할에만 집중할 수 있다.

사이드카(Sidecar)
애플리케이션과 항상 함께 동작해야 하는 보조 기능을 같은 파드에 배치한다. 로그 수집, 프록시, 보안 처리 같은 공통 기능을 분리해 애플리케이션 코드를 단순화한다.

어댑터(Adapter)
외부 시스템과의 차이를 중간에서 흡수하는 역할을 한다. 데이터 형식이나 통신 방식이 달라도 애플리케이션이 영향을 받지 않도록 하며, 복잡한 통합 로직을 한 곳에 모아 관리할 수 있다.

앰배서더(Ambassador)
외부 통신을 대신 처리하는 전용 역할이다. 인증, TLS, 재시도 같은 네트워크 처리를 애플리케이션 밖으로 분리해 비즈니스 로직에 집중할 수 있도록 한다.