Karpenter 정리: Kubernetes 노드 오토스케일링

AWS EKS에서 클러스터 오토스케일러의 한계를 보완하는 노드 프로비저닝 도구 Karpenter를 실무 관점에서 정리해 보자

개요

Karpenter는 AWS에서 개발한 오픈소스 Kubernetes 노드 프로비저너로, 기존 클러스터 오토스케일러(Cluster Autoscaler)의 한계를 극복하려고 만들어졌습니다. 2021년 처음 공개됐고, 현재는 Kubernetes 클러스터의 노드 라이프사이클 관리의 새로운 표준으로 자리 잡고 있습니다.

왜 Karpenter가 필요했을까?

클러스터 오토스케일러의 한계점

기존 Cluster Autoscaler에는 이런 문제가 있었습니다.

1. 노드 그룹 기반의 제약적 스케일링

yaml

# 기존 방식: 미리 정의된 노드 그룹만 사용 가능
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler-status
data:
  node-group-1: "t3.medium (2-20 nodes)"
  node-group-2: "t3.large (1-10 nodes)"
  # 새로운 워크로드 요구사항이 생기면? 노드 그룹 추가 필요! 😰

2. 느린 스케일링 속도

bash

# 전통적인 스케일링 과정
Pod 스케줄 실패 → ASG 스케일 아웃 → 인스턴스 시작 → kubelet 등록
# 평균 3-5분 소요 😴

3. 비효율적인 리소스 활용

yaml

# 실제 필요: CPU 1.5 코어, 메모리 3GB
# 할당된 노드: t3.large (2 코어, 8GB) - 50% 이상 낭비! 💸

Karpenter의 해결 접근법

Pod 생성 요청부터 Karpenter 감지, 인스턴스 타입 계산, EC2 직접 프로비저닝, Pod 스케줄링 완료까지의 순서와 기존 방식·Karpenter 소요 시간이다.

Karpenter 핵심 아키텍처

주요 컴포넌트

1. Karpenter Controller

yaml

# Karpenter의 두뇌 역할
apiVersion: v1
kind: Pod
metadata:
  name: karpenter-controller
spec:
  containers:
  - name: controller
    image: public.ecr.aws/karpenter/karpenter:v0.37.0
    # 실시간 Pod 스케줄링 요구사항 모니터링
    # 최적 인스턴스 선택 알고리즘 실행
    # 노드 라이프사이클 관리

2. NodePool (이전 Provisioner)

yaml

# Karpenter v0.32+ 에서 도입된 새로운 리소스
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: default
spec:
  # 노드 프로비저닝 템플릿
  template:
    metadata:
      labels:
        node-type: "general-purpose"
    spec:
      # 노드 클래스 참조
      nodeClassRef:
        apiVersion: karpenter.k8s.aws/v1beta1
        kind: EC2NodeClass
        name: default
      # 인스턴스 요구사항
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ["t3.medium", "t3.large", "t3.xlarge"]
      # Taints 적용
      taints:
        - key: "workload-type"
          value: "batch"
          effect: NoSchedule
  # 스케일링 제한
  limits:
    cpu: 1000
  # 중단 정책
  disruption:
    consolidationPolicy: WhenEmpty
    consolidateAfter: 30s
    expireAfter: 2160h # 90일

3. EC2NodeClass

yaml

# AWS EC2 인스턴스 세부 설정
apiVersion: karpenter.k8s.aws/v1beta1
kind: EC2NodeClass
metadata:
  name: default
spec:
  # AMI 선택
  amiFamily: AL2
  
  # 서브넷 자동 선택
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: "my-cluster"
  
  # 보안 그룹 자동 선택  
  securityGroupSelectorTerms:
    - tags:
        karpenter.sh/discovery: "my-cluster"
  
  # IAM 인스턴스 프로파일
  instanceProfile: "KarpenterNodeInstanceProfile"
  
  # 사용자 데이터 커스터마이징
  userData: |
    #!/bin/bash
    /etc/eks/bootstrap.sh my-cluster
    # 추가 커스터마이징...
  
  # 블록 디바이스 매핑
  blockDeviceMappings:
    - deviceName: /dev/xvda
      ebs:
        volumeSize: 100Gi
        volumeType: gp3
        encrypted: true

