Kubernetes HPA 指标显示 unknown 且不扩容:从指标链路到计算条件的排查实践
Kubernetes HPA 指标显示 <unknown> 且不扩容:从指标链路到计算条件的排查实践 服务流量已经升高,Pod 的 CPU 也明显繁忙,但 kubectl get hpa 中的 TARGETS 长时间显示 <unknown>/60%,副本数始终不变。这个现象不能直接归因于 HPA 控制器故障:资源指标要
Tag
包含这个标签的文章。
Kubernetes HPA 指标显示 <unknown> 且不扩容:从指标链路到计算条件的排查实践 服务流量已经升高,Pod 的 CPU 也明显繁忙,但 kubectl get hpa 中的 TARGETS 长时间显示 <unknown>/60%,副本数始终不变。这个现象不能直接归因于 HPA 控制器故障:资源指标要
适用场景 应用把 ConfigMap 中的单个配置文件挂载到容器现有目录,例如 /etc/app/app.conf。运维修改了 ConfigMap,kubectl get configmap 显示新值,但运行中的应用始终使用旧配置。本文以一个单副本 Deployment 复现,并给出两种可验证的修复路径。以下命令以 B
适用场景 本文适用于在 Kubernetes 中运行数据库备份、账单汇总、定时同步、报表生成等周期任务,并遇到以下问题的团队: 上一次任务尚未结束,下一次任务已经启动,两个 Pod 同时修改同一批数据; 控制面短暂不可用或 CronJob 暂停后恢复,任务突然补跑; 配置了 concurrencyPolicy: For
适用场景 本文适用于通过 Kubernetes Deployment 滚动发布的 HTTP 服务。系统平时运行正常,但每次发布、缩容或节点驱逐时都会出现少量 502、连接重置或上游提前关闭;错误只持续几秒,Pod 日志里又看不到明显异常。 这类问题通常不是新版本启动失败,而是旧 Pod 的进程退出、EndpointSl
适用场景 集群管理员准备升级内核、更换节点或缩容节点池,执行 kubectl drain 后命令长时间重试,并反复出现 Cannot evict pod as it would violate the pod's disruption budget。业务当前未必已经中断,但维护窗口正在被耗尽。 本文适用于由 Deplo
适用场景 Java、Django、Node.js 等服务在 Kubernetes 中滚动发布后,新 Pod 长时间处于 CrashLoopBackOff,Deployment 一直无法完成;而在开发或低负载环境中启动正常。日志常只来得及打印数据库连接、缓存预热或迁移检查的前几行。 本文以“应用冷启动约 90 秒,但存活
适用场景 集群中的应用偶发报出 lookup xxx on 10.96.0.10:53: i/o timeout、SERVFAIL 或连接外部服务失败;重试后又恢复。故障通常集中在业务高峰,Pod 重建、扩容或切换节点后更明显。本文适用于使用 CoreDNS 作为集群 DNS,且 CoreDNS 需要转发外部域名查询的
适用场景 部署在 Kubernetes 中的 Web、API 或消费服务在高峰期 CPU 已长期接近上限,但 HorizontalPodAutoscaler(HPA)始终保持原副本数;也可能在 kubectl get hpa 中看到 CPU 显示为 <unknown>。本文以基于 CPU 利用率的 HPA 为例,给出一
适用场景 本文适用于 Kubernetes 集群中出现以下问题的场景: 新发布的 Pod 长时间处于 Pending 状态; kubectl describe pod 中看到 node(s) had disk pressure; 节点状态出现 DiskPressure=True; 容器镜像、日志或临时目录占满节点磁盘,
适用场景 这篇文章适用于 Pod 一直停留在 Pending、ErrImagePull 或 ImagePullBackOff,业务发布后没有新实例可用的场景。常见环境包括自建 Kubernetes、云厂商托管集群、私有镜像仓库 Harbor、阿里云/腾讯云镜像仓库,以及通过 CI/CD 自动更新镜像 tag 的发布链路