Share via

将 Kubernetes 资源从中心群集传播到成员群集（预览版）

  • 项目

本文介绍使用 Azure Kubernetes 舰队管理器（舰队）将 Kubernetes 资源从中心群集传播到成员群集的概念。

平台管理员通常需要将 Kubernetes 资源部署到多个群集，这出于多种原因，例如：

  • 使用跨多个群集的角色和角色绑定来管理访问控制。
  • 运行需要位于所有群集上的基础结构应用程序，例如 Prometheus 或 Flux。

应用程序开发人员通常需要将 Kubernetes 资源部署到多个群集，这出于各种原因，例如：

  • 将视频服务应用程序部署到不同区域的多个群集，以获得低延迟观看体验。
  • 将购物车应用程序部署到两个配对区域，以便客户能够在单个区域中断期间继续购物。
  • 将批处理计算应用程序部署到具有廉价现成节点池的群集。

跨多个群集手动创建、更新和跟踪这些 Kubernetes 资源非常繁琐。 舰队提供 Kubernetes 资源传播，以大规模管理 Kubernetes 资源。 使用舰队，你可以在中心群集中创建 Kubernetes 资源，并通过 Kubernetes 客户资源将其传播到所选成员群集：MemberCluster 和 ClusterResourcePlacement。 Fleet 基于开源云原生多群集解决方案为这些自定义资源提供支持。 有关详细信息，请参阅上游舰队文档。

重要

Azure Kubernetes 舰队管理器预览功能是可选择启用的自助功能。 预览功能是“按现状”和“按可用”提供的，不包括在服务级别协议和有限保证中。 客户支持部门会尽力为 Azure Kubernetes 舰队管理器预览功能提供部分支持。 因此，这些功能并不适合用于生产。

资源传播工作流

显示 Kubernetes 资源如何传播到成员群集的示意图。

什么是 MemberCluster？

在将群集加入舰队后，会在中心群集上创建相应的 MemberCluster 自定义资源。 可以使用此自定义资源来选择资源传播中的目标群集。

以下标签可以用于资源传播中的目标群集选择，会自动添加到所有成员群集：

  • fleet.azure.com/location
  • fleet.azure.com/resource-group
  • fleet.azure.com/subscription-id

有关详细信息，请参阅 MemberCluster API 参考。

什么是 ClusterResourcePlacement？

ClusterResourcePlacement 对象用于告知舰队日程安排如何将给定的群集范围对象从中心群集放置到成员群集中。 选择命名空间范围的对象（如 Deployment、StatefulSets、DaemonSets、ConfigMaps、Secrets 和 PersistentVolumeClaims）包含的命名空间时，包含这些对象。

通过 ClusterResourcePlacement，您可以：

  • 选择要传播到成员群集的群集范围的 Kubernetes 资源。
  • 指定放置策略，以便手动或自动选择部分或所有成员群集作为目标群集。
  • 指定推出策略，以便安全地将所选 Kubernetes 资源的任何更新推出到多个目标群集。
  • 查看向每个目标群集的传播进度。

ClusterResourcePlacement 对象支持使用 ConfigMap 来封装对象，这样有助于传播到成员群集，不产生任何意外的副作用。 选择方法包括：

  • 组、版本和种类：选择并放置给定类型的所有资源。
  • 组、版本、种类和名称：选择并放置给定类型的一个特定资源。
  • 组、版本、种类和标签：选择并放置与提供的标签匹配的给定类型的所有资源。

有关详细信息，请参阅 ClusterResourcePlacement API 参考。

选择资源后，可以使用多种放置策略：

  • PickAll 将资源放入所有可用成员群集中。 此策略可用于放置基础结构工作负荷，例如群集监视或报告应用程序。
  • PickFixed 按名称将资源放入成员群集的特定列表中。
  • PickN 是最灵活的放置选项，允许根据相关性或拓扑分布约束选择群集，并且在将工作负荷分散到多个适当的群集以确保可用性时非常有用。

PickAll 放置策略

可以使用 PickAll 放置策略在舰队中的所有成员群集上部署工作负荷（可选匹配一组条件）。

