缩放比例是基于requests的百分比，而不是limits。我认为我们应该改变这个答案，因为在接受的答案中的例子显示：

limits:
   cpu: 1000m

字符串
但是targetCPUUtilizationPercentage是基于requests的，比如：

requests:
   cpu: 1000m

型
对于每个pod的资源指标（类似于CPU），控制器从HorizontalPodAutoscaler针对的每个Pod的资源度量API获取度量。然后，如果设置了目标利用率值，则控制器计算利用率值作为每个Pod中的容器上的等效资源请求的百分比。如果设置了目标原始值，直接使用原始指标值。然后，控制器在所有目标Pod上获取利用率或原始值（取决于指定的目标类型）的平均值，并产生用于缩放所需副本数量的比率。
https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#how-does-a-horizontalpodautoscaler-work

这很棘手，可能是一个bug，但我不这么认为，大多数时候人们配置的值太低，我将解释。

targetCPUUtilizationPercentage与Pod资源requests的关系。

targetCPUUtilizationPercentage根据pod指定的所需CPU配置百分比。在Kubernetes上，如果不将requests指定为CPU，我们就无法创建HPA。添加一些限制也是有意义的，因为大多数时候我们不想使用所有可用的物理CPU。
假设这是我们的requests：

apiVersion: v1
kind: Pod
metadata:
  name: apache
spec:
  containers:
    - name: apache
      image: httpd:alpine
      resources:
        requests:
          cpu: 1000m

字符串
在我们的targetCPUUtilizationPercentage内部HPA中，我们指定75%。
这很容易解释，因为我们要求100% （1000 m = 1个CPU核心） 的单核，所以当这个核心的使用率约为75%时，HPA将开始工作。
但是如果我们将requests定义为：

spec:
  containers:
    - name: apache
      image: httpd:alpine
      resources:
        requests:
          cpu: 500m

型
现在，我们的pod指定的100%的CPU仅为单个核心的50%。好吧，所以这个pod的100%的CPU资源使用率在硬件上意味着单个核心的50%使用率。
这对于targetCPUUtilizationPercentage来说是无关紧要的，如果我们保持75%的值，HPA将在我们的单核使用率大约为37.5%时开始工作，因为这是pod请求的所有CPU的75%。
从pod/hpa的Angular 来看，它们永远不知道它们在CPU或内存上受到限制。

理解上题场景

对于上面问题中使用的某些程序- * CPU峰值确实会出现 * -但仅在很短的时间内 （例如10秒尖峰）。由于这些尖峰的短持续时间，度量服务器不保存该尖峰，但仅在1 m窗口之后保存度量。在这种情况下，将排除这些窗口之间的尖峰。这解释了为什么在指标 Jmeter 板，但由HPA拾取。
因此，对于具有 * 低CPU资源/限制 * 的服务，较大的纵向扩展时间窗口 （HPA中的scaleUp设置） 可能是理想的。