[Kubernetes] Karpenter vs Cluster Autoscaler 비교 분석

Karpenter vs Cluster Autoscaler 이야기는 Kubernetes(쿠버네티스) 운영하시는 분들이 한 번쯤 꼭 부딪히는 주제입니다. 파드(Pod)가 늘어나는데 노드(Node)가 제때 안 붙으면 서비스가 밀리고, 반대로 너무 빨리 늘어나면 비용이 튀거든요. 저도 처음엔 HPA(Horizontal Pod Autoscaler, 파드 수평 확장)만 잘 걸어두면 끝인 줄 알았는데, 실제로 운영해보니 워크로드 확장과 노드 확장은 완전히 다른 문제더라고요. 특히 EKS 같은 클라우드 환경에서 직접 써보니까 Karpenter와 Cluster Autoscaler는 비슷해 보여도 철학이 꽤 다릅니다.

이번 글에서는 Karpenter vs Cluster Autoscaler를 실무 관점에서 비교해보겠습니다. 단순히 기능 목록만 나열하는 게 아니라, 어떤 워크로드에서 무엇이 더 잘 맞는지, 설치할 때 어디서 삽질하는지, 검증은 어떻게 해야 하는지까지 정리해보겠습니다. 혹시 지금 Kubernetes 오토스케일링 구성을 만지시는 중이라면 꽤 바로 도움이 되실 겁니다.

Cluster Autoscaler와 Karpenter가 각각 어떤 방식으로 노드를 늘리고 줄이는지 한눈에 보여주는 개요 다이어그램이 들어갈 자리입니다.

Kubernetes 오토스케일링이 왜 생각보다 어렵냐면요

쉽게 말해, Kubernetes 오토스케일링은 두 층으로 나뉩니다. 하나는 파드 수를 늘리는 것이고, 다른 하나는 그 파드를 올릴 노드를 확보하는 것입니다. HPA가 앞단이라면, Karpenter나 Cluster Autoscaler는 뒷단이라고 보시면 됩니다.

• HPA: CPU, 메모리, 커스텀 메트릭 기준으로 파드 수를 늘리고 줄립니다.
• Cluster Autoscaler: 기존 노드 그룹(Node Group, 노드 묶음)의 크기를 늘리거나 줄입니다.
• Karpenter: 스케줄링되지 못한 파드를 보고, 필요한 조건에 맞는 노드를 더 직접적으로 프로비저닝(Provisioning, 자원 생성)합니다.

여기서 중요한 포인트가 하나 있습니다. Cluster Autoscaler는 미리 정의된 노드 그룹 중심으로 생각하고, Karpenter는 파드 요구사항 중심으로 생각합니다. 이 차이가 운영 난이도, 비용 최적화, 확장 속도에 꽤 큰 영향을 줍니다.

Karpenter vs Cluster Autoscaler: 핵심 개념 차이

처음 문서를 보면 둘 다 자동으로 노드를 늘려주는 도구라서 별 차이 없어 보이는데요, 실제로 써보면 운영 감각이 다릅니다. 제가 직접 비교하면서 느낀 건 아래 표 하나로 많이 정리되더라고요.

정리하면 이렇습니다. Cluster Autoscaler는 전통적인 방식입니다. 이미 만들어 둔 노드 그룹이 있고, 그 그룹의 min/max 범위 안에서 증감시키죠. 반면 Karpenter는 필요한 자원을 그때그때 맞춰 뽑아내는 쪽에 가깝습니다. 그래서 워크로드 패턴이 자주 바뀌거나, 다양한 인스턴스 타입을 섞어 쓰고 싶을 때 체감이 꽤 납니다.

언제 Karpenter가 유리하고, 언제 Cluster Autoscaler가 편한가

이건 솔직히 정답이 하나는 아닙니다. 운영팀 성향, 클러스터 규모, 클라우드 의존도에 따라 달라지거든요. 저도 처음엔 무조건 신형이 좋아 보였는데, 몇 번 굴려보니 케이스가 나뉘더라고요.

Cluster Autoscaler가 잘 맞는 경우

• 이미 Managed Node Group 기반 운영 체계가 안정적으로 잡혀 있는 경우
• 보안, 승인, 변경 관리 때문에 노드 타입을 엄격히 통제해야 하는 경우
• 여러 팀이 공용으로 쓰는 클러스터라서 예측 가능한 증설 패턴이 중요한 경우
• 기존 운영팀이 노드 그룹 기반 모델에 익숙한 경우

