你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

使用 ResourcePlacement 部署命名空间范围内的资源（预览版）

本文介绍 ResourcePlacement API，该 API 使用 Azure Kubernetes 机群管理器跨成员群集对命名空间范围的 Kubernetes 资源进行精细控制。

重要

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

概述

ResourcePlacement 是一个命名空间范围的 API，能够动态选择和多集群传播命名空间范围的资源。它提供对命名空间中特定资源在队列中跨成员群集分布方式的精细控制。

重要

ResourcePlacement 使用 placement.kubernetes-fleet.io/v1beta1 API 版本，目前以预览版提供。本文中演示的某些功能（例如 selectionScope in ClusterResourcePlacement）也是 v1beta1 API 的一部分，在 v1 API 中不可用。

主要特征：

命名空间范围：对象 ResourcePlacement 及其管理的资源都存在于同一命名空间中。
选择性：可以按类型、名称或标签而不是整个命名空间以特定资源为目标。
声明性：使用与ClusterResourcePlacement相同的放置模式以确保一致的行为。

由 ResourcePlacement 三个核心组件组成：

资源选择器：定义要包含的命名空间范围资源。
放置策略：使用PickAll、PickFixed或PickN策略确定目标群集。
推出策略：控制更改在所选群集之间传播的方式。

何时使用 ResourcePlacement

ResourcePlacement 非常适合需要对命名空间范围资源进行精细控制的方案：

选择性资源分发：部署特定的 ConfigMap、机密或服务，而不会影响整个命名空间。
多租户环境：允许不同的团队在共享命名空间中独立管理其资源。
配置管理：在不同的群集环境间分发环境特定的配置。
符合性和治理：将不同的策略应用于同一命名空间中的不同资源类型。
渐进式推出：使用零停机时间策略在群集之间安全部署资源更新。

在多群集环境中，工作负荷通常由需要分布在不同群集中的群集范围和命名空间范围的资源组成。虽然 ClusterResourcePlacement （CRP）可以有效地处理群集范围的资源、整个命名空间及其内容，但在某些情况下，你需要对现有命名空间中的命名空间范围资源进行更精细的控制。

ResourcePlacement （RP）旨在通过提供来解决这一差距：

命名空间范围内的资源管理：面向命名空间中的特定资源，而不会影响整个命名空间。
作灵活性：允许团队单独管理同一命名空间中的不同资源。
互补功能：与 CRP 一起提供完整的多群集资源管理解决方案。

注释

ResourcePlacement 可以与 ClusterResourcePlacement 在仅命名空间模式下一起使用。例如，可以使用 CRP 部署命名空间，同时使用 RP 对特定资源（例如特定于环境的 ConfigMaps 或机密）进行精细管理。

实际命名空间使用模式

虽然 CRP 假定命名空间表示应用程序边界，但实际使用模式通常更为复杂。组织经常使用命名空间作为团队边界，而不是应用程序边界，这导致了几个挑战，ResourcePlacement 直接应对这些挑战：

多应用程序命名空间：在许多组织中，单个命名空间包含同一团队拥有的多个独立应用程序。这些应用程序可能具有：

不同的生命周期要求（一个应用程序可能需要频繁更新，而另一个应用程序仍保持稳定）。
不同的群集放置需求（开发应用程序与生产应用程序）。
独立的扩展和资源需求。
单独的合规性或治理要求。

单个计划决策：许多工作负荷（尤其是 AI/ML 作业）需要单独的计划决策：

AI 作业：机器学习工作负载通常由需要根据群集资源可用性、GPU 可用性或数据区域安排的短期资源密集型作业组成。
批处理工作负荷：同一命名空间中的不同批处理作业可能会根据计算要求针对不同的群集类型。

完整的应用程序团队控制： ResourcePlacement 为应用程序团队提供对资源放置的直接控制，而无需平台团队干预：

自助操作：团队可以管理自己的资源分发策略。
独立部署周期：命名空间中的不同应用程序可以有独立的推出计划。
精细覆盖功能：团队可以自定义每个群集的资源配置，而不会影响命名空间中的其他应用。

