Karpenter로 쿠버네티스 노드 비용 40% 절감하기 2026 오토스케일링 실전

쿠버네티스 클러스터를 운영하다 보면 노드가 필요 이상으로 놀거나, 반대로 파드가 스케줄링되지 못해 대기하는 상황을 자주 겪는다. 전통적인 클러스터 오토스케일러(Cluster Autoscaler)는 미리 정의된 노드 그룹 안에서만 스케일을 조정하기 때문에 유연성이 떨어졌다. 카펜터(Karpenter)는 이 접근을 완전히 뒤집는다. 노드 그룹이라는 개념 없이 실제로 대기 중인 파드의 요구사항을 직접 분석해 가장 저렴하고 적합한 인스턴스 타입을 실시간으로 골라 프로비저닝한다. 2026년 현재 카펜터는 v1.x 정식 버전으로 안정화되어 대규모 프로덕션에서 광범위하게 쓰인다.

카펜터가 클러스터 오토스케일러보다 나은 점

기존 오토스케일러는 오토스케일링 그룹(ASG)에 의존한다. 관리자가 미리 인스턴스 타입을 정해 그룹을 만들어두면, 스케일 아웃이 필요할 때 그 그룹에서만 노드를 추가한다. 문제는 워크로드의 리소스 요구가 다양할 때 발생한다. GPU가 필요한 파드, 메모리 집약적인 파드, CPU 위주 파드가 섞여 있으면 각각을 위한 노드 그룹을 미리 만들어야 하고, 어느 그룹도 딱 맞지 않으면 자원이 낭비된다.

카펜터는 스케줄링되지 못한 파드를 감지하면 그 파드의 CPU, 메모리, 아키텍처, 노드 셀렉터, 어피니티, 톨러레이션을 모두 종합해 가장 적합한 인스턴스를 즉석에서 선택한다. 수백 가지 인스턴스 타입 중 요구를 만족하면서 가장 저렴한 것을 고르므로 자원 낭비가 극적으로 줄어든다. 노드 부팅 시간도 빨라져서, 파드가 대기 상태에서 실행 상태로 넘어가는 시간이 기존 방식보다 훨씬 짧다.

NodePool과 스팟 인스턴스 설정

카펜터의 핵심 리소스는 NodePool과 EC2NodeClass다. NodePool은 어떤 종류의 노드를 어떤 제약 아래 만들지 정의하고, EC2NodeClass는 AMI, 서브넷, 보안 그룹 같은 인프라 세부사항을 담는다. 비용 절감의 열쇠는 스팟 인스턴스를 적극 활용하되, 중단에 견딜 수 있도록 다양한 인스턴스 타입을 허용하는 것이다.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64", "arm64"]
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: ["c", "m", "r"]
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s
  limits:
    cpu: "1000"

여기서 consolidationPolicy를 WhenEmptyOrUnderutilized로 설정하면 카펜터가 지속적으로 클러스터를 관찰하다가, 파드를 더 적은 노드로 재배치할 수 있으면 자동으로 통합한다. 예를 들어 세 노드에 흩어진 파드가 두 노드에 들어갈 수 있다면 한 노드를 제거하고 파드를 옮긴다. 이 통합 기능이 실제 비용 절감의 가장 큰 부분을 차지한다.

실전 운영 팁과 주의사항

스팟 인스턴스를 쓸 때는 중단 처리를 반드시 고려해야 한다. AWS는 스팟 노드 회수 2분 전에 알림을 보내며, 카펜터는 이 신호를 받아 파드를 미리 다른 노드로 안전하게 옮긴다. 하지만 상태가 있는 워크로드나 재시작 비용이 큰 배치 작업은 온디맨드를 섞어 안정성을 확보하는 편이 낫다. ARM 기반 그래비톤 인스턴스를 허용 목록에 넣으면 같은 성능을 더 낮은 가격에 얻을 수 있어 추가 절감 효과가 크다. 다만 이미지가 멀티 아키텍처를 지원하는지 먼저 확인해야 한다.

통합 정책을 공격적으로 설정하면 비용은 줄지만 파드 재스케줄링이 잦아져 짧은 지연이 생길 수 있다. 지연에 민감한 서비스에는 파드 중단 예산(PodDisruptionBudget)을 설정해 동시에 내려가는 파드 수를 제한하는 것이 안전하다. 또 카펜터가 지나치게 큰 노드를 하나 만들어 여러 파드를 몰아넣는 것을 막으려면 NodePool의 limits로 상한을 두고, 필요하면 토폴로지 분산 제약으로 가용 영역에 고르게 퍼뜨린다. 실제 적용 사례에서 스팟 비중 확대와 그래비톤 전환, 통합 정책 최적화를 결합하면 컴퓨트 비용을 30퍼센트에서 40퍼센트까지 낮추는 경우가 흔하다. 도입 초기에는 통합 정책을 보수적으로 시작해 워크로드 안정성을 확인한 뒤 점진적으로 조여가는 접근을 권한다.

워크로드 특성에 맞춘 NodePool 분리

모든 워크로드를 하나의 NodePool로 묶으면 카펜터가 최적 결정을 내리기 어렵다. 성격이 다른 워크로드는 별도 NodePool로 나누는 것이 정석이다. 예를 들어 상태가 없고 중단에 강한 웹 서버는 스팟 비중을 높인 NodePool에, 데이터베이스나 메시지 큐처럼 안정성이 중요한 워크로드는 온디맨드 위주의 NodePool에 배치한다. 배치 처리나 머신러닝 학습처럼 GPU가 필요한 작업은 GPU 인스턴스만 허용하는 별도 NodePool로 격리한다. 이렇게 나누면 각 NodePool이 자기 목적에 맞는 인스턴스만 선택하므로 낭비가 줄고, 워크로드 간 간섭도 방지된다.

관측성 확보도 비용 최적화의 필수 요소다. 카펜터가 어떤 결정을 왜 내렸는지 로그로 남기므로, 노드가 갑자기 늘거나 줄었을 때 그 이유를 추적할 수 있다. 여기에 클러스터 비용을 시각화하는 도구를 붙이면 어떤 네임스페이스와 워크로드가 비용을 얼마나 쓰는지 한눈에 파악된다. 실무에서는 파드마다 리소스 요청값을 정확히 설정하는 것이 중요하다. 요청값이 실제 사용량보다 과하게 크면 카펜터가 필요 이상으로 큰 노드를 띄우고, 반대로 너무 작으면 노드가 과밀해져 성능이 떨어진다. 리소스 요청값을 실제 사용 패턴에 맞게 튜닝하는 작업이 병행되어야 카펜터의 효율이 온전히 발휘된다.

마지막으로 업그레이드 전략도 고려해야 한다. 카펜터는 노드 이미지가 갱신되면 기존 노드를 순차적으로 교체하는 드리프트 감지 기능을 제공한다. 이를 통해 보안 패치가 적용된 최신 이미지로 클러스터를 무중단에 가깝게 유지할 수 있다. 다만 대규모로 노드를 교체할 때는 파드 중단 예산과 함께 사용해 서비스 가용성을 지켜야 한다. 결국 카펜터는 단순한 비용 절감 도구가 아니라, 클러스터의 라이프사이클 전반을 자동화하는 플랫폼 엔지니어링의 핵심 축으로 이해하는 것이 옳다.