分类频道
云原生
该分类下的文章、提问与讨论帖。
背景 我在一个 24 节点的 K8s 1.28 集群上跑一套 Go 1.21 的实时行情计算服务，节点规格是双路 32C（Intel 8358，2 个 NUMA node，每个 16C）/128G/512G NVMe，containerd
一、现象：凌晨 03:12，一台 32G 节点 40 秒内 evict 了 3 个 Pod，死的不是"最重"的那个 上个月凌晨 03:00，我们电商集群一台 8C32G 的 worker 节点（K8s 1.28.9，containerd 1
discussion
容器镜像"能调试"和"够安全"到底能不能兼得？聊聊你的取舍
【背景】 我做了 5 年嵌入式，近两年主力在容器化和 K8s 运维。最近帮两个团队做镜像安全加固，被问得最多的一句话就是："线上出了 segfault / 内存越界，镜像里连 gdb 都没有，怎么查？" 热榜上有探针、OOM、资源声明的讨论
【背景】 我维护一个 8 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v2，100GB 系统盘）的生产集群，CNI 是 Calico 路由模式。最近 2 个月节点磁盘压力明显上来
背景 我在一个 12 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v1）的生产集群上跑一套 Java 17 / Spring Boot 3 的无状态订单服务。每个 Pod 里有
«结论先行：K8s 上有一类故障长得很像「服务挂了」，其实服务、Pod、Service 全活，只是节点的内核连接跟踪表（conntrack）满了——新连接被内核直接丢弃，已建连的长连接还能跑。它的特点是按节点分布、只影响新建连接、"kube
背景 最近给一个 200+ Pod 的 K8s 集群做容量审计，发现一个很有意思的现象：同一个团队的 Java 服务，A 团队 limit=requests，B 团队 limit=2×requests，C 团队干脆不写 limit 只写 r
«结论先行：「这个镜像在 arm 节点上跑得好好的，为什么到了 x86 节点就 "exec format error" / 冷启动慢 6 倍」——根因几乎都不是应用代码，而是 manifest list 的多架构子镜像被拉错了，或者 bin
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
discussion
可观测性要做到「全链路统一标准」还是「按需分层裁剪」？投入产出账怎么算
背景 社区里最近已经攒了不少可观测性相关的干货：#90 讨论了网络层观测做到什么程度算够，#45 复盘了告警治理把噪音从 57 条压到 6 条的过程，#33 讲 GC 毛刺对 P99 的影响。这些文章共同指向一个问题——观测能力是稳定性体系
背景 我负责一个 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 配置
discussion
HPA 扩容后那 30 秒冷启动窗口，P99 抖动到底该谁兜底
【背景】 做了 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，全都