企业官网建设流程全解析

Sidecar 资源配额调优：CPU 和内存分配不当比不用网格还糟

一、压测时发现 30% 的 CPU 都喂给了 Sidecar

Service Mesh 上线第一版时，我们直接套用 Istio 官方推荐的 Sidecar 资源配置：requests.cpu=100m, requests.memory=128Mi。结果压测一跑，同一个业务 Pod 在不注入 Sidecar 时 QPS 4200，注入后降到 2900——近 1/3 的性能被 Sidecar 吃掉。查了半天发现不是 Envoy 的问题，是我们把它的资源配额设得太低，导致 Envoy 和业务容器在 CPU 层面互相争抢。

更隐蔽的问题是：requests设低了，K8s 调度器把 Envoy 和业务容器放在同一物理核上，上下文切换频率飙升。limits设低了，Enovy 在高流量下被 CPU throttling 限死，连接数上去后延迟爆炸。

二、Sidecar 的 CPU/内存消耗模型

Envoy 的资源消耗不是线性的——它的 CPU 消耗和连接数、QPS、TLS 握手频率强相关，内存消耗和连接数、配置复杂度相关。

graph LR A["流量进入 Pod<br/>iptables 劫持"] --> B["Envoy Inbound<br/>TLS 终结/路由"] B --> C["业务容器<br/>处理请求"] C --> D["Envoy Outbound<br/>TLS 发起/负载均衡"] D --> E["目标服务"] B -.-> F["CPU 消耗因素<br/>- 并发连接数<br/>- QPS 大小<br/>- TLS 握手率<br/>- 过滤器链长度"] D -.-> F B -.-> G["内存消耗因素<br/>- 活跃连接数<br/>- 集群/端点数量<br/>- Filter State<br/>- 日志缓冲"] D -.-> G style F fill:#FF6B6B,color:#fff style G fill:#4A90D9,color:#fff

三个关键认知：

1. 每连接成本：Envoy 每维护一个 TCP 连接约消耗 16-32KB 内存。如果你是长连接模型且连接数 10w+，Sidecar 内存必须上 GB。
2. Worker 线程数：Envoy 默认--concurrency = CPU 核数。如果你给 Sidecar 分配了cpu: 0.5，Envoy 仍然起 2 个 worker 线程，结果两个线程争 500m CPU，吞吐反而低于单线程。
3. TLS 握手是 CPU 黑洞：一次 mTLS 握手约消耗 1ms CPU 时间。万级 QPS 的全 mTLS 通信场景，Sidecar CPU 不给够就会出现连接超时。

三、生产级 Sidecar 资源配置实践

第一步：根据 QPS 和连接数计算基线

#!/usr/bin/env python3 """ Envoy Sidecar 资源配额计算器 根据 QPS、连接数、TLS 比例自动计算推荐的 requests/limits """ from dataclasses import dataclass from enum import Enum class TLSMode(Enum): NONE = "none" # 无 TLS INBOUND = "inbound" # 仅入站 TLS MUTUAL = "mutual" # 全 mTLS @dataclass class SidecarProfile: """业务 Pod 的流量画像""" avg_qps: int # 平均 QPS peak_qps: int # 峰值 QPS concurrent_connections: int # 并发长连接数 tls_mode: TLSMode avg_response_size_kb: int = 10 class EnvoyResourceCalculator: """基于 Envoy 资源模型的配额计算""" # 每个连接的静态内存开销（KB），来自 Envoy 社区基准测试 MEM_PER_CONNECTION_KB = 24 # 每 QPS 的 CPU 消耗（millicore），实际值因业务而异 # 无 TLS 时约 0.02m，mTLS 时约 0.15m（含握手开销） CPU_PER_QPS_NO_TLS = 0.02 CPU_PER_QPS_MUTUAL_TLS = 0.15 # Envoy 自身的基础内存（MB），无论流量多大都会占用 BASE_MEMORY_MB = 64 def calculate(self, profile: SidecarProfile) -> dict: # —— CPU 计算 —— if profile.tls_mode == TLSMode.MUTUAL: cpu_per_qps = self.CPU_PER_QPS_MUTUAL_TLS else: cpu_per_qps = self.CPU_PER_QPS_NO_TLS # 请求层：按峰值 QPS 分配 CPU，确保高负载不 throttling cpu_request = profile.peak_qps * cpu_per_qps # 为什么用峰值而非平均值：K8s 的 CPU throttling 在 requests=limits 时最安全 # 如果 requests < limits，burst 时会触发 CFS throttling # 加 30% 余量，应对偶发的连接风暴和过滤器计算 cpu_request *= 1.3 # 最小 100m，最大不超过 Node 单核 cpu_request_m = max(100, min(int(cpu_request), 4000)) cpu_limit_m = cpu_request_m * 2 # Burst 允许用到 2 倍 # —— 内存计算 —— # 连接层内存 conn_memory_mb = ( profile.concurrent_connections * self.MEM_PER_CONNECTION_KB / 1024 ) # 总内存 = 基础 + 连接 + 20% 余量（日志缓冲/Filter State） memory_mb = self.BASE_MEMORY_MB + conn_memory_mb memory_mb *= 1.2 return { "resources": { "requests": { "cpu": f"{cpu_request_m}m", "memory": f"{int(memory_mb)}Mi", }, "limits": { "cpu": f"{cpu_limit_m}m", "memory": f"{int(memory_mb * 1.5)}Mi", }, }, "concurrency_hint": max(1, cpu_request_m // 500), # 建议的 Envoy --concurrency 参数 # 每 500m CPU 配一个 worker 线程 } # —— 使用示例 —— if __name__ == "__main__": profile = SidecarProfile( avg_qps=2000, peak_qps=5000, concurrent_connections=5000, tls_mode=TLSMode.MUTUAL, ) calc = EnvoyResourceCalculator() result = calc.calculate(profile) print(f"建议 Sidecar 资源配置:") print(f" requests: cpu={result['resources']['requests']['cpu']}, " f"memory={result['resources']['requests']['memory']}") print(f" limits: cpu={result['resources']['limits']['cpu']}, " f"memory={result['resources']['limits']['memory']}") print(f" Envoy concurrency: {result['concurrency_hint']}")

