K8s 多容器 Pod 里 istio-proxy + log-agent 到底吃掉多少资源？main 容器的 request/limit 该怎么留余量？

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

• main（Java 业务，-Xmx4g，CPU request=2 / limit=4，Memory request=6Gi / limit=8Gi）
• istio-proxy（Envoy 1.25，mTLS + 全链路 telemetry，CPU request=100m / limit=500m，Memory request=128Mi / limit=512Mi）
• fluent-bit（日志采集，CPU request=50m / limit=200m，Memory request=64Mi / limit=256Mi）

现象 过去两个月，同一 Deployment 触发了 7 次 main 容器 OOMKilled（Exit 137）+ 3 次 P99 飙到 2s（CFS 节流）。但每次炸之前：

• kubectl top pod 看到的 Pod 总 USED 只有 limit 的 70%~80%；
• main 容器的 container_memory_working_set_bytes 确实在涨，但 container_cpu_cfs_throttled_seconds_total 的增量远大于 container_cpu_usage_seconds_total 的增量——说明 CPU 被 CFS 周期切了，不是真的"用完了"；
• istio-proxy 的 CPU 在流量高峰时实际跑到 800~1200m（远超 500m limit），fluent-bit 的 memory 在日志量突增时飙到 400~600Mi（远超 256Mi limit）；
• 节点层面 node_cpu_seconds_total 并没有打满，但 Pod 级别的 CFS quota 已经触顶。

已尝试的排查

1. 把 istio-proxy 的 CPU limit 从 500m 提到 1000m → P99 抖动缓解了一半，但 OOM 没解决；
2. 把 fluent-bit 的 memory limit 从 256Mi 提到 512Mi → 日志突增时不再 OOM，但节点 page cache 被挤占，main 容器的 container_memory_working_set_bytes 反而涨了 200MB；
3. 试了把 sidecar 拆成独立的 DaemonSet → 运维成本翻倍（多一组 Deployment、多一组 HPA），而且 istio-proxy 拆出去后 mTLS 链路要走 node-local IP，延迟多了 2~5ms，业务不答应；
4. 看了一圈 container_cpu_cfs_throttled_seconds_total / container_cpu_usage_seconds_total，istio-proxy 在高峰时 throttle ratio 高达 40%+，但 main 容器只有 5%~10%——不确定这是否说明"sidecar 的 CFS 配额被吃掉了，挤占了 main 的调度窗口"。

期望得到的答案形态

1. 一个可落地的预算公式或经验值：给定 main 容器的 CPU/Memory request，istio-proxy（mTLS + telemetry on/off）和 fluent-bit（日志 QPS ~5k/s）各应该占多少 CPU/Memory？有没有 Envoy / fluent-bit 官方的 sizing guide 可以参考？
2. cgroup v1 下多容器 Pod 的 CFS quota 是怎么分配的——是 Pod 级别共享一个 quota，还是每个容器独立？如果 istio-proxy 的 CFS quota 被用满，会不会"挤占"同一 Pod 内 main 容器的调度窗口？
3. 监控上怎么区分"sidecar 吃多了"和"main 自己用多了"——Prometheus 的 container_* 指标按 container name 拆分后，有没有一条 PromQL 能直接算出"sidecar 占 Pod 总 CPU/Memory 的比例"，以及对应的告警阈值建议？
4. 对于日志量突增的场景（比如一次批量导入触发 10x 日志），fluent-bit 的 Mem_Buffer_Limit 和 K8s memory limit 怎么配合，才能既不让 fluent-bit 被 OOM，也不挤占 main 容器的 page cache？

最好能贴一段真实的多容器 YAML（含 3 个容器的 request/limit）+ 一组 PromQL 告警规则作为参考。空对空的"给 sidecar 多点资源"就略过了。