핵심 동작 원리

1. 실시간 스케줄링 감지

yaml

# Pod가 pending 상태가 되면 즉시 감지
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        cpu: "500m"
        memory: "1Gi"
  # 이 Pod가 스케줄링 안 되면 Karpenter가 즉시 반응!

2. 최적 인스턴스 선택 알고리즘

bash

# Karpenter의 스마트한 계산 과정
1. Pod 리소스 요구사항 분석
   - CPU: 500m
   - Memory: 1Gi
   
2. 가능한 인스턴스 타입 평가
   - t3.small (1 vCPU, 2GB): ✅ 적합
   - t3.medium (2 vCPU, 4GB): ✅ 적합 (여유 있음)
   - t3.large (2 vCPU, 8GB): ❌ 과도한 스펙
   
3. 비용 최적화 선택
   - t3.small 선택 ($0.0208/시간)
   
4. 즉시 프로비저닝 시작

3. 빠른 프로비저닝 과정

Pod Pending 감지부터 인스턴스 계산·생성 요청, 노드 등록, 스케줄링 완료까지 Pod·Karpenter·EC2·EKS 사이 순서와 단계별 시간이다.

주요 기능

1. 다중 아키텍처 지원

yaml

# ARM64와 AMD64 혼합 사용
apiVersion: karpenter.sh/v1beta1
kind: NodePool
spec:
  template:
    spec:
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64", "arm64"]
        - key: node.kubernetes.io/instance-type
          operator: In
          values: 
            - "t4g.medium"    # ARM64 Graviton
            - "t3.medium"     # x86_64

2. 스팟 인스턴스 최적화

yaml

# 스팟과 온디맨드 혼합으로 비용 절감
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
      # 스팟 인스턴스 우선 사용으로 80% 비용 절감!

3. 세밀한 리소스 제어

yaml

# GPU, 네트워크 성능 등 다양한 요구사항 지원
spec:
  template:
    spec:
      requirements:
        # GPU 인스턴스만 선택
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ["p3.2xlarge", "p3.8xlarge"]
        # 향상된 네트워킹 필요
        - key: karpenter.k8s.aws/instance-network-bandwidth
          operator: Gt
          values: ["10000"]

Consolidation: 노드 최적화

개념 및 필요성

Consolidation은 Karpenter의 핵심 기능으로, 노드 리소스 사용률을 최적화해 비용을 절감합니다.

문제 상황

yaml

# 현재 클러스터 상태
Node-1 (t3.large): CPU 20%, Memory 30% 사용률
Node-2 (t3.large): CPU 15%, Memory 25% 사용률  
Node-3 (t3.large): CPU 10%, Memory 20% 사용률
# → 총 3개 노드가 모두 저사용률! 💸 비용 낭비

Consolidation 후

yaml

# 최적화 후
Node-1 (t3.large): CPU 45%, Memory 75% 사용률 
# Node-2, Node-3 제거됨
# → 66% 비용 절감! 🎉

Consolidation 설정

1. 기본 Consolidation 설정

yaml

apiVersion: karpenter.sh/v1beta1
kind: NodePool
spec:
  disruption:
    # 언제 consolidation을 수행할지 정의
    consolidationPolicy: WhenEmpty | WhenUnderutilized
    
    # consolidation 실행 대기 시간
    consolidateAfter: 30s
    
    # 노드가 비어있을 때만 consolidation (안전한 옵션)
    # consolidationPolicy: WhenEmpty

2. 고급 Consolidation 설정

yaml

spec:
  disruption:
    # 적극적 consolidation - 저사용률 노드도 정리
    consolidationPolicy: WhenUnderutilized
    
    # consolidation 대기 시간 (더 빠른 반응)
    consolidateAfter: 15s
    
    # Pod disruption budget 고려
    # PDB가 있는 Pod는 보호됨

Consolidation 동작 과정

사용률이 낮으면 재배치 검토, PDB·Anti-affinity 확인, 드레인과 재스케줄링, 빈 노드 종료로 이어지고 정상이면 모니터링을 계속한다.

실습: Consolidation 효과 측정

bash

