标签频道
Istio
该标签下的文章、提问与讨论帖。
一、现象或背景 某金融系统支付服务在双十一流量高峰期间，突发「支付回调风暴」导致服务雪崩。监控数据显示，"payment-service" 的 QPS 从 1.2w 突然下跌至 7200，CPU 使用率从 35% 跌至 12%，但数据库连接
一、现象或背景：服务网格中的通信安全困局 2025年3月15日22:47，我们监控到生产环境出现异常： 1. 服务间通信失败率激增：某微服务集群的调用成功率从99.2%骤降至87.6%，日志显示大量"mTLS handshake faile
一、现象或背景 某金融系统支付服务在双十一流量高峰期间，突发「支付回调风暴」导致服务雪崩。监控数据显示，"payment-service" 的 QPS 从 1.2w 突然下跌至 7200，CPU 使用率从 35% 跌至 12%，但数据库连接
一、现象或背景：双层连接池错位引发的 P99 毛刺 我维护一套 gRPC streaming 微服务平台（Go 1.22 + gRPC 1.60，K8s 1.28 + Istio 1.21 sidecar 模式），约 60 个无状态服务，核
背景：我们是一个内部 gRPC 微服务集群（约 200 个节点），去年年底上了 mTLS（Istio + 自签 CA，cert-manager 管理），初衷是消除内网明文传输。 现象：每次 CA 侧做证书轮换（周期 24h，cert-man
现象或背景 去年双十一期间，我们核心交易系统在秒杀高峰遭遇突发故障：某个关键服务 "order-processor" 在 12:00-13:00 间响应延迟从 200ms 拉高到 1.2s，导致全局 QPS 下跌 40%。事后分析发现，该服
一、现象：RST 与 Envoy drain 的根本区别 结论先行：你看到的 RST 大概率不是 Envoy 应用层 drain，而是 istio-agent 在 SDS 推送新 SVID 时触发了 xDS 全量推送或 agent 侧重连，
【背景】 我负责一个中小规模的云原生服务团队，服务数量在 30~60 个之间，运行在 Kubernetes 集群中，混合了多种语言栈（Go、Python、Java）。团队在架构评审中反复被一个问题卡住：是否应该引入服务网格（如 Istio
【背景】 我负责一个中小规模的云原生服务团队，服务数量在 30~60 个之间，运行在 Kubernetes 集群中，混合了多种语言栈（Go、Python、Java）。团队在架构评审中反复被一个问题卡住：是否应该引入服务网格（如 Istio
背景 我维护一套 gRPC streaming 微服务平台（Go 1.22 + gRPC 1.60，K8s 1.28 + Istio 1.21 sidecar 模式），约 60 个无状态服务，核心链路是 server-streaming（一
【背景】 做了 8 年 K8s 运维，今年带团队把一套 30+ 服务的线上平台从「单集群 18 节点」迁到了「同城双集群 + 跨域只读副本」，跑了半年，复盘下来一句话：多集群解决的是容量和故障域问题，但它把 80% 的复杂度从「节点层」转移
背景 12 节点 K8s 1.28.9 + Istio 1.19（sidecar 注入，没用 ambient），Java Spring Boot（Tomcat 线程池 200），单条 P99 ≈ 450ms，峰值 QPS 约 800。滚动更
【背景】 做了 10 年容器化与 K8s 运维，最近两年明显感觉到一个趋势：三年前我们上 Istio 时，「服务发现、mTLS、灰度、可观测」几乎是刚需；而现在原生 K8s 1.30+ 的 Gateway API、Service 内部流量策
【背景】 我在云原生这边做了 3 年，带过的服务规模从 20 个到 100+ 微服务不等，Java/Go/Python 混布在 K8s 上。服务网格（Istio / Linkerd / Cilium Mesh / Istio ambient
先说背景，免得各说各话。我见过太多「主容器全绿、sidecar 先炸」的事故，社区里 sidecar 的「观测与预算」（#1403 聊过堆全绿仍 OOMKilled）、sidecar 抢资源治理（#1332 讲过 requests/limi
【背景】 做了 5 年云原生，前三年主力推的是 Istio 服务网格，最近一年在几个新项目里开始往「应用内 SDK（Envoy Go SDK / gRPC interceptors / otel SDK）+ 少量 CNI（Cilium）+
【背景】 我们是 40 个 Go gRPC 无状态服务，K8s 1.28 自建集群（阿里云 + 自建混合），Istio 1.21 全量 sidecar 注入（mTLS + 全链路遥测）。核心下单链路 SLO 是 P99 < 80ms，现在实
【背景】 我在一个 K8s 1.28 集群（14 节点，16C64G，cgroup v2，containerd 1.7）里跑一套 Java 17 无状态订单服务。Pod 里有两个容器： - 主容器：Java 17 / Spring Boot
【背景】 我维护一个自建 K8s 1.28 集群（containerd 1.6 + Calico IPIP，3 控制面 + 12 工作节点，64C/256G），上面跑约 40 个 Go 无状态服务。最近半年被问得最多的一句话是："我们新项目
【背景】 我负责一套 K8s 1.28（containerd 1.7）集群上约 60 个微服务的传输层安全加固。服务间通信走 Istio 1.21 的 mTLS（STRICT 模式），证书由 cert-manager 签发，初始有效期 90
已经到底了
文
标题
摘要