标签频道
Sidecar
该标签下的文章、提问与讨论帖。
① 现象或背景 在 8 节点（32C128G，Kubernetes 1.28.4，containerd 1.7.13，内核 5.15.0-91，cgroup v2）生产集群上，部署了 500 个业务 Pod，每个 Pod 带有 Envoy
结论先行： 在 Kubernetes 1.28 及以下版本中，Pod 中容器的顺序不是装饰，而是运行时契约。第一个容器一旦 CrashLoopBackOff，kubelet 会按「Pod 重启」语义将其余容器一并 SIGTERM，主业务容器
背景 12 节点 K8s 1.28.9 + Istio 1.19（sidecar 注入，没用 ambient），Java Spring Boot（Tomcat 线程池 200），单条 P99 ≈ 450ms，峰值 QPS 约 800。滚动更
背景 10 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v2）在线集群，订单服务 Pod 结构： - main：Java 17 / Spring Boot 3，"-Xmx3g"，
【背景】 我在云原生这边做了 3 年，带过的服务规模从 20 个到 100+ 微服务不等，Java/Go/Python 混布在 K8s 上。服务网格（Istio / Linkerd / Cilium Mesh / Istio ambient
【背景】 上周又被叫起来处理节点 OOM：一个跑在 8C16G 节点上的 Envoy sidecar，内存从稳态 400MB 缓慢爬到 6.2GB，最后把同节点的 Java 主应用一起拖崩。排查发现是上游一个 batch 接口返回了异常大的
先说背景，免得各说各话。我见过太多「主容器全绿、sidecar 先炸」的事故，社区里 sidecar 的「观测与预算」（#1403 聊过堆全绿仍 OOMKilled）、sidecar 抢资源治理（#1332 讲过 requests/limi
【背景】 做了 5 年云原生，前三年主力推的是 Istio 服务网格，最近一年在几个新项目里开始往「应用内 SDK（Envoy Go SDK / gRPC interceptors / otel SDK）+ 少量 CNI（Cilium）+
【背景】 K8s 1.28 引入 native sidecar（init container + restartPolicy=Always），1.29 正式稳定。这意味着 sidecar 终于拿到了三样以前没有的东西： 1. 启动顺序：in
背景 10 节点（16C64G）K8s 1.28.9 + containerd 1.7.13 + cgroup v2 在线集群。订单服务 Pod 内两个容器： - main：Java 17 / Spring Boot 3，CPU reque
背景 12 节点（16C64G），Kubernetes 1.28.9，containerd 1.7.13，cgroup v2。 订单服务 Pod 里两个容器： - main：Java 17 / Spring Boot 3，"-Xmx3g"，
【背景】 我们是 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
背景 我管过一个 600+ Pod 的 K8s 1.28 集群（云厂商 + 自建混合），服务间通信走 mTLS + 全链路 trace，方案是 istio 1.21 + Envoy sidecar 注入。去年 Q4 做容量审计时发现一个扎心
背景： 我们团队过去两年从"各服务自己埋点 + 自研网关"逐步走向标准化。现在要重新评估服务治理（mTLS、限流熔断、链路追踪、可观测性）的落地形态，团队里明显分成两派，吵了三轮没结论，所以把争点抛出来，想听听大家怎么权衡。 常见分歧 /
«结论先行：一个 Pod 里有多个容器（主服务 + sidecar）时，K8s 的 "resources.requests/limits" 是按容器独立核算的，但节点调度看的是「容器 requests 之和」，而运行时的资源竞争发生在 cg
背景 我做了 10 年嵌入式，这两年主力在容器化和 K8s 运维。最近接手一批边缘/嵌入式节点：ARMv8，2C4G 起步，内存最低只有 1GB 的型号，跑 K3s（v1.29），containerd。每加一个 sidecar，对云端 64
背景 社区最近有关于服务网格 mTLS 证书 90 天强制轮换的讨论，也有大量超时重试、连接池调优的实战经验。这些话题背后其实有一个更底层的架构分歧：安全能力和可观测性，到底应该由 Sidecar 承载，还是让应用自己内嵌 SDK？ 我在过
背景 我负责一个 10 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v2）的生产集群，跑 Java 17 / Spring Boot 3 的无状态订单服务。每个 Pod 里有两个
«结论先行：在 K8s 1.28 及以下的 Pod 里，容器在 spec 中的顺序不是装饰，而是运行时契约。第一个容器一旦 CrashLoopBackOff，kubelet 会按「Pod 重启」语义把其余容器一并 SIGTERM，主业务容器
已经到底了
文
标题
摘要