DEBUG.WIKI
京东云;让 AI 进入真实业务;零售 · 物流 · 客服 · 硬件;查看方案 →
ZgoCloud:多地区部署,按需选节点;日本、美国、香港、德国
Evoxt;最高 6.0GHz CPU;高频云服务器 · 免费每周备份;查看配置 →

HPA 的 CPU TARGETS 一直 unknown:有使用量,还要有 requests

HPA CPU TARGETS 显示 unknown 时,按 missing request 与指标缺失分开检查,核对实际容器 requests、采集接口及扩缩容行为。

kubectl get hpa 显示 CPU 的 TARGETS 为 <unknown>/50%,应用正常运行,监控也能看到 CPU 使用量。先看 HPA 的事件:如果出现 missing request for cpu,问题是百分比计算缺少 CPU requests;如果提示没有指标,则要检查指标采集链路。两种情况不能只靠等待来区分。

本文讨论基于 CPU 的 Resource、Utilization 目标。它计算的是使用量相对于 requests 的比例,不是相对于 CPU limit 的比例。已经设置 limit,也要核对实际 Pod 上是否获得了 request。

describe 给出的原因比 unknown 更具体

以下是只读检查示例,替换命名空间、HPA 和 Deployment 名称:

kubectl -n app describe hpa web
kubectl -n app get hpa web -o yaml
kubectl -n app get deployment web -o yaml
kubectl -n app get pods -o yaml
kubectl -n app top pods --containers

确认 HPA 的 scaleTargetRef 指向预期工作负载,查看事件中点名的 Pod 和容器,再核对它们的实际资源字段。模板与运行中的 Pod 可能不同,注入的辅助容器也可能没有填写 request;不能只检查主应用容器的配置片段。

top 能返回使用量,说明资源指标接口至少对该次查询可用,但它不能证明 HPA 的每一个目标 Pod 都有完整指标,也不能替代 requests。top 本身失败时,则需要先处理指标接口或权限问题。

missing request for cpu:补的是分母

基于 Pod 的 CPU 利用率需要相关容器的 CPU request。某个参与计算的容器缺少 request,该 Pod 的 CPU 利用率可能无法定义。错误里点名辅助容器时,给主容器再提高 limit 不会修正它。

资源字段应位于容器的 resources.requests 下。以下只展示已有容器的字段位置,200m 是结构示例,须依据实际需求确定:

spec:
  template:
    spec:
      containers:
        - name: web
          resources:
            requests:
              cpu: 200m

合并到现有容器配置,保留镜像、命令、其他资源和挂载。不要用这一片段替换整个 containers 数组,也不要为了让百分比好看就随意调大 requests。更大的 request 会改变调度需求,也会改变同一使用量对应的百分比,进而影响扩缩容判断。

集群可能通过资源默认规则补充 request,因此判断依据是实际生效的 Pod 配置。若确实只想按主应用容器扩缩容,支持相应版本的集群可另行评估 ContainerResource 指标;这会改变指标范围,应同步考虑容器名和版本支持,不能当作绕过缺字段的临时补丁。

没有指标:检查采集链路,再等新样本

事件为 unable to get metrics、no metrics returned 等信息时,先确认资源指标接口是否可用。当前资源指标常由 Metrics Server 提供,具体部署方式以集群平台为准。还要检查采集服务状态、到节点的网络、认证和证书配置,不要看到 unknown 就重复安装第二套服务。

刚启动的 Pod 或刚恢复的指标服务可能需要等待样本出现,但等待不能修复缺少 requests、持续采集失败或错误的目标对象。旧集群资料中的 Heapster 和已移除的控制器参数不适用于当前部署,也不能把关闭 TLS 校验作为常规解决方法。

如果 requests 与指标均正常,应继续按 HPA 当前事件核对目标对象、就绪状态和指标类型。AverageValue 使用原始指标值,和本文的利用率百分比不是同一种目标,不能只替换字段来消除 unknown。

数值出现后,还要确认扩缩容符合设计

修改前保存工作负载和 HPA 配置,评估 requests 变化、滚动更新和集群剩余容量。通过原部署入口更新后,先确认新 Pod 的资源字段和指标,再观察 HPA 的事件及当前数值是否持续正常。

验收不仅是 TARGETS 从 unknown 变成数字,还包括目标工作负载正确、正常负载下副本数合理、实际负载变化时能在配置范围内响应。回退时恢复相应模板与 HPA 配置;不要假定配置回退会立即把当前副本数恢复到旧值,仍需核对扩缩容状态。