Kubernetes

背景 我在 3 个不同团队里都见过 sidecar：Istio 的 envoy、log 采集的 filebeat/fluent-bit、mesh 里的 mTLS、还有"为了绕开 K8s 原生能力"硬塞进来的 proxy。同一个集群里，有的

背景 做了 15 年运维，从 2012 年写 crontab 脚本自动拉起进程，到今天在 K8s 里配 liveness 探针 + 自动驱逐重启，"自愈"这个词我们喊了十几年。但每次事故复盘，绕不开一个问题：这条自愈链路，到底是救了我们，还

先说背景：我带过的团队，从 2019 年开始有人把 Istio 当「银弹」——mTLS、流量治理、可观测性一把抓，结果半年后代理内存、控制面 etcd 压力、跨命名空间授权模型把 SRE 压得喘不过气；也有团队 2024 年才上 Linke

背景 我负责一个 Go 1.22 写的订单网关，部署在 K8s 1.28（containerd 1.7，节点 16C64G）。QPS 峰值 ~3k，单副本。最近一个月被 OOMKilled 3 次，每次都在流量高峰 1~2 小时内，重启后又

«结论先行："kubectl edit configmap" 之后 Pod 里读到的还是旧值，这不是 bug，而是 K8s 的设计——配置「更新」和「Pod 感知到更新」之间隔着两层机制，且它们的生效条件完全不同。这篇文章把 ConfigM

背景 10 年 SRE，最近接手一个 K8s 1.28（containerd 1.7，节点 16C64G）上的 Go 1.21 网关服务，4 副本、单副本峰值 QPS 约 2k，主要工作是转发 + 一些带 30~60s 长连接的任务。 现象

«结论先行：滚动发布期间那波「每次都来、但每次又只持续几十秒」的 5xx，根因几乎都是优雅下线的时序没配对，而不是代码 bug。这篇文章给一份我能直接抄的 preStop + terminationGracePeriodSeconds 配置

【背景】 K8s 1.29 + Kafka 3.5（3 broker，ISR=3），消费组 12 实例（K8s Deployment，maxSurge=1 / maxUnavailable=0），topic "order-pay" 32 分

【背景】 做了 8 年嵌入式，近两年把主要精力放在容器化和 K8s 运维。最近一次流量突增复盘里，我盯着一个很别扭的现象：HPA 在 40 秒内把副本从 6 拉到 18，扩容本身没出错、没 OOMKilled、探针也都绿了，但 P99 在扩

背景 我做了 8 年运维，现在维护一个 12 节点（16C64G，Kubernetes 1.28.9 + containerd 1.7.13，cgroup v2）的在线业务集群，监控栈是 node-exporter + cAdvisor +

背景 我们是一个 40 人团队、约 60 个 Java/Go 微服务，跑在 8 节点自建 K8s 1.28（containerd，CNI 是 Calico）。目前集群内东西向流量全是明文 HTTP，安全团队要求年底前把服务间通信升级为 mT

一、现象与背景：CPU 没打满，延迟却翻了 46 倍 先交代规模和数字。我们一个 12 节点（8C16G，Kubernetes 1.28.9 + containerd 1.7.13，cgroup v1）的网关集群，跑着一个 Go 网关（单实

结论先行 "-Xmx" 只约束了 Java 堆，可 cgroup 的 "memory.limit" 约束的是整个进程 RSS——堆、Metaspace、线程栈、DirectByteBuffer、JIT 代码缓存、glibc arena，全都

背景：团队从单业务线扩到多业务线之后，K8s 集群粒度就成了绕不开的问题。我见过"一个集群扛所有"的，也见过"每个服务一个集群"的，两种极端都有人踩坑。 常见分歧（三种流派）： - 派 A「能少就少」：多集群 = 多套基础设施、多套 CI/

背景 我在一家做工业网关的厂里，核心是一个 1ms 控制周期的实时任务（运动控制 + 协议桥），原本裸机跑在 8C/16G 的工控机上，SCHED_FIFO 99，P99 抖动 <200us，跑了三年稳定。今年公司要求统一容器化、上 K8s

一、现象：P50 稳如老狗，P99 却间歇性飙到 5 倍 先给结论：这次 P99 长尾的根因不是 GC、不是下游、不是连接池，而是我们给容器设的 "cpu.limit=1.5" 触发了 Linux CFS 的周期性硬切（throttling

背景 我做了 15 年嵌入式，早期写 MCU 固件时，"崩溃"是一个必须严肃对待的事件：看门狗喂狗、状态机复位、外设寄存器回写、DMA 通道重初始化——"恢复"从来不等于"重新启动"，而是要回到一个可证明一致的状态。 后来转做容器化和 K8

【背景】 我在给一套 K8s（1.28.9，containerd 1.7.x）里的 Java 8 业务镜像做安全加固，目标是"零业务代码改动 + 非 root 运行 + 只读根文件系统"。securityContext 配了 runAsNo

背景 我做了 15 年运维，最近团队一个 3 副本的 Java 业务（K8s 1.28.9，containerd 1.7.13，cgroup v2）做 rolling update 时翻车：老 Pod 卡在 "Terminating" 状态

背景：我负责一个 12 节点（8C16G、节点池混部）的生产集群，Kubernetes 1.28，containerd。最近做成本复盘时发现一个反复出现的矛盾：很多业务 Pod 的 CPU/Memory request 是按压测峰值 × 1