[EKS Best Practices] Cluster Autoscaling - Karpenter

원문: Cluster Autoscaling - Karpenter

Karpenter 개요

Karpenter는 Kubernetes 클러스터의 노드 수명주기 관리를 자동화하는 오픈소스 프로젝트입니다. Pod의 스케줄링 요구사항에 따라 노드를 자동으로 provisioning/deprovisioning하여 효율적인 스케일링과 비용 최적화를 달성합니다.

핵심 동작 흐름

flowchart LR
    A[Pending Pods 감지] --> B[스케줄링 요구사항 평가]
    B --> C{리소스 요청·Node Selector\nAffinity·Toleration 분석}
    C --> D[적절한 크기의\n신규 노드 Provisioning]
    D --> E[Pod 스케줄링]
    E --> F{노드 활용도\n모니터링}
    F -->|불필요| G[노드 자동 제거]
    F -->|활용 중| E

Karpenter의 4가지 핵심 기능

Karpenter를 사용해야 하는 이유

Karpenter vs Cluster Autoscaler 비교

flowchart TB
    subgraph CAS["Cluster Autoscaler 방식"]
        direction TB
        K8s1[Kubernetes API] --> Bridge[CAS Bridge] --> ASG[AWS ASG API]
        ASG --> NG1[Node Group 1\n- m5.large]
        ASG --> NG2[Node Group 2\n- c5.xlarge]
        ASG --> NG3[Node Group 3\n- r5.large]
        ASG --> NG4[Node Group N\n- ...]
    end

    subgraph KAR["Karpenter 방식"]
        direction TB
        K8s2[Kubernetes API] --> KARP[Karpenter Controller]
        KARP --> NP[단일 NodePool]
        NP --> I1[m5.large]
        NP --> I2[c5.xlarge]
        NP --> I3[r5.large]
        NP --> I4[필요에 따라\n자동 선택]
    end

언제 Karpenter를 사용할 것인가

Karpenter Best Practices

1. Production에서 AMI 고정 (Pin AMI)

Production 클러스터에서는 반드시 검증된 AMI 버전을 고정(pin)해야 합니다.

# EC2NodeClass에서 AMI 버전 고정 (권장)
amiSelectorTerms:
  - alias: al2023@v20240807

2. Karpenter Controller 배치

flowchart LR
    subgraph 권장배치["Karpenter Controller 배치 옵션"]
        A["옵션 1: 소규모 Managed Node Group\n최소 1개 워커 노드"]
        B["옵션 2: EKS Fargate\nkarpenter namespace에\nFargate Profile 생성"]
    end
    C[/"Karpenter가 관리하는 노드에\nKarpenter를 배치하지 말 것!"/]

    style C fill:#ff6b6b,color:#fff

주의: Karpenter가 관리하는 노드 위에 Karpenter Controller를 실행하면 안 됩니다. Karpenter가 자신의 노드를 삭제하면 Controller도 함께 내려갈 수 있습니다.

3. 불필요한 Instance Type 제외

# 대형 Graviton 인스턴스 제외 예시
- key: node.kubernetes.io/instance-type
  operator: NotIn
  values:
    - m6g.16xlarge
    - m6gd.16xlarge
    - r6g.16xlarge
    - r6gd.16xlarge
    - c6g.16xlarge

4. Spot 사용 시 Interruption Handling 활성화

sequenceDiagram
    participant SQS as SQS Queue
    participant KAR as Karpenter Controller
    participant Node as 영향받는 Node
    participant NewNode as 신규 Node

    SQS->>KAR: Interruption Event 수신
    KAR->>Node: Taint 적용
    KAR->>NewNode: 신규 노드 프로비저닝 시작
    KAR->>Node: Drain (Pod 이전)
    NewNode-->>KAR: Ready
    KAR->>Node: Terminate
    Note over Node,NewNode: Spot 2분 경고 시
빠르게 신규 노드 준비

5. Private Cluster (인터넷 미연결) 구성

NodePool 생성 Best Practices

1. 복수 NodePool 생성이 필요한 경우

2. NodePool 간 상호 배타성 또는 가중치 설정

여러 NodePool이 동일 Pod에 매칭될 경우 Karpenter가 랜덤하게 선택하므로, 상호 배타적(mutually exclusive) 이거나 가중치(weighted) 를 부여해야 합니다.

패턴 A: GPU NodePool + Taint/Toleration 기반 분리

# GPU NodePool - Taint로 일반 워크로드 차단
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu
spec:
  disruption:
    consolidateAfter: 1m
    consolidationPolicy: WhenEmptyOrUnderutilized
  template:
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      requirements:
        - key: node.kubernetes.io/instance-type
          operator: In
          values:
            - p3.8xlarge
            - p3.16xlarge
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand"]
      taints:
        - effect: NoSchedule
          key: nvidia.com/gpu
          value: "true"

