Kubernetes 동작 원리 - Deployment와 장애 복구

Deployment의 주요 역할

Deployment는 세 가지 핵심 역할을 한다.

스케일링: Pod 수를 자동으로 조절
자동 복구: Pod 장애 시 다시 띄움
롤링 업데이트: 무중단으로 새 버전 배포

한 가지 알아두어야 할 것은, Deployment 자체는 etcd에 저장된 선언 데이터라는 점이다. Controller Manager 안의 Deployment Controller가 이를 읽고 실제 역할을 수행한다.

스케일링

Deployment 선언 데이터에서 ReplicaSet의 숫자를 변경하면 동일한 방식으로 스케일링이 이루어진다. 또는 CPU/메모리 사용량에 따라 HPA(Horizontal Pod Autoscaler)를 통한 오토 스케일링도 가능하다.

롤링 업데이트 과정

새 버전을 배포할 때 서비스를 중단하지 않고 점진적으로 교체한다.

초기 상태
ReplicaSet-v1: 파드 3개 (v1)

업데이트 시작
ReplicaSet-v2 새로 생성

Step 1
ReplicaSet-v1: 파드 3개 (v1)
ReplicaSet-v2: 파드 1개 (v2)  ← 추가

Step 2
ReplicaSet-v1: 파드 2개 (v1)  ← 1개 삭제
ReplicaSet-v2: 파드 2개 (v2)

Step 3
ReplicaSet-v1: 파드 1개 (v1)
ReplicaSet-v2: 파드 3개 (v2)

완료
ReplicaSet-v1: 파드 0개 (보존됨 — 롤백용)
ReplicaSet-v2: 파드 3개 (v2) ✓

이전 ReplicaSet은 완전히 삭제되지 않고 보존된다. 문제가 생기면 이것을 이용해 롤백할 수 있다.

Pod 장애 발생 시 복구 메커니즘

Pod에 장애가 발생하면 Control Loop (Reconciliation Loop) 를 통해 선언된 상태를 유지하려 한다.

kubelet이 파드 죽음 감지
↓
API Server에 상태 보고
↓
etcd에 현재 상태 저장 ("파드 2개만 있음")
↓
Controller Manager가 감지 ("목표 3개인데 2개네, 1개 더 필요")
↓
Scheduler가 어느 노드에 띄울지 결정
↓
API Server가 해당 노드의 kubelet에 명령
↓
kubelet이 새 파드 실행

여기서 중요한 점은 Controller Manager가 kubelet에 직접 명령을 보내지 않는다는 것이다. 항상 API Server를 통해서 명령이 전달된다. 모든 컴포넌트는 API Server하고만 통신한다.

Control Loop란?

while True:
    현재 상태 확인
    목표 상태와 비교
    차이가 있으면 → 행동
    차이가 없으면 → 대기

쿠버네티스 전체가 이 루프로 동작한다. 선언된 상태와 현재 상태 사이의 차이를 감지하고 계속 맞춰나간다.

Probe: 헬스체크 메커니즘

파드 상태를 주기적으로 확인할 때, 단순히 프로세스가 살아있는지만이 아니라 앱이 실제로 정상 동작 중인지를 알아야 한다. 이를 위해 Probe를 사용한다.

3가지 종류

Probe	목적	실패 시
livenessProbe	생존 확인 — 데드락, 무한 루프 등 프로세스는 살아있지만 동작은 못하는 상황 감지	kubelet이 컨테이너를 재시작
readinessProbe	준비 확인 — 앱 초기화 중, DB 연결 중, 캐시 로딩 중 등 트래픽을 받을 준비가 됐는지 감지	Service가 이 파드로 트래픽을 보내지 않음 (준비될 때까지 대기)
startupProbe	시작 확인 — 초기화가 수십 초 걸리는 레거시 앱 등 시작이 오래 걸리는 경우	startupProbe 성공 전까지 liveness/readiness 검사를 수행하지 않음

startupProbe가 없으면 초기화가 오래 걸리는 앱을 livenessProbe가 실패로 판단해 계속 재시작시킬 수 있다.

감지 방식 3가지

방식	설명	주의사항
HTTP GET	지정한 엔드포인트(`/health` 등)에 GET 요청	개발자가 해당 엔드포인트를 직접 구현해야 함
TCP Socket	포트 연결 시도 (gRPC, DB 등에 활용)	포트가 열려있으면 성공으로 판정 → 정확도가 낮음
Exec	컨테이너 내부에서 명령 실행, 종료 코드로 판단	—

gRPC 서비스의 경우, gRPC 공식 헬스체크 표준을 따라 앱에 프로토콜을 구현해두어야 정확하게 감지할 수 있다.