ResourcePlacement を使用して名前空間スコープのリソースをデプロイする (プレビュー)

この記事では、 ResourcePlacement API について説明します。これにより、Azure Kubernetes Fleet Manager を使用して、メンバー クラスター間で名前空間スコープの Kubernetes リソースをきめ細かく制御できます。

概要

ResourcePlacement は、名前空間スコープのリソースの動的な選択とマルチクラスターの伝達を可能にする名前空間スコープの API です。 名前空間内の特定のリソースをフリート内のメンバー クラスター間で分散する方法をきめ細かく制御できます。

主な特性:

• 名前空間スコープ: ResourcePlacement オブジェクトとそれが管理するリソースの両方が同じ名前空間内に存在します。
• 選択的: 名前空間全体ではなく、種類、名前、またはラベルによって特定のリソースをターゲットにすることができます。
• 宣言型: 一貫した動作のために、 ClusterResourcePlacement と同じ配置パターンを使用します。

ResourcePlacementは、次の 3 つのコア コンポーネントで構成されます。

• リソース セレクター: 含める名前空間スコープのリソースを定義します。
• 配置ポリシー: PickAll、 PickFixed、または PickN 戦略を使用してターゲット クラスターを決定します。
• ロールアウト戦略: 選択したクラスター間で変更がどのように反映されるかを制御します。

ResourcePlacement を使用するタイミング

ResourcePlacement は、名前空間スコープのリソースをきめ細かく制御する必要があるシナリオに最適です。

• 選択的なリソース分散: 名前空間全体に影響を与えずに、特定の ConfigMap、シークレット、またはサービスをデプロイします。
• マルチテナント環境: 異なるチームが共有名前空間内で個別にリソースを管理できるようにします。
• 構成管理: 環境固有の構成を異なるクラスター環境に分散します。
• コンプライアンスとガバナンス: 同じ名前空間内のさまざまなリソースの種類に異なるポリシーを適用します。
• 段階的なロールアウト: ダウンタイムなしの戦略を使用して、クラスター間でリソースの更新プログラムを安全にデプロイします。

マルチクラスター環境では、ワークロードは多くの場合、異なるクラスター間で分散する必要があるクラスター スコープのリソースと名前空間スコープのリソースの両方で構成されます。 ClusterResourcePlacement (CRP) は、クラスター スコープのリソース、名前空間全体、およびその内容を効果的に処理しますが、既存の名前空間内の名前空間スコープのリソースをより細かく制御する必要があるシナリオがあります。

ResourcePlacement (RP) は、次の機能を提供することで、このギャップに対処するように設計されました。

• 名前空間スコープのリソース管理: 名前空間全体に影響を与えずに、名前空間内の特定のリソースを対象とします。
• 運用の柔軟性: チームが同じ名前空間内のさまざまなリソースを個別に管理できるようにします。
• 補完的な機能: CRP と連携して、完全なマルチクラスター リソース管理ソリューションを提供します。

実際の名前空間の使用パターン

CRP では名前空間がアプリケーションの境界を表していると想定されていますが、実際の使用パターンは多くの場合、より複雑です。 組織では名前空間をアプリケーションの境界ではなくチームの境界として頻繁に使用することがあり、それにより発生するいくつかの課題をResourcePlacementで直接解決します。

マルチアプリケーション名前空間: 多くの組織では、1 つの名前空間に、同じチームが所有する複数の独立したアプリケーションが含まれています。 これらのアプリケーションには、次の内容が含まれます。

• ライフサイクル要件が異なります (あるアプリケーションでは頻繁な更新が必要な場合もあれば、別のアプリケーションが安定している場合もあります)。
• さまざまなクラスター配置のニーズ (開発アプリケーションと運用アプリケーション)。
• 独立したスケーリングとリソースの要件。
• コンプライアンスまたはガバナンスの要件を分離します。

個々のスケジュール決定: 多くのワークロード (特に AI/ML ジョブ) には、個々のスケジュール決定が必要です。

• AI ジョブ: 機械学習ワークロードは、多くの場合、クラスター リソースの可用性、GPU の可用性、またはデータの局所性に基づいてスケジュールする必要がある、短期間のリソース集中型ジョブで構成されます。
• バッチ ワークロード: 同じ名前空間内のバッチ ジョブが異なると、コンピューティング要件に基づいて異なるクラスターの種類が対象になる場合があります。

アプリケーション チームの完全な制御: ResourcePlacement は、プラットフォーム チームの介入を必要とせずに、アプリケーション チームにリソースの配置を直接制御できるようにします。

• セルフサービス運用: Teams は、独自のリソース分散戦略を管理できます。
• 独立したデプロイ サイクル: 名前空間内のさまざまなアプリケーションに、独立したロールアウト スケジュールを設定できます。
• きめ細かいオーバーライド機能: Teams では、名前空間内の他のアプリケーションに影響を与えることなく、クラスターごとのリソース構成をカスタマイズできます。

この細かいアプローチにより、 ResourcePlacement は、フリートスケジューリングフレームワークのシンプルさとパワーを維持しながら、多様な組織構造とワークロードパターンに適応することができます。

ResourcePlacement と ClusterResourcePlacement の主な違い

次の表では、 ResourcePlacement と ClusterResourcePlacementの主な違いを示します。

ResourcePlacementとClusterResourcePlacementの両方で、相違点の表に記載されていない他のすべての側面に対して同じコア機能が共有されます。

ClusterResourcePlacement の使用

ResourcePlacement は、完全なマルチクラスター リソース管理ソリューションを提供するために、 ClusterResourcePlacement (CRP) と連携するように設計されています。 この関係を理解することは、効果的なフリート管理に不可欠です。

名前空間の前提条件

一般的なワークフロー:

1. プラットフォーム管理者: ClusterResourcePlacement を使用して、フリート全体に名前空間を展開します。
2. Application Teams: ResourcePlacement を使用して、確立された名前空間内の特定のリソースを管理します。

次の例は、CRP と RP を調整する方法を示しています。

プラットフォーム管理者: まず、 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

ベスト プラクティス

ResourcePlacementでClusterResourcePlacementを使用する場合は、次のベスト プラクティスに従ってください。

• 最初に名前空間を確立する: ResourcePlacement オブジェクトを作成する前に、必ず CRP 経由で名前空間がデプロイされるようにします。
• 依存関係の監視: 依存 RP をデプロイする前に、Fleet 監視を使用して名前空間レベルの CRP が正常であることを確認します。
• ポリシーを調整する: 競合を回避するために 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 のドキュメントを参照してください。

次のステップ

• ResourcePlacement を使用して名前空間スコープのリソースを複数のクラスターにデプロイする
• ClusterResourcePlacement を使用してクラスター スコープのリソースをデプロイする
• クラスタ リソース プレースメントを用いた複数クラスタ リソース プレースメント
• オーバーライドを使用して名前空間スコープのリソースをカスタマイズする
• リソース配置のロールアウト戦略の定義
• クラスター リソースの配置に関する FAQ