EKS 1.32 + Karpenter v1.5에서 Spot 인스턴스 disruption이 너무 잦습니다

Karpenter v1.5에서 disruption 모델이 정리되었지만, 기본값이 비용 최적화 우선이라 batch 워크로드 입장에서는 공격적입니다. 핵심은 워크로드 종류별로 NodePool을 분리하는 것입니다.

1) 워크로드 분리 — NodePool 두 개 운영

--- # Spot — stateless web/api 전용
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: spot-stateless
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
      taints:
        - key: workload-type
          value: stateless
          effect: NoSchedule
  disruption:
    consolidationPolicy: WhenEmpty
    consolidateAfter: 30s
---
--- # On-demand 또는 reserved spot — batch/stateful 전용
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: ondemand-batch
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand"]
      taints:
        - key: workload-type
          value: batch
          effect: NoSchedule
  disruption:
    consolidationPolicy: WhenEmpty
    consolidateAfter: 5m  # batch는 보수적으로
    budgets:
      - nodes: "0"
        schedule: "0 9-18 * * 1-5"  # 업무시간 disruption 차단
        duration: 9h

그리고 batch job은 toleration으로 ondemand-batch에만 스케줄:

tolerations:
- key: workload-type
  operator: Equal
  value: batch
  effect: NoSchedule

2) Spot 안정성 강화 — 다양화

Spot disruption 빈도는 인스턴스 타입·AZ 다양성과 직접 관련됩니다.

requirements:
- key: node.kubernetes.io/instance-type
  operator: In
  values:  # 동급 다른 타입 5~10개
    - "m5.large"
    - "m5a.large"
    - "m5n.large"
    - "m6i.large"
    - "m6a.large"
- key: topology.kubernetes.io/zone
  operator: In
  values: ["ap-northeast-2a", "ap-northeast-2c"]

3) Spot interruption 미리 대응 — node-termination-handler

helm install aws-node-termination-handler eks/aws-node-termination-handler \
  --set enableSpotInterruptionDraining=true \
  --set enableRebalanceMonitoring=true \
  --set enableRebalanceDraining=true

이게 있으면 EC2 회수 2분 알림을 받자마자 Pod를 graceful하게 빼냅니다.

4) PodDisruptionBudget 강제

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
spec:
  minAvailable: 80%
  selector:
    matchLabels:
      app: api

Karpenter는 PDB를 존중합니다. minAvailable 위반 시 disruption 자동 보류.

5) Karpenter v1.5 disruption budget 활용

spec:
  disruption:
    budgets:
      - nodes: "10%"          # 한 번에 최대 10%만
        reasons: ["Drifted"]
      - nodes: "0"            # batch 시간엔 0
        schedule: "0 0 * * *"
        duration: 8h
        reasons: ["Underutilized"]

실무 체크리스트

1. 워크로드 타입별 NodePool 분리 (stateless / batch / stateful)
2. Spot은 인스턴스 타입 5개 이상 + AZ 2개 이상 다양화
3. aws-node-termination-handler 설치 (필수)
4. 중요 워크로드는 PDB 명시
5. disruption budget으로 시간대·이유별 제한
6. 비용 추적 — kubecost 또는 OpenCost로 NodePool별 비용 분리 모니터링

대안 — Karpenter Spot Block (v1.5 신기능)

requirements:
- key: karpenter.k8s.aws/spot-block-duration
  operator: In
  values: ["1h", "2h", "3h", "4h", "5h", "6h"]

Spot인데 명시 시간(최대 6시간) 동안은 회수되지 않습니다. 가격은 일반 Spot보다 약 30% 비싸지만 batch에는 합리적입니다.

마지막으로 — "Spot이 너무 자주 죽는다"의 절반은 인스턴스 다양화 부족입니다. 단일 타입에 의존하면 그 풀의 가격 변동이 그대로 회수로 이어집니다.