第二步：Istio 注解式覆盖默认配置

# 对单个 Deployment 注入自定义 Sidecar 资源 apiVersion: apps/v1 kind: Deployment metadata: name: high-qps-service spec: template: metadata: annotations: # 覆盖 Istio 默认注入的 Sidecar 资源配额 sidecar.istio.io/proxyCPU: "500m" sidecar.istio.io/proxyCPULimit: "1000m" sidecar.istio.io/proxyMemory: "256Mi" sidecar.istio.io/proxyMemoryLimit: "512Mi" # 指定 Inbound/Outbound 拦截端口，缩小 Envoy 的监听范围 # 为什么不全部拦截：每多一个端口，Envoy 多一个 listener， # 启动时间 +50ms，内存 +2MB traffic.sidecar.istio.io/includeInboundPorts: "8080" # 连接池配置：限制单个上游的最大连接数 # 默认 1024，高并发服务需要翻倍 sidecar.istio.io/statsInclusionPrefixes: "cluster.outbound"

第三步：运行时动态调整 Envoy 参数

生产环境最怕的是"配好了但不生效"。Envoy 支持运行时动态配置（LDS/RDS/CDS/EDS），但并发线程数、内存缓冲区大小等启动参数需要重启才能改。

# 1. 查看当前 Envoy 的内存和连接指标 kubectl exec -it <pod> -c istio-proxy -- \ curl -s localhost:15000/stats | grep -E 'server\.(memory|connections)' # 2. 查看 CPU throttling 情况 kubectl exec -it <pod> -c istio-proxy -- \ cat /sys/fs/cgroup/cpu/cpu.stat | grep throttled # 3. 如果 throttled_usec 持续增长，说明 CPU limit 不够 # 应立即调整 annotation 并重启 Pod（Istio 1.18+ 支持不重启更新 Envoy 配置）

四、Sidecar 资源过配的代价

缺点：

• 资源浪费叠加：1000 个 Pod 的 Sidecar，每个多配 50m CPU，总共多占 50 核——相当于 3 台 C6 节点。
• CPU requests 过高会降低调度密度：K8s 调度器只看 requests，一台 16 核节点若每个 Sidecar 占 500m，最多调 32 个 Pod——虽然实际 Envoy 大多时候用不到 500m。
• 内存限制过死会 OOM Kill：Envoy 被 OOM Kill 后，Pod 的所有流量立即中断（iptables 规则还在，但 Envoy 已死），比业务容器 OOM 更致命。

禁用场景：

• 毫秒级延迟敏感的交易系统，任何 Sidecar 代理都不可接受（应选 eBPF 模式的 Cilium）。
• 流量极低（<10 QPS）的内部管理服务，Sidecar 的 64MB 基础内存浪费不值得。

五、总结

Sidecar 资源配置不是"给个默认值就行"的事。CPU 给低了会 throttling，给高了浪费集群资源。正确的做法是：根据 QPS、连接数、TLS 模式计算资源基线，用 Istio annotation 对不同类型的服务独立配置，并通过concurrency参数让 Envoy 的线程数和分配到的 CPU 匹配。最好的配置，是最接近实际流量模型的配置。