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. 我不知道如何深入挖掘以获取正在发生的事情的指标。
   

---

解决第一个问题：我集思广益地理解它在单容器场景中的工作原理（然后意识到我不了解多容器场景所以我决定问这个问题）

这是我对 HPA（自动缩放/v1）在我有 1 个容器时如何工作的理解（暂时忽略上述部署规范中的第二个容器）：
当所有 Pod 的 CPU 利用率平均值偏离我的正常预期时，HPA 将产生更多副本500m 或以下至 750m 的负载（150% x 500m 要求）

---

为了解决第二个问题：我发现了如何挖掘以查看基于具体数值的指标与基于相对百分比的指标，以帮助找出幕后发生的事情：

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 不是' t 与上述部署相关联，这就是数字关闭的原因。）

Answer 1

基于 stackoverflow 社区成员在其他情况下的回答

“HPA 将 pod cpu 利用率计算为 pod 中所有容器的总 cpu 使用量除以总请求。我认为任何地方的文档中都没有指定这一点，但相关代码在这里”

您已获得更多信息，并在上面的链接中提供了示例。

根据文档

Horizo​​ntal Pod Autoscaler根据观察到的 CPU 利用率（或者，在测试版支持下，根据应用程序提供的其他一些指标）自动缩放复制控制器、部署或副本集中的 Pod 数量。

所以基本上：

apiVersion autoscaling/v1 HPA 基于cpu。

apiVersion 自动缩放/v2beta2 基于cpu、内存、自定义指标。

更多信息请点击这里