云原生

【背景】 我们团队管着 3 个 K8s 集群（阿里云 ACK、自建 3 节点、客户私有化），200+ 微服务。过去两年，「CPU limits 到底设不设」在三次架构评审里被反复吵，每次结论都不一样。今天想把它摊开，听听大家真实生产里的做法

背景 我维护一个 14 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v2，内核 5.15，100GB 系统盘，Calico 路由模式）的生产集群，跑 Java 17 + Go 的

背景 我在一家中型公司带云原生平台组，集群规模从 30 节点长到 120 节点，业务方从 2 个团队长到 11 个。集群本身没出过大故障，但人和边界的问题越滚越大，最近三个月集中爆了三类矛盾，我越想越觉得这是个没有标准答案、但每个 K8s

【背景】 做云原生 15 年，最近一年带团队做 K8s 1.28 生产集群（40+ 节点、200+ 服务）的容量治理，翻了一遍 HPA 配置，发现一个很尴尬的事实：80% 以上的 Deployment 还是 "type: Resource"

【背景】 做了 8 年嵌入式，最近两年重心放在容器化和 K8s 运维。站内已经有很多单点的好内容：CPU limit 触发 CFS 节流把 P99 从 45ms 打到 2.1s 的复盘、CTE 物化导致 JOIN 变慢、还有我自己在双路 3

背景 过去五年 K8s 从"容器编排方案之一"变成了"容器编排的默认解"。我见过不少团队的姿态是：只要跑容器，第一反应就是上 K8s——哪怕只有 5 个服务、3 台机器、没有跨集群诉求、没有复杂发布流程。 但热榜上「集群粒度」「要不要上 I

背景 过去两年，几乎所有我接触的云原生团队都在评估 Karpenter，最常见的结论是：「比 CA 快、比 CA 灵活、直接换掉」。我自己在 3 个不同规模的集群（8 节点 / 40 节点 / 200+ 节点）里都做过 CA → Karpe

一、现象：凌晨 03:12，一台 32G 节点 40 秒内 evict 了 3 个 Pod，死的不是"最重"的那个 上个月凌晨 03:00，我们电商集群一台 8C32G 的 worker 节点（K8s 1.28.9，containerd 1

背景 最近给一个 200+ Pod 的 K8s 集群做容量审计，发现一个很有意思的现象：同一个团队的 Java 服务，A 团队 limit=requests，B 团队 limit=2×requests，C 团队干脆不写 limit 只写 r

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

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

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

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

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

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

先说结论：这个问题没有标准答案，但默认应该从"更少"出发，而不是从"更多"出发。多一个集群，就多一套 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 单节点部署，走内网千兆链

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

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