# Pod를 직접 생성했을 때의 문제
kubectl run my-pod --image=nginx:alpine
# Pod가 죽으면? → 자동 복구 없음
# 새 버전 배포? → 삭제 후 재생성 (다운타임)
# 여러 개 필요? → 일일이 kubectl run 반복

# Deployment를 쓰면
kubectl create deployment my-app --image=nginx:alpine --replicas=3
# → Pod 3개 자동 생성 + 자동 복구
# → 이미지 변경 시 롤링 업데이트 자동
# → 실패 시 자동 롤백 가능

# Deployment 생성
kubectl create deployment my-app \
  --image=nginx:alpine \
  --replicas=3 \
  -n deploy-lab

# 계층 구조 확인
kubectl get deployment,replicaset,pod -n deploy-lab
# NAME                    READY   UP-TO-DATE   AVAILABLE
# deployment.apps/my-app  3/3     3            3
#
# NAME                              DESIRED   CURRENT   READY
# replicaset.apps/my-app-5d85b4bdc  3         3         3
#
# NAME                        READY   STATUS    RESTARTS
# pod/my-app-5d85b4bdc-abc12  1/1     Running   0
# pod/my-app-5d85b4bdc-def34  1/1     Running   0
# pod/my-app-5d85b4bdc-ghi56  1/1     Running   0

# Pod 하나를 수동으로 삭제해 보자
kubectl delete pod my-app-5d85b4bdc-abc12 -n deploy-lab

# 즉시 새 Pod가 생성됨
kubectl get pods -n deploy-lab
# NAME                        READY   STATUS    RESTARTS   AGE
# my-app-5d85b4bdc-def34      1/1     Running   0          5m
# my-app-5d85b4bdc-ghi56      1/1     Running   0          5m
# my-app-5d85b4bdc-xyz99      1/1     Running   0          5s  ← 새로 생성됨

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: deploy-lab
spec:
  replicas: 3                    # 원하는 Pod 수
  selector:
    matchLabels:
      app: my-app                # 어느 Pod를 관리할지
  strategy:
    type: RollingUpdate          # 배포 전략
    rollingUpdate:
      maxUnavailable: 1          # 업데이트 중 최대 불가 Pod 수
      maxSurge: 1               # 추가로 생성 가능한 최대 Pod 수
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: nginx
        image: nginx:1.24        # 이미지 버전 관리의 핵심
        ports:
        - containerPort: 80
        readinessProbe:          # 롤링 업데이트의 안전 장치
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 5
        resources:
          requests:
            memory: "64Mi"
            cpu: "50m"
          limits:
            memory: "128Mi"
            cpu: "100m"

초기 상태: Pod v1.0 × 3개

1단계: 새 ReplicaSet 생성 (v2.0)
       Pod v1.0 × 3, Pod v2.0 × 1 (maxSurge: 1)

2단계: v2.0 Pod가 Ready → v1.0 Pod 1개 종료
       Pod v1.0 × 2, Pod v2.0 × 1

3단계: v2.0 Pod 하나 더 생성
       Pod v1.0 × 2, Pod v2.0 × 2

4단계: v2.0 Pod Ready → v1.0 Pod 1개 종료
       Pod v1.0 × 1, Pod v2.0 × 2

... 반복 ...

최종: Pod v2.0 × 3, 구 ReplicaSet(v1.0) replicas=0으로 보관

# 방법 1: kubectl set image (빠른 업데이트)
kubectl set image deployment/my-app nginx=nginx:1.25 -n deploy-lab

# 방법 2: kubectl edit (YAML 직접 편집)
kubectl edit deployment/my-app -n deploy-lab
# → image: nginx:1.24 를 nginx:1.25 로 변경

# 방법 3: YAML 파일 수정 후 apply (권장 — GitOps 방식)
# deployment.yaml의 image 필드 수정 후
kubectl apply -f deployment.yaml -n deploy-lab

# 롤아웃 진행 상황 실시간 확인
kubectl rollout status deployment/my-app -n deploy-lab
# Waiting for deployment "my-app" rollout to finish: 1 out of 3 new replicas have been updated...
# Waiting for deployment "my-app" rollout to finish: 2 out of 3 new replicas have been updated...
# Waiting for deployment "my-app" rollout to finish: 1 old replicas are pending termination...
# deployment "my-app" successfully rolled out

# 배포 이력 확인
kubectl rollout history deployment/my-app -n deploy-lab
# REVISION  CHANGE-CAUSE
# 1         <none>
# 2         <none>

# 특정 revision 상세 확인
kubectl rollout history deployment/my-app --revision=2 -n deploy-lab

# 전략 1: 기본 (빠른 배포)
rollingUpdate:
  maxUnavailable: 1   # 교체 중 최대 1개 다운 허용
  maxSurge: 1         # 최대 1개 추가 생성

# 전략 2: 무중단 (가용성 최우선)
rollingUpdate:
  maxUnavailable: 0   # 다운 없이 교체
  maxSurge: 1         # 새 Pod 먼저 생성 후 교체

# 전략 3: 빠른 교체 (속도 최우선)
rollingUpdate:
  maxUnavailable: 2   # 2개까지 동시 교체
  maxSurge: 2         # 2개 추가 생성 허용

[변경]  spec.template 의 image: nginx:1.24 → 1.25
   │
   ① 컨트롤러가 template 해시 변경 감지 → 새 ReplicaSet(rev N+1) 생성 (replicas=0)
   │
   ② 새 RS를 maxSurge 만큼 +늘림 → 새 파드 기동 (잠깐 replicas+surge)
   │
   ③ 새 파드가 readinessProbe 통과 → Ready → Service 엔드포인트 편입
   │      (readiness 통과가 트래픽 전환의 방아쇠)
   │
   ④ Ready 확보분만큼 옛 RS 파드 종료 (maxUnavailable 범위 내)
   │
   ⑤ ②~④ 점진 반복 → 새 RS가 목표 replicas 도달, 옛 RS는 0으로 축소(삭제 아님·보관)
   │
   ⑥ 완료 → 옛 RS는 revision 이력으로 남아 rollout undo 시 복귀 대상
   ▼
[결과]  전 파드 nginx:1.25, 다운타임 0, revision N+1 기록