Kubernetes Horizo​​ntal Pod Autoscaler 如何計算多容器 Pod 的 CPU 利用率？

Question

問題 1.)
給定一個多容器 pod 的場景，其中所有容器都有一個定義的 CPU 請求：
Kubernetes Horizo​​ntal Pod Autoscaler 如何計算多容器 Pod 的 CPU 利用率？
它是平均的嗎？ (((500m cpu req + 50m cpu req) /2) * X% HPA 目標 cpu 利用率
它會添加它們嗎？ ((500m cpu req + 50m cpu req) * X% HPA 目標 cpu 利用率
它會單獨跟蹤它們嗎？ （500m cpu req * X% HPA 目標 cpu 利用率 = 目標 #1，50m cpu req * X% HPA 目標 cpu 利用率 = 目標 #2。）

問題2。）
給定多容器 pod 的場景，其中 1 個容器具有定義的 CPU 請求和其他容器的空白 CPU 請求：
Kubernetes Horizo​​ntal Pod Autoscaler 如何計算多容器 Pod 的 CPU 利用率？
它是否像只有 1 個容器 pod 一樣工作？

問題 3。）
問題 1 和 2 的答案是否會根據 HPA API 版本而變化？
我注意到 stable/nginx-ingress helm chart，圖表版本 1.10.2，為我部署了一個具有以下規格的 HPA：

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler

（我注意到 apiVersion: autoscaling/v2beta2 現在存在）

背景資料：
我最近遇到了一個問題，即在將 sidecar（第二個容器）添加到 nginx 入口控制器部署（通常是一個帶有單個容器的 pod）后，在最小和最大 pod 之間不斷地來回擴展。 就我而言，它是一個 oauth2 代理，盡管我認為 istio sidecar 容器的人也可能一直遇到此類問題。

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: nginx-ingress-controller #(primary-container)
          resources:
            requests:
              cpu: 500m    #baseline light load usage in my env 
              memory: 2Gi  #according to kubectl top pods
            limits:
              memory: 8Gi  #(oom kill pod if this high, because somethings wrong)
        - name: oauth2-proxy #(newly-added-2nd-sidecar-container)
          resources: 
            requests:
              cpu: 50m
              memory: 50Mi
            limits:
              memory: 4Gi

我有一個 HPA (apiVersion: autoscaling/v1)：

• 最少 3 個副本（在滾動更新期間保留 HA）
• 目標 CPU 利用率百分比 = 150%

我突然想到，我的錯誤配置導致意外的瘋狂擴展是由兩個問題引起的：

1. 當 pod 有多個容器時，我實際上不明白 HPA 是如何工作的
2. 我不知道如何深入挖掘以獲取正在發生的事情的指標。
   

---

解決第一個問題：我集思廣益地理解它在單容器場景中的工作原理（然后意識到我不了解多容器場景所以我決定問這個問題）

這是我對當我有 1 個容器時 HPA（自動縮放/v1）如何工作的理解（暫時忽略上述部署規范中的第二個容器）：
當所有 Pod 的 CPU 平均利用率從我的正常預期負載 500m 或更少轉移到 750m（150% x 500m 請求）時，HPA 將產生更多副本

---

為了解決第二個問題：我發現了如何挖掘以查看基於具體數值的指標與基於相對百分比的指標，以幫助找出幕后發生的事情：

bash# kubectl describe horizontalpodautoscaler nginx-ingress-controller -n=ingress | grep Metrics: -A 1
Metrics:                                               ( current / target )
  resource cpu on pods  (as a percentage of request):  5% (56m) / 100%

（注意：kubectl top pods -n=ingress，顯示 5 個副本的 CPU 使用情況為 36m、34m、88m、36m、91m，因此 57m 電流與 56m 電流匹配）

此外，現在它是一個基本的比例數學問題，可以求解目標靜態值：
(5% / 56m) = (100% / xm) --> x = 56 * 100 / 5 = 1120m 目標 cpu
（注意：此 HPA 與上述部署無關，這就是數字關閉的原因。）

Answer 1

其他情況下基於stackoverflow社區成員的回答

“HPA 將 pod cpu 利用率計算為 pod 中所有容器的總 cpu 使用率除以總請求。我認為文檔中沒有指定任何地方，但相關代碼在這里”

您有更多信息，上面的鏈接中有示例。

---

基於文檔

Horizo​​ntal Pod Autoscaler根據觀察到的 CPU 利用率（或者，在測試版支持下，應用程序提供的一些其他指標）自動擴展復制控制器、部署或副本集中的Pod數量。

所以基本上：

基於cpu 的apiVersion autoscaling /v1 HPA。

apiVersion 自動縮放/v2beta2 基於cpu、內存、自定義指標。

更多信息在這里

Answer 2

對於問題 2，如果我們查看源代碼，我們可以看到它單獨查看所有容器，如果容器沒有請求則返回。

func calculatePodRequests(pods []*v1.Pod, resource v1.ResourceName) (map[string]int64, error) {
   requests := make(map[string]int64, len(pods))
   for _, pod := range pods {
      podSum := int64(0)
      for _, container := range pod.Spec.Containers {
         if containerRequest, ok := container.Resources.Requests[resource]; ok {
            podSum += containerRequest.MilliValue()
         } else {
            return nil, fmt.Errorf("missing request for %s", resource)
         }
      }
      requests[pod.Name] = podSum
   }
   return requests, nil
}

---

---