Google 刚刚移动了控制平面边界

Source: Dev.to

• 需要更多容量吗？ 添加一个集群。
• 需要工作负载隔离吗？ 添加一个集群。
• 需要区域分离吗？ 添加一个集群。
• 需要专用 GPU 池吗？ 添加一个集群。

集群成为了规模单元，因为控制平面无法扩展到足以避免将其设为单元的程度。

对立的赌注 – Google Cloud Next ’26

在 Google Cloud Next ’26 上，Google 宣布了一个 单一的符合 Kubernetes 标准的控制平面，它跨多个地区覆盖 256 000 个节点，并将 一百万个加速器 作为统一的容量储备进行管理。

不是更大的 Kubernetes，而是完全不同的架构声明。

声明： 现在 控制平面 成为规模的单位。 集群 则不是。

大多数平台架构并未围绕这一假设构建。它们仍然在旧的边界上运行——而这种不匹配正是本文所要讨论的核心。

集群即边界模型

该模型在出现时是有道理的：

• Kubernetes 控制平面存在真实的规模限制。
• 策略执行是 集群范围 的。
• 可观测性是 集群本地 的。
• 容量池与控制平面能够管理的节点组在物理上是绑定的。

这解决了当时的迫切问题，但也悄然产生了另一类问题，且问题会相互叠加：

• 碎片化容量 —— 一个集群中的闲置容量无法被另一个因资源不足而需要扩容的工作负载使用。
• 策略重复 —— 每个集群都需要自己的 RBAC、网络策略和准入控制。更改必须在所有集群间传播，导致结构漂移。
• 观测脱节 —— 指标和日志是集群本地的。要了解系统整体状态，需要把来自数十个独立来源的信号拼接在一起。
• 运维开销叠加 —— 每个集群都是一个离散的对象，需要进行生命周期管理、升级以及故障响应。

业界之所以接受集群数量的激增，是因为另一种选择——对控制平面本身进行扩容——当时并不是一个可信的方案。直到现在。

GKE Hypercluster：架构边界声明

GKE Hypercluster 不是容量声明，而是 架构边界声明：

单个符合 Kubernetes 标准的控制平面，管理跨多个 Google Cloud 区域的 256 000 个节点，将分布式基础设施视为统一的容量储备——这是一种关于边界应位于何处的主张。不是在集群上，而是在 控制平面 上。

控制平面边界

控制平面边界 是调度权限、策略执行和容量治理统一的逻辑边界。过去十年，这一边界因需求而必须是 集群。Hypercluster 是 Google 发出的信号，表明它 不必 局限于此。

当控制平面边界向外扩展——从 集群范围 移至 舰队范围 时：

1. 容量规划变为全局化。
2. 策略成为控制平面的关注点，而非集群的关注点。
3. 调度转变为跨统一多区域池的容量编排。
4. 故障域被重新定义。

这并非 GKE 特有的演进，而是关于架构重心迁移的信号。

四个仍然普遍存在的集群范围假设

1. 集群作为运营边界 – 运行手册、升级周期、证书轮换 … 全部以集群为范围。
2. 集群作为策略边界 – RBAC、网络策略、准入 webhook … 全部在集群范围内应用，在整个集群 fleet 中重复，随时间漂移。
3. 集群作为容量边界 – 集群自动伸缩、节点池、资源配额 … 全部在集群内部定义。跨集群容量感知需要外部工具或手动协调。
4. 集群作为故障边界 – 围绕集群作为自然故障单元的冲击半径假设和可用区映射。

这些假设在控制平面无法超越它们时是正确的架构选择。当控制平面边界向外扩展时，它们就会成为 架构债务。

当控制平面边界转移时会有什么变化

• 容量规划不再是集群本地的。

  • “这个集群还有多少余量？”这个问题变得不正确。
  • 正确的问题是“在这个调度域中可用的容量是多少？”——它可能跨越多个地区和节点类型。

• 策略默认不再是集群范围的。

  • 以前被视为可接受的运营成本的策略复制，在统一调度域中成为设计不一致。

• 故障域不再干净地与集群边界对齐。

  • 在控制平面边界尺度上的冲击半径设计是一项明确的架构决策，而非集群拓扑的默认设置。

• 可观测性必须建模全控制平面的状态。

  • 集群本地指标描述本地状态。全 fleet 的调度决策需要全 fleet 的可视性。当调度域在没有刻意仪表化的情况下扩大时，仪表盘显示的内容与系统实际行为之间的差距不会缩小。

• 调度变成容量编排，而不仅仅是节点放置。

  • 在集群范围内，Kubernetes 调度是一个装箱问题。
  • 在控制平面边界范围内，它是一个容量分配问题。不同的思维模型、不同的工具、不同的运营纪律。

这就是 Kubernetes 运维变成分布式控制平面设计 的地方。这才是真正的转变——而不是芯片数量。

真正的要点

Hypercluster 的头条数字是 一百万颗芯片。这不是应该关注的重点。

Google 并没有告诉你需要管理一百万颗芯片。Google 告诉你 下一个基础设施瓶颈不是计算——而是管理计算的控制平面。

仍然通过增加集群来扩展的团队正在解决 昨天的瓶颈。在旧模型下每新增一个集群，都意味着一次迁移对话的潜在发生。

Source:

控制平面边界正在转移

集群乘法架构的成本不仅仅是运营开销。
它是行业正在超越的边界假设的结构性成本。

控制平面边界 不是 GKE 的特性。它是分布式基础设施中的下一个架构驱动因素。

对其他所有人的架构问题不是是否采用 Hypercluster；而是你的平台设计是否围绕已经在改变的边界假设构建。

为什么当初集群乘法是正确的

Kubernetes 集群乘法并不是错误。它是对真实约束的正确架构响应：控制平面无法扩展到足以使其变得不必要的程度。

该约束现在已经被直接挑战。控制平面边界——调度权威、策略执行和容量治理统一的逻辑边界——应位于 fleet 级别，而不是 cluster 级别。Google 在 Next ’26 上公开做出了这一赌注。

传统假设

大多数平台架构仍然围绕集群作为边界进行设计。指导这些设计的四大假设是：

• 集群作为运营边界
• 集群作为策略边界
• 集群作为容量边界
• 集群作为故障边界

这些假设在上限较低时是正确的，但当上限提升时，它们就会成为架构债务。

“百万芯片”叙事遗漏了什么

百万芯片的数字本身不是重点。重点在于它所暗示的瓶颈转移方向。十年来，团队通过增加集群来规避控制平面上限。上限只是被移动了。

关键问题是：你的架构是为 约束 设计的，还是为 约束阻止你解决的问题 设计的。

结论

控制平面边界 已经转移。大多数架构尚未跟上。

Originally published at rack2cloud.com.