将 Kubernetes 资源从中心群集传播到成员群集
本文介绍使用 Azure Kubernetes 舰队管理器(舰队)将 Kubernetes 资源从中心群集传播到成员群集的概念。
平台管理员通常需要将 Kubernetes 资源部署到多个群集,这出于多种原因,例如:
- 使用跨多个群集的角色和角色绑定来管理访问控制。
- 运行需要位于所有群集上的基础结构应用程序,例如 Prometheus 或 Flux。
应用程序开发人员通常需要将 Kubernetes 资源部署到多个群集,这出于各种原因,例如:
- 将视频服务应用程序部署到不同区域的多个群集,以获得低延迟观看体验。
- 将购物车应用程序部署到两个配对区域,以便客户能够在单个区域中断期间继续购物。
- 将批处理计算应用程序部署到具有廉价现成节点池的群集。
跨多个群集手动创建、更新和跟踪这些 Kubernetes 资源非常繁琐。 舰队提供 Kubernetes 资源传播,以大规模管理 Kubernetes 资源。 使用舰队,你可以在中心群集中创建 Kubernetes 资源,并通过 Kubernetes 客户资源将其传播到所选成员群集:MemberCluster
和 ClusterResourcePlacement
。 Fleet 基于开源云原生多群集解决方案为这些自定义资源提供支持。 有关详细信息,请参阅上游舰队文档。
重要
Azure Kubernetes 舰队管理器预览功能是可选择启用的自助功能。 预览功能是“按现状”和“按可用”提供的,不包括在服务级别协议和有限保证中。 客户支持部门会尽力为 Azure 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 参考。
创建 ClusterResourcePlacement
时,可以指定以下相关性类型:
- requiredDuringSchedulingIgnoredDuringExecution:由于这类相关性是计划期间所需的类型,因此会根据群集的属性对其进行筛选。
- preferredDuringSchedulingIgnoredDuringExecution:由于这类相关性只属于首选类型,在计划期间并非必需,因此它根据你指定的属性(如成本或资源可用性)对群集进行优先排序。
有多种放置类型可用于控制 Kubernetes 资源需要传播到的群集数量:
PickAll
将资源放入所有可用成员群集中。 此策略可用于放置基础结构工作负荷,例如群集监视或报告应用程序。PickFixed
按名称将资源放入成员群集的特定列表中。PickN
是最灵活的放置选项,允许根据相关性或拓扑分布约束选择群集,并且在将工作负荷分散到多个适当的群集以确保可用性时非常有用。
PickAll
放置策略
可以使用 PickAll
放置策略在舰队中的所有成员群集上部署工作负荷(可选匹配一组条件)。
以下示例展示了如何在标有 environment: production
的所有群集中部署 prod-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
此简单策略采用 prod-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
)会在现有放置中逐步推出,但不触发工作负荷重新安排。
容忍
ClusterResourcePlacement
对象支持适用于 ClusterResourcePlacement
对象的容忍规范。 每个容忍对象包含以下字段:
key
:容忍的键。value
:容忍的值。effect
:容忍的影响,如NoSchedule
。operator
:容忍的运算符,如Exists
或Equal
。
每个容忍用于容忍应用于 ClusterResourcePlacement
的一个或多个特定的污点。 容忍对 MemberCluster
的所有污点后,计划程序便可将资源传播到群集。 创建 ClusterResourcePlacement
对象后,就不能更新或删除其中的容忍。
有关详细信息,请参阅上游舰队文档。
访问舰队资源群集的 Kubernetes API
如果在创建 Azure Kubernetes 舰队管理器资源时启用了中心群集,则可将其用于集中控制 Kubernetes 对象传播等方案。 若要访问舰队资源群集的 Kubernetes API,请按照使用 Azure Kubernetes 舰队管理器访问舰队资源群集的 Kubernetes API 中的步骤进行操作。