動態調整

在 Kubernetes 中，如果為量化交易系統的 Pod 設置了可伸縮（HPA / VPA / 自定義控制器），并且默認副本數是 5，那么節點數量（副本數）是否變化，主要取決于以下幾個因素。

? 什么情況下 Pod 節點數量會大于 5？

一般是因為資源不足、負載升高等條件觸發了自動擴容：

情況 1：CPU 或內存使用率超過閾值

• 使用 HPA（Horizontal Pod Autoscaler）時，如果 CPU 或內存使用率持續高于配置的 targetAverageUtilization（如 70%），Kubernetes 就會自動增加副本數。

情況 2：消息堆積、延遲上升

• 如果使用了自定義指標（如 Kafka lag、處理延遲等），當指標超過設定閾值時，也會觸發自動擴容。

情況 3：并發請求量猛增

• 配合 Ingress + Service + autoscaler，當網絡請求量飆升，QPS 陡增，也可能觸發擴容。

? 什么情況下 Pod 節點數量會減少（小于 5）？

? 有可能小于 5，前提是你允許最低副本數小于 5。

如果你設置了：

minReplicas: 2
maxReplicas: 10

那就意味著當負載很低、系統空閑時，Pod 數可能減少至 2。

常見觸發縮容的情況：

• CPU 或內存使用率長期低于閾值（如低于 20%）
• Kafka 消息消費滯后清零、請求量降至低水平
• 某些夜間、節假日等場景策略不運行或數據源減少

? 是否一定不會小于默認值 5？

不是的 —— 默認值 5 是部署時設置的一個初始副本數，不是最小值，除非你顯式設置了 minReplicas: 5，否則就有可能被縮容小于 5。

? 如果想確保副本永遠不小于 5，可以這樣配置：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:minReplicas: 5maxReplicas: 10metrics:- type: Resourceresource:name: cputarget:type: UtilizationaverageUtilization: 70

這樣無論負載多低，Pod 數也不會低于 5。

固定數量

如果 Pod 節點數量設定為固定值（如 Deployment 中指定 replicas: 5），那么在沒有人為干預或故障的情況下，Pod 的數量是不會變化的。

固定副本數 = 固定 Pod 數量

當你這樣配置：

spec:replicas: 5

Kubernetes 控制器會始終保證有 5 個副本存活：

• 如果某個 Pod 宕機，它會立即拉起一個新的 Pod 進行補充
• 這個新 Pod 的名稱、IP 可能變化，但副本數量始終是 5

什么情況下會改變 Pod 數量？

只有以下幾種情況才會使數量變化：

• 你手動更改 replicas 配置
• 引入了 HPA（Horizontal Pod Autoscaler） 自動伸縮組件
• 使用 kubectl scale 命令動態調整副本數
• Deployment 被刪除或重新創建

如果明確沒有使用這些機制，那副本數量就是穩定不變的。

在 Deployment 設置了固定副本數（如 replicas: 5）的前提下，Pod 的實際數量在正常情況下不會大于 5，但在以下特定場景中可能會短暫超過這個數量：

? 可能導致 Pod 數量“暫時”大于 5 的幾種情況：

1. Pod 滾動更新過程中

當你更新鏡像或配置時，Kubernetes 會進行滾動更新：

• 新 Pod 先啟動（如 quant-abcde），
• 再刪除舊 Pod（如 quant-xyz12）

這個過程中，為了保持服務不中斷，Kubernetes 短時間內會同時保留舊 Pod 和新 Pod，所以可能出現：

實際 Pod 數量 = 6（1 個新的 + 5 個舊的，還未完全切換）

可通過 maxSurge 控制是否允許多啟動：

strategy:rollingUpdate:maxSurge: 1maxUnavailable: 0

2. Pod 重啟失敗 / CrashLoopBackOff 時

某個 Pod 重啟中或卡在 Terminating 狀態，Kubernetes 可能拉起一個新的 Pod 補位，而舊的 Pod 還沒完全清理掉。