以下示例展示了如何在标有 environment: production 的所有群集中部署 test-deployment 命名空间及其所有对象：

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp-1
spec:
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                        environment: production
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1

此简单策略采用 test-deployment 命名空间及其中包含的所有资源，并将其部署到具有给定 environment 标签的舰队中的所有成员群集。 如果需要所有群集，可以完全移除 affinity 术语。

PickFixed 放置策略

若要将工作负荷部署到一组已知的成员群集中，可以使用 PickFixed 放置策略按名称选择群集。

以下示例显示如何将 test-deployment 命名空间部署到成员群集 cluster1 和 cluster2 中：

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp-2
spec:
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: test-deployment
      version: v1

PickN 放置策略

PickN 放置策略是最灵活的选项，允许根据相关性和拓扑分布约束将资源放置在可配置数量的群集中。

具有相关性的 PickN

将相关性与 PickN 放置策略函数一起使用与将相关性与 Pod 日程安排一起使用类似。 可以同时设置必需和首选相关性。 必需相关性可防止放置到与这些指定的相关性不匹配的群集；首选相关性允许在做出放置决策时对有效群集集进行排序。

以下示例展示了如何将工作负荷部署到三个群集中。 只有具有 critical-allowed: "true" 标签的群集是有效的放置目标，优先选择具有标签 critical-level: 1 的群集：

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickN
    numberOfClusters: 3
    affinity:
        clusterAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
              weight: 20
              preference:
              - labelSelector:
                  matchLabels:
                    critical-level: 1
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                      critical-allowed: "true"

具有拓扑分布约束的 PickN

可以使用拓扑分布约束来强制跨拓扑边界划分群集放置，以满足可用性要求，例如跨区域或更新通道拆分放置。 还可以配置拓扑分布约束，以在无法满足约束时阻止安排 (whenUnsatisfiable: DoNotSchedule) 或尽可能进行安排 (whenUnsatisfiable: ScheduleAnyway)。

以下示例演示如何将给定的资源集分散到多个区域，并尝试在不同的更新日跨成员群集进行日程安排：

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickN
    topologySpreadConstraints:
    - maxSkew: 2
      topologyKey: region
      whenUnsatisfiable: DoNotSchedule
    - maxSkew: 2
      topologyKey: updateDay
      whenUnsatisfiable: ScheduleAnyway

有关详细信息，请参阅上游拓扑分布约束舰队文档。

更新策略

舰队使用滚动更新策略来控制如何在多个群集放置上推出更新。

以下示例显示如何使用默认设置配置滚动更新策略：

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    ...
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

计划程序按顺序将更新推出到每个群集，至少在群集之间等待 unavailablePeriodSeconds。 如果所有资源都已正确应用于群集，则推出状态被视为成功。 推出状态检查不会级联到子资源，例如，它不会确认部署创建的 Pod 是否已准备就绪。

有关详细信息，请参阅上游推出策略舰队文档。

放置状态

舰队计划程序将有关放置决策的详细信息和状态更新到 ClusterResourcePlacement 对象。 可以使用 kubectl describe crp <name> 命令查看此信息。 输出包括以下信息：

  • 当前适用于放置的条件，包括是否已成功完成放置。
  • 每个成员群集的放置状态部分，其中显示了部署到该群集的状态。

以下示例显示了一个 ClusterResourcePlacement，它使用 PickN 将 test 命名空间及 test-1 ConfigMap 部署到两个成员群集中。 放置已成功完成，资源已放入 aks-member-1 和 aks-member-2 群集中。

Name:         crp-1
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  placement.kubernetes-fleet.io/v1beta1
Kind:         ClusterResourcePlacement
Metadata:
  ...
Spec:
  Policy:
    Number Of Clusters:  2
    Placement Type:      PickN
  Resource Selectors:
    Group:
    Kind:                  Namespace
    Name:                  test
    Version:               v1
  Revision History Limit:  10
