HPA 只看 Pod 级 CPU 利用率，sidecar 占大头时 main 容器明明还有余量就提前扩容了，怎么破？

背景 我负责一个 10 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v2）的生产集群，跑 Java 17 / Spring Boot 3 的无状态订单服务。每个 Pod 里有两个容器：

• main：Java 订单服务，request=2 CPU / 4Gi，limit=4 CPU / 6Gi
• istio-proxy：Envoy，request=0.5 CPU / 512Mi，limit=1 CPU / 1Gi

HPA 配置：type: Resource, target: Utilization, targetAverageUtilization: 70，minReplicas=4，maxReplicas=20，behavior 里 scaleUp stabilizationWindow=60s，scaleDown=300s。

现象 白天高峰（QPS 约 3200）时，HPA 把副本从 8 扩到 14，但用 kubectl top pod 和 Prometheus 的 container_cpu_usage_seconds_total 拆开看：

• istio-proxy 的 CPU 均值稳定在 0.85 CPU（request 0.5 的 170%）
• main 的 CPU 均值只有 1.2 CPU（request 2 的 60%）
• Pod 级 CPU 利用率 = (0.85+1.2) / (0.5+2) = 82% > 70% 阈值，所以 HPA 持续扩容

但 main 容器实际还有 40% 的 CPU 余量，P99 延迟在 38ms 完全健康。扩到 14 副本后，节点 CPU 分配率从 62% 升到 89%，成本多花了约 35%（按 ACK 按量付费算）。

已尝试的排查

1. 把 targetAverageUtilization 从 70 调到 85 → 缓解了但治标不治本，sidecar 负载一涨又会触发
2. 把 istio-proxy 的 request 从 0.5 调到 1.0 → Pod 级利用率降到 70%，但 main 的 request 占比被稀释，调度装箱率反而变差
3. 看了 HPA 的 API 文档，target: Utilization 确实是按 Pod 级（所有容器 usage 之和 / 所有容器 request 之和）算的，没有 per-container 的选项
4. 社区里有人提到 target: AverageValue 可以配合 custom metrics，但我们的 metrics-server 只暴露 Pod 级指标，Prometheus 里有 per-container 的 container_cpu_usage_seconds_total

期望得到的答案

1. 有没有不改 HPA 核心机制的折中方案？比如调 sidecar 的 request 比例、用 targetAverageValue 配合 per-container 指标，或者用 external metrics 桥接 Prometheus？
2. 如果上 Prometheus Adapter + target: AverageValue，per-container 的 CPU 指标表达式怎么写？有没有已验证的 Helm chart 或 YAML 示例？
3. 成本角度：为了"只看 main 容器"引入 Prometheus Adapter + custom metrics 的运维成本（多一个组件、多一套告警、多一条指标链路），在 10 节点 / 200+ Pod 的规模下，到底值不值？有没有更轻的替代（比如直接用 KEDA + 业务指标 QPS）？
4. 如果 sidecar 是 Istio（Envoy），有没有社区推荐的 sidecar request 配比经验值，能让 Pod 级利用率尽量反映 main 的真实负载？

希望答案能给出可复现的配置片段（HPA YAML / Prometheus Adapter CRD / KEDA ScaledObject），以及落地后一周内的观测指标和预期效果。