envoy

背景：我们是一个内部 gRPC 微服务集群（约 200 个节点），去年年底上了 mTLS（Istio + 自签 CA，cert-manager 管理），初衷是消除内网明文传输。 现象：每次 CA 侧做证书轮换（周期 24h，cert-man

一、现象：RST 与 Envoy drain 的根本区别 结论先行：你看到的 RST 大概率不是 Envoy 应用层 drain，而是 istio-agent 在 SDS 推送新 SVID 时触发了 xDS 全量推送或 agent 侧重连，

【背景】 上周又被叫起来处理节点 OOM：一个跑在 8C16G 节点上的 Envoy sidecar，内存从稳态 400MB 缓慢爬到 6.2GB，最后把同节点的 Java 主应用一起拖崩。排查发现是上游一个 batch 接口返回了异常大的

先说背景，免得各说各话。我见过太多「主容器全绿、sidecar 先炸」的事故，社区里 sidecar 的「观测与预算」（#1403 聊过堆全绿仍 OOMKilled）、sidecar 抢资源治理（#1332 讲过 requests/limi

【背景】 我在一个 K8s 1.28 集群（14 节点，16C64G，cgroup v2，containerd 1.7）里跑一套 Java 17 无状态订单服务。Pod 里有两个容器： - 主容器：Java 17 / Spring Boot

«结论先行：一个 Pod 里有多个容器（主服务 + sidecar）时，K8s 的 "resources.requests/limits" 是按容器独立核算的，但节点调度看的是「容器 requests 之和」，而运行时的资源竞争发生在 cg