리소스 플래너 및 자동 스케일링
간단한 요약
안정적인 스케일링은 다음 네 가지 지원에서 지원됩니
1. 요청/제한 및 QoS 클래스를 수정합니다.
2. 올바른 적층 (토폴로지, 친화력, 우선 순위, 선점).
3. 다단계 자동 스케일링: HPA/VPA/KEDA + 클러스터/노드 오토 스케일러 + 따뜻한 풀.
4. 플랩 방지 및 예산이있는 SLO 지향 논리 (대기 시간/대기열 깊이).
기본 리소스 모델
요청/제한 및 QoS 수업
요청 = 스케줄러에 대한 보증; 런타임에 대한 한계 = 천장.
QoS: 보장 (req = lim by CPU/Memory), Burstable (부분), BestEffort (아무것도).
하드 SLO를 사용한 생산 서비스-보장/버스 테이블; 배경-Burstable/BestEffort.
CPU/메모리/IO/네트워크
CPU-탄성 (시간 공유), 메모리-하드 (초과하면 OOM 킬).
IO/네트워크에서는 제한/우선 순위를 개별적으로 설정합니다 (cgroup/TC). 그렇지 않으면 "잡음 이웃" 입니다.
GPU/가속기
벡터 (GPU = 1, 프로파일을 통한 VRAM) 를 요청하고 비판을 위해 nodeSelector/tains 및 PodPriority를 사용하십시오.
추론을 위해-배치 크기 및 모델 가열.
일정 정책
우선 순위, 선점 및 PDB
중요한 경로 (지불, 로그인) 에 대한 PriorityClass, 선점이 허용됩니다.
PodDisruptionBudget은 대피/업데이트 중에 최소한의 신호를 보호합니다.
선호도/토폴로지
코 로케이션/디코 로케이션에 대한 노드/포드 친 화성 (예: 하나의 호스트에 복제본을 넣지 마십시오).
topologySpreadConstrints는 난로를/AZ 구역에 정렬합니다.
NUMA/토폴로지: 낮은 대기 시간이 중요한 핀 -CPU/허지 페이지.
Teyinths와 공차
별도의 수영장: 'prod', 'batch', 'gpu', 'system'. 비판은 더 적은 이웃을 견뎌냅니다.
자동 스케일링: 레벨 및 신호
1) HPA (수평 포드 오토 스케일러)
CPU/메모리/사용자 정의 (Prometheus Adapter): 메트릭 별 포드 복제본 스케일.
좋은 신호: 대기 시간 p95/p99, 대기열 길이/지연, 포드 당 RPS, 소비자 지연.
플래핑 방지: 안정화 (안정화 창), 최소 단계, 대기 시간.
yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: { name: api-hpa }
spec:
scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: api }
minReplicas: 6 maxReplicas: 120 behavior:
scaleUp:
stabilizationWindowSeconds: 60 policies: [{ type: Percent, value: 100, periodSeconds: 60 }]
scaleDown:
stabilizationWindowSeconds: 300 policies: [{ type: Percent, value: 20, periodSeconds: 60 }]
metrics:
- type: Pods pods:
metric:
name: http_server_request_duration_seconds_p95 target:
type: AverageValue averageValue: "0.25" # 250ms2) VPA (Vertical Pod Autoscaler)
실제 소비에 대한 조정 요청/제한 (권장 사항 업데이트).
모드: 'Off', 'Auto' (재시작), 'Initial' (시작시에만).
연습: 'Off' → 통계 수집 → 릴리스에 적용됩니다.
3) KEDA/큐 기반 스케일링
Kafka 지연, SQS 깊이, Redis 길이, Prometheus 등 외부 신호로 반응합니다.
이벤트/큐 소비자 (EDA) 에게 이상적입니다.
yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: { name: consumer-scale }
spec:
scaleTargetRef: { name: txn-consumer }
minReplicaCount: 2 maxReplicaCount: 200 cooldownPeriod: 120 pollingInterval: 5 triggers:
- type: kafka metadata:
bootstrapServers: broker:9092 consumerGroup: tx-cg topic: payments lagThreshold: "10000"4) 클러스터/노드 자동 스케일러 (CA) + 따뜻한 수영장
CA는 결핍/초과시 노드를 추가/제거합니다.
따뜻한 수영장: 예열 된 노드/준비된 이미지 (콜드 스타트 속도).
피크의 경우-사전에 스텝 스케일링 및 확대 된 minNodes.
반응 속도와 온난화
SLO 반응 지연: 프론트 레이어는 1-2 분, 백엔드/DB-개별적으로 그리고 미리.
워밍업: TLS/DNA/연결, 로딩 모델, 캐시 워밍업 및 JIT.
이벤트의 차가운 경로를 "펌핑" 하기위한 섀도우로드.
플래핑 방지 및 안정성
메트릭스에 대한 히스테레시, 스무딩 (Exp. medium).
'scaleDown' 이 큰 HPA의 안정화 창.
"톱" 대신 스텝 스케일링; 복제본을 수정하기위한 속도 제한.
예산 조정: 분당 추가 된 트래픽/복제본의% 를 제한합니다.
관찰 및 SLO
주요 SLI:- p95/99 대기 시간, 오류율, 처리량, 대기열 깊이/지연, CPU/메모리 채도, 포드 보류 시간, 노드 압력.
- 보류중인 포드, 교환 할 수없는 이벤트, IP/서브넷 부족, 이미지가 길어짐, 퇴거.
- 트레일: p99 테일의 테일 기반 샘플링 → 스케일링 할 때 병목 현상이 나타납니다.
FinOps: 탄성 비용
지표: $/1000 RPS, $/ms p95, $/hour reserve.
믹스: 주문형 + 예약 + 스팟 (비판 론적).
자동 스케일 임계 값은 오류 비용과 관련이 있습니다. 때로는 따뜻한 주식을 유지하는 것이 수익성이 있습니다.
iGaming/fintech의 특성
경기/토너먼트 피크: 'minReplicas' 와 minNodes를 미리 올리고 따뜻한 수영장을 켜고 캐시/모델을 예열하십시오.
지불 소비자: 지연 + demempotency에 의한 KEDA, 외부 성능 저하의 원인으로 공급자 제한 (PSP).
안티 봇: 별도의 수영장, 빠른 규칙의 규칙, "회색" 경로.
규정: 규정 준수 서비스에 대한 PDB, 우선 순위는 배치보다 높습니다.
시트 확인
디자인
- 프로파일 링 데이터에 의해 지정된 요청/제한; QoS가 선택되었습니다.
- PriorityClass, PDB, 인내/공차 및 토폴로지 스프레드-구성.
- CPU뿐만 아니라 SLO 지표에 의한 HPA.
- 권장 사항을 수집하기 위해 'Off' VPA ('Auto' 로 마이그레이션 계획).
- KEDA/이벤트로드 대기열.
- CA + 따뜻한 수영장, 이미지가 캐시됩니다 (이미지 사전 풀).
작동
- 안정화 창과 쿨 다운이 설정됩니다 (플 래핑 제외).
- 보류중인/교환 불가능, 지연, p95, 오류율에 대한 경고.
- 런북: "노드 없음", "이미지가 늘어나지 않습니다", "OOM/퇴거", "폭풍우".
- 매월 용량 검토: 규모 대 계획/비용의 사실.
일반적인 실수
IO/데이터베이스 한계가있는 CPU → 위도 회귀 만 HPA.
PDB와 우선 순위의 부족 → 비판이 첫 번째가 될 것입니다.
같은 수영장에서 비판과 배치를 섞지 않고 → "시끄러운 이웃".
제로 가열 → 냉기는 피크에서 시작됩니다.
공격적인 'scaleDown' → 용기를보고 던졌습니다.
dempotency가없는 KEDA → 폭풍우에 메시지를 복제합니다.
미니 플레이 북
1) 피크 이벤트 전 (T-30 분)
1. 'minReplicas '/minNodes를 늘리고 따뜻한 수영장을 활성화하십시오.
2. 따뜻하게 만드는 모델을 만들 수 있습니다.
3. 봇의 회색 경로/제한을 포함합니다.
4. 대시 보드 확인: 보류/지연/p95.
2) 노드 결핍 (교환 불가)
1. CA, 클라우드 할당량, 서브넷/IP를 확인하십시오.
2. 배치 한계를 일시적으로 낮추고 낮은 우선 순위에 대해 선점을 가능하게합니다.
3. 일시적으로 더 큰 인스턴스 유형 또는 두 번째 풀을 올립
3) 대기열의 지연 증가
1. KEDA: 방아쇠로 확장; 2) 소비자 한도 상승;
2. demempotency 키 및 후압 생성기를 활성화하십시오.
4) 복제본
1. 안정화/쿨 다운 증가; 2) 스텝 스케일링으로 전환;
2. 지수 평균으로 메트릭을 매끄럽게합니다.
침대 설정
VPA (권장 사항 모음):yaml apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: { name: api-vpa }
spec:
targetRef: { apiVersion: "apps/v1", kind: Deployment, name: api }
updatePolicy: { updateMode: "Off" } # собираем рекомендации
--balance-similar-node-groups
--expander=least-waste
--max-empty-bulk-delete=10
--scale-down-utilization-threshold=0.5
--scale-down-delay-after-add=10myaml topologySpreadConstraints:
- maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: { matchLabels: { app: api } }결과
효율적인 스케줄러 및 자동 스케일링은 SLO 및 밀리 초 비용과 관련된 올바른 요청/제한 + 스마트 스태킹 + 다단계 스케일링 (HPA/VPA/KEDA/CA) + 워밍업 및 플랩 방지입니다. IaC의 정책을 수정하고 "올바른" 메트릭 (대기 시간/지연) 으로 관찰하고 따뜻한 재고를 최고점에 유지하십시오. 플랫폼은 탄력적이고 예측 가능하며 경제적입니다.