K8s 集群粒度：什么时候该拆多集群、什么时候一个就够？

楼主苏清和-123

Kubernetes多集群架构设计云原生运维

背景：团队从单业务线扩到多业务线之后，K8s 集群粒度就成了绕不开的问题。我见过"一个集群扛所有"的，也见过"每个服务一个集群"的，两种极端都有人踩坑。

常见分歧（三种流派）：

派 A「能少就少」：多集群 = 多套基础设施、多套 CI/CD、多套监控告警，运维成本线性增长。只要 namespace 隔离 + ResourceQuota + LimitRange 用对，一个 200+ 节点的大集群完全能扛。拆了之后你会发现 80% 的精力花在跨集群同步和一致性上。
派 B「必须拆」：大集群爆炸半径太大——一次 etcd 抖动、一次网络分区、一次 controller-manager OOM，影响面是所有业务。按"故障域"拆，每个集群独立 etcd、独立控制面，天然隔离。"大集群就是定时炸弹"。
派 C「按环境/租户拆」：生产一个、预发一个、测试一个；SaaS 场景按租户拆。不追求极致隔离，但保证"测试环境故障不波及生产"、"A 租户资源不挤占 B 租户"。

我的倾向：默认一个集群起步，但提前定义"必须拆"的触发条件。触发条件不是节点数，而是以下任意一条： (1) 存在 SLA 等级差异 >2 个数量级的业务（比如支付 99.99% vs 内部工具 99%）； (2) 存在强合规/数据隔离要求（金融、医疗、跨境）； (3) 团队规模超过 50 人且跨多个独立产品组，namespace 级别的 RBAC 权限隔离开始失控。理由：多集群的运维成本是真实的，但"爆炸半径"和"权限边界"这两个风险，在单集群里靠软隔离是兜不住的。反过来，如果没有上面任何一条触发条件，硬拆就是自找 3 套 etcd 备份、3 套证书轮换、3 套 Ingress 配置的麻烦。

想听大家：

你们在什么场景下选了多集群？是 SLA 差异、合规、团队规模，还是单纯"怕大集群炸"？
有没有人试过先大后拆，最后发现拆的成本比一开始就拆高得多（历史数据迁移、DNS 切换、跨集群服务发现）？
多集群之后你们怎么解决跨集群的服务调用和服务发现？Service Mesh、GitOps 联邦、还是干脆拆成独立系统？

赞 0 · 收藏 0 · 楼层 1

楼层

#129 苏清和-123

补充一个实操细节：namespace 隔离 + ResourceQuota 在 200+ 节点集群里确实能扛，但有两个容易踩的坑。第一，limits.cpu 是硬上限不是建议值——业务有突发流量（秒杀、批量导入）时，limits.cpu 设太紧会导致 Pod 被 throttle，表现是 P99 延迟突然飙升但 CPU 利用率并不高，排查时非常迷惑。建议 requests.cpu 设到日常 P95 的 120%，limits.cpu 设到 P99 的 150%，留足突发余量。第二，pods 这个 quota key 经常被忽略——它限制的是 namespace 内的 Pod 总数，滚动更新时新旧 Pod 并存会临时翻倍，设太紧会导致新 Pod 起不来、旧 Pod 被驱逐的恶性循环，K8s 日志里看到的是 FailedCreate: pods "xxx" is forbidden，很容易误判为 RBAC 问题。