企业级 Kubernetes 升级长期面临两难

在大规模企业集群环境中升级 Kubernetes 一直需要在及时获取安全补丁与避免业务中断之间做平衡。Google Kubernetes Engine（GKE）默认按照 Google Cloud 的区域时间表逐步推送自动升级。区域滚动升级对独立集群足够有效，但它并不理解企业自身的业务拓扑结构。

打开网易新闻 查看精彩图片

如果预生产集群部署在 us-central1，而关键生产集群部署在 us-east1，标准区域滚动升级可能在预生产验证完成之前就升级了生产环境。这种顺序错位会直接带来业务风险。

自定义阶段让升级顺序匹配业务重要性

GKE 滚动升级排序功能的自定义阶段版本已正式发布（GA）。该功能为平台团队提供声明式控制能力，可以跨集群组、跨环境，甚至跨不同的 Google Cloud 组织来安排集群升级顺序。排序依据从云地理位置改为业务关键程度。

滚动升级排序建立在 GKE 集群组管理之上。集群组作为开发、预生产、生产等环境的逻辑边界。通过滚动升级排序，平台团队可以定义一个有序的升级阶段流水线，由名为 RolloutSequence 的中央资源统一管理。

升级流程按阶段顺序推进

当 GKE 为发布渠道发布新的自动升级目标版本，或者平台团队显式触发目标版本时，系统会创建一个 Rollout 对象。该对象按照预先定义的阶段顺序依次推进：

  • 控制平面升级从第一阶段开始。该阶段内所有控制平面达到目标版本后，阶段浸泡计时器启动。
  • 节点升级与控制平面升级并行进行，同时遵循节点池的升级策略，例如 surge 或 blue-green。
  • 当控制平面和节点都完成升级并满足配置的浸泡时长后，升级流程才进入序列中的下一个阶段。

如果某个阶段中的集群因维护窗口限制或排除规则导致升级耗时超过 30 天，GKE 会触发强制浸泡期，避免整个多阶段流水线被无限期卡住。

标签选择器实现更细粒度的阶段划分

此前基于集群组的滚动升级排序严格以集群组为单位，意味着整个集群组必须完成升级后，另一个集群组才能开始。自定义阶段引入了使用通用表达式语言（CEL）标签选择器的能力，可以把单个集群组拆分为多个更细粒度的升级阶段。

例如，在生产集群组内，可以将一部分集群标记为金丝雀目标，让它们先于生产集群组中的其他集群完成升级。以下是一个定义三阶段序列的 YAML 清单示例：

  • 第一阶段：集群组项目为 projects/dev-fleet-host，浸泡时长为 3 天。
  • 第二阶段：集群组项目为 projects/prod-fleet-host，标签选择器为 resource.labels.tier=='canary'，浸泡时长为 4 天。
  • 第三阶段：集群组项目为 projects/prod-fleet-host，浸泡时长为 7 天。

设计自定义阶段时需关注两个架构要点

在构建自定义阶段时，平台团队需要重点考虑阶段边界的划分逻辑以及浸泡时长的设置。阶段划分应当反映业务依赖关系和验证流程，浸泡时长则需要为预生产验证留出足够时间，同时避免整体升级周期被过度拉长。

通过将升级顺序与业务拓扑对齐，企业可以在保持安全补丁及时性的同时，确保关键生产环境不会在验证完成前被提前升级。这种从区域驱动到业务驱动的转变，为大规模集群管理提供了更可控的升级路径。