Woojae Joo ursonice

[Kubernetes] AutoScaling

작성 2025년 6월 29일수정 2025년 6월 30일

Cluster 관점

Horizontal Scaling

  • 노드 갯수 조절
  • 노드를 옆으로 늘리는 것으로 예를들어 서버가 3대인데 자원이 부족해서 서버를 3대 더 추가해 총 6대로 만드는 것이다.

    스케일링 방법

    Manual Way(수동 방식)
    • 새 서버를 직접 준비하고 kubeadm join 명령으로 클러스터에 노드로 추가라는 것이다.
      • 프로피저닝: 새 노드를 그냥 빈 컴퓨터(서버)일 수 있음으로 도커나 쿠버네티스 등을 설치하고 클러스터에 참여할 준비를 마치는 것.

Vertical Scaling

  • 노드 사양 조절
  • 기존 노드의 성능을 위로 높이는 것으로 예를들어 서버 1대의 CPU나 메모리를 더 장착하는 것이다.

    스케일링 방법

    Manual Way(수동 방식)
    • 서버를 종료한 뒤 CPU, 메모리를 더 장착한 후 서버를 다시 시작한다.
    • 이 방식은 쿠버네티스에서 권장되는 방법이 아니다.

Workload 관점

Horizontal Scaling

  • 파드 갯수 조정
  • 파드를 더 많이 생성하는 것으로 예를들어 웹 서버를 1개에서 5개로 늘리는 것이다.

    스케일링 방법

    Manual Way(수동 방식)
    • kubectl scale 명령으로 파드 수를 늘리거나 줄이는 식으로 수동으로 처리한다.
    • 이 방식은 항상 개발자가 모니터앞에 앉아서 사용량을 확인하고 CPU사용량이 많아지면 그때 명령어를 직접 입력해 확장해줘야 한다는 것이다.
    • 또한 갑작스럽게 트래픽이 증가하는 경우 대처하지 못할 수 있다.
    • 이를 해결하기 위해 자동 방식인 HPA를 사용한다.
    Automated Way(자동 방식)
    • Horizontal Pod Autoscaler(HPA)
      • HPA는 top 명령으로 수동 모니터링하던 지표를 지속적으로 감시한다.
      • 그리고 CPU, 메모리, 사용자 정의 지표에 따라 Deployment, StatefulSet, ReplicaSet의 파드 수를 자동으로 늘리거나 줄인다.
      • CPU나 메모리 사용량이 너무 높아지면 HPA가 추가 파드를 생성해 부하를 분산한다.
      • 사용량이 낮아지면 불필요한 파드를 제거해 자원을 절약한다.

      아래 그림을 봐보면 HPA를 실행했고 CPU 사용량이 50% 이상 사용되면 파드설정 파일의 Replicaset갯수만큼 Scaling한다.

      이때 최대 1개에서 10까지 파드가 생성되도록 최소/최대 값을 걸어준다.

      더 이상 HAP가 필요없는 경우에는 삭제가 가능하다.

    • 이렇게 명령형(Imperative)방식 말고도 선언형(Declarative)방식으로도 사용 가능하다.
    • scaleTargetRef 항목을 통해 HPA가 감시할 대상을 지정한다. 여기서는 Deployment로 실행되는 my-app이다.
    • 그 다음 최소/최대로 확장/축소할 값을 설정한다.
    • 마지막으로 metrics를 통해 감시할 지표를 설정한다. 여기서는 CPU 사용률을 50%로 지정했다.
    • HPA는 Kubernetes 1.23부터 내장되어 있어 따로 설치할 필요가 없으며 Metrics Server가 필수이므로 반드시 설치되어 있어야한다.
    • 왜냐하면 HPA는 현재 리소스 사용량을 얻기 위해 Metrics Server에 의존하기 때문이다.

    Metrics Server

