資源調度與自動滑行

簡短的摘要

1.正確的查詢/限制和QoS類。

2.正確的造型（拓撲，仿射，優先級，預裝）。

3.多級自動滑板：HPA/VPA/KEDA+群集/Node autoscaler+warm pools。

4.SLO面向邏輯（latency/queue depth），具有反翻轉和預算。

基本資源模型

要求/限制和QoS類

Requests=計劃者的保證；Limits=runtime的天花板。
QoS：guaranteed（CPU/Memory的req=lim），Burstable（部分），BestEffort（沒有）。
具有剛性SLO的生產服務-Guaranteed/Burstable；背景是Burstable/BestEffort。

CPU/內存/IO/網絡

CPU是彈性的（時間共享），內存是剛性的（超過時為OOM殺手）。
在IO/網絡上，分別設置限制/優先級（cgroups/TC），否則為「嘈雜的鄰居」。

GPU/加速器

請求矢量（GPU=1, VRAM通過配置文件）,使用nodeSelector/taints和PodPriority進行批評。
對於地獄-batch尺寸和加熱模型。

造型策略（Scheduling）

優先級、投資前和PDB

PriorityClass用於關鍵路徑（付款,登錄）,允許預先啟動。
PodDisruptionBudget在撤離/升級時保護最小復制副本。

Affinity/拓撲

node/pod affinity（例如,不要將復制副本聚類到單個主機上）。
topologySpreadConstraints 在區域/AZ上對齊。
NUMA/拓撲：pin-CPU/hugepages，其中低潛伏率很重要。

泰因特和托勒蘭斯

偵察池：「prod」，「batch」，「gpu」，「system」。批評容忍的鄰居較少。

自動滑冰： 水平和信號

1) HPA (Horizontal Pod Autoscaler)

按度量劃分副本：CPU/內存/定制 （Prometheus Adapter）。
好信號：latency p95/p99，queue length/lag，RPS per pod，consumer lag。
反翻轉：穩定（stabilizationWindow），最小步驟，冷靜。

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" # 250ms

2) VPA (Vertical Pod Autoscaler)

將要求/限制調整為實際消費（更新建議）。
模式：「Off」（收集），「Auto」（重新啟動），「Initial」（僅在開始時）。
練習：啟用「Off」 →收集統計數據→應用於發布。

3） KEDA/基於隊列的滑板

響應外部信號：Kafka lag，SQS depth，Redis length，Prometheus。
適合事件/隊列消費者（EDA）。

KEDA ScaledObject (Kafka lag):

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) Cluster/Node Autoscaler (CA) + Warm Pools

CA在短缺/過剩的情況下添加/清除營養素。
Warm pools：預先加熱的nods/準備好的圖像（加速冷啟動）。
對於峰值-預先進行分級和放大的minNodes。

反應速度和熱量

SLO反應延遲：前層≤ 1-2分鐘，後端/DB-單獨和提前。
加熱：TLS/DNS/連接，模型加載，緩存加熱和JIT。
Shadow載荷,用於在事件發生前「泵送」卡路。

反翻轉和穩定

度量上的滯後,平滑度（*.中等）。
HPA中的Windows穩定化，在「scaleDown」中較大。
步驟滑冰而不是「喝酒」；rate-limit更改副本。
Budget滑板：限制每分鐘添加的流量/副本的百分比。

可觀察性和SLO

• p95/99 latency, error rate, throughput, queue depth/lag, CPU/Memory saturation, pod pending time, node pressure.

• pending pods, unschedulable事件,IP/子網缺陷, image pull long evictions.
• Traces：基於p99尾巴的尾巴采樣→看到滑行瓶頸。

FinOps： 彈性成本

指標：$/1000 RPS, $/ms p95,$/小時儲備金。
混合：點播+保留+點（非批評）。
自動滑板閾值與錯誤的成本有關：有時保持扭曲庫存是有益的。

iGaming/fintech的細節

比賽/錦標賽高峰：提前舉起「minReplicas」和minNodes，打開戰爭池並加熱緩存/模型。
支付消費者：KEDA通過拉格+等效性，提供商限額（PSP）作為外部降解誘因。
Antibot：一個單獨的池，快速的規則尺度，「灰色」路線。
監管：合規服務的PDB優先級高於電池。

支票單

設計

• Requests/limits是根據分析數據設置的；選擇了QoS。
• PriorityClass、PDB、taints/tolerations和topologySpread-配置。
• 通過SLO度量的HPA，而不僅僅是CPU。
• VPA在「Off」中收集建議（計劃遷移到「Auto」）。
• 事件載荷的KEDA/隊列。
• CA+warm pools,映像緩存（圖像預拉）。

運營活動

• Stabilization windows和cooldowns設置為（不包括flapping）。
• Alerta on pending/unschedulable, lag, p95, error-rate。
• Runbooks：「no nod」，「image not」，「OOM/evict」，「retrais storm」。
• 每月Capacity-review： Scale vs計劃/成本的事實。

典型的錯誤

HPA僅通過CPU → IO/DB限制下的lat倒退。
缺少PDB和優先事項→批評首先會出現。
批評和擊球在一個沒有觸摸池的混合→「嘈雜的鄰居」。
零熱→高峰時寒冷的開始。
激進的「scaleDown」 →喝酒和thrash容器。
KEDA在暴風雨中→重復報告。

迷你花花公子

1）高峰事件發生前（T-30分鐘）

1.放大「minReplicas」/minNodes，激活warm pools。
2.加熱CDN/DNS/TLS/連接,加載模型。
3.啟用「灰色」路線/機器人限制。
4.檢查dashboards： pending/lag/p95。

2）缺錢（unschedulable）

1.檢查CA 、雲配額、子網/IP。
2.暫時降低擊球限制，包括低優先級前期。
3.暫時提升更大的實例類型或第二個池。

3）在隊列中長大

1.KEDA： 觸發尺度；2）提高消費者的限制；

2.啟用idempotency-keys和backpressure prodewsers。

4）鋸復制品

1.增加stabilization/cooldown；2）改用階梯式滑板；

2.用指數平均值平滑度量。

Config Spargalki

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=10m

yaml topologySpreadConstraints:
- maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: { matchLabels: { app: api } }

結果

高效調度儀和自動滑板是正確的要求/限制+智能造型+多層滑板（HPA/VPA/KEDA/CA）+加熱和防翻轉,與SLO和毫秒成本掛鉤。在IaC中記錄策略,觀察「正確」的度量（latency/lag）,將warm庫存保持在峰值之下-平臺將具有彈性、可預測性和經濟性。