# 1. 현재 노드 상태 확인
kubectl get nodes -o custom-columns="NAME:.metadata.name,CPU-REQ:.status.allocatable.cpu,MEM-REQ:.status.allocatable.memory"

# 2. Pod 리소스 사용률 확인  
kubectl top nodes

# 3. Karpenter consolidation 로그 확인
kubectl logs -n karpenter deployment/karpenter -f | grep consolidation

# 예시 로그 출력
# {"level":"INFO","time":"2024-01-15T10:30:00Z","message":"consolidating nodes","nodes":["ip-10-0-1-100"]}
# {"level":"INFO","time":"2024-01-15T10:30:30Z","message":"deleted node","node":"ip-10-0-1-100"}

expireAfter: 노드 생명주기 관리

개념

expireAfter는 노드의 최대 수명을 제한하는 기능입니다. 아래 목적으로 씁니다.

보안 업데이트 적용: 정기적인 노드 교체로 최신 AMI 반영
장기 실행 방지: 노드가 무한정 실행되어 비용이 누적되는 것을 방지
장애 예방: 오래된 노드에서 발생할 수 있는 하드웨어/소프트웨어 이슈 예방

설정 방법

yaml

apiVersion: karpenter.sh/v1beta1
kind: NodePool
spec:
  disruption:
    # 노드 최대 수명: 2160시간 (90일)
    expireAfter: 2160h
    
    # 다른 예시들
    # expireAfter: 24h    # 1일 (개발환경 적합)
    # expireAfter: 168h   # 1주일 (테스트환경)
    # expireAfter: 720h   # 30일 (일반적인 운영환경)
    # expireAfter: never  # 무제한 (비권장)

실무 권장사항

환경별 expireAfter 설정

yaml

# 개발 환경: 비용 최우선
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: dev-nodepool
spec:
  disruption:
    expireAfter: 24h  # 매일 교체 (비용 절감)
    consolidationPolicy: WhenEmpty
---
# 스테이징 환경: 안정성과 비용 균형
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: staging-nodepool
spec:
  disruption:
    expireAfter: 168h  # 주간 교체
    consolidationPolicy: WhenUnderutilized
---
# 프로덕션 환경: 안정성 우선
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: prod-nodepool
spec:
  disruption:
    expireAfter: 720h  # 월간 교체
    consolidationPolicy: WhenEmpty  # 보수적 접근

expireAfter vs 다른 정책들의 조합

yaml

# 모든 정책을 함께 사용한 최적화 예시
spec:
  disruption:
    # 최대 30일 수명
    expireAfter: 720h
    
    # 빈 노드는 30초 후 정리
    consolidationPolicy: WhenEmpty
    consolidateAfter: 30s
    
    # 추가 정책들
    replacePolicy: WhenHealthy  # 건강하지 않은 노드 교체

실무 구현 가이드

1. Karpenter 설치 및 기본 설정

IRSA (IAM Role for Service Account) 생성

bash

# 1. Karpenter를 위한 IAM 역할 생성
export CLUSTER_NAME="my-eks-cluster"
export AWS_REGION="ap-northeast-2"

# Karpenter Controller IAM Role 생성
eksctl create iamserviceaccount \
  --cluster=$CLUSTER_NAME \
  --namespace=karpenter \
  --name=karpenter \
  --role-name=${CLUSTER_NAME}-karpenter \
  --attach-policy-arn=arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy \
  --approve

Helm으로 Karpenter 설치

bash

# 2. Karpenter 설치
helm repo add karpenter https://charts.karpenter.sh/
helm repo update

helm upgrade --install karpenter karpenter/karpenter \
  --version v0.37.0 \
  --namespace karpenter \
  --create-namespace \
  --set settings.clusterName=$CLUSTER_NAME \
  --set settings.defaultInstanceProfile=KarpenterNodeInstanceProfile \
  --set settings.interruptionQueueName=$CLUSTER_NAME \
  --wait

2. 단계적 NodePool 구성 전략

Phase 1: 기본 NodePool (안전한 시작)

yaml

apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: general-purpose
spec:
  template:
    spec:
      nodeClassRef:
        name: default
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand"]  # 온디맨드만 사용 (안전)
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ["t3.medium", "t3.large"]  # 검증된 인스턴스만
  limits:
    cpu: 100  # 작은 제한으로 시작
  disruption:
    consolidationPolicy: WhenEmpty  # 보수적 정책
    consolidateAfter: 60s
    expireAfter: 720h  # 30일