패턴 B: 일반 컴퓨팅 NodePool + Label/NodeAffinity 기반 분리

# 일반 컴퓨팅 NodePool - 팀별 Label 부여
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: generalcompute
spec:
  template:
    metadata:
      labels:
        billing-team: my-team
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      requirements:
        - key: node.kubernetes.io/instance-type
          operator: In
          values:
            - m5.large
            - m5.xlarge
            - m5.2xlarge
            - c5.large
            - c5.xlarge
            - r5.large
            - r5.xlarge

flowchart TB
    subgraph Cluster["EKS Cluster"]
        subgraph NP1["NodePool: gpu"]
            T1["Taint: nvidia.com/gpu=true:NoSchedule"]
            N1["p3.8xlarge / p3.16xlarge"]
        end

        subgraph NP2["NodePool: generalcompute"]
            L1["Label: billing-team=my-team"]
            N2["m5 / c5 / r5 계열"]
        end
    end

    GPU_WL["GPU Workload\n(Toleration 있음)"] --> NP1
    GENERAL_WL["일반 Workload\n(NodeAffinity 매칭)"] --> NP2

    style NP1 fill:#e8d5f5
    style NP2 fill:#d5e8f5

3. Spot 사용 시 Instance Type을 과도하게 제한하지 않기

flowchart LR
    A["다양한 Instance Type 허용"] --> B["깊은 Spot Pool 접근"]
    B --> C["낮은 중단 위험"]

    E["소수 Instance Type만 허용"] --> F["제한된 Spot Pool"]
    F --> G["높은 중단 위험"]

    style A fill:#90EE90
    style E fill:#FFB6C1

# ec2-instance-selector 사용 예시
$ ec2-instance-selector --memory 4 --vcpus 2 --cpu-architecture x86_64 -r ap-southeast-1
c5.large
c5a.large
c5ad.large
c5d.large
c6i.large
t2.medium
t3.medium
t3a.medium

Pod 스케줄링 Best Practices

1. 고가용성(HA) 확보

2. 비용 모니터링 및 Resource Limit 설정

# NodePool에 Resource Limit 설정
spec:
  limits:
    cpu: 1000        # 최대 1000 vCPU
    memory: 1000Gi   # 최대 1000Gi 메모리

flowchart TB
    subgraph 비용관리["비용 관리 다층 방어 체계"]
        direction TB
        L1["1단계: NodePool Resource Limits\ncpu: 1000, memory: 1000Gi"]
        L2["2단계: CloudWatch Billing Alarm\n임계값 초과 시 알림"]
        L3["3단계: AWS Cost Anomaly Detection\nML 기반 이상 지출 감지"]
        L4["4단계: AWS Budgets Actions\n이메일 / SNS / Slack 알림"]

        L1 --> L2 --> L3 --> L4
    end

3. karpenter.sh/do-not-disrupt Annotation 활용

metadata:
  annotations:
    karpenter.sh/do-not-disrupt: "true"

4. Consolidation 사용 시 non-CPU 리소스는 requests = limits 설정

flowchart LR
    subgraph 문제상황["requests 와 limits 가 다를 때 문제"]
        P1["Pod A\nrequest: 256Mi\nlimit: 512Mi"] --> Node["Node\nallocatable: 1Gi"]
        P2["Pod B\nrequest: 256Mi\nlimit: 512Mi"] --> Node
        P3["Pod C\nrequest: 256Mi\nlimit: 512Mi"] --> Node
        P4["Pod D\nrequest: 256Mi\nlimit: 512Mi"] --> Node
        Node -->|"4 Pod x 256Mi request = 1Gi\n하지만 4 Pod x 512Mi burst = 2Gi"| OOM["OOM Kill 발생!"]
    end

    style OOM fill:#ff6b6b,color:#fff

5. LimitRange로 기본 리소스 설정

flowchart LR
    A["Pod 생성\n(리소스 미지정)"] --> B{"LimitRange\n존재?"}
    B -->|Yes| C["기본 requests/limits\n자동 적용"]
    B -->|No| D["무제한 리소스 사용\n스케줄링 문제 발생"]
    C --> E["Karpenter가 정확한\n노드 크기 선택 가능"]
    D --> F["Karpenter가 올바른\n노드 결정 불가"]

    style E fill:#90EE90
    style F fill:#FFB6C1

CoreDNS 권장 사항

전체 Best Practices 체크리스트

추가 학습 리소스