apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 2    # 최대 2개까지 동시에 내릴 수 있음
      maxSurge: 2          # 최대 2개까지 추가 생성 가능
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:v2.0
        readinessProbe:    # 이거 없으면 롤링 업데이트 의미 없음!
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5

# 고가용성 우선 설정
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 0    # 절대 기존 파드 먼저 내리지 않음
    maxSurge: 1          # 한 번에 1개씩 추가 생성 후 교체
    
# 이 설정의 동작 순서:
# 1. 새 파드 1개 생성 (총 replicas+1개)
# 2. 새 파드 Ready 확인
# 3. 구 파드 1개 종료
# 4. 반복...

# 빠른 배포 우선 설정 (replicas: 20 기준)
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 5    # 25% 동시 교체
    maxSurge: 5          # 25% 추가 생성 허용
    
# 이 설정으로 20개 파드를 5개씩 묶어서 배포
# 총 4번의 배치로 완료 → 훨씬 빠름!

# 균형 잡힌 기본 설정 (replicas: 8 기준)
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 25%  # = 2개 (소수점 내림)
    maxSurge: 25%        # = 2개 (소수점 올림)
    
# 동작: 2개씩 교체, 최대 10개까지 파드 존재 가능
# 총 4번의 배치로 완료

containers:
- name: my-app
  image: my-app:v2.0
  
  # 시작 프로브: 앱이 완전히 뜰 때까지 기다림
  startupProbe:
    httpGet:
      path: /health/startup
      port: 8080
    failureThreshold: 30    # 30번 실패 허용
    periodSeconds: 10       # 10초마다 체크 → 최대 300초 대기
    
  # 준비 프로브: 트래픽 받을 준비 됐는지 (롤링 업데이트 핵심!)
  readinessProbe:
    httpGet:
      path: /health/ready
      port: 8080
    initialDelaySeconds: 5  # 시작 후 5초 뒤부터 체크
    periodSeconds: 5        # 5초마다 체크
    successThreshold: 1     # 1번 성공하면 Ready
    failureThreshold: 3     # 3번 연속 실패하면 Not Ready
    timeoutSeconds: 3       # 3초 안에 응답 없으면 실패
    
  # 생존 프로브: 데드락 등 감지
  livenessProbe:
    httpGet:
      path: /health/live
      port: 8080
    initialDelaySeconds: 15
    periodSeconds: 10
    failureThreshold: 3

spec:
  # 파드 종료 대기 시간 설정 (기본 30초)
  terminationGracePeriodSeconds: 60  # 60초로 늘림
  
  containers:
  - name: my-app
    lifecycle:
      preStop:
        exec:
          # SIGTERM 받기 전에 먼저 실행되는 훅
          # 로드밸런서 업데이트 지연을 위한 sleep
          command: ["/bin/sh", "-c", "sleep 5"]

# Python FastAPI 예시
import signal
import asyncio
from fastapi import FastAPI

app = FastAPI()
is_shutting_down = False

@app.on_event("shutdown")
async def shutdown_event():
    global is_shutting_down
    is_shutting_down = True
    # 진행 중인 요청 완료 대기
    await asyncio.sleep(5)

@app.get("/health/ready")
async def readiness():
    if is_shutting_down:
        # 종료 중이면 503 반환 → 로드밸런서에서 제거
        return Response(status_code=503)
    return {"status": "ready"}

# Node.js Express 예시
process.on('SIGTERM', () => {
    console.log('SIGTERM received, starting graceful shutdown');
    server.close(() => {
        console.log('HTTP server closed');
        process.exit(0);
    });
    // 새 연결 거부, 기존 연결 완료 대기
    setTimeout(() => process.exit(1), 30000);
});

# 현재 배포 상태 확인
kubectl rollout status deployment/my-app

# 배포 히스토리 확인
kubectl rollout history deployment/my-app
# REVISION  CHANGE-CAUSE
# 1         kubectl apply --image=my-app:v1.0
# 2         kubectl apply --image=my-app:v2.0
# 3         kubectl apply --image=my-app:v3.0

# 즉시 이전 버전으로 롤백 (가장 많이 씀!)
kubectl rollout undo deployment/my-app

# 특정 리비전으로 롤백
kubectl rollout undo deployment/my-app --to-revision=1

# 롤백 진행 상황 모니터링
kubectl rollout status deployment/my-app --watch

spec:
  revisionHistoryLimit: 5  # 최근 5개 리비전만 보관 (기본값 10)
  # 너무 많이 보관하면 etcd 용량 차지하니까 적절히 설정

# Argo Rollouts를 활용한 자동 롤백 설계 예시
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  replicas: 10
  strategy:
    canary:
      steps:
      - setWeight: 10      # 10% 트래픽만 신버전으로
      - pause: {duration: 5m}  # 5분 관찰
      - setWeight: 50      # 50%로 증가
      - pause: {duration: 5m}
      - setWeight: 100     # 전체 전환
      
      # 자동 분석 설정
      analysis:
        templates:
        - templateName: success-rate
        startingStep: 1
        args:
        - name: service-name
          value: my-app
          
---
# 분석 템플릿 (에러율 5% 초과 시 자동 롤백)
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  metrics:
  - name: success-rate
    interval: 1m
    successCondition: result[0] >= 0.95  # 성공률 95% 이상
    failureLimit: 3
    provider:
      prometheus:
        address: http://prometheus:9090
        query: |
          sum(rate(http_requests_total{
            job="my-app",status!~"5.."}[5m]))
          /
          sum(rate(http_requests_total{
            job="my-app"}[5m]))

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  # 방법 1: 최소 가용 파드 수 지정
  minAvailable: 3          # 항상 최소 3개는 살아있어야 함
  
  # 방법 2: 최대 불가용 파드 수 지정 (둘 중 하나만 사용)
  # maxUnavailable: 1      # 동시에 최대 1개만 내릴 수 있음
  
  selector:
    matchLabels:
      app: my-app
      
# 퍼센트로도 설정 가능
# minAvailable: "70%"      # 항상 70% 이상 유지
# maxUnavailable: "30%"    # 최대 30%까지 동시 중단 허용

# 디버깅 명령어 모음
# 파드 상태 상세 확인
kubectl describe pod [파드명] -n [네임스페이스]

# 파드 로그 확인
kubectl logs [파드명] --previous  # 이전 컨테이너 로그

# 롤아웃 이벤트 확인
kubectl describe deployment [디플로이먼트명]

# 리소스 사용량 확인
kubectl top nodes
kubectl top pods

# 롤아웃 일시정지 (문제 분석 시간 벌기)
kubectl rollout pause deployment/my-app

# 분석 후 재개
kubectl rollout resume deployment/my-app

spec:
  template:
    spec:
      # 파드를 가용 영역(AZ)에 균등 분산
      topologySpreadConstraints:
      - maxSkew: 1                    # AZ 간 파드 수 차이 최대 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: my-app
            
      # 노드 간에도 균등 분산
      - maxSkew: 2
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: ScheduleAnyway  # 불가능하면 그냥 배치
        labelSelector:
          matchLabels:
            app: my-app

containers:
- name: my-app
  resources:
    requests:
      cpu: "500m"       # 스케줄링 기준 (이만큼 보장)
      memory: "512Mi"
    limits:
      cpu: "1000m"      # 최대 사용 제한
      memory: "1Gi"
      
# requests가 없으면 스케줄러가 노드 선택을 못 해서
# 롤링 업데이트 중 파드가 Pending 상태로 멈출 수 있음!
# 반드시 requests 설정할 것!