• 這種狀態下，Pod 數量暫時會 > 5
• 但不會長期維持

3. 調度器異常 or 節點漂移中

在節點失聯或遷移時，K8s 也可能多調度一個副本做備份，舊 Pod 仍未完全回收。

? 總結：

狀態	是否可能大于5	是否長期存在
正常運行	? 否	否
滾動更新	? 是（短暫）	? 否（更新完成即恢復）
Pod 故障重啟	? 是（短暫）	? 否
手動誤擴容	? 是（人為操作）	? 是（需恢復）

? 應對建議：

• 路由服務獲取 Pod 列表時，過濾掉非 Running 狀態的 Pod
• 不要依賴 “當前 Pod 數量 == 5” 做分片判斷，而是基于實際可用 Pod 名單進行哈希分片
• 避免在滾動更新時觸發重新分片（可加標志位鎖）

在設置 replicas: 5 的情況下，也有可能出現 Pod 數量短暫小于 5 的情況。

? 出現小于 5 個 Pod 的常見原因：

1. Pod 異常退出 / CrashLoopBackOff

• 某個 Pod 由于代碼異常、配置錯誤或資源不足掛掉了。
• Kubernetes 會嘗試重啟它，但在短暫時間內，Running 狀態的 Pod 會小于 5。

2. 調度失敗

• 有些節點資源不足（CPU/內存），導致 Pod 調度不成功。
• 此時，Pending 狀態的 Pod 不計入 Running 的數量。

3. 節點宕機

• Pod 所在的 Node 突然失聯或宕機。
• Kubernetes 會重新調度 Pod，但需要一定時間。

4. 滾動更新中設定了 maxUnavailable > 0

例如：

strategy:rollingUpdate:maxUnavailable: 1

• 表示允許最多有 1 個副本在更新過程中不可用。
• 那么更新中最多只有 4 個 Pod 是可用的。

5. 手動干預

• 人為刪除某些 Pod。
• Deployment 會嘗試恢復，但恢復前數量會小于預設值。

? 是否是“正常”現象？

短時間內低于 replicas 是 Kubernetes 自愈機制的一部分，系統會自動嘗試恢復目標副本數。

? 建議應對：

• 分片服務在判斷當前副本數是否達標時，不要依賴副本總數是否為 5，而是：
  • 拉取當前狀態為 Running 的 Pod 列表（過濾掉 Pending、CrashLoop、Terminating）
  • 以此為基礎進行路由與分片判斷
• 在 Pod 啟動完成后再注冊分片，避免中間狀態時觸發不必要的重分片
• 對于關鍵策略，可添加一個健康檢查機制，確保某個分片活躍地運行在某個 Pod 中

量化交易系統的 Pod 設計

在量化交易系統中，如果行情是廣播式推送（如通過行情網關、Kafka、Multicast、RabbitMQ fanout 等），那部署“可伸縮（自動伸縮）”的副本方式是沒有必要的。

可伸縮部署并不適合廣播式行情的量化系統，大多數情況下不建議自動彈性伸縮，建議使用固定副本數部署。
原因如下：

🚫【風險點】行情是廣播 → 副本數增加會造成重復消費、計算放大

如果行情是“廣播”給所有量化副本的（如 Kafka 的 fan-out 模式、行情接收層做了 multicast），那么：

• 增加一個副本 = 每條行情被多處理一次
• 會導致重復運算、系統資源浪費
• 如果沒有良好的策略路由與隔離，會導致策略調度混亂或沖突

?【適合伸縮的場景】是pull 模式 / 隊列分片型系統

例如：

• 使用 Kafka 按策略 ID 分區 + 分組消費
• 或者策略是從數據庫拉取的任務型架構
• 或者你對每個副本分派明確的策略子集

在這些模式下伸縮可以帶來負載均衡、性能彈性。