这种精细方法可确保能够 ResourcePlacement 适应各种组织结构和工作负荷模式，同时保持车队计划框架的简单性和强大性。

ResourcePlacement 与 ClusterResourcePlacement 之间的主要区别

下表突出显示了ResourcePlacement和ClusterResourcePlacement之间的主要区别。

方面	ResourcePlacement （RP）	ClusterResourcePlacement （CRP）
Scope	仅限命名空间范围内的资源	群集范围的资源（尤其是命名空间及其内容）
资源	命名空间范围的 API 对象	集群范围内的 API 对象
选择边界	限制为与 RP 位于同一命名空间中的资源	可以选择任何集群范围资源
典型用例	AI/ML 作业、单个工作负载、需要独立做出放置决定的特定 ConfigMaps/Secrets	应用程序捆绑包、整个命名空间、群集范围的策略
团队所有权	可由命名空间所有者/开发人员管理	通常由平台操作员管理

对于差异表中未列出的所有其他方面，ResourcePlacement和ClusterResourcePlacement共享相同的核心功能。

与 ClusterResourcePlacement 一起工作

ResourcePlacement 旨在配合 ClusterResourcePlacement （CRP）提供完整的多群集资源管理解决方案。了解这种关系对于有效的车队管理至关重要。

命名空间先决条件

重要

ResourcePlacement 只能将命名空间范围的资源放置到已经包含目标命名空间的群集。建议使用 ClusterResourcePlacement 来建立命名空间。

典型工作流：

平台管理员：使用 ClusterResourcePlacement 在整个集群中部署命名空间。
应用程序团队：用于 ResourcePlacement 管理这些已建立的命名空间中的特定资源。

以下示例演示如何协调 CRP 和 RP：

注释

以下示例使用 placement.kubernetes-fleet.io/v1beta1 API 版本。该 selectionScope: NamespaceOnly 字段是 v1beta1 中提供的预览功能，在 v1 API 中不可用。

平台管理员：首先，使用 ClusterResourcePlacement：

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: app-namespace-crp
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
      selectionScope: NamespaceOnly # only namespace itself is placed, no resources within the namespace
  policy:
    placementType: PickAll # If placement type is not PickAll, the application teams needs to know what are the clusters they can place their applications.

应用程序团队：然后，使用 ResourcePlacement以下命令管理命名空间中的特定资源：

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ResourcePlacement
metadata:
  name: app-configs-rp
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2

最佳做法

使用ResourcePlacementClusterResourcePlacement时，请遵循以下最佳做法：

首先建立命名空间：始终确保在创建 ResourcePlacement 对象之前通过 CRP 部署命名空间。
监控依赖项：使用 Fleet 监控来确保命名空间级 CRP 在部署依赖 RP 之前正常运行。
协调策略：对齐 CRP 和 RP 放置策略以避免冲突（例如，如果 CRP 将命名空间置于群集 A、B、C、RP 可以针对这些群集的任何子集）。
团队边界：对于平台托管资源（如命名空间、RBAC），使用 CRP；对于应用程序托管资源（如应用配置、机密），使用 RP。

这种协调的方法可确保在 ResourcePlacement 维护平台操作员管理的基础基础结构的同时，提供团队所需的灵活性。

资源选择、放置和推出

ResourcePlacement 使用与 ClusterResourcePlacement 相同的放置模式。

放置类型，PickAll、PickFixed和PickN策略对两个 API 的工作方式相同。
推出策略：控制使用相同滚动更新机制在群集之间传播更新的方式。
状态和可观测性：使用 kubectl describe resourceplacement <name> -n <namespace>监视部署进度。
高级功能：使用容忍、资源替代、拓扑分散约束和关联规则。

主要区别在于 资源选择 范围。虽然 ClusterResourcePlacement 通常选择整个命名空间及其内容，但 ResourcePlacement 提供对单个命名空间范围资源的精细控制。

有关这些功能的完整详细信息，请参阅 ClusterResourcePlacement 文档。

后续步骤

反馈

此页面是否有帮助？

Last updated on 2025-11-19