Karpenter가 잘 맞는 경우

• 워크로드 확장 패턴이 들쭉날쭉해서 빠른 대응이 필요한 경우
• 다양한 인스턴스 타입 조합으로 비용 최적화를 하고 싶은 경우
• 스케줄링 요구사항이 세밀해서 노드 그룹을 많이 쪼개기 싫은 경우
• 빈번한 배치 작업, CI 러너, 이벤트성 트래픽처럼 탄력성이 중요한 경우

제 경험상 노드 그룹이 많아질수록 Cluster Autoscaler는 운영 피로도가 올라갑니다. 반대로 Karpenter는 초반 설계만 잘못 잡으면 예상치 못한 노드 생성 패턴 때문에 당황하게 되더라고요. 그러니까 둘 중 뭐가 무조건 더 좋다기보다, 운영 모델에 맞는 선택이 더 중요합니다.

실전 구현 1: Cluster Autoscaler 구성 흐름

먼저 Cluster Autoscaler부터 보겠습니다. 예시는 EKS 환경 기준으로 적겠습니다. 다른 클라우드에서도 개념은 비슷합니다. 핵심은 오토스케일 대상 노드 그룹이 먼저 존재해야 한다는 점입니다.

1. 오토스케일 가능한 노드 그룹을 준비합니다.
2. 노드 그룹의 최소/최대 크기를 정합니다.
3. Cluster Autoscaler를 클러스터에 배포합니다.
4. 스케줄 불가 파드가 생기면 해당 노드 그룹 크기를 늘립니다.

helm repo add autoscaler https://kubernetes.github.io/autoscaler
helm repo update

helm upgrade --install cluster-autoscaler autoscaler/cluster-autoscaler \
  --namespace kube-system \
  --set autoDiscovery.clusterName=my-cluster \
  --set awsRegion=ap-northeast-2 \
  --set rbac.serviceAccount.create=true

설치 자체는 그렇게 복잡하지 않습니다. 근데 실제로는 IAM(Role, 권한 역할), 오토디스커버리 태그, 노드 그룹 min/max 값 같은 주변 설정에서 삽질을 많이 하게 됩니다. 특히 노드 그룹 태그가 안 맞으면 파드가 Pending(펜딩, 스케줄 대기) 상태로 남아 있는데도 노드가 안 늘어납니다. 저도 처음엔 로그만 한참 봤네요.

kubectl -n kube-system logs deploy/cluster-autoscaler
kubectl get pods -A
kubectl describe pod <pending-pod-name>

여기서 보는 포인트는 간단합니다. 파드가 왜 스케줄링되지 않았는지, 그리고 Cluster Autoscaler가 어떤 노드 그룹을 확장 후보로 판단했는지입니다.

실전 구현 2: Karpenter 구성 흐름

Karpenter는 접근 방식이 다릅니다. 미리 노드 그룹을 세세하게 많이 만들기보다, 어떤 종류의 노드를 허용할지 정책으로 정의하는 느낌에 가깝습니다. 그래서 처음엔 구조가 낯선 감이 있더라고요. 저도 처음엔 이게 뭔가 싶었는데, 한번 감을 잡고 나니 꽤 편하더라고요.

1. Karpenter 컨트롤러를 설치합니다.
2. 클라우드 권한과 네트워크 조건을 연결합니다.
3. 어떤 노드를 만들 수 있는지 정책을 정의합니다.
4. 스케줄 불가 파드가 생기면 그 요구사항을 기반으로 노드를 생성합니다.

helm repo add karpenter https://charts.karpenter.sh
helm repo update

helm upgrade --install karpenter karpenter/karpenter \
  --namespace karpenter \
  --create-namespace

apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: default
spec:
  requirements:
    - key: kubernetes.io/arch
      operator: In
      values:
        - amd64
    - key: kubernetes.io/os
      operator: In
      values:
        - linux
  limits:
    resources:
      cpu: "1000"
  ttlSecondsAfterEmpty: 30

요즘 Karpenter 관련 리소스 모델은 환경과 시점에 따라 구성이 조금씩 달라질 수 있어서, 실제 배포 전에는 현재 사용하는 배포 가이드와 CRD(Custom Resource Definition, 사용자 정의 리소스 정의)를 반드시 맞춰보셔야 합니다. 여기서는 비교 분석이 핵심이라, 파드 요구사항 기반으로 노드를 뽑아낸다는 운영 개념에 집중해서 보시면 됩니다.

