本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
Kubernetes 1.27:HorizontalPodAutoscaler ContainerResource 型別指標進入 Beta 階段
Kubernetes 1.20 在 HorizontalPodAutoscaler (HPA) 中引入了ContainerResource
型別的度量。
在 Kubernetes 1.27 中,此功能進入 Beta 階段,並且相應的功能門控(HPAContainerMetrics
)預設啟用。
什麼是 ContainerResource 型別度量
ContainerResource 型別的度量允許我們根據單個容器的資源使用情況來配置自動擴縮。
在下面的示例中,HPA 控制器會擴縮目標,使所有 Pod 中 application 容器的平均 CPU 利用率維持在 60% 左右。(有關如何精確計算所需副本數的詳細資訊,請參閱演算法細節)
type: ContainerResource
containerResource:
name: cpu
container: application
target:
type: Utilization
averageUtilization: 60
與 Resource 型別度量的區別
HPA 已經有Resource 型別的度量。
你可以像下面這樣定義目標資源利用率,然後 HPA 將根據當前的利用率來擴縮副本。
type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 60
但是,這種 Resource 型別的度量指的是 Pod 的平均利用率。
如果一個 Pod 有多個容器,利用率的計算方式將是
sum{the resource usage of each container} / sum{the resource request of each container}
每個容器的資源利用率可能沒有直接關聯,或者隨著負載的變化以不同的速率增長。
例如
- 一個 Sidecar 容器僅提供輔助服務,例如日誌傳送。如果應用程式不經常記錄日誌或不在其熱點路徑中產生日誌,那麼日誌傳送器的使用量就不會增長。
- 一個提供身份驗證的 Sidecar 容器。由於大量快取,當主容器上的負載增加時,其使用量只會略有增加。在當前的混合使用率計算方法中,這通常會導致 HPA 不擴容部署,因為混合使用率仍然很低。
- 注入的 Sidecar 可能沒有設定資源,這會阻止基於利用率的擴縮。在當前的邏輯中,如果未設定資源請求,HPA 控制器只能根據 Pod 的絕對資源使用量進行擴縮。
並且,在這種情況下,如果只有一個容器的資源利用率很高,Resource 型別的度量可能不會建議擴容。
因此,為了實現精確的自動擴縮,你可能希望對此類 Pod 使用 ContainerResource 型別的度量。
Beta 版本有哪些新內容?
對於 Kubernetes v1.27,如本文開頭所述,ContainerResource 型別的度量預設可用。(你仍然可以透過 HPAContainerMetrics
功能門控停用它。)
此外,我們透過從 kube-controller-manager 暴露一些度量來改進 HPA 控制器的可觀測性
metric_computation_total
:度量計算次數。metric_computation_duration_seconds
:HPA 控制器計算一個度量所需的時間。reconciliations_total
:HPA 控制器的協調次數。reconciliation_duration_seconds
:HPA 控制器協調一次 HPA 物件所需的時間。
這些度量具有標籤 action
(scale_up
、scale_down
、none
)和 error
(spec
、internal
、none
)。此外,前兩個度量還有一個 metric_type
標籤,對應於 HorizontalPodAutoscaler 的 .spec.metrics[*].type
。
所有度量對於 HPA 控制器的一般監控都很有用,你可以更深入地瞭解哪個部分有問題,哪裡耗時,你的叢集在什麼時間傾向於發生多大規模的擴縮等。
另一個小改動是,我們更改了 SuccessfulRescale
事件的訊息,以便每個人都可以檢查事件是來自資源度量還是容器資源度量(參見相關的 PR)。
參與進來
此功能由 SIG Autoscaling 管理。請加入我們並分享你的反饋。我們期待你的迴音!