Phase 2: 스팟 인스턴스 도입

yaml

apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: spot-optimized
spec:
  template:
    spec:
      nodeClassRef:
        name: default
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]  # 스팟 우선 사용
      # 스팟 인터럽션 대응을 위한 taints
      taints:
        - key: "node.kubernetes.io/spot"
          value: "true"
          effect: NoSchedule
  limits:
    cpu: 500
  disruption:
    consolidationPolicy: WhenUnderutilized  # 적극적 최적화
    consolidateAfter: 30s
    expireAfter: 168h  # 더 짧은 수명

Phase 3: 워크로드별 특화 NodePool

yaml

# GPU 워크로드용
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: gpu-workload
spec:
  template:
    metadata:
      labels:
        node-type: "gpu"
    spec:
      nodeClassRef:
        name: gpu-nodeclass
      requirements:
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ["p3.2xlarge", "p3.8xlarge"]
      taints:
        - key: "nvidia.com/gpu"
          value: "true"
          effect: NoSchedule
  limits:
    cpu: 1000
  disruption:
    consolidationPolicy: WhenEmpty  # GPU는 보수적으로
    expireAfter: 2160h  # 더 긴 수명 (비싼 인스턴스)

3. 모니터링 및 비용 최적화

Karpenter 메트릭 확인

bash

# 1. Karpenter가 생성한 노드들 확인
kubectl get nodes -l karpenter.sh/provisioner-name

# 2. NodePool 상태 확인  
kubectl get nodepools

# 3. Karpenter 이벤트 확인
kubectl get events -n karpenter --sort-by='.lastTimestamp'

# 4. 비용 추적을 위한 태그 확인
aws ec2 describe-instances \
  --filters "Name=tag:karpenter.sh/cluster,Values=$CLUSTER_NAME" \
  --query 'Reservations[].Instances[].[InstanceId,InstanceType,State.Name]'

비용 최적화 스크립트

bash

#!/bin/bash
# cost-analysis.sh

echo "=== Karpenter 비용 분석 ==="

# 현재 실행 중인 노드들
RUNNING_NODES=$(kubectl get nodes -l karpenter.sh/provisioner-name --no-headers | wc -l)
echo "📊 Karpenter 관리 노드 수: $RUNNING_NODES"

# 인스턴스 타입별 분포
echo "📈 인스턴스 타입 분포:"
kubectl get nodes -l karpenter.sh/provisioner-name -o jsonpath='{.items[*].metadata.labels.node\.kubernetes\.io/instance-type}' | tr ' ' '\n' | sort | uniq -c

# 스팟 vs 온디맨드 비율
echo "💰 Capacity Type 분포:"
kubectl get nodes -l karpenter.sh/provisioner-name -o jsonpath='{.items[*].metadata.labels.karpenter\.sh/capacity-type}' | tr ' ' '\n' | sort | uniq -c

# 예상 시간당 비용 (간단 계산)
SPOT_COUNT=$(kubectl get nodes -l karpenter.sh/provisioner-name,karpenter.sh/capacity-type=spot --no-headers | wc -l)
ONDEMAND_COUNT=$(kubectl get nodes -l karpenter.sh/provisioner-name,karpenter.sh/capacity-type=on-demand --no-headers | wc -l)

echo "💸 예상 시간당 비용:"
echo "  - Spot 인스턴스: $SPOT_COUNT 개 (평균 $0.05/시간)"
echo "  - On-Demand: $ONDEMAND_COUNT 개 (평균 $0.20/시간)"
echo "  - 총 예상 비용: $$(echo "$SPOT_COUNT * 0.05 + $ONDEMAND_COUNT * 0.20" | bc)/시간"

주의사항 및 모범 사례

1. 점진적 도입 전략

단계별 접근법

yaml

# Stage 1: 개발환경에서 검증 (1-2주)
환경: Development
위험도: Low
설정: 보수적 (온디맨드, WhenEmpty)

