Kubernetes Deployment

1. Deployment란?

Deployment는 Kubernetes에서 애플리케이션의 선언적 업데이트를 관리하는 리소스입니다.

"이 앱을 이런 설정으로, 이 개수만큼 항상 실행되도록 유지해줘!" 라고 Kubernetes에게 선언하는 것

---

2. 리소스 계층 구조

Deployment
    └── ReplicaSet
            └── Pod
                    └── Container

---

3. 각 리소스 역할

리소스	비유	역할
Deployment	건축 설계도	Pod의 설계도 관리 (이미지, 리소스, 버전, 배포 전략)
ReplicaSet	건설 현장 감독	실제 Pod 생성 / 제거 / 유지 / 재시작
Pod	실제 건물	컨테이너가 실행되는 최소 단위
Container	건물 내부	실제 애플리케이션 프로세스

---

4. Deployment가 관리하는 것

• 🐳 어떤 이미지를 사용할지 (image: my-app:1.0.0)
• 💾 리소스 제한 (CPU, Memory requests/limits)
• 🔑 환경변수, ConfigMap, Secret 연결
• 📜 버전 히스토리 (롤백용 이전 ReplicaSet 보존)
• 🔄 배포 전략 (RollingUpdate, Recreate 등)

---

5. ReplicaSet이 관리하는 것

• ✅ 지정된 수의 Pod 항상 유지
• ➕ Pod 부족 시 생성
• ➖ Pod 초과 시 제거
• 🔁 Pod 장애 시 재생성

---

6. 스케일링 관리

스케일링의 목표 수치를 선언하는 것은 Deployment (또는 HPA), 실제로 Pod 수를 맞추는 것은 ReplicaSet입니다.

수동 스케일링

사용자 → Deployment (replicas 선언) → ReplicaSet (Pod 수 실현) → Pod

자동 스케일링 (HPA)

CPU/메모리 임계값 초과
        ↓
       HPA (자동 감지)
        ↓
   Deployment (replicas 자동 조절)
        ↓
   ReplicaSet (Pod 수 실현)
        ↓
   Pod Pod Pod Pod Pod

---

7. 버전 관리 & 롤백 원리

Deployment는 새 버전 배포 시 이전 ReplicaSet을 삭제하지 않고 보존합니다.
이 덕분에 빠른 롤백이 가능합니다.

배포 시

[현재] Deployment (image: v2)
         ├── ReplicaSet-A (v1) → Pod 0개  ← 보존됨
         └── ReplicaSet-B (v2) → Pod 3개  ← 현재 운영 중

롤백 시

[롤백] Deployment (image: v1으로 복구)
         ├── ReplicaSet-A (v1) → Pod 3개  ← 복구됨
         └── ReplicaSet-B (v2) → Pod 0개  ← 축소됨

---

8. ReplicaSet 데이터 저장 방식

ReplicaSet을 포함한 모든 Kubernetes 리소스는 etcd에 저장됩니다.

etcd란?

항목	설명
종류	분산 Key-Value 데이터베이스
저장 방식	디스크에 영구 저장 (재시작해도 유지)
저장 내용	모든 K8s 리소스 상태 (Deployment, ReplicaSet, Pod 등)
특징	고가용성, 분산 저장, Watch 기능 (변경 감지)

저장 흐름

kubectl apply -f deployment.yaml
        ↓
   API Server
        ↓
  etcd (분산 Key-Value DB) ← 여기에 영구 저장!
        ↓
  Controller Manager
  (etcd 상태를 보고 ReplicaSet, Pod 생성/관리)

---

9. ReplicaSet 보관 주기 관리

이전 ReplicaSet의 보존 개수는 revisionHistoryLimit 으로 설정합니다. (기본값: 10)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  revisionHistoryLimit: 3  # 이전 ReplicaSet 보존 개수
  selector:
    matchLabels:
      app: my-app
  template:
    ...

동작 방식 (revisionHistoryLimit: 3)

배포 v1 → ReplicaSet-A 생성
배포 v2 → ReplicaSet-B 생성  (A 보존)
배포 v3 → ReplicaSet-C 생성  (A, B 보존)
배포 v4 → ReplicaSet-D 생성  (B, C 보존, A 삭제! ← 3개 초과)
배포 v5 → ReplicaSet-E 생성  (C, D 보존, B 삭제! ← 3개 초과)

⚠️ revisionHistoryLimit: 0 으로 설정하면 이전 ReplicaSet을 전혀 보존하지 않아 롤백이 불가능해집니다!

---

10. 전체 핵심 요약

항목	내용
Deployment	Pod 설계도 (이미지, 리소스, 버전, 배포 전략 관리)
ReplicaSet	Pod 실제 생성/제거/유지 담당
스케일링 선언	Deployment 또는 HPA
스케일링 실현	ReplicaSet
롤백 가능 이유	이전 ReplicaSet을 etcd에 보존하기 때문
데이터 저장소	etcd (디스크 영구 저장)
보관 주기 설정	revisionHistoryLimit (기본값: 10)