Vertical Scaling

  • 파드 리소스 조정
  • 기존 파드에 할당된 CPU나 메모리를 늘리는 것으로 예를들어 웹서버가 사용할 수 있는 CPU와 메모리 리소스를 2배로 늘리는 것이다.

    스케일링 방법

    Manual Way(수동 방식)
    • kubectl edit 명령으로 관련 Deployment, StatefulSet, ReplicaSet등을 열어 파드의 리소스 limits값과 requests값을 수정한다.
    • 파드 리소스 요구량을 변경하면, 기본 동작은 기존 파드를 삭제한 뒤 변경 사항을 반영한 새 파드를 생성한다.
    • 즉, 파드의 리소스 정의 변경은 제자리(In-place)에서 적용되지 않으며, 파드를 종료하고 리소스가 수정된 새 파드를 만들게 된다는 것으로 파드가 중단된다는 단점이 있다.
    • 그래서  파드 리소스를 수정하면 파드를 인플레이스형태로 업데이트하는 개선 기능이 k8s 1.27부터 개발 중이라고 한다.

    따라서 기본적으로 비활성화 되어있으며 FEATURE_GATES=InPlacePodVerticalScaling=true 옵션을 통해 활성화 시키고 사용하면 된다.

    먼저 아래 그림의 파란색 박스의 의미는 CPU변경 시에는 파드를 재시작하지 않고, 메모리변경 시에는 파드를 재시작하도록 정의하란 소리다.

    이 기능은 Kubernetes 1.33에서도 여전히 알파 상태이다.

    제약사항은 inplace resizing은 CPU와 메모리 리소스에만 가능하다.

    Automated Way(자동 방식)
    • Vertical Pod Autoscaler(VPA)
      • Vertical Pod Autoscaler는 HPA와 달리 쿠버네티스에 기본적으로 설치되어있지 않다.
      • 따라서 github를 통해서 설치가 가능하며 설치시 vpa-admission-controller, recommender, updater 3가지가 설치된다.
        • Recommender는 Kubernetes Metrics API로부터 CPU와 메모리 사용량 데이터를 실시간 및 과거 기준으로 수집하고 분석하여, 적절한 리소스 요청/제한 값을 추천합니다. 단, 직접 값을 변경하지는 않는다.
        • Updater는 Recommander추천 값을 통해 파드의 리소스 할당이 비효율적일 경우 이를 감지하고, 해당 파드를 종료한다.
        • Admission Controller는 새로운 파드가 생성될 때 Recommender의 추천 값을 적용하여, 파드가 적절한 리소스를 가지고 시작되도록 자동으로 스펙을 수정한다.
        • 프로세스
          • Recommender가 리소스 사용 데이터를 수집하고 최적 값을 추천
          • Updater는 기존 파드의 리소스가 비효율적이면 해당 파드를 종료
          • 파드가 종료되면 Deployment가 자동으로 새 파드를 생성
          • 이때 Admission Controller가 개입해 새 파드의 리소스를 추천 값으로 적용해 적절한 크기로 시작
      • 모니터링 대상은 Deployment의 my-app 로 설정한다.
      • containerPolicies가 모니터링 범위를 정의한다. 여기서는 CPU의 minAllowed와 maxAllowed를 설정했다.
      • VPA의 updatePolicy 모드에는 네 가지가 있다.
        • Off 모드
          • Recommender만 동작하며 Updater와 Admission Controller는 동작하지 않는다.
          • CPU나 메모리 변경 추천만 하고, 실제로 파드 리소스를 변경하지는 않는다.
        • Initial 모드
          • 파드가 처음 생성될 때만 리소스가 변경된다.
          • Recommender가 리소스를 추천하고, Deployment가 스케일링 등으로 새 파드를 생성하면, Admission Controller가 개입해 추천된 리소스를 적용한다.
          • 이 모드에서는 Updater가 파드를 종료하지 않는다.
        • Recreate 모드
          • Recommender가 추천한 값과 비교했을 때, 현재 파드 리소스가 비효율적으로 할당되어 있고, 그 차이가 임계치를 초과할 경우 Updater가 파드를 종료한다.
          • 이후 Deployment가 새 파드를 생성하고, 이때 Admission Controller가 개입하여 리소스를 추천 값으로 설정한다.
          • 예: Recommender는 CPU 200m를 추천했는데 파드는 500m를 사용 중이라면, 리소스 낭비로 판단하고 threshold를 넘으면 Updater는 파드를 종료한다.
        • Auto 모드
          • 현재는 Recreate 모드와 동일하게 동작한다.
          • 하지만 향후 Kubernetes가 in-place resource update(파드를 종료하지 않고 리소스만 조정) 기능을 정식 지원하게 되면, Auto 모드는 Recreate보다 우선 사용되는 기본 모드가 될 예정이다. 다시 말해, Auto 모드는 미래를 대비한 기능이다.

        VPA는 리소스 사용량을 모니터링하고 recommander가 추천값을 제안한다고 했다.

        이를 보는 방법은 아래 명령어를 통해 확인할 수 있다.

        kubectl describe vpa <이름>

VPA와 HPA 차이

VPA는 기존 파드의 CPU·메모리를 높이거나 파드를 재생성해 리소스를 조정하고, HPA는 수요에 따라 파드 수를 늘리거나 줄인다.

  • 트래픽 급증 대응
    • 이 경우 HPA가 확실히 유리하며 트래픽 수요가 증가하면 즉시 파드를 추가하므로 빠른 스케일링이 필요한 애플리케이션에 적합하다.
    • 반면 VPA는 파드 재시작이 필요해 지연이 발생하므로 급격한 스파이크에 효율적으로 대응하기 어렵다.
  • 비용 최적화
    • VPA는 실제 사용량에 맞춰 CPU·메모리를 조정해 과다 할당을 방지한다.
    • HPA는 불필요한 유휴 파드를 줄여 과도한 인스턴스를 유지하지 않고 자원을 효율적으로 사용합니다.
    • VPA는 데이터베이스, JVM 기반 애플리케이션, AI/ML처럼 세밀한 리소스 조정이 필요한 워크로드에 적합하다.
      • 예를 들어 어떤 애플리케이션은 초기 기동 시 CPU를 많이 쓰지만 이후에는 덜 필요할 수 있기 때문이다
      • 초기에는 높은 CPU를 할당했다가 초기화가 끝난 뒤 CPU·메모리를 줄이는 식으로 VPA를 활용할 수 있다.
    • HPA는 웹 애플리케이션, 마이크로서비스, 웹 서버, 메시지 큐, API 서비스처럼 트래픽 변동에 빠르게 대응해야 하는 Stateless 워크로드에 이상적입니다.
      • Stateless 워크로드 의미
        • Stateless는 상태를 저장하지 않는다.
          • 매 요청이 독립적으로 모든 요청에 필요한 정보를 클라이언트가 제공한다. 이전 요청과의 연결 고리가 없다.
          • 즉, 워크로드(파드·서비스)가 자체적으로 보존해야 할 세션, 파일 등이 없어 어떤 인스턴스가 요청을 받아도 동일 결과를 리턴한다.
          • 따라서 stateless workload는 각 요청을 독립적으로 처리하고, 이전 기록을 기억하지 않는 서비스이다.