# Stage 2: 스테이징에서 부하 테스트 (2-3주)  
환경: Staging
위험도: Medium
설정: 중간 (스팟 혼합, WhenUnderutilized)

# Stage 3: 프로덕션 부분 적용 (4-6주)
환경: Production (non-critical workload)
위험도: Medium-High
설정: 최적화된 설정

# Stage 4: 프로덕션 전면 적용
환경: Production (all workloads)
위험도: High
설정: 검증된 최종 설정

2. 스팟 인스턴스 대응 전략

스팟 인터럽션 처리

yaml

# 스팟 친화적 워크로드 설정
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      # 스팟 노드를 허용하는 toleration
      tolerations:
      - key: "node.kubernetes.io/spot"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"
      
      # 스팟 선호도
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 50
            preference:
              matchExpressions:
              - key: karpenter.sh/capacity-type
                operator: In
                values: ["spot"]
      
      # 인터럽션 대응을 위한 설정
      terminationGracePeriodSeconds: 30

3. 비용 거버넌스

예산 제한 설정

yaml

# 노드풀별 리소스 제한
apiVersion: karpenter.sh/v1beta1
kind: NodePool
spec:
  # 팀별/프로젝트별 리소스 제한
  limits:
    cpu: 1000      # 최대 1000 코어
    memory: 1000Gi # 최대 1TB 메모리
    
  template:
    metadata:
      # 비용 추적을 위한 라벨
      labels:
        team: "backend"
        project: "ecommerce"
        environment: "production"
    spec:
      # 비용 최적화 인스턴스만 허용
      requirements:
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ["t3.medium", "t3.large", "t3.xlarge"]
          # 비싼 인스턴스 제외 (예: r5.24xlarge)

성능 및 비용 효과 분석

Before vs After 비교

기존 Cluster Autoscaler

yaml

# 문제점들
평균 노드 프로비저닝 시간: 3-5분 ⏰
리소스 낭비율: 30-50% 💸
운영 복잡도: 높음 😰
인스턴스 타입 유연성: 제한적 📦

# 월간 비용 (예시)
EC2 인스턴스 비용: $2,400
낭비되는 리소스: $1,200 (50%)
총 비용: $3,600/월

Karpenter 도입 후

yaml

# 개선 효과
평균 노드 프로비저닝 시간: 30초-1분 ⚡
리소스 낭비율: 10-20% ✅
운영 복잡도: 낮음 😊
인스턴스 타입 유연성: 매우 높음 🎯

# 월간 비용 (예시)
EC2 인스턴스 비용: $1,800 (스팟 활용)
낭비되는 리소스: $200 (10%)
총 비용: $2,000/월
절약액: $1,600/월 (44% 절감!) 💰

실제 측정 방법

bash

# 성능 측정 스크립트
#!/bin/bash
# performance-test.sh

echo "=== Karpenter 성능 테스트 ==="

# 1. 노드 프로비저닝 시간 측정
echo "노드 프로비저닝 시간 테스트 시작..."
START_TIME=$(date +%s)

# 대용량 Pod 생성으로 노드 프로비저닝 유도
kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: load-test
spec:
  replicas: 10
  selector:
    matchLabels:
      app: load-test
  template:
    metadata:
      labels:
        app: load-test
    spec:
      containers:
      - name: stress
        image: nginx
        resources:
          requests:
            cpu: 1000m
            memory: 1Gi
EOF

# Pod가 Running이 될 때까지 대기
kubectl wait --for=condition=Ready pod -l app=load-test --timeout=300s

END_TIME=$(date +%s)
DURATION=$((END_TIME - START_TIME))

echo "✅ 프로비저닝 완료 시간: ${DURATION}초"

# 2. 리소스 효율성 측정
echo "📊 리소스 사용률 분석:"
kubectl top nodes

# 정리
kubectl delete deployment load-test

고급 활용 사례

1. 멀티 테넌트 환경 구성

yaml

# 팀별 전용 NodePool 구성
---
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: team-frontend
spec:
  template:
    metadata:
      labels:
        team: frontend
    spec:
      nodeClassRef:
        name: default
      # 프론트엔드 최적화 인스턴스
      requirements:
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ["t3.medium", "t3.large"]
      taints:
        - key: "team"
          value: "frontend"
          effect: NoSchedule
  limits:
    cpu: 200
