"✔️ハブ クラスターを使用した Fleet Manager に適用されます"
複数のクラスター間で Kubernetes リソースを管理することは、プラットフォーム管理者とアプリケーション開発者の両方にとって大きな課題となります。 組織が 1 つのクラスターを超えて Kubernetes インフラストラクチャをスケーリングする場合、多くの場合、リソースの分散、一貫性、および手動管理のオーバーヘッドに関連する複雑さが発生します。 各クラスターを個別に管理する従来のアプローチでは、運用サイロが作成され、フリートのサイズが大きくなるにつれて保守がますます困難になります。
プラットフォーム管理者は、多くの場合、次のようなさまざまな理由で、Kubernetes リソースを複数のクラスターにデプロイする必要があります。
- 複数のクラスター間でロールとロール バインドを使用してアクセス制御を管理する。
- すべてのクラスター上に必要な、Prometheus や Flux などのインフラストラクチャ アプリケーションを実行する。
アプリケーション開発者は、多くの場合、次のようなさまざまな理由で、Kubernetes リソースを複数のクラスターにデプロイする必要があります。
- 低待機時間の視聴エクスペリエンスを実現するために、ビデオ サービス アプリケーションを異なるリージョンの複数のクラスターにデプロイする。
- ショッピング カート アプリケーションを 2 つのペアのリージョンにデプロイすることで、顧客は 1 つのリージョンの停止中に買い物を続けることができます。
- 安価なスポット ノード プールを使用できるクラスターにバッチ コンピューティング アプリケーションをデプロイする。
複数のクラスター間で Kubernetes リソースを手動で作成、更新、追跡するのは面倒で、エラーが発生しやすい可能性があります。
この記事では、Fleet Manager のインテリジェント リソース配置機能を使用して、フリート内のメンバー クラスター間でのクラスターおよび名前空間スコープ Kubernetes リソースの分散を管理する方法について説明します。
Fleet Manager のリソース配置機能は、 KubeFleet CNCF プロジェクトに基づいています。
リソース配置プロセスの概要
Fleet Manager のインテリジェントなリソース配置を使用するには、次の手順に従います。
- ハブ クラスターでリソースをステージングする: 継続的配置、GitOps、または同様の方法を使用して、Fleet Manager ハブ クラスター上のリソース配布のマニフェストを適用します。
- リソース配置の作成: リソースを選択し、リソースを受け取るメンバー クラスターを選択するためのポリシーを定義する配置マニフェストを作成します。
- ハブ クラスターにリソース配置を適用する: 配置マニフェストをハブ クラスターに適用して、リソースの配布を開始します。
- Fleet Manager はリソースをスケジュールします。Fleet Manager は、リソースの配置と選択したスコープを監視し、リソースの分散を実行します。
- リソース配置を使用して分散を観察する: ハブ クラスター上のリソースの配置にクエリを実行して、ロールアウト時にリソースの状態を確認します。
Fleet Manager には、ロールアウトをより視覚的に表現できるリソース配置用のAzure ポータル エクスペリエンスがあります。
クラスター スコープのリソース配置の概要
ClusterResourcePlacement (CRP) を使用して、クラスター スコープのリソースの特定のセットまたは名前空間全体を Fleet Manager ハブ クラスターから 1 つ以上のメンバー クラスターに配布します。
主な特性:
- クラスター スコープ: クラスター スコープのリソースまたは名前空間を選択します。
-
宣言型: 一貫した動作のために、
ResourcePlacementと同じ配置ポリシーを使用します。
CRP を使用すると、次のことができます。
- 配布する Kubernetes リソースを選択します。 これらのリソースには、 Kubernetes Group Version Kind (GVK) 参照を使用して定義されたクラスター スコープの Kubernetes リソースや、名前空間とそのすべてのリソースを分散する名前空間を指定できます。
- メンバー クラスターを選択する配置ポリシーを指定します。 これらのポリシーでは、名前によってクラスターを明示的に選択したり、クラスターのラベルとプロパティに基づいてクラスターを動的に選択したりできます。
- 選択した Kubernetes リソースの更新プログラムを複数のターゲット クラスターに安全にロールアウトするためのロールアウト戦略を指定する。
- 各ターゲット クラスターのロールアウトの進行状況を表示します。
名前空間内の名前空間スコープの個々のリソースをきめ細かく制御する必要があるシナリオについては、名前空間 スコープのリソース配置を参照してください。これにより、名前空間全体ではなく特定のリソースを分散できます。
名前空間スコープのリソース配置の概要
ResourcePlacement (RP) を使用して、Fleet Manager ハブ クラスターから 1 つ以上のメンバー クラスターに特定の名前空間内の特定のリソース セットを配布します。 ResourcePlacement では、名前空間内の特定のリソースをメンバー クラスター間で分散する方法をきめ細かく制御できます。
主な特性:
-
名前空間スコープ:
ResourcePlacementと選択したリソースの両方が同じ名前空間内に存在します。 - 選択的: 名前空間全体ではなく、種類、名前、またはラベルによって名前空間内の特定のリソースを選択します。
-
宣言型: 一貫した動作のために、
ClusterResourcePlacementと同じ配置ポリシーを使用します。
ResourcePlacement を使用するタイミング
ResourcePlacement は、名前空間スコープのリソースをきめ細かく制御する必要があるシナリオに最適です。
- 選択的なリソース分散: 名前空間全体に影響を与えずに、特定の ConfigMap、シークレット、またはサービスをデプロイします。
- マルチテナント環境: 異なるチームが共有名前空間内で個別にリソースを管理できるようにします。
- 構成管理: 環境固有の構成を異なるクラスター環境に分散します。
- コンプライアンスとガバナンス: 同じ名前空間内のさまざまなリソースの種類に異なるポリシーを適用します。
- 段階的なロールアウト: ダウンタイムなしの戦略を使用して、クラスター間でリソース更新プログラムを安全にデプロイします。
多くの場合、マルチクラスター環境では、ワークロードはクラスター スコープと名前空間スコープの両方のリソースで構成され、さまざまなクラスターに分散する必要があります。
ClusterResourcePlacement (CRP) はクラスター スコープのリソースを効果的に処理しますが、名前空間全体とその内容も管理します。 ただし、一部のシナリオでは、既存の名前空間内の名前空間スコープのリソースをより細かく制御する必要があります。
ResourcePlacement (RP) は、次の機能を提供することで、このギャップに対処します。
- 名前空間スコープのリソース管理: 名前空間全体に影響を与えずに、名前空間内の特定のリソースを対象とします。
- 運用の柔軟性: チームが同じ名前空間内のさまざまなリソースを個別に管理できるようにします。
- 補完的な機能: CRP と連携して、完全なマルチクラスター リソース管理ソリューションを提供します。
注
ResourcePlacementは、名前空間のみのモードでClusterResourcePlacementと共に使用できます。 たとえば、CRP を使用して名前空間をデプロイし、RP を使用して、環境固有の ConfigMap や、その名前空間内のシークレットなどの特定のリソースをきめ細かく管理します。
リソース配置コンポーネント
スコープ (クラスターまたは名前空間) に関係なく、リソースの配置は次のコンポーネントで構成されます。
-
リソース セレクター:
resourceSelectorsを使用して含めるリソースを選択します。 -
配置ポリシー:
placementType、PickAll、またはPickFixedの種類のいずれかを使用して、PickNを使用してクラスターを選択する方法を定義します。 -
ロールアウト戦略: オプションの
strategyを含めることで、選択したクラスター間でリソースをロールアウトする方法を制御します。
このサンプル ClusterResourcePlacement (CRP) は、フリート内のすべてのクラスターに名前空間 my-app を配置します。 明示的な戦略を定義しない場合、プロセスは RollingUpdateを使用します。
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: namespace-only-crp
spec:
resourceSelectors:
- group: ""
kind: Namespace
name: my-app
version: v1
policy:
placementType: PickAll
このサンプル ResourcePlacement (RP) は、名前空間app=my-applicationのmy-appラベルが付いた ConfigMap を、2 つの名前付きクラスターの一致する名前空間に配置します。 明示的な戦略を定義しない場合、プロセスは RollingUpdateを使用します。
apiVersion: placement.kubernetes-fleet.io/v1
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
リソース セレクター
プレースメント内で 1 つ以上のresourceSelectorsを使用して、リソースを選択します。 各リソース セレクターでは、次を指定できます。
- グループ、バージョン、種類 (GVK):選択する Kubernetes リソースの種類。
- 名前: 特定のリソースの名前。
- ラベル セレクター: 複数のリソースに一致するラベル。
名前空間の選択スコープ
クラスター スコープの配置を使用して名前空間全体を選択する場合は、 selectionScope フィールドを使用して、名前空間にすべての子リソースを含めるか、単に空の名前空間を配置するかを制御します。
-
既定の動作 (
selectionScopeが指定されていない場合): 名前空間とその中のすべてのリソースを分散します。 -
NamespaceOnly: 名前空間内のリソースを使用せずに、名前空間リソースのみを分散します。 このオプションは、ResourcePlacementを使用して個々のリソースを個別に管理しながら、クラスター間で名前空間を確立する場合に便利です。
この例では、名前空間のみをその内容なしで配布する方法を示します。
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: namespace-only-crp
spec:
resourceSelectors:
- group: ""
kind: Namespace
name: my-app
version: v1
selectionScope: NamespaceOnly
policy:
placementType: PickAll
このアプローチにより、プラットフォーム管理者が ClusterResourcePlacement を使用して名前空間を確立するワークフローが可能になります。一方、アプリケーション チームは ResourcePlacement を使用して、それらの名前空間内の特定のリソースをきめ細かく制御できます。
配置ポリシー
Fleet Manager リソース配置では、クラスターの選択方法を制御するための次の配置ポリシーの種類がサポートされています。
- PickFixed は、 そのクラスター名を使用してメンバー クラスターにリソースを配置します。
- PickAll は 、すべてのメンバー クラスター、または条件を満たすすべてのメンバー クラスターにリソースを配置します。 このポリシーは、クラスターの監視やレポート アプリケーションなどのインフラストラクチャ ワークロードを配置する場合に役立ちます。
- PickN は、最も柔軟な配置オプションです。 アフィニティ制約またはトポロジ分散制約に基づいてクラスターを選択できます。 複数の同様のクラスターにワークロードを分散して可用性を維持する場合は、このポリシーを使用します。
PickFixed 配置の種類
PickFixedを使用して、クラスターを名前で選択します。
clusterNames配列の名前を指定します。 空または省略された配列は、どのクラスターも選択しません。
この例では、 test-deployment 名前空間をメンバー クラスター cluster1 および cluster2に配布する方法を示します。
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp-fixed
spec:
resourceSelectors:
- group: ""
kind: Namespace
name: test-deployment
version: v1
policy:
placementType: PickFixed
clusterNames:
- cluster1
- cluster2
このサンプル ResourcePlacement (RP) は、名前空間app: my-applicationのmy-appラベルが付いた ConfigMap を、2 つの名前付きクラスターの一致する名前空間に配置します。
apiVersion: placement.kubernetes-fleet.io/v1
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
ターゲット クラスターなしで配置を作成するか、既存の配置をゼロ クラスターにスケールダウンするには、 specの下で次のポリシーを使用します。
policy:
placementType: PickFixed
clusterNames: []
既存の配置でアレイ設定をクリアすると、Fleet Manager は、その配置によって以前に配布されたリソースをメンバー クラスターから削除します。 ハブ クラスター上の配置オブジェクトと選択されたリソースは残ります。 リソースをもう一度配布するには、ターゲット クラスター名を clusterNames に追加して戻します。
PickAll 配置の種類
PickAllを使用して、すべてのメンバー クラスター、または指定した条件に一致するすべてのクラスターにリソースを分散します。
この種類の配置を作成するときは、次のクラスター アフィニティの種類を指定します。
- requiredDuringSchedulingIgnoredDuringExecution: このポリシーはスケジュール中に必須であるため、指定された条件に基づいてクラスターはフィルター処理されます。
この例では、 prod-deployment 名前空間とそのすべての子リソースを、 environment: productionでラベル付けされたすべてのメンバー クラスターに分散する方法を示します。
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp-pickall
spec:
resourceSelectors:
- group: ""
kind: Namespace
name: prod-deployment
version: v1
policy:
placementType: PickAll
affinity:
clusterAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
clusterSelectorTerms:
- labelSelector:
matchLabels:
environment: production
このサンプル ResourcePlacement (RP) は、名前空間app: my-applicationのmy-appラベルが付いた ConfigMap を、environment: productionでラベル付けされたすべてのクラスター上の一致する名前空間に配置します。
apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
name: app-configs-rp-pickall
namespace: my-app
spec:
resourceSelectors:
- group: ""
kind: ConfigMap
version: v1
labelSelector:
matchLabels:
app: my-application
policy:
placementType: PickAll
affinity:
clusterAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
clusterSelectorTerms:
- labelSelector:
matchLabels:
environment: production
PickN 配置の種類
PickNを使用して、アフィニティ制約とトポロジ分散制約の両方に基づいて構成可能な数のクラスターにリソースを分散します。
この種類の配置を作成するときは、次のクラスター アフィニティの種類を指定します。
- requiredDuringSchedulingIgnoredDuringExecution: このポリシーはスケジュール中に必須であるため、指定された条件に基づいてクラスターはフィルター処理されます。
- preferredDuringSchedulingIgnoredDuringExecution: このポリシーは優先されますが、スケジュール中に必須ではないため、指定した条件に基づいてクラスターにランク付けされます。
必須と優先の両方のアフィニティを設定できます。 必要なアフィニティにより、一致しないクラスターへの配置が禁止されます。 優先アフィニティは、一致するクラスターの順序を提供します。
アフィニティを使用した PickN
PickN配置ポリシーでアフィニティを使用することは、1 つの Kubernetes クラスターでのポッド スケジューリングでのアフィニティの使用と同様に機能します。
次の例は、3 つのクラスターにリソースをデプロイする方法を示しています。
critical-allowed: "true" ラベルを持つクラスターのみが有効な配置ターゲットであり、ラベル critical-level: 1 を持つクラスターが優先されます。
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp-pickn-critical-preferences
spec:
resourceSelectors:
- group: ""
kind: Namespace
name: prod-deployment
version: v1
policy:
placementType: PickN
numberOfClusters: 3
affinity:
clusterAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
weight: 20
preference:
- labelSelector:
matchLabels:
critical-level: 1
requiredDuringSchedulingIgnoredDuringExecution:
clusterSelectorTerms:
- labelSelector:
matchLabels:
critical-allowed: "true"
apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
name: app-configs-rp-pickn-critical-preferences
namespace: my-app
spec:
resourceSelectors:
- group: ""
kind: ConfigMap
version: v1
labelSelector:
matchLabels:
app: my-application
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: 制約を満たすことができない場合は、配置要求に失敗します。
- ScheduleAnyway: 制約が満たされない場合は、リソースを配置します。
次の例は、複数のAzure リージョンにリソースを分散し、カスタム ラベル updateDayを使用して更新日が異なるメンバー クラスター間でスケジュールを設定する方法を示しています。
Azureリージョンの拡散が満たされない場合、配置は失敗します。
updateDay制約が満たされていない場合でも、配置が行われます。
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp-pickn-locations-updates
spec:
resourceSelectors:
- group: ""
kind: Namespace
name: prod-deployment
version: v1
policy:
placementType: PickN
topologySpreadConstraints:
- maxSkew: 2
topologyKey: fleet.azure.com/location
whenUnsatisfiable: DoNotSchedule
- maxSkew: 2
topologyKey: updateDay
whenUnsatisfiable: ScheduleAnyway
apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
name: app-configs-rp-pickn-locations-updates
namespace: my-app
spec:
resourceSelectors:
- group: ""
kind: ConfigMap
version: v1
labelSelector:
matchLabels:
app: my-application
policy:
placementType: PickN
topologySpreadConstraints:
- maxSkew: 2
topologyKey: fleet.azure.com/location
whenUnsatisfiable: DoNotSchedule
- maxSkew: 2
topologyKey: updateDay
whenUnsatisfiable: ScheduleAnyway
詳細については、 トポロジの分散制約に関する KubeFleet のドキュメントを参照してください。
ラベルとプロパティを使用してクラスターを選択する
Fleet Manager インテリジェント リソース配置では、 PickN と PickAll の配置の種類を使用するときにクラスターを選択する方法を決定するときに使用できる強力な条件のセットが提供されます。 このセクションでは、これらのオプションを使用して、ニーズに合ったポリシーを構築する方法について説明します。
配置ポリシーのオプション
次の表に、各配置の種類で使用可能なスケジュール ポリシー フィールドを示します。
| ポリシー フィールド | ピックフィックス | PickAll | PickN |
|---|---|---|---|
placementType |
✅ | ✅ | ✅ |
affinity |
❌ | ✅ | ✅ |
clusterNames |
✅ | ❌ | ❌ |
numberOfClusters |
❌ | ❌ | ✅ |
topologySpreadConstraints |
❌ | ❌ | ✅ |
メンバークラスターラベル
ハブ クラスター上の MemberCluster リソースには、任意の Kubernetes リソースと同様にラベルを付けることができます。
さらに、Fleet Manager は、次の読み取り専用ラベルをすべてのメンバー クラスターに自動的に追加します。
| ラベル | 説明 |
|---|---|
| fleet.azure.com/location | クラスターのAzureリージョン (westus) |
| fleet.azure.com/resource-group | クラスターのAzureリソース グループ (rg_prodapps_01) |
| fleet.azure.com/subscription-id | Azureクラスターが存在するサブスクリプション識別子。 UUID/GUID 形式です。 |
| fleet.azure.com/cluster-name | フリート メンバー クラスター リソースに関連付けられているクラスターの名前。 |
| fleet.azure.com/member-name | クラスターに対応する Fleet Manager メンバー クラスター名の名前。 |
クラスターのプロパティ
配置ポリシーの一部として、次のプロパティを使用します。
| プロパティ名 | 説明 |
|---|---|
| kubernetes-fleet.io/ノード数 | メンバー クラスター上で使用できるノード。 |
| resources.kubernetes-fleet.io/total-cpu | クラスターの合計 CPU リソース ユニット。 |
| resources.kubernetes-fleet.io/allocatable-cpu | クラスターに割り当て可能な CPU リソース ユニット。 |
| resources.kubernetes-fleet.io/available-cpu | クラスターの使用できる CPU リソース ユニット。 |
| resources.kubernetes-fleet.io/total-memory | クラスターの合計メモリ リソース ユニット。 |
| resources.kubernetes-fleet.io/allocatable-memory | クラスターの割り当て可能なメモリ リソース ユニット。 |
| resources.kubernetes-fleet.io/available-memory | クラスターの使用できるメモリ リソース ユニット。 |
| kubernetes.azure.com/per-cpu-core-cost | クラスターの CPU コアあたりのコスト。 |
| kubernetes.azure.com/per-gb-memory-cost | クラスターの GiB あたりのメモリ コスト。 |
| kubernetes.azure.com/vm-sizes/{vm-sku-name}/count | クラスター内の vm-sku-name 型の既存のノードの使用可能な数*。 VM SKU 名の例: NV16as_v4。 * v1beta1 API を使用したプレビュー段階。 |
| kubernetes.azure.com/vm-sizes/{vm-sku-name}/capacity | クラスターの Azure リージョン内の vm-sku-name 型の潜在的な新しいノードの数*。 VM SKU 名の例: NV16as_v4。 * v1beta1 API を使用したプレビュー段階。 |
Kubernetes リソース ユニットは、CPU とメモリのプロパティを表します。 詳細については、「 Kubernetes のリソース ユニット」を参照してください。
コスト プロパティは、クラスター内のノードが使用するAzureコンピューティングの 1 時間あたりのコストを米ドルで表す 10 進数です。 コストは、Azure のパブリック価格に基づいています。
選択マッチング条件
ポリシー条件でクラスター のプロパティを使用する場合は、次のように指定します。
名前: この記事のプロパティに 記載されている プロパティの 1 つであるプロパティの名前。
演算子: 制約または目的の値とクラスターの観測値の間の条件を表す演算子。 現在、次の演算子がサポートされています。
-
Gt(より大きい): 指定されたプロパティのクラスターの監視対象の値は、リソースの配置に対して選択する前に、条件の値より大きくする必要があります。 -
Ge(以上): 指定されたプロパティのクラスターの監視対象の値は、リソースの配置に対して選択する前に、条件の値以上にする必要があります。 -
Lt(より小さい): 指定されたプロパティのクラスターの監視対象の値は、リソースの配置に対して選択する前に、条件の値より小さくする必要があります。 -
Le(以下): 指定されたプロパティのクラスターの監視対象の値は、リソースの配置に対して選択する前に、条件の値以下にする必要があります。 -
Eq(等しい): 指定されたプロパティのクラスターの監視対象の値は、リソースの配置に対して選択する前に、条件の値と等しくする必要があります。 -
Ne(等しくない): 指定されたプロパティのクラスターの観測値は、リソースの配置に対して選択される前に、条件の値と等しくすることはできません。
演算子
Gt、Ge、Lt、Le、Eq、またはNeを使用する場合、条件内の値の一覧には、正確に 1 つの値がある必要があります。-
Values: プロパティの使用可能な値の一覧です。
フリートは、条件内で指定した属性に基づいて各クラスターを評価します。 クラスターが requiredDuringSchedulingIgnoredDuringExecutionに記載されている条件を満たしていない場合、Fleet はリソースの配置からクラスターを除外します。
注
メンバー クラスターに条件で表されるプロパティがない場合、条件は自動的に失敗します。
5 つ以上のノードを持つクラスターのみを選択する配置ポリシーの例を次に示します。
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp-pickall-five-nodes
spec:
resourceSelectors:
- group: ""
kind: Namespace
name: prod-deployment
version: v1
policy:
placementType: PickAll
affinity:
clusterAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
clusterSelectorTerms:
- propertySelector:
matchExpressions:
- name: "kubernetes-fleet.io/node-count"
operator: Ge
values:
- "5"
apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
name: app-configs-rp-pickall-five-nodes
namespace: my-app
spec:
resourceSelectors:
- group: ""
kind: ConfigMap
version: v1
labelSelector:
matchLabels:
app: my-application
policy:
placementType: PickAll
affinity:
clusterAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
clusterSelectorTerms:
- propertySelector:
matchExpressions:
- name: "kubernetes-fleet.io/node-count"
operator: Ge
values:
- "5"
プロパティのランク付けのしくみ
preferredDuringSchedulingIgnoredDuringExecutionを使用すると、プロパティソーターは、その値に基づいて、フリート内のすべてのクラスターを昇順または降順でランク付けします。 順序付けに使用される重みは、指定した値に基づいて計算されます。
プロパティ ソーターは、次の要素で構成されます。
- Name: クラスター プロパティの名前。
-
並べ替え順序: 並べ替え順序は、
AscendingまたはDescendingにすることができます。Ascending順序を使用する場合は、観測値が低いメンバー クラスターをお勧めします。Descending順序を使用する場合は、観測値が高いメンバー クラスターをお勧めします。
詳細については、 プロパティ ベースのスケジュール設定に関する KubeFleet ドキュメントを参照してください。
ロールアウト戦略の構成
Fleet Manager リソース配置では、既定の RollingUpdate 戦略を使用して、リソースをメンバー クラスターに分散する方法を制御します。
次の例では、各メンバー クラスターに対して配置が順次行われ、クラスター間では少なくとも unavailablePeriodSeconds の間隔を開けています。
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp-pick-all-rolling
spec:
resourceSelectors:
- group: ""
kind: Namespace
name: prod-deployment
version: v1
policy:
placementType: PickAll
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 25%
maxSurge: 25%
unavailablePeriodSeconds: 60
apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
name: app-configs-rp-pickall-rolling
namespace: my-app
spec:
resourceSelectors:
- group: ""
kind: ConfigMap
version: v1
labelSelector:
matchLabels:
app: my-application
policy:
placementType: PickAll
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 25%
maxSurge: 25%
unavailablePeriodSeconds: 60
すべてのリソースがクラスターに正しく適用されている場合、ロールアウトの状態は成功と見なされます。 この状態は子リソースの状態を連鎖しないため、デプロイによってメンバー クラスターに作成されたポッドの準備が完了することは確認されません。
詳細については、 ロールアウト戦略に関するドキュメントを参照してください。
容認の使用
クラスター内のノードをテイントするのと同様に、メンバークラスターもテイントできます。
リソース配置では、各容認が次のフィールドで構成される容認の使用がサポートされています。
-
key: 容認の鍵。 -
value: 容認の値。 -
effect:NoScheduleなど、容認の効果。 -
operator:ExistsやEqualなど、容認の演算子。
各容認は、 MemberCluster に適用される 1 つ以上の特定のテイントを許容するために使用されます。 すべてのテイントが許容されると、Fleet Manager はメンバー クラスターにリソースを分散できます。
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: test-ns
spec:
policy:
placementType: PickAll
tolerations:
- key: app-team-a
operator: Exists
resourceSelectors:
- group: ""
kind: Namespace
name: test-ns
version: v1
revisionHistoryLimit: 10
strategy:
type: RollingUpdate
apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
name: app-configs-rp-pickall-rolling
namespace: my-app
spec:
resourceSelectors:
- group: ""
kind: ConfigMap
version: v1
labelSelector:
matchLabels:
app: my-application
policy:
placementType: PickAll
tolerations:
- key: app-team-a
operator: Exists
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 25%
maxSurge: 25%
unavailablePeriodSeconds: 60
詳細については、 容認に関するドキュメントを参照してください。
エンベロープ リソースの使用
Fleet Manager ハブ クラスターは、Kubernetes クラスターでもあります。 最初に、ハブ クラスターに配布するリソースを適用します。 このアプローチは以下のような結果をもたらします:
意図しない副作用: ValidatingWebhookConfigurations、MutatingWebhookConfigurations、またはアドミッション コントローラーがハブ クラスターでアクティブになり、ハブ クラスターの操作がインターセプトされ、影響を受ける可能性があります。
セキュリティ リスク: メンバー クラスターを対象とした RBAC リソース (ロール、ClusterRoles、RoleBindings、ClusterRoleBindings) は、ハブ クラスターに対するアクセス許可を付与または制限できます。
リソースの制限事項: メンバー クラスターに対して定義されている ResourceQuotas、FlowSchema、または LimitRanges がハブ クラスターで有効になります。
不要な副作用を回避するために、Fleet Manager はカスタム エンベロープ リソース (ClusterResourceEnvelope と ResourceEnvelope) を提供してオブジェクトをラップし、これらの潜在的な問題を回避します。
エンベロープ リソースはハブ クラスターに適用しますが、含まれているリソースは、メンバー クラスターに到達したときに抽出され、適用されます。
詳細については、エンベロープ オブジェクトに関するドキュメントを参照してください。
配置の状態を確認する
Fleet Manager リソースの配置には、ハブ クラスターのアクセス レベルと要件に応じて状態を表示する 2 つの方法があります。
-
ClusterResourcePlacement の状態: クラスター スコープの
ClusterResourcePlacementリソースで配置の状態を直接表示します。 クラスター レベルのアクセス許可があり、フリート全体にわたる配置の状態を表示する必要がある場合に使用します。
-
ResourcePlacement の状態: 名前空間スコープの
ResourcePlacementリソースで配置の状態を直接表示します。 名前空間レベルのアクセス許可があり、フリート全体にわたる名前空間スコープの配置の状態を確認する必要がある場合に使用します。
ClusterResourcePlacement の状態の表示
この情報を表示するには、 kubectl describe resourceplacement <rp-name> コマンドを使用します。
kubectl describe resourceplacement place-cmap-1
-
ClusterResourcePlacementStatus: 名前空間スコープの
ClusterResourcePlacementStatusリソースを使用して配置の状態を表示します。 このリソースは、名前空間スコープのユーザーがクラスター レベルのアクセス許可を付与せずに配置の状態を表示する必要がある場合に使用します。 詳細については、「 ClusterResourcePlacementStatus」セクションを参照してください。
どちらの方法でも、次の情報が提供されます。
- 配置に現在適用されている条件。配置が正常に完了したかどうかが含まれます。
- 各メンバー クラスターについての配置状態セクション。ここには、そのクラスターへのデプロイの状態が表示されます。
ClusterResourcePlacement の状態を使用する
次の例は、ClusterResourcePlacementを使用して、test名前空間と test-1 ConfigMap を 2 つのメンバー クラスターにデプロイしたPickNから直接状態を表示する方法を示しています。 配置が正常に完了し、リソースが aks-member-1 と aks-member-2 のクラスターに配置されました。
この情報を表示するには、 kubectl describe clusterresourceplacement <crp-name> コマンドを使用します。
kubectl describe clusterresourceplacement crp-1
Name: crp-1
Namespace:
Labels: <none>
Annotations: <none>
API Version: placement.kubernetes-fleet.io/v1
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
ClusterResourcePlacementStatus リソースを使用する
ClusterResourcePlacementStatus リソースは名前空間スコープであり、対応するクラスター スコープのClusterResourcePlacement オブジェクトの状態の名前空間固有のビューを提供します。 このリソースを使用すると、クラスター レベルの権限を持たない名前空間ユーザーは、名前空間の外部から情報を公開することなく、配置の状態を読み取ることができます。
Important
2027 年 1 月 31 日以降、名前空間固有のビューには、選択した名前空間と、その名前空間内のリソースと参照のみが含まれます。 Fleet Manager では、クラスター スコープのリソースと参照および名前空間をまたぐリソースと参照は省略されます。 また、ドリフトと差分の詳細の空でないメンバー クラスタとハブの値を (redacted) に置き換えます。 クラスター スコープ ClusterResourcePlacement の状態は変更されません。
この方法を使用するには、ClusterResourcePlacement API を使用して、statusReportingScope: NamespaceAccessibleでv1を構成します。
statusReportingScopeを NamespaceAccessible に設定すると、名前空間リソース セレクターは 1 つだけ指定でき、作成後に変更することはできません。
ClusterResourcePlacementStatus の構成
この機能を使用するには、ClusterResourcePlacementで v1 API バージョンを指定します。
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp-with-status-reporting
spec:
statusReportingScope: NamespaceAccessible
resourceSelectors:
- group: ""
kind: Namespace
name: my-app
version: v1
policy:
placementType: PickAll
ClusterResourcePlacementStatus の閲覧
kubectl describe コマンドを使用して、状態を表示できます。
kubectl describe clusterresourceplacementstatuses.v1.placement.kubernetes-fleet.io crp-with-status-reporting -n my-app
出力には、選択した名前空間内に表示される状態情報が含まれます。 これには、選択した名前空間、その名前空間内のリソース、および同じ名前空間のリソースオーバーライドとリソース エンベロープへの参照が含まれます。 クラスター スコープのリソースまたはクロス名前空間リソース、クラスター リソース オーバーライド、またはクラスター リソース エンベロープは含まれません。
ドリフトと差分の詳細は、JSON パスを保持します。 Fleet Manager は、空でない各 valueInMember および valueInHub 値を (redacted) に置き換えます。 空の値は、JSON パスがその側に存在しないことを示し続けます。
アプリケーションが ClusterResourcePlacementStatus を読み取る場合は、2027 年 1 月 31 日より前に更新して、省略されたエントリを許容し、編集マーカーを利用不可のデータとして扱います。 アプリケーションで完全なリソース ID または生のドリフト値と差分値が必要な場合は、適切なクラスターレベルのロールベースのアクセス制御 (RBAC) のアクセス許可を持つ資格情報を使用して、クラスター スコープの ClusterResourcePlacement の状態を読み取ります。
詳細については、配置結果を理解する方法に関するドキュメントを参照してください。
配置変更トリガー
Fleet Manager スケジューラは、既存のリソース配置の安定性に優先順位を付けます。 この優先順位により、リソースを削除および再スケジュールする変更の数が制限されます。
次のシナリオでは、配置の変更がトリガーされる可能性があります。
- リソース配置 (
ClusterResourcePlacementまたはResourcePlacement) の配置ポリシーの変更により、リソースの削除と再スケジュールがトリガーされる可能性があります。- スケールアウト操作 (他の変更なしで
numberOfClustersを増やす) は、新しいクラスターにのみワークロードを配置し、既存の配置には影響しません。
- スケールアウト操作 (他の変更なしで
- メンバー クラスターに以下のような変更があります:
- 新しいメンバー クラスターが対象となり、たとえば
PickAllポリシーなどの配置ポリシーの条件を満たすこと。 - フリートからのメンバー クラスターの削除。 ポリシーに応じて、スケジューラは、既存の配置に影響を与えることなく、影響を受けるすべてのリソースを残りのクラスターに配置しようとします。
- 新しいメンバー クラスターが対象となり、たとえば
選択したリソースを更新する (たとえば、 Deploymentを変更する) か、リソース配置で resourceSelector を更新すると、Fleet Manager によって既存の配置が徐々にロールアウトされますが、リソースの再スケジュール (つまり、選択したクラスターの変更) はトリガー されません 。
ResourcePlacement と ClusterResourcePlacement を一緒に利用する
ClusterResourcePlacementは名前空間がアプリケーションの境界を表していることを前提としていますが、実際の使用パターンは多くの場合、より複雑です。 組織は、アプリケーションの境界ではなく、チームの境界として名前空間を頻繁に使用します。 このアプローチにより、ResourcePlacement が直接対処するいくつかの課題が生じます。
マルチアプリケーション名前空間: 多くの組織では、1 つの名前空間に、同じチームが所有する複数の独立したアプリケーションが含まれています。 これらのアプリケーションには、次の内容が含まれます。
- さまざまなライフサイクル要件。 たとえば、あるアプリケーションで頻繁に更新する必要がある一方で、別のアプリケーションは安定している場合があります。
- さまざまなクラスター配置のニーズ。 たとえば、開発アプリケーションと運用アプリケーションです。
- 独立したスケーリングとリソースの要件。
- コンプライアンスまたはガバナンスの要件を分離します。
個々のスケジュール決定: 多くのワークロード (特に AI/ML ジョブ) には、個々のスケジュール決定が必要です。
- AI ジョブ: 機械学習ワークロードは、多くの場合、クラスター リソースの可用性、GPU の可用性、またはデータの局所性に基づいてスケジュールする必要がある、短期間のリソース集中型ジョブで構成されます。
- バッチ ワークロード: 同じ名前空間内のバッチ ジョブが異なると、コンピューティング要件に基づいて異なるクラスターの種類が対象になる場合があります。
アプリケーション チームの完全な制御: ResourcePlacement は、プラットフォーム チームの介入を必要とせずに、アプリケーション チームにリソースの配置を直接制御できるようにします。
- セルフサービス運用: Teams は、独自のリソース分散戦略を管理できます。
- 独立したデプロイ サイクル: 名前空間内のさまざまなアプリケーションに、独立したロールアウト スケジュールを設定できます。
- きめ細かいオーバーライド機能: Teams では、名前空間内の他のアプリケーションに影響を与えることなく、クラスターごとのリソース構成をカスタマイズできます。
この細かいアプローチにより、 ResourcePlacement は、フリートスケジューリングフレームワークのシンプルさとパワーを維持しながら、多様な組織構造とワークロードパターンに適応することができます。
ResourcePlacement と ClusterResourcePlacement の主な違い
次の表では、 ResourcePlacement と ClusterResourcePlacementの主な違いを示します。
| 特徴 | ResourcePlacement (RP) | ClusterResourcePlacement (CRP) |
|---|---|---|
| Scope | 名前空間スコープのリソースのみ | クラスター スコープのリソース (特に名前空間とその内容) |
| 資源 | 名前空間スコープの API オブジェクト | クラスター スコープ API オブジェクト |
| 選択境界 | RP と同じ名前空間内のリソースに限定 | クラスター全体にスコープされたリソースから選択可能です |
| 一般的なユース ケース | AI/ML ジョブ、個々のワークロード、独立した配置の決定を必要とする特定の ConfigMaps/Secret | アプリケーション バンドル、名前空間全体、クラスター全体のポリシー |
| チームの所有権 | 名前空間の所有者と開発者 | プラットフォームオペレーター |
ResourcePlacementとClusterResourcePlacementの両方で、相違点の表に記載されていない他のすべての側面に対して同じコア機能が共有されます。
ResourcePlacement と ClusterResourcePlacement を使用したシナリオの例
ResourcePlacement は、 ClusterResourcePlacement (CRP) と連携して、完全なマルチクラスター リソース管理ソリューションを提供します。 この関係を理解することは、効果的なフリート管理に不可欠です。
Important
ResourcePlacement は、既にターゲット名前空間を持つクラスターにのみ名前空間スコープのリソースを配置できます。 名前空間の確立には ClusterResourcePlacement を使用します。
一般的なワークフロー:
-
プラットフォーム管理者:
ClusterResourcePlacementを使用して、フリート全体に名前空間をデプロイします。 -
アプリケーション チーム:
ResourcePlacementを使用して、確立された名前空間内の特定のリソースを管理します。
次の例では、CRP と RP を調整する方法を示します。
プラットフォーム管理者: ClusterResourcePlacementを使用して名前空間を作成します。
apiVersion: placement.kubernetes-fleet.io/v1
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/v1
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で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では、名前空間スコープの個々のリソースをきめ細かく制御できます。