kubernetes本身不自动弹性部署，必须显式配置hpa并确保metrics server正常运行；hpa依赖metrics server采集指标，未部署或异常会导致状态显示unknown；ai推理服务应避免仅用cpu指标，需结合gpu显存、推理延迟等自定义指标，并严格设置resource limits（含nvidia.com/gpu和memory），同时建议配合cluster autoscaler实现节点级弹性。
直接说结论：Kubernetes 本身不自动弹性部署，必须显式配置 HorizontalPodAutoscaler（HPA）并确保 Metrics Server 正常运行，否则 kubectl scale 手动扩缩只是静态操作，和“弹性”无关。
HPA 配置前必须确认 Metrics Server 是否就绪
很多团队卡在第一步——HPA 创建后一直显示 unknown 状态，根本原因是 Metrics Server 没装或没连上。它不是 Kubernetes 默认组件，必须手动部署：
- 用
kubectl get apiservices | grep metrics检查v1beta1.metrics.k8s.io是否为True - 若为
False，常见原因包括：证书过期、RBAC 权限缺失、Deployment 崩溃（kubectl -n kube-system logs -l k8s-app=metrics-server） - 云厂商托管集群（如阿里云 ACK、腾讯云 TKE）通常预装，但可能默认关闭聚合 API，需进控制台开启
HPA 的 targetCPUUtilizationPercentage 不适合 AI 推理服务
AI 模型服务（如 RetinaFace、MGeo、万物识别）的瓶颈往往不在 CPU，而在 GPU 显存或推理延迟。用 CPU 利用率触发扩缩会严重失准：
Kubernetes Skills
下载
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
- GPU 模型常驻内存，CPU 可能长期低于 20%，但并发请求一上来，
torch.cuda.OutOfMemoryError直接崩 - 正确做法是切换到自定义指标（Custom Metrics），例如 Prometheus 抓取的
http_request_duration_seconds_bucket或gpu_memory_used_bytes - 需额外部署
prometheus-adapter，并让 HPA 引用CustomMetric类型，而非ResourceMetric
Deployment 的 resource limits 必须严格设置 GPU 和内存
HPA 扩容后，如果 Pod 因资源不足无法调度，就会卡在 Pending 状态。尤其 GPU 资源容易被忽略：
-
nvidia.com/gpu: 1必须写在resources.limits下，仅写requests无效；Kubernetes 调度器只看limits做 GPU 绑定 - GPU 显存不足时，模型加载失败日志通常是
CUDA out of memory，但 Pod 状态仍是Running，HPA 完全感知不到 - 内存也要设紧：大模型（如 ResNeSt101）单实例常需
memory: "8Gi"，设低了会导致 OOMKilled，而 HPA 默认不监控容器退出事件
Cluster Autoscaler 和 HPA 要配合使用，但注意缩容节奏
只配 HPA 不配 Cluster Autoscaler（CA），当所有节点 GPU 都被占满时，新 Pod 就无法调度。但两者联动有坑：
- CA 缩容 Node 前会驱逐其上 Pod，若 HPA 正在扩容，可能刚起的 Pod 又被立刻驱逐，造成震荡
- CA 默认缩容阈值是节点 CPU+内存利用率持续 10 分钟
- 生产环境建议：用 CA 管理节点池（如专建
gpu-node-pool），再用 HPA 管理该池内 Pod 数量，避免跨池调度混乱
真正难的不是写几行 YAML，而是把 GPU 调度、指标采集、扩缩决策、节点生命周期这四层逻辑对齐。一个没对齐，弹性就变成间歇性可用。