---
apiVersion: karpenter.sh/v1beta1
kind: NodePool  
metadata:
  name: team-backend
spec:
  template:
    metadata:
      labels:
        team: backend
    spec:
      nodeClassRef:
        name: default
      # 백엔드 최적화 인스턴스 (메모리 중심)
      requirements:
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ["r5.large", "r5.xlarge"]
      taints:
        - key: "team"  
          value: "backend"
          effect: NoSchedule
  limits:
    cpu: 500

2. CI/CD 파이프라인 최적화

yaml

# 빌드 전용 NodePool
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: ci-builds
spec:
  template:
    metadata:
      labels:
        workload-type: ci-build
    spec:
      nodeClassRef:
        name: build-optimized
      # 빌드에 최적화된 CPU 중심 인스턴스
      requirements:
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ["c5.large", "c5.xlarge", "c5.2xlarge"]
        # 스팟 인스턴스로 비용 절감
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot"]
      taints:
        - key: "workload-type"
          value: "ci-build"  
          effect: NoSchedule
  limits:
    cpu: 100
  disruption:
    # 빌드 완료 후 빠른 정리
    consolidationPolicy: WhenEmpty
    consolidateAfter: 10s
    # 짧은 수명으로 비용 최적화
    expireAfter: 2h

3. 배치 작업 최적화

yaml

# 배치 처리 전용 NodePool
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: batch-processing
spec:
  template:
    metadata:
      labels:
        workload-type: batch
    spec:
      nodeClassRef:
        name: batch-optimized
      requirements:
        # 대용량 메모리 인스턴스
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ["r5.2xlarge", "r5.4xlarge", "r5.8xlarge"]
        # 스팟으로 최대 비용 절감
        - key: karpenter.sh/capacity-type
          operator: In  
          values: ["spot"]
      taints:
        - key: "workload-type"
          value: "batch"
          effect: NoSchedule
  disruption:
    # 배치 작업 완료 후 즉시 정리
    consolidationPolicy: WhenEmpty
    consolidateAfter: 5s
    # 매우 짧은 수명
    expireAfter: 4h

트러블슈팅 가이드

1. 일반적인 문제들

노드가 프로비저닝되지 않는 경우

bash

# 1. Karpenter 로그 확인
kubectl logs -n karpenter deployment/karpenter -f

# 2. NodePool 상태 확인
kubectl describe nodepool

# 3. Pod 이벤트 확인
kubectl describe pod <pending-pod-name>

# 일반적인 원인들:
# - IAM 권한 부족
# - 서브넷/보안그룹 태그 누락  
# - 인스턴스 한도 초과
# - NodePool 리소스 제한 도달

Consolidation이 작동하지 않는 경우

bash

# 1. PodDisruptionBudget 확인
kubectl get pdb --all-namespaces

# 2. Pod anti-affinity 규칙 확인  
kubectl get pods -o yaml | grep -A 10 "podAntiAffinity"

# 3. Karpenter consolidation 로그 확인
kubectl logs -n karpenter deployment/karpenter -f | grep -i consolidat

2. 응급 대응 가이드

예상치 못한 대량 스케일 아웃 시

bash

# 1. 긴급 NodePool 제한 설정
kubectl patch nodepool default --type='merge' -p='{"spec":{"limits":{"cpu":"100"}}}'

# 2. 특정 NodePool 일시 중지
kubectl patch nodepool batch-processing --type='merge' -p='{"spec":{"template":{"spec":{"requirements":[{"key":"node.kubernetes.io/instance-type","operator":"In","values":["t3.nano"]}]}}}}'

# 3. 불필요한 Pod 스케일 다운
kubectl scale deployment expensive-app --replicas=0

결론 및 실무 권장사항

Karpenter는 Kubernetes 노드 관리 방식을 바꾸는 도구입니다. 기존 Cluster Autoscaler의 한계를 극복해, 더 빠르고 비용 효율적으로 노드를 프로비저닝합니다.

핵심 성공 요인

1. 단계적 도입

개발환경 → 스테이징 → 프로덕션 순서로 점진 적용
작은 규모부터 시작하여 경험 축적

2. 적절한 정책 조합

