Container Settings
Smart Sizing 탭의 각 컨테이너 카드에는 Container Settings 버튼이 있습니다. 클릭하면 Recommendation bounds와 Auto-apply 두 섹션으로 구성된 컨테이너별 모달이 열립니다.
Recommendation bounds
이 값들은 Smart Sizing이 추천하는 값의 범위를 정합니다. 실행 중인 Pod를 직접 건드리지는 않습니다.
| 컨트롤 | 효과 | 기본값 |
|---|---|---|
| Min (CPU core / 메모리 MB) | 하한: 사용량이 아무리 낮아져도 추천 값은 이 아래로 내려가지 않습니다 | 없음 |
| Max (CPU core / 메모리 MB) | 상한: 추천 값이 이 값을 넘지 않습니다. 사실상 비용 상한선입니다 | 없음 |
| Buffer (%) | min/max로 clamp되기 전에 관측 사용량 위에 더해지는 안전 마진 | 10% |
메모리 범위의 단위는 MiB입니다 (콘솔에는 MB로 표시되지만 값은 동일한 MiB 수치입니다).
Set custom min/max and buffer for recommendations를 활성화하면 값을 편집할 수 있습니다. 주기별 처리 과정은 다음과 같습니다: 사용량 관찰 → 버퍼 추가 → min/max로 clamp → 변경 임계값 확인 → 적용 (auto-apply가 켜져 있는 경우).
버퍼를 추가하는 이유. Smart Sizing은 안정적이고 비용 효율적인 값을 목표로 하지만, 메모리는 분석이 미처 보지 못한 방식으로 튈 수 있습니다. 추천 값 위에 얹는 버퍼가 이런 예상치 못한 상황을 흡수해줍니다. 트래픽이 튀는 워크로드라면 버퍼를 높이고, 시작 시 여유가 필요한 앱(전형적인 예가 JVM warm-up)에는 메모리 Min을 설정하세요.
일반적인 패턴:
- 중요한 프로덕션 서비스: 버퍼 20~30%, 메모리 min을 안전한 하한으로 설정.
- 비용 최적화 배치 / 백그라운드 워커: 기본값 (버퍼 10%) 유지, 필요하면 비용 상한으로 CPU max 설정.
- Aggressive Recommendations를 사용하는 워크로드: 의미 있는 버퍼와 min을 유지하세요. 1시간 창은 여유가 적습니다.
Auto-apply
Apply recommendations automatically를 켜면 이 컨테이너가 Realtime Resizing에 opt-in됩니다. 추천 값은 워크로드의 모드(In-place 또는 Manifest)를 사용해 10분 주기마다 적용됩니다. 워크로드 모드가 Off라면 추천 값은 계속 계산되지만 아무것도 적용되지 않습니다. 자동 리사이즈가 동작하려면 두 스위치가 모두 켜져 있어야 합니다.
limit 적용 여부를 제어하는 두 개의 하위 옵션이 있습니다:
| 옵션 | 기본값 |
|---|---|
| Apply CPU limit | off |
| Apply memory limit | off |
auto-apply가 켜져 있으면 request는 항상 적용됩니다. limit은 이 옵션을 명시적으로 활성화해야만 적용됩니다.
메모리 limit은 Manifest 모드에서만 적용됩니다. In-Place 모드는 메모리 request만 적용합니다. Kubernetes의 in-place resize 경로는 메모리 limit을 바꾸지 않기 때문입니다. 따라서 In-Place를 선택하면 Apply memory limit 옵션은 아무 효과가 없습니다.
limit이 기본적으로 꺼져 있는 이유. 메모리 limit을 자동으로 낮추는 것은 사이징에서 가장 위험한 동작입니다. 방금 낮춘 limit에 예상치 못한 스파이크가 오면 OOMKill로 이어집니다. limit을 auto-apply에서 제외하면 비용 효과(스케줄링과 청구를 좌우하는 것은 request입니다)는 그대로 유지하면서, 안전 상한선은 설정한 그대로 남겨둘 수 있습니다.
항상 적용되는 안전장치
설정과 무관하게, 추천 값은 적용 전에 항상 정합성 검사를 거칩니다:
- limit ≥ request는 항상 강제됩니다.
- CPU 추천 값은 0.1 core 아래로 내려가지 않습니다. Aggressive Recommendations가 켜져 있으면 0.01 core입니다.
- 메모리 추천 값은 컨테이너 런타임의 최소값인 12 MiB 아래로 내려가지 않습니다.
- 값이 0이거나 없는 경우는 절대 적용되지 않습니다.
- 하한에 걸린 추천은 보류됩니다(Wave 3.4.2+). 컨테이너의 request가 이미 하한보다 낮으면(OpenShift처럼 기본 request가 몇 millicore인 환경에서 흔합니다), 추천 값을 하한까지 끌어올리는 것은 request를 올리는 결과가 되어 아무도 원하지 않은 변경으로 절감 리포트를 부풀립니다. 이제 Wave는 그런 추천이 현재 request를 낮추는 경우가 아니면 아예 버립니다. 해당 컨테이너에는 Smart Sizing 탭에 recommendation withheld 태그가 붙고, 툴팁으로 이유를 설명합니다.
보류된 추천은 데이터 없음과 다릅니다. 3.4.2 이전에는 콘솔에서 둘이 똑같이 보여서, 하한에 걸린 컨테이너와 단순히 메트릭이 덜 쌓인 컨테이너를 구분할 수 없었습니다. 이제 withheld 태그가 이 둘을 나눠줍니다.
워크로드 단위 설정
Info 카드의 (Realtime Resizing 옆) Settings 버튼에는 워크로드 전체에 적용되는 옵션이 있으며, 현재는 Aggressive Recommendations 토글만 있습니다.