Kubernetes

先说结论：这个问题没有标准答案，但默认应该从"更少"出发，而不是从"更多"出发。多一个集群，就多一套 CNI、监控、告警、CI/CD、证书、RBAC、镜像仓库、节点池管理；人力的边际成本是线性的，而故障隔离的收益是场景化的——大多数团队没到

背景 我维护一个 48 台 worker（8C16G，200GB 系统盘）的 K8s 1.28 集群，containerd 1.7，私有 Harbor 单节点。业务镜像偏大（基础镜像 + 依赖层，单镜像 1.8~2.4GB），发布节奏是每天

现象：一次正常大小的发布，卡了 23 分钟 先交代规模：Kubernetes 1.29.3（containerd 1.7.x），业务集群 46 台 worker（8C16G，200GB 系统盘），私有 Harbor 单节点部署，走内网千兆链

【背景】 我做了 5 年嵌入式，近两年主要精力放在容器化和 K8s 运维上。最近带新人做集群扩容时，被问得最多的一句话就是："requests 和 limits 到底填什么？" 我发现社区里对这件事的分歧非常大，甚至同一家公司内不同团队的做

【背景】 我负责一个 3 节点 K8s 1.28 集群（containerd 1.7，CNI 是 Calico 路由模式），跑 Spring Boot 3 / Java 17 的无状态订单服务，入口是集群内 Service + 一个 Env

背景 我在一个 1.28 的 K8s 集群（containerd 1.7，节点 16C64G，跑 Java 17 / Spring Boot 3 的无状态服务）里，团队之前按「limit = 2 × 堆」的土办法给 Pod 设内存：JVM

现象：一台 100GB 系统盘的节点，凌晨 40 分钟驱逐了 19 个 Pod 上个月凌晨 03:12，集群里一台 8C16G、100GB 系统盘的 worker 节点（Kubernetes 1.28.9，containerd 1.7.13

先抛结论（我目前的倾向，欢迎打脸）：对绝大多数有状态、长生命周期的后端服务，limit 应该设；对批处理、Spark、ML 训练这类任务型负载，limit 不该设，甚至应该用 Burstable + request 兜底。但社区里这三种流派

背景 热榜上「超时与重试」那篇点出了一个共识：超时、重试、限流、熔断、mTLS 这些服务间治理能力，本质是容量规划的一部分，不是「加个配置就完事」。但下一个问题立刻浮出来——这些能力到底放在哪一层做？ 我 3 年里带过的团队，至少见过三种流

背景：K8s 版本 1.27 已 EOL，社区节奏是「小版本 14 个月支持窗口」，生产集群不可能每次都能跟上。我 3 年里带过的团队，升级姿势差别极大：有的坚持滚动升级 + 灰度节点池，每次 1.x → 1.(x+1) 走一遍；有的直接上

背景：我带过的团队里，两种流派都有人。一种是「一应用一 namespace」，权限、配额、NetworkPolicy 都好切，审计也清爽；另一种是「按环境/业务域分 namespace，应用共用」，namespace 数量可控，RBAC 和

结论先行 探针不是「加上就对了」，而是「加错了就是故障放大器」。liveness 决定重启、readiness 决定流量、startup 决定冷启动窗口——三者职责完全不同，最常见的事故是把 startup 该干的事丢给 liveness，