consolidationPolicy: 환경별 맞춤 설정
expireAfter: 보안과 비용의 균형점 찾기
스팟 인스턴스: 점진적으로 비중 확대

3. 지속적 모니터링

비용 효과 측정 및 최적화
성능 임팩트 모니터링
장애 대응 계획 수립

최종 권장사항

도입하면 좋은 경우

AWS EKS 환경에서 노드 관리 복잡도 해결 필요
다양한 워크로드로 인한 리소스 낭비 심각
빠른 스케일링과 비용 최적화가 중요
스팟 인스턴스 활용으로 비용 절감 필요

신중히 검토해야 하는 경우

매우 안정적인 노드가 절대적으로 필요한 환경
AWS 외 다른 클라우드 환경 (아직 제한적)
레거시 애플리케이션이 많은 환경

실무 체크리스트

도입 전:

[ ] IAM 권한 및 서비스 계정 준비
[ ] 서브넷, 보안그룹 태깅 완료
[ ] 기존 워크로드 리소스 요구사항 분석
[ ] 비용 베이스라인 측정
[ ] 롤백 계획 수립

도입 후:

[ ] 노드 프로비저닝 시간 측정
[ ] 리소스 사용률 개선 확인
[ ] 스팟 인터럽션 처리 검증
[ ] 비용 절감 효과 측정
[ ] 팀 교육 및 운영 가이드 정비

Karpenter를 적절히 활용하면 비용 절감과 운영 효율성을 동시에 얻을 수 있습니다.

Karpenter 정리: Kubernetes 노드 오토스케일링

개요

왜 Karpenter가 필요했을까?

클러스터 오토스케일러의 한계점

1. 노드 그룹 기반의 제약적 스케일링

2. 느린 스케일링 속도

3. 비효율적인 리소스 활용

Karpenter의 해결 접근법

Karpenter 핵심 아키텍처

주요 컴포넌트

1. Karpenter Controller

2. NodePool (이전 Provisioner)

3. EC2NodeClass

핵심 동작 원리

1. 실시간 스케줄링 감지

2. 최적 인스턴스 선택 알고리즘

3. 빠른 프로비저닝 과정

주요 기능

1. 다중 아키텍처 지원

2. 스팟 인스턴스 최적화

3. 세밀한 리소스 제어

Consolidation: 노드 최적화

개념 및 필요성

문제 상황

Consolidation 후

Consolidation 설정

1. 기본 Consolidation 설정

2. 고급 Consolidation 설정

Consolidation 동작 과정

실습: Consolidation 효과 측정

expireAfter: 노드 생명주기 관리

개념

설정 방법

실무 권장사항

환경별 expireAfter 설정

expireAfter vs 다른 정책들의 조합

실무 구현 가이드

1. Karpenter 설치 및 기본 설정

IRSA (IAM Role for Service Account) 생성

Helm으로 Karpenter 설치

2. 단계적 NodePool 구성 전략

Phase 1: 기본 NodePool (안전한 시작)

Phase 2: 스팟 인스턴스 도입

Phase 3: 워크로드별 특화 NodePool

3. 모니터링 및 비용 최적화

Karpenter 메트릭 확인

비용 최적화 스크립트

주의사항 및 모범 사례

1. 점진적 도입 전략

단계별 접근법

2. 스팟 인스턴스 대응 전략

스팟 인터럽션 처리

3. 비용 거버넌스

예산 제한 설정

성능 및 비용 효과 분석

Before vs After 비교

기존 Cluster Autoscaler

Karpenter 도입 후

실제 측정 방법

고급 활용 사례

1. 멀티 테넌트 환경 구성

2. CI/CD 파이프라인 최적화

3. 배치 작업 최적화

트러블슈팅 가이드

1. 일반적인 문제들

노드가 프로비저닝되지 않는 경우

Consolidation이 작동하지 않는 경우

2. 응급 대응 가이드

예상치 못한 대량 스케일 아웃 시

결론 및 실무 권장사항

핵심 성공 요인

1. 단계적 도입

2. 적절한 정책 조합

3. 지속적 모니터링

최종 권장사항

도입하면 좋은 경우

신중히 검토해야 하는 경우

실무 체크리스트

참고 자료