Karpenter가 파드의 요구 리소스를 읽고 적절한 노드를 동적으로 생성하는 흐름을 설명하는 구성 이미지 자리입니다.

워크로드 확장 테스트: 직접 확인하는 방법

설치보다 중요한 게 검증입니다. 오토스케일링은 붙어 있다고 끝이 아니거든요. 원하는 타이밍에, 원하는 방식으로, 과하지 않게 확장되는지를 봐야 합니다. 저는 보통 부하 테스트용 디플로이먼트(Deployment)를 하나 띄워두고 확인합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: inflate
spec:
  replicas: 1
  selector:
    matchLabels:
      app: inflate
  template:
    metadata:
      labels:
        app: inflate
    spec:
      containers:
        - name: inflate
          image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
          resources:
            requests:
              cpu: "1"
              memory: "1Gi"
            limits:
              cpu: "1"
              memory: "1Gi"

kubectl apply -f inflate.yaml
kubectl scale deployment inflate --replicas=20
kubectl get pods -w
kubectl get nodes -w

이 테스트에서 봐야 할 건 세 가지입니다.

• 확장 속도: Pending 파드가 얼마나 빨리 해소되는지
• 적합성: 필요한 크기의 노드가 제대로 붙는지
• 정리 속도: 부하가 끝난 뒤 빈 노드가 얼마나 깔끔하게 제거되는지

실제로 써보니까 Karpenter는 워크로드 확장에 좀 더 민감하게 반응하는 느낌이 있었고, Cluster Autoscaler는 노드 그룹 구조를 잘 짜놨을 때 안정감이 있었습니다. 드디어 됐다! 싶은 순간이 오긴 오는데, 그 전에 로그와 이벤트를 많이 보게 됩니다 ㅎㅎ

파드가 Pending 상태가 되었다가 새 노드가 생성되고 Running으로 전환되는 과정을 단계별로 보여주는 이미지 자리입니다.

⚠️ 제가 실제로 자주 겪었던 트러블슈팅 포인트

이 섹션이 제일 중요할 수도 있습니다. 문서대로만 보면 금방 될 것 같지만, 현실은 그렇지 않더라고요.

1. 파드는 Pending인데 노드가 안 늘어나는 경우

• 리소스 요청값(requests)이 비현실적으로 큰지 확인합니다.
• 노드 선택 조건(nodeSelector, affinity, taint/toleration)이 너무 빡빡한지 봅니다.
• Cluster Autoscaler라면 대상 노드 그룹 태그와 범위를 확인합니다.
• Karpenter라면 허용된 인스턴스 조건과 서브넷/보안 그룹 연결을 확인합니다.

처음엔 저도 컨트롤러 문제인 줄 알았는데, 알고 보니 파드 스펙 자체가 너무 까다로운 경우가 꽤 있었습니다. 특히 GPU나 특정 아키텍처를 요구하는 워크로드는 더 그렇습니다.

2. 노드는 늘어나는데 생각보다 비효율적인 경우

이건 비용 문제로 바로 이어집니다. Cluster Autoscaler는 노드 그룹 단위로 움직이기 때문에, 작은 파드 몇 개 때문에 상대적으로 큰 노드가 붙는 상황이 생기곤 합니다. Karpenter도 제약 조건을 널널하게 열어두면 예상보다 다양한 노드가 만들어지곤 해요. 그래서 요청 리소스(requests) 튜닝이 정말 중요합니다.

3. 축소(scale down)가 너무 늦거나 안 되는 경우

• PodDisruptionBudget(PDB, 파드 중단 예산) 때문에 축소가 막힐 수 있습니다.
• DaemonSet(데몬셋)과 로컬 스토리지 사용 여부도 확인해야 합니다.
• 노드가 비어 보여도 eviction(축출) 조건 때문에 남아 있을 수 있습니다.

이 부분은 진짜 많이 놓칩니다. 저도 한동안 왜 비용이 안 줄지 봤더니, 특정 시스템 파드가 노드 정리를 막고 있더라고요.

검증과 결과: 무엇을 기준으로 비교해야 하나

Karpenter vs Cluster Autoscaler를 비교할 때 단순히 “누가 더 빠르냐”만 보면 아쉽습니다. 운영에서는 아래 기준으로 보시는 걸 추천드립니다.

