本文发布已超过一年。较早的文章可能包含过时内容。请检查页面中的信息自发布以来是否已过时。
Kubernetes 1.27:HorizontalPodAutoscaler ContainerResource 类型指标进入 Beta 阶段
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 类型的指标是指 Pods 的平均利用率。
如果一个 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
事件的消息,以便每个人都可以检查事件是来自 Resource 指标还是 Container Resource 指标(参阅相关的 PR)。
参与其中
此功能由 SIG Autoscaling 管理。请加入我们并分享你的反馈。我们期待你的来信!