为什么K8s Deployment的HPA计算不包含Istio sidecar的CPU request

结论 #

这是Kubernetes 1.19之前版本的预期行为，不属于BUG。

根因分析 #

• HPA计算Pod级CPU利用率的核心逻辑是：Pod所有容器实际CPU用量之和 / Pod所有容器CPU Request总和 * 100%，不同版本K8s获取计算分母的来源存在差异。
• 1.19版本之前，HPA会直接读取关联Deployment的Pod模板（Deployment.spec.template.spec.containers）中定义的容器CPU Request之和作为计算分母。Istio Proxy是通过MutatingAdmissionWebhook在Pod创建阶段动态注入的，配置不会写入Deployment的静态模板，因此HPA不会把它的Request纳入分母计算，观测到的分母仅为业务容器4G的情况符合该版本逻辑。
• 1.19及以上版本的K8s已经优化了该逻辑，HPA会直接从运行态的Pod对象中读取所有容器（含动态注入的Sidecar）的CPU Request之和作为分母，该场景下计算结果会符合预期。

旧版本兼容方案 #

如果暂时无法升级K8s版本，可以用两种方式规避该问题：

• 手动将Istio Proxy的CPU、内存Request/Limit配置写到Deployment的Pod模板中，Istio自动注入时会复用同名容器的配置不会重复注入，HPA即可读取到Sidecar的Request计入分母。
• 改用自定义指标做HPA，比如单独采集业务容器的CPU利用率，或者基于QPS等业务指标做扩容依据，完全规避Sidecar资源指标的干扰。

内容的提问来源于stack exchange，提问作者bin he