这篇文章已经一年多了，较旧的文章可能包含过时的内容。请检查从发表以来，页面中的信息是否变得不正确。

Kubernetes 1.27：HorizontalPodAutoscaler ContainerResource 类型指标进阶至 Beta

作者: Kensei Nakada (Mercari)

译者: Michael Yao (DaoCloud)

Kubernetes 1.20 在 HorizontalPodAutoscaler (HPA) 中引入了 ContainerResource 类型指标。

在 Kubernetes 1.27 中，此特性进阶至 Beta，相应的特性门控 (HPAContainerMetrics) 默认被启用。

什么是 ContainerResource 类型指标

ContainerResource 类型指标允许我们根据各个容器的资源使用量来配置自动扩缩。

在下面的示例中，HPA 控制器扩缩目标，以便所有 Pod 的应用程序容器的 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{每个容器的资源使用量} / sum{每个容器的资源请求}

每个容器的资源利用率可能没有直接关系，或可能随着负载变化而以不同的速度增长。

例如：

  • 边车容器仅提供日志传输这类辅助服务。 如果应用程序不经常记录日志或在其频繁执行的路径中不生成日志，则日志发送器的使用量不会增长。
  • 提供身份验证的边车容器。由于重度缓存，当主要容器的负载增加时，使用量只会略微增加。 在当前的混合用量计算方法中，这通常导致 HPA 不会对 Deployment 向上扩容，因为混合的使用量仍然很低。
  • 边车可能在未设置资源的情况下被注入，这会阻止基于利用率进行扩缩。 在当前的逻辑中，当未设置资源请求时，HPA 控制器只能根据 Pod 的绝对资源使用量进行扩缩。

在这种情况下，如果仅有一个容器的资源利用率增加，则 Resource 类型指标可能不会建议扩容。

因此，为了实现准确的自动扩缩，你可能需要改为使用 ContainerResource 类型指标来替代这些 Pod。

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 进行管理。请加入我们分享反馈。我们期待聆听你的声音！

了解更多