为 Azure Kubernetes 舰队管理器群集资源放置定义推出策略

2025-08-15

在群集资源放置（CRP）的生存期内，可能会对 CRP 进行更改，这可能会导致以下情况之一：

所有选定的群集可能需要承担新的工作负载
已放置在选取的群集上的工作负荷可能会更新或删除
以前选取的一些群集现已取消选取，并且必须从此类群集中删除工作负荷
已新选取了一些群集，必须将工作负荷添加到这些群集中。

大多数情景可能会导致服务中断，因为 Fleet Manager 调度更新资源时，成员群集上运行的工作负荷可能会暂时不可用。未被选择的群集将失去所有已放置的资源，从而导致网络流量丢失。如果选择了太多新群集，并且机群管理器会同时将资源置于这些群集上，群集可能会过载。确切的中断模式可能因放置的资源而异。

为了最大程度地减少中断，Fleet Manager 的群集资源放置允许用户配置推出策略，类似于本机 Kubernetes 部署，以便尽可能顺利地在更改之间进行转换。

本文介绍可用于群集资源放置的推出策略选项。

注释

如果不熟悉 Fleet Manager 的群集资源放置（CRP），请在阅读本文之前阅读资源放置的概念概述。

没有显式策略的默认行为

群集资源放置不需要定义推出策略。如果未指定其中一个参数，则默认行为是使用 RollingUpdate 策略，其中 maxSurge 为 25%，maxUnavailable 为 25%，unavailablePeriodSeconds 为 10 秒。

滚动更新策略

要实现显式滚动更新策略，可以按如下示例将 strategy 规范添加到 CRP 中。可以定义控制舰队管理器资源放置中断程度的参数。

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-example
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: test-namespace
      version: v1
  policy:
    placementType: PickN
    numberOfClusters: 2
    affinity:
      clusterAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          clusterSelectorTerms:
            - labelSelector:
                matchLabels:
                  fleet.azure.com/location: chinanorth3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 50%

可以使用以下参数配置滚动更新策略：

maxUnavailable： 如果资源尚未成功应用于群集，则认为该群集不可用，并确保在任何时间 至少有（N - maxUnavailable）个群集是可用的。可以设置为绝对数或百分比。默认值为 25%，不应使用零。将此参数设置为较低的值会导致更改期间中断较少，但导致推出速度较慢。
maxSurge： 确保在任何时候，可用的群集数量最多为（N + ）。可以设置为绝对数或百分比。默认值为 25%，不应使用零。将此参数设置为较低值会导致 Fleet Manager 在更多群集上放置较少的资源，从而减缓推出过程的速度。
unavailablePeriodSeconds 允许在资源评估为“就绪”之前定义一个时间段。默认值为 60 秒。在资源成功应用到该群集后，舰队管理器仅将群集上的新应用的资源视为“就绪” unavailablePeriodSeconds 秒。将此参数设置为较低的值会导致更快的部署。但是，强烈建议用户设置一个允许完成初始化/准备任务的值。

如何确定群集计数

机群管理器使用布置类型来确定在计算N或maxUnavailable时要使用的群集maxSurge的基线数：

PickFixed：clusterNames的指定数目
PickAll：选取的群集数
PickN： numberOfClusters 值。

如果对参数使用百分比，则也会根据 N 该参数进行计算。

分阶段更新策略（预览版）

分阶段更新策略通过组织群集到具有可配置进度规则的顺序阶段，对资源推出进行精细控制。与滚动更新策略不同，分阶段更新是使用单独的自定义资源在外部定义的，这些资源共同协调部署。

重要

Azure Kubernetes 舰队管理器预览功能可以通过自助服务方式选择性启用。预览版按“现状”和“视供应情况”提供，它们不包括在服务级别协议和有限保证范围内。客户支持部门会尽力为 Azure Kubernetes 舰队管理器预览功能提供部分支持。因此，这些功能并不适合用于生产。

分阶段更新的工作原理

分阶段更新使用三个自定义资源：

ClusterResourcePlacement - 配置为 strategy.type: External 指示外部策略管理
ClusterStagedUpdateStrategy - 定义阶段、群集选择和进度规则
ClusterStagedUpdateRun - 针对特定 CRP 和资源快照执行 clusterStagedUpdateStrategy

具有外部策略的 ClusterResourcePlacement

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: my-app-placement
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
  policy:
    placementType: PickAll
  strategy:
    type: External  # Rollout is controlled by ClusterStagedUpdateRun, ClusterStagedUpdateStrategy.

ClusterStagedUpdateStrategy

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterStagedUpdateStrategy
metadata:
  name: three-stage-strategy
spec:
  stages:
    - name: staging
      labelSelector:
        matchLabels:
          environment: staging
      afterStageTasks:
        - type: TimedWait
          waitTime: 1h
    - name: canary
      labelSelector:
        matchLabels:
          environment: canary
      sortingLabelKey: name
      afterStageTasks:
        - type: Approval
    - name: production
      labelSelector:
        matchLabels:
          environment: production
      sortingLabelKey: order

策略中的每个阶段都可以指定：

用于确定哪些群集属于阶段的标签选择器
使用（可选 - 如果未指定，按名称按字母顺序对群集进行排序）sortingLabelKey
阶段后任务（按 时间等待或审批要求）（可选，每个阶段最多 2 个任务，每种类型最多一个）

ClusterStagedUpdateRun

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterStagedUpdateRun
metadata:
  name: my-app-rollout
spec:
  placementName: my-app-placement # ClusterResourcePlacement name the update run is applied to.
  resourceSnapshotIndex: "0" # Resource snapshot index of the selected resources to be updated across clusters.
  stagedRolloutStrategyName: three-stage-strategy # The name of the update strategy to use.

阶段进度

机群管理器按顺序处理阶段：

阶段中的所有群集都根据其排序顺序接收更新
成功更新阶段中的所有群集后，执行任何已配置的后阶段任务
下一阶段仅在上一阶段任务完成后才开始

对于基于审批的进展，Fleet Manager 会创建一个资源，该资源必须经过批准，然后才能继续下一 ClusterApprovalRequest 阶段。

示例部署模式

下图演示了典型的三阶段部署模式：

此模式允许你：

首先部署到过渡群集进行初始验证
等待指定时间，然后继续访问 Canary 群集
在部署到生产环境之前需要手动批准
控制 Canary 和生产阶段内的更新顺序

何时使用暂存更新

需要时，分阶段更新策略是理想的选择：

基于环境的推出 （开发→过渡→生产）
阶段之间的验证延迟和审批入口
阶段内群集更新的确定性顺序
跨多个群集资源放置的可重用部署模式

对于基于百分比的推出足够简单的方案，请考虑改用内联滚动更新策略。

小窍门

若要了解如何分步实现分阶段更新运行，请参阅如何使用 ClusterStagedUpdateRun 协调分阶段推出。

通过