Skip to content
All writing Part 10 of 12 · 在容器裡遙控 Chrome 的完整路由
Engineering · 1 min read

Headless Service 的 DNS 容量模型

一條公式把 per-pod ceiling 和 Ready pod 數連結到最大併發量。三個 KEDA 設定防禦冷啟動尖峰。

公式

最大同時量 = 每 Pod 上限 × Ready pod 數 3 pods × 50 req/pod = 150 concurrent OK 3 pods × 67 req/pod = 200 concurrent 502s 6 pods × 33 req/pod = 200 concurrent OK

Headless Service 的 DNS 每個 Ready Pod 回傳一筆記錄。正在啟動的 Pod 不會出現。Client 只看到能接單的 Pod。

決定容量的三個數字

  • Per-pod ceiling。 一個 Pod 在 timeout 或 OOM 之前能同時處理多少請求。用單 Pod 做 burst test 來測量。
  • Ready pod count。 只有通過 readinessProbe 的 Pod 才出現在 DNS。還在啟動的 Pod 是隱形的。
  • Failure window。 從「KEDA 觸發 scale-up」到「新 Pod 通過 readiness」之間的空窗期。這段時間,現有 Pod 吸收所有流量。Burst 超過它們的上限,請求就失敗。

對抗冷啟動的三道防線

  • minReplicas 基底 Pod 數量。吸收第一波 burst,不用等 KEDA。
  • cooldownPeriod spike 後保持 Pod 存活。吸收重複的 burst。
  • fallbackReplicas Prometheus 斷線時的保底 Pod 數量。

實測數字。 3 個 Pod 撐住 150 concurrent,每 Pod 約 50。推到 200 時,99 個回 502。加到 6 個 warm Pod 再試,199/200 成功。Per-pod ceiling 大約 50。


參考來源:

Related:KEDA 壓測如何驗證這些數字,或回到系列總覽

Tags #kubernetes #chrome-devtools #containers
// connect

Be brave | Be wise | Be grateful

21 BreakinCode

// elsewhere
LinkedInMedium (lang: en)Youtube
wh:~$William Hung· © 2026 Taipei · GMT+8 · Available for collaboration