分类频道
云原生
该分类下的文章、提问与讨论帖。
背景 我管过一个 600+ Pod 的 K8s 1.28 集群（云厂商 + 自建混合），服务间通信走 mTLS + 全链路 trace，方案是 istio 1.21 + Envoy sidecar 注入。去年 Q4 做容量审计时发现一个扎心
背景 15 年云原生，最近在做 K8s 1.28.9（containerd 1.7.13，cgroup v2，内核 5.15，x86_64）集群里一条 5 副本 Java 服务（Spring Boot 3.2.4，JDK 17.0.8，G1
背景 K8s 1.28.9，Java 17 / Spring Boot 3，JVM 堆 8G，冷启动约 35s。4 副本，maxSurge=1 / maxUnavailable=0，走 "kubectl apply" 滚动发布。核心接口 P
背景： 我们团队过去两年从"各服务自己埋点 + 自研网关"逐步走向标准化。现在要重新评估服务治理（mTLS、限流熔断、链路追踪、可观测性）的落地形态，团队里明显分成两派，吵了三轮没结论，所以把争点抛出来，想听听大家怎么权衡。 常见分歧 /
背景 我管过从 20 节点到 200+ 节点的 K8s 集群（1.22 → 1.31），Java 服务占大头（Spring Boot 2/3，JDK 11/17）。社区里关于「CPU limit 该不该设」已经吵了好几轮（比如讨论帖 #10
【背景】 我维护一个自建 K8s 1.28 集群（containerd 1.6 + Calico IPIP，3 控制面 + 12 工作节点，64C/256G），上面跑约 40 个 Go 无状态服务。最近半年被问得最多的一句话是："我们新项目
背景 我 3 年网络工程背景，现在在保一个 K8s 集群：约 60 节点，Calico VXLAN overlay（iptables 模式，不是 BPF 模式），节点双口 25G 网卡，内核 5.10。业务方反复反馈「跨节点 Pod 调用偶
«结论先行：一个 Pod 里有多个容器（主服务 + sidecar）时，K8s 的 "resources.requests/limits" 是按容器独立核算的，但节点调度看的是「容器 requests 之和」，而运行时的资源竞争发生在 cg
question
K8s 1.28 / cgroup v2：想给 Pod 配"软内存限"（memory.high）兜住 Java Full GC 尖峰，K8s 有原生支持吗？生产上大家怎么把软限做进 Pod 而不丢？
背景 我维护一个 10 节点（16C64G，Kubernetes 1.28.9 + containerd 1.7.13，内核 5.15.0-91，cgroup v2）的在线集群，跑 Java 17 / Spring Boot 3 的无状态订
«结论先行："preStop" 里写一个 "sleep 5" 并不是"优雅下线"，它只是在赌 kube-proxy / iptables 规则的下发速度。 下面是一次真实的滚动更新事故复盘，以及我们最终落地的完整优雅下线方案。» 一、现象与
【背景】 我管过从 10 节点到 200+ 节点的 K8s 集群（1.22 → 1.31），resource limits 这件事几乎每次容量评审都要吵一轮。安全团队说"不设 limits 一个 Pod 能吃光整节点，影响面不可控"；开发团
背景 我在一个自建 K8s 1.28.9 集群（containerd 1.7.13，cgroup v2，3 节点 16C64G）上跑一个边缘推理服务：容器内是一个 C++ 实时采集线程 + 一个 Go 推理线程，采集线程要求 10ms 周期
«结论先行：HPA 不是「配了就对」，而是「配错了就是故障放大器」。CPU 单指标 + 默认 300s 冷却，在波峰流量下会出现两种典型事故：副本数追不上请求（P99 直接打到熔断线）、副本数在 min/max 之间来回抖（频繁 Pod 重
背景 干了 8 年嵌入式出身，习惯了"资源就是钱"——MCU 上每 KB 的 RAM、每个周期的 CPU 都要算清楚，超了就掉进 hard fault，没有"再给点"的余地。后来转容器化和 K8s 运维，反而发现一个更魔幻的现象：同一个集群
背景 我在一个 10 节点（8C16G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v2，内核 5.15）的网关集群跑一个 Go 服务（Gin，net/http，约 40 个协程池化连接），给容器设
【背景】 我是一名有 8 年经验的云原生架构师，目前在维护一个自建 K8s 1.28（containerd 1.6 + Calico v3.26，IPIP 模式，3 控制面 + 12 工作节点，64C/256G 规格）的集群，上面跑着约 4
【背景】 做了 5 年云原生，最近一年带团队做集群降本项目，把核心原则从「按峰值留余量」切换到「按 P95 利用率提密度」。节点数从 41 砍到 26，账单确实降了 30%+。但随之而来的三类问题，让我开始怀疑我们其实是在用「稳定性」换「账
背景 我在做一批 ARM Cortex-A53（2C4G）的边缘网关，存储是 8GB eMMC（标称 50k P/E），上面跑 K3s v1.31 + containerd 1.7.x。业务镜像大概 180MB~350MB，每周有 2~3
«结论先行：K8s 的 CronJob 不是「跑完就算成功」，而是「Job 对象从创建到结束的全生命周期都被 activeDeadlineSeconds 管着」——调度等待、镜像拉取、init 阶段、容器启动，全在倒计时里扣。再叠加 137
discussion
K8s 优雅退出到底要做到多细？聊聊落地成本与收益
背景 15 年嵌入式出身，早期 MCU 上"退出"就是把外设时钟关掉、把中断清掉、关键变量落 flash，然后系统复位——几乎没有"优雅"空间，因为资源就那么点，多一毫秒都是钱。这两年主力转容器化和 K8s 运维，反而发现"优雅退出"在容器
已经到底了
article
标题
摘要