第一步确认是否真为内存泄露：执行istioctl proxy-status，若显示stale或not sent，说明控制平面同步卡顿导致假性内存上涨；第二步检查内存limit是否低于路由规则数所需值，如180条规则需至少384mi，否则为oomkilled而非泄露；第三步用kubectl top pod观察内存是否持续缓慢爬升，再启用prometheus指标采集、istioctl调试接口和als日志进行深度诊断。
排查Istio中Envoy Sidecar内存泄露与延迟过高，需从指标采集、配置校验、运行时诊断三路并进，跳过日志盲扫和重启试探等低效动作。
确认是否真为内存泄露而非配置不当
第一步：登录任意一个业务Pod，执行 istioctl proxy-status 查看该Sidecar是否处于SYNCED状态。若大量显示STALE或NOT SENT，说明控制平面下发卡顿，此时内存上涨是Envoy持续重试同步导致的假性泄露，【不是内存泄露，而是配置同步失败】。
第二步：检查当前Sidecar的内存limit是否低于路由规则数对应的推荐值——例如集群中VirtualService+DestinationRule总数达180条，却只设了256Mi内存limit，Envoy会在384Mi左右触发OOMKilled，表现为周期性CrashLoopBackOff，这不是泄露，是硬性超限。
第三步：用 kubectl top pod -n <namespace></namespace> 观察Sidecar容器的实时内存使用，若长期稳定在limit的85%以上且缓慢爬升（如每小时+5Mi），才进入下一步深度排查。
启用Envoy实时内存与延迟指标采集
方法一：通过Prometheus直接抓取Envoy暴露的/metrics端点
确保Istio已启用meshConfig.defaultConfig.proxyMetadata.PROXY_XDS_VIA_AGENT=true，否则Envoy指标中缺失envoy_cluster_upstream_cx_active等关键连接指标，无法判断连接泄漏。
方法二：用istioctl调试接口获取堆内存快照
执行 istioctl proxy-config clusters <pod-name>.<namespace> --port 15000</namespace></pod-name>，若返回超时，说明Envoy Admin端口被iptables拦截或未开启；此时需检查Pod annotation中是否含sidecar.istio.io/enable: "true"且无traffic.sidecar.istio.io/includeInboundPorts错误覆盖。
方法三：开启Envoy访问日志（ALS）并对接SkyWalking
修改IstioControlPlane配置，启用meshConfig.enableEnvoyAccessLogService=true并指向SkyWalking OAP地址；这一步必须在istioctl install时完成，运行中无法热加载，【热更新会中断所有流量】。
定位延迟高发链路与协议错配
① 执行 istioctl proxy-config listeners <pod-name>.<namespace> --port 15000 -o json | jq '.[].filter_chains[].filters[]? | select(.name=="envoy.filters.network.http_connection_manager")'</namespace></pod-name>，检查http_filters中是否包含envoy.filters.http.ext_authz且grpc_service指向不可达地址——这是延迟飙升最常见原因，外部鉴权服务超时会阻塞整个HTTP pipeline。
② 检查端口命名是否符合Istio协议识别规范：Kubernetes Service的port名称必须以http-、https-、tcp-等前缀开头，否则Envoy默认按TCP透传处理，无法启用HTTP/2升级、gRPC流控等能力，导致RTT翻倍。
③ 运行 istioctl experimental monitor <pod-name>.<namespace></namespace></pod-name>，观察输出中upstream_rq_time分位值。若P99 > 2s但P50 duration字段过滤出具体路径。
