Ingress 不能被 HPA 扩缩，真正扩缩的是 Ingress Controller 的 Deployment/StatefulSet；必须设置 resources.requests 才能正确计算利用率；推荐组合使用 CPU、自定义（如 QPS、5xx 率）和外部指标；需配合 Cluster Autoscaler 防止调度失败。
Ingress 本身不是 Pod，不能直接被 HPA 扩缩——它只是 Kubernetes 中的一组 API 对象（Ingress 资源 + Ingress Controller），真正需要扩缩的是背后的 Ingress Controller（如 Nginx Ingress Controller、Traefik、Envoy 等）的 Pod 实例。
扩缩对象是 Ingress Controller 的 Deployment/StatefulSet
你无法对 Ingress 资源做 HPA，但可以对运行 Ingress Controller 的工作负载（通常是 Deployment）配置 HPA。例如：
- Nginx Ingress Controller 默认以 Deployment 方式部署，它的 Pod 处理所有入向 HTTP/HTTPS 流量；
- Traefik 或 APISIX 也类似，都是通过一组 Pod 提供七层网关能力；
- 扩缩它们，等于提升或降低整个集群入口的并发处理能力。
关键前提：合理设置 resources.requests
HPA 判断依据是指标利用率（如 CPU Utilization），而利用率 = 实际使用量 / requests 值。所以必须为 Ingress Controller 容器显式设置 resources.requests.cpu 和 memory：
- 不设 requests → HPA 无法计算利用率，可能拒绝生效或行为异常；
- requests 过小 → 稍有流量就触发扩容，造成震荡；
- requests 过大 → 高负载时利用率仍低于阈值，HPA 不响应。
建议基于压测结果设定：例如单个 Nginx Ingress Pod 在 4c8g 节点上稳定承载 2000 QPS，则可设 requests: {cpu: "500m", memory: "1Gi"}，再配目标 CPU 利用率 60%。
推荐监控指标与 HPA 配置方式
仅靠 CPU 可能滞后（请求已涌入但 CPU 尚未打满），建议组合使用：
- CPU 利用率：基础兜底，防突发计算型压力；
-
自定义指标（推荐）：如每秒新建连接数（
nginx_ingress_controller_nginx_connections_active）、HTTP 5xx 率、或后端平均延迟； -
外部指标：若对接 Prometheus + kube-prometheus-adapter，可基于
sum(rate(nginx_ingress_controller_requests_total[2m]))设定 QPS 目标值。
示例 HPA（v2）片段：
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
- type: Pods
pods:
metric:
name: http_requests_total
target:
type: AverageValue
averageValue: 1500注意节点层协同：Cluster Autoscaler 要配合开启
当 Ingress Controller 因流量激增持续扩容，可能导致节点资源不足（Pending Pod）。此时需确保 Cluster Autoscaler（CA）已启用并正确配置节点组上下限：
- CA 检测到 Pending 的 Ingress Controller Pod，会自动添加新节点；
- 避免只开 HPA 却卡在调度失败，形成“扩不动”的假象；
- 云厂商节点组（如 AWS ASG、阿里云 ESS）需授权 CA 执行扩缩操作。
