korean-docs
Wave Sizing
개요

Smart Sizing 개요

Smart Sizing은 클러스터에 있는 모든 워크로드의 CPU와 메모리 사용량을 분석하고, 컨테이너마다 request/limit 값을 추천합니다. 분석은 10분마다 실행되며, 추천은 사이징이 잘못된 두 가지 방향을 모두 다룹니다:

  • Over-provisioning(과다 프로비저닝): 실사용량보다 훨씬 높은 request는 비용을 낭비하고 스케줄링 가능 용량을 막습니다.
  • Under-provisioning(과소 프로비저닝): 실사용량보다 낮은 request는 CPU 스로틀링과 OOMKill 위험을 높입니다.

두 가지 추천 모델

Smart Sizing은 워크로드가 수평으로 스케일링되는지 여부에 따라 모델을 자동으로 선택합니다.

Smart Sizing (사용량 기반 모델)Smart Sizing with HPA / Autopilot (워크로드 성능 모델)
적용 대상HPA나 Autopilot을 사용하지 않는 워크로드HPA가 있거나 Wave Autopilot이 활성화된 Deployment
동작 방식7일 이상의 CPU/메모리 사용량과 SLI로 사용되는 다른 워크로드 지표(네트워크 인/아웃, request 처리 패턴)를 관찰해 안정적이고 비용 효율적인 값을 추천합니다. 단순히 가장 낮은 관측 사용량이 아니라 워크로드의 신뢰성 자체를 검토합니다워크로드 그룹이 서로 다른 레플리카 수(5개, 10개, 15개는 각각 다르게 동작합니다)에서 어떻게 동작하는지 모델링하여, 워크로드가 수평으로 스케일링되는 동안에도 유효한 CPU/메모리 값 하나를 추천합니다
필요 데이터24~48시간 내 첫 추천, 7일 후 안정화서로 다른 레플리카 수에서 최소 5개 데이터 포인트가 필요합니다. 트래픽 변화가 충분하지 않은 워크로드는 아직 추천이 나오지 않을 수 있습니다
적용 방법Resize Now (수동) 또는 Realtime Resizing (자동)Resize Now (수동)만 가능합니다. 아래에서 이유를 확인하세요

워크로드 상세 페이지에서 어떤 모델이 활성화되어 있는지 확인할 수 있습니다. 탭 이름이 Smart Sizing, Smart Sizing with HPA, Smart Sizing with Autopilot 중 하나로 표시됩니다.

추천을 적용하는 두 가지 방법

적용 경로하는 일위치
수동: Resize Now추천 값을 검토한 뒤 컨테이너 단위로 직접 적용합니다. in-place resize와 매니페스트 수정 중 선택할 수 있습니다Resize Now
Realtime ResizingWave가 10분 주기마다 추천을 자동으로 적용합니다. 워크로드/컨테이너 단위로 opt-in하며, In-place와 Manifest 모드를 지원합니다Realtime Resizing

HPA나 Autopilot을 사용하는 워크로드는 실제로 스케일링이 진행되는 동안 Realtime Resizing을 사용할 수 없습니다. 워크로드가 오토스케일링되면 Pod가 동적으로 생성되고 종료되므로, 실행 중인 Pod에 새 값을 적용하면 새로 스케일업된 Pod만 다른 크기를 갖게 되고, 매니페스트 패치는 스케일링 도중 모든 Pod를 재시작시킵니다. 대신 추천 값을 검토하고 수동으로 적용하세요. 이 제한은 Autopilot이나 HPA가 실제로 워크로드를 스케일링하고 있을 때만 적용됩니다. Autopilot이 Monitoring Mode인 워크로드는 스케일링되고 있지 않으므로 Realtime Resizing을 계속 사용할 수 있습니다. 자세한 이유는 Realtime Resizing에서 다룹니다.

추천 값 조정하기

  • Aggressive Recommendations: 워크로드를 7일 이상 관찰 창에서 최근 1시간(request = 평균 사용량, limit = 최고 사용량) 기준으로 전환해 비용을 최대한 절감합니다.
  • Container Settings: 컨테이너별 min/max 범위와 안전 버퍼(기본 10%)로 모든 추천 값의 범위를 정하고, auto-apply를 opt-in할 수 있습니다.

기본 안전장치

Smart Sizing은 어떤 값도 무작정 적용하지 않습니다:

  • 추천 값은 항상 limit ≥ request를 만족합니다. CPU는 0.1 core 아래로 내려가지 않으며(Aggressive Recommendations가 켜져 있으면 0.01 core), 메모리는 컨테이너 런타임의 최소값인 12 MiB 아래로 내려가지 않습니다.
  • 값이 0이거나 없는 추천은 클러스터에 절대 반영되지 않습니다.
  • Wave가 컨테이너를 처음 리사이즈할 때 원래 request/limit 값을 캡처해두며, Restore Original 버튼으로 언제든 되돌릴 수 있습니다.
  • 모든 자동 적용은 워크로드별 Apply History 테이블에 기록됩니다.
  • 사소한 변경은 건너뜁니다. 적용은 의미 있는 변화(비율 ≥ 10%, ≥ 50 mCPU, 또는 ≥ 64 MiB)가 있을 때만 이루어집니다. Aggressive 워크로드는 더 가벼운 기준(비율 검사 없이 ≥ 10 mCPU 또는 ≥ 10 MiB)을 사용해 1시간 창을 촘촘하게 따라갈 수 있습니다.

지원하는 워크로드 종류

Deployment, StatefulSet, DaemonSet, Argo Rollout, OpenShift DeploymentConfig (OpenShift / OKD).

Smart Sizing과 Kubernetes VPA 비교

항목Kubernetes VPASmart Sizing
추천 입력사용량 히스토그램, 백분위수 집계신뢰성 검사를 포함한 사용량 기반 모델, 또는 수평 스케일링 워크로드를 위한 워크로드 성능 모델
HPA 호환성호환되지 않음 (같은 워크로드에서 충돌)전용 Smart Sizing with HPA 모델: 레플리카 수가 바뀌어도 유효한 추천 값
노드 리소스 부족 시 적용 동작자동으로 축출 후 재생성으로 대체명시적인 모드만 사용: In-place는 해당 Pod를 건너뛰고 다음 주기에 재시도하며, 조용한 재시작은 없음
컨테이너별 제어minAllowed / maxAllowedContainer Settings를 통한 min/max 범위 및 안전 버퍼
지원 종류Deployment, StatefulSet, DaemonSetArgo Rollout과 OpenShift DeploymentConfig 추가 지원
운영자 가시성VPA 이벤트, kubectl describe vpasavings/risk 순위와 워크로드별 Apply History를 제공하는 Dashboard

다음으로 볼 문서

CRD 모드시작하기