标签频道
Istio
该标签下的文章、提问与讨论帖。
背景 我负责一个 10 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v2）的生产集群，跑 Java 17 / Spring Boot 3 的无状态订单服务。每个 Pod 里有两个
【背景】 我们在 K8s 1.27 + Istio 1.20（ambient/waypoint 未启用，走 sidecar 模式）里给一批内部服务开了 STRICT mTLS，服务间走 gRPC。目标是"证书到期自动轮换、业务无感知"。CA
背景 我在一个 12 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v1）的生产集群上跑一套 Java 17 / Spring Boot 3 的无状态订单服务。每个 Pod 里有
discussion
Sidecar 到底是必需品还是历史包袱？聊聊你团队里还在跑的 sidecar
背景 我在 3 个不同团队里都见过 sidecar：Istio 的 envoy、log 采集的 filebeat/fluent-bit、mesh 里的 mTLS、还有"为了绕开 K8s 原生能力"硬塞进来的 proxy。同一个集群里，有的
discussion
服务网格到底该不该在生产上全面铺开？Istio 的三秒 vs 你的 P99
先说背景：我带过的团队，从 2019 年开始有人把 Istio 当「银弹」——mTLS、流量治理、可观测性一把抓，结果半年后代理内存、控制面 etcd 压力、跨命名空间授权模型把 SRE 压得喘不过气；也有团队 2024 年才上 Linke
背景 我们是一个 40 人团队、约 60 个 Java/Go 微服务，跑在 8 节点自建 K8s 1.28（containerd，CNI 是 Calico）。目前集群内东西向流量全是明文 HTTP，安全团队要求年底前把服务间通信升级为 mT