제가 여러 번 테스트하면서 느낀 결론은 이렇습니다.

• 보수적이고 예측 가능한 운영이 중요하면 Cluster Autoscaler가 편합니다.
• 유연한 워크로드 확장과 세밀한 자원 최적화가 중요하면 Karpenter가 매력적입니다.
• 둘 다 잘 쓰려면 결국 파드 스펙, 요청 리소스, 스케줄링 제약조건을 먼저 정리해야 합니다.

kubectl top pods -A
kubectl top nodes
kubectl get events --sort-by=.lastTimestamp
kubectl describe node <node-name>

이 명령어들만 잘 봐도 현재 Kubernetes 오토스케일링이 어디에서 막히는지 감이 꽤 옵니다. 대시보드만 보지 마시고 이벤트(event)와 describe 출력도 꼭 같이 보세요. 진짜 차이가 여기서 보이거든요.

노드 수 변화, 파드 Pending 해소, 리소스 사용률 등을 한눈에 보여주는 결과 검증용 대시보드 이미지 자리입니다.

실무 선택 가이드: 그래서 무엇을 고르면 되냐

질문을 많이 받는 부분이라 아주 현실적으로 정리해보겠습니다.

1. 기존에 노드 그룹 체계가 잘 잡혀 있고 변경 리스크를 줄이고 싶다면 Cluster Autoscaler부터 가는 게 안전합니다.
2. 새 클러스터를 설계하거나, 워크로드 종류가 다양하고 변동폭이 크다면 Karpenter를 적극 검토할 만합니다.
3. 어떤 도구를 쓰든 HPA, requests/limits, affinity 정책을 먼저 정리하지 않으면 효과가 반감됩니다.
4. 운영팀이 디버깅하기 쉬운 구조인지도 꼭 보셔야 합니다. 기술적으로 좋아 보여도 팀이 못 다루면 오래 못 갑니다.

여기서 중요한 포인트! Karpenter vs Cluster Autoscaler의 승부는 기능표가 아니라 운영 방식에서 갈립니다. 홈랩에서 실험할 때도 그렇고 실제 서비스에서도 그렇고, 결국 오래 버티는 건 팀이 이해하고 통제할 수 있는 구조였습니다.

정리와 FAQ

정리하자면, Cluster Autoscaler는 익숙하고 보수적인 선택지입니다. Karpenter는 더 유연하고 워크로드 중심적인 선택지이고요. 어느 쪽이든 워크로드 확장의 핵심은 파드와 노드의 관계를 제대로 이해하는 데 있습니다. 저도 처음엔 단순히 “자동으로 늘려준다” 정도로 생각했었는데, 실제로 써보니까 오토스케일링은 설계의 문제더라고요.

다음 글에서는 HPA와 VPA(Vertical Pod Autoscaler, 수직 오토스케일러)를 함께 붙였을 때 어떤 점을 조심해야 하는지 다뤄볼 예정입니다. 이전 글에서 다뤘던 Ingress(인그레스, 외부 트래픽 진입점)와 서비스 분리 구조를 같이 보시면 더 이해가 잘 되실 겁니다.

자주 묻는 질문

• Q. 둘을 동시에 써도 되나요?
  A. 환경과 목적에 따라 가능은 하지만, 노드 프로비저닝 책임이 겹치지 않도록 설계를 분명히 나누는 게 중요합니다.
• Q. Kubernetes 오토스케일링에서 가장 먼저 봐야 할 건 뭔가요?
  A. 파드 requests/limits와 스케줄링 제약조건입니다. 여기서 꼬이면 어떤 오토스케일러를 써도 답답합니다.
• Q. 초보 운영자에게는 뭐가 더 쉬운가요?
  A. 이미 노드 그룹 개념이 익숙하다면 Cluster Autoscaler가 더 이해하기 쉬운 편입니다. 다만 장기적으로는 Karpenter의 유연성이 매력적일 수 있습니다.

두 오토스케일러의 장단점, 추천 시나리오, 선택 기준을 한 장으로 정리한 마무리용 인포그래픽 자리입니다.

✅ 결론만 짧게 말하면 이렇습니다. 안정성과 익숙함이면 Cluster Autoscaler, 유연성과 최적화면 Karpenter입니다. 다만 둘 다 만능은 아니고, 결국 좋은 오토스케일링은 좋은 워크로드 설계에서 시작합니다. 이거 진짜 중요합니다.