接入 Istio 后每个业务 Pod 都会多出一个名为 istio-proxy 的容器。这个容器运行的是 Envoy，负责拦截、转发、加密所有进出流量，还会收集遥测数据、执行限流和路由规则。它虽然不运行业务代码，但资源消耗并不低，一旦没有合理设置资源请求和限制，轻则影响调度，重则导致 Pod 被 Kubernetes 驱逐。先看资源消耗的主要来源：Envoy 的 listener、cluster、route 配置会占用内存，连接数越多内存越大；CPU 消耗主要来自加解密、路由匹配、上游健康检查和指标生成。默认情况下 Istio 会为 sidecar 注入一个较为宽松的配置，但在流量增长后很容易出现内存不足或 CPU 争抢。
Istio Proxy 的资源消耗来自哪里
Envoy 在运行时会维护大量配置对象，例如每个 cluster 对应一个或多个 endpoint，每个 listener 对应一组 filter chain。对于大型网格，一个 sidecar 可能加载数百个 cluster，每个 cluster 又包含健康检查、熔断、重试等配置，这些都会直接占用堆内存。以 100 个 cluster 为例，仅配置对象本身就可能消耗 50 MiB 以上的内存；如果启用 mTLS，还需要为每个连接维护证书和会话状态，内存压力进一步放大。
CPU 的消耗则与流量特征强相关。Envoy 对每个请求执行 L7 路由匹配、头部解析、超时控制和遥测采样，这些都属于 CPU 密集型操作。特别是当网关或服务开启全局 mTLS、链路追踪、访问日志后，每个请求都要经过多个 filter，CPU 使用率会明显上升。实际观测中，一个每秒处理 500 个请求的 sidecar，其 CPU 消耗通常在 200m 到 800m 之间，波动取决于请求大小和规则复杂度。
另外需要注意，Envoy 的内存管理并不像业务容器那样线性。它会预分配一定大小的堆，并随着连接数增长逐步扩展。如果只设置了 memory request 而没有设置 memory limit，在极端流量下 sidecar 可能占用节点大量内存，甚至触发宿主机 OOM。因此，理解这些消耗来源是后续配置 requests 和 limits 的前提。
requests 和 limits 应该怎么设
Kubernetes 中 requests 用于调度器判断节点是否有足够资源，limits 则是容器可以使用的硬上限。对 Istio Proxy 来说，requests 设置过低会让调度器误判节点容量，导致 Pod 被调度到资源紧张的节点上；limits 设置过低则可能直接杀死代理进程。一个常见误区是把 sidecar 的 memory limit 设成与业务容器相同的 128 MiB，结果在流量高峰时 Envoy 因内存超限被 OOMKilled，连带业务容器也无法正常服务。
一般建议先设置一个相对保守的初始值，再根据监控逐步调整。对于大多数中小型服务，sidecar 的 CPU request 可以设为 50m 到 100m，memory request 设为 64 MiB 到 128 MiB；CPU limit 可以放宽到 500m 到 2000m，避免短时毛刺被限流，memory limit 则建议从 256 MiB 起，再根据 kubectl top pod 的实际工作集调整。网关类工作负载由于流量集中，通常需要单独评估，不能直接套用普通 sidecar 的数值。
设置时还要区分 QoS 等级。如果业务容器和 sidecar 都设置了 requests 和 limits，并且两者数值相等，Pod 会获得 Guaranteed 等级，不容易被驱逐；如果只设置 requests 不设置 limits，属于 Burstable 等级，在节点资源紧张时可能被优先回收。生产环境建议至少为 sidecar 同时配置 requests 和 limits。
通过注解和全局配置管理资源
Istio 提供了多种方式为 sidecar 设置资源。最细粒度的方法是直接在 Pod 模板上添加注解，例如：
apiVersion: v1
kind: Pod
metadata:
name: reviews-v1
labels:
app: reviews
version: v1
annotations:
sidecar.istio.io/proxyCPU: "100m"
sidecar.istio.io/proxyCPULimit: "500m"
sidecar.istio.io/proxyMemory: "128Mi"
sidecar.istio.io/proxyMemoryLimit: "256Mi"
spec:
containers:
- name: reviews
image: docker.io/istio/examples-bookinfo-reviews-v1:1.16.2
这些注解会在 sidecar 注入时被读取并写入 istio-proxy 容器的 resources 字段。注解中的 CPU 单位可以是毫核，内存单位可以是 Mi、Gi，Kubernetes 会解析成对应的数值。需要注意的是，注解只对新建或重启后的 Pod 生效，修改 Deployment 后需要滚动更新才能应用。
如果希望对某个命名空间内的所有 Pod 统一设置，可以在命名空间上打同样的注解。注入器在创建 Pod 时会继承命名空间注解，从而避免为每个 Deployment 重复配置。全局默认值则可以在安装 Istio 时通过 values.global.proxy.resources 指定，示例如下：
spec:
values:
global:
proxy:
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 2000m
memory: 1024Mi
上面的配置会影响所有注入 sidecar 的工作负载，除非 Pod 注解显式覆盖。这种分层设计很实用：全局给一个宽泛的默认值，命名空间按团队或环境收紧，个别高流量服务再用 Pod 注解精确控制。注意调整全局默认值后，已经运行的 Pod 不会自动更新，需要重启对应工作负载。
监控、告警与常见误区
只设置资源值还远远不够，必须配合监控才能判断是否合理。最直接的方式是使用 kubectl top pod -n 命名空间 查看每个 Pod 的 sidecar 容器实际消耗。如果发现 istio-proxy 的内存工作集长期接近 limit，说明需要上调或排查内存泄漏；如果 CPU 使用率已经达到 limit 但仍然出现延迟尖刺，说明可能存在 CPU 节流。
Envoy 本身也暴露了丰富的内存指标，例如 envoy_server_memory_allocated 表示当前分配内存，envoy_server_memory_heap_size 表示堆大小。将这些指标接入 Prometheus 后，可以设置告警规则：当某个 sidecar 的内存使用率超过 limit 的 80% 时发出预警，而不是等到 OOMKilled 再处理。同时建议关注 envoy_server_uptime 和连接数指标，因为连接数增长往往先于内存增长。
常见误区主要有三类：一是把业务容器的资源经验直接套在 sidecar 上，忽略了 Envoy 自身的基础消耗；二是只设 limit 不设 request，导致调度器无法感知真实资源需求；三是把 limit 设得极高以追求绝对稳定，结果让节点超售严重，反而影响整集群稳定性。合理的做法是为每个服务先测量一段时间的峰值和均值，再分别设定 request 和 limit，通常 limit 是 request 的 2 到 4 倍，既保留弹性空间，又避免资源浪费。
Istio Proxy容器资源管理资源请求与限制修改时间：2026-09-24 18:21:45