Status:
  Conditions:
    Last Transition Time:  2023-11-10T08:14:52Z
    Message:               found all the clusters needed as specified by the scheduling policy
    Observed Generation:   5
    Reason:                SchedulingPolicyFulfilled
    Status:                True
    Type:                  ClusterResourcePlacementScheduled
    Last Transition Time:  2023-11-10T08:23:43Z
    Message:               All 2 cluster(s) are synchronized to the latest resources on the hub cluster
    Observed Generation:   5
    Reason:                SynchronizeSucceeded
    Status:                True
    Type:                  ClusterResourcePlacementSynchronized
    Last Transition Time:  2023-11-10T08:23:43Z
    Message:               Successfully applied resources to 2 member clusters
    Observed Generation:   5
    Reason:                ApplySucceeded
    Status:                True
    Type:                  ClusterResourcePlacementApplied
  Placement Statuses:
    Cluster Name:  aks-member-1
    Conditions:
      Last Transition Time:  2023-11-10T08:14:52Z
      Message:               Successfully scheduled resources for placement in aks-member-1 (affinity score: 0, topology spread score: 0): picked by scheduling policy
      Observed Generation:   5
      Reason:                ScheduleSucceeded
      Status:                True
      Type:                  ResourceScheduled
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully Synchronized work(s) for placement
      Observed Generation:   5
      Reason:                WorkSynchronizeSucceeded
      Status:                True
      Type:                  WorkSynchronized
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully applied resources
      Observed Generation:   5
      Reason:                ApplySucceeded
      Status:                True
      Type:                  ResourceApplied
    Cluster Name:            aks-member-2
    Conditions:
      Last Transition Time:  2023-11-10T08:14:52Z
      Message:               Successfully scheduled resources for placement in aks-member-2 (affinity score: 0, topology spread score: 0): picked by scheduling policy
      Observed Generation:   5
      Reason:                ScheduleSucceeded
      Status:                True
      Type:                  ResourceScheduled
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully Synchronized work(s) for placement
      Observed Generation:   5
      Reason:                WorkSynchronizeSucceeded
      Status:                True
      Type:                  WorkSynchronized
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully applied resources
      Observed Generation:   5
      Reason:                ApplySucceeded
      Status:                True
      Type:                  ResourceApplied
  Selected Resources:
    Kind:       Namespace
    Name:       test
    Version:    v1
    Kind:       ConfigMap
    Name:       test-1
    Namespace:  test
    Version:    v1
Events:
  Type    Reason                     Age                    From                                   Message
  ----    ------                     ----                   ----                                   -------
  Normal  PlacementScheduleSuccess   12m (x5 over 3d22h)    cluster-resource-placement-controller  Successfully scheduled the placement
  Normal  PlacementSyncSuccess       3m28s (x7 over 3d22h)  cluster-resource-placement-controller  Successfully synchronized the placement
  Normal  PlacementRolloutCompleted  3m28s (x7 over 3d22h)  cluster-resource-placement-controller  Resources have been applied to the selected clusters

放置更改

舰队计划程序优先考虑现有工作负荷放置的稳定性。 此优先性可以限制导致工作负荷被删除和重新安排的更改数量。 以下场景可能会触发放置更改：

  • ClusterResourcePlacement 对象中的放置策略更改可能会触发工作负荷的删除和重新安排。
    • 横向扩展操作（增加 numberOfClusters 且无其他更改）只会在新群集上放置工作负荷，不会影响现有放置。
  • 群集更改，包括：
    • 如果新群集满足放置策略（例如 PickAll 策略），则新群集可能触发放置。
    • 从舰队中移除放置的群集将尝试重新放置所有受影响的工作负荷，而不会影响其他放置。

仅资源更改（更新 ClusterResourcePlacement 对象中的资源或更新 ResourceSelector）会在现有放置中逐步推出，但不触发工作负荷重新安排。

访问舰队资源群集的 Kubernetes API

如果在创建 Azure Kubernetes 舰队管理器资源时启用了中心群集，则可将其用于集中控制 Kubernetes 对象传播等方案。 若要访问舰队资源群集的 Kubernetes API，请按照使用 Azure Kubernetes 舰队管理器访问舰队资源群集的 Kubernetes API 中的步骤进行操作。

后续步骤

设置从中心群集到成员群集的 Kubernetes 资源传播。