1.14. ManagedClusterSets の作成および管理
ManagedClusterSet
は、マネージドクラスターのグループです。マネージドクラスターセットでは、グループ内の全マネージドクラスターに対するアクセス権を管理できます。ManagedClusterSetBinding
リソースを作成して ManagedClusterSet
リソースを namespace にバインドすることもできます。
マネージドクラスターはそれぞれ、ManagedClusterSet
のメンバーにする必要があります。ハブクラスターをインストールすると、default
と呼ばれるデフォルトの ManagedClusterSet
が作成されます。マネージドクラスターセットに特に割り当てられていないマネージドクラスターはすべて、デフォルト
のマネージドクラスターセットに自動的に割り当てられます。デフォルトのマネージドクラスターセットを常に利用可能にするには、デフォルト
のマネージドクラスターセットを削除したり、更新したりできません。
注記: ManagedClusterSet
に追加するように指定されていないクラスタープールは、デフォルトの ManagedClusterSet
に追加されません。マネージドクラスターがクラスタープールから要求された後に、別の ManagedClusterSet
に特に追加されていない場合は、デフォルトの ManagedClusterSet
に追加されます。
1.14.1. ManagedClusterSet の作成
マネージドクラスターセットにマネージドクラスターをグループ化して、マネージドクラスターでのユーザーのアクセス権限を制限できます。
必要なアクセス権限: クラスターの管理者
ManagedClusterSet
は、クラスタースコープのリソースであるため、ManagedClusterSet
の作成先となるクラスターで管理者権限が必要です。マネージドクラスターは、複数の ManagedClusterSet
に追加できません。Red Hat Advanced Cluster Management for Kubernetes コンソールまたはコマンドラインインターフェイスから、マネージドクラスターセットを作成できます。
1.14.1.1. コンソールを使用した ManagedClusterSet の作成
Red Hat Advanced Cluster Management コンソールを使用して、マネージドクラスターセットを作成するには、以下の手順を実行します。
- メインコンソールナビゲーションで Infrastructure > Clusters を選択し、Cluster sets タブが選択されていることを確認します。
- Create cluster set を選択し、クラスターセットの名前を入力します。
1.14.1.2. コマンドラインを使用した ManagedClusterSet の作成
コマンドラインを使用して yaml
ファイルに以下のマネージドクラスターセットの定義を追加し、マネージドクラスターセットを作成します。
apiVersion: cluster.open-cluster-management.io/v1beta1 kind: ManagedClusterSet metadata: name: <clusterset1>
clusterset1
はマネージドクラスターセットの名前に置き換えます。
1.14.2. ManagedClusterSet に対するユーザーまたはグループのロールベースのアクセス制御パーミッションの割り当て
ハブクラスターに設定したアイデンティティープロバイダーが提供するクラスターセットに、ユーザーまたはグループを割り当てることができます。
必要なアクセス権限: クラスターの管理者
ManagedClusterSet
API が提供する RBAC パーミッションにはレベルが 2 つあります。
クラスターセット
admin
- マネージドクラスターセットに割り当てられた、すべてのクラスターおよびクラスタープールリソースに対する完全なアクセス権限。
- クラスターの作成、クラスターのインポート、クラスタープールの作成権限。パーミッションは、マネージドクラスターセットの作成時に設定したマネージドクラスターに割り当てる必要があります。
クラスターセット
view
- マネージドクラスターセットに割り当てられた、すべてのクラスターおよびクラスタープールリソースに対する読み取り専用の権限。
- クラスターの作成、クラスターのインポート、またはクラスタープールの作成を実行する権限なし。
Red Hat Advanced Cluster Management コンソールからマネージドクラスターセットにユーザーまたはグループを割り当てるには、以下の手順を実行します。
- コンソールのメインナビゲーションメニューで、Infrastructure > Clusters を選択します。
- Cluster sets タブを選択します。
- ターゲットクラスターセットを選択します。
- Access management タブを選択します。
- Add user or group を選択します。
- アクセス権を割り当てるユーザーまたはグループを検索して選択します。
- Cluster set admin または Cluster set view ロールを選択して、選択したユーザーまたはグループに付与します。ロールのパーミッションについての詳細は、ロールの概要 を参照してください。
- Add を選択して変更を送信します。
テーブルにユーザーまたはグループが表示されます。全マネージドクラスターセットリソースのパーミッションの割り当てがユーザーまたはグループに伝播されるまでに数秒かかる場合があります。
ロールアクションの詳細は、ロールベースのアクセス制御 を参照してください。
配置の詳細は、配置での ManagedClusterSets の使用 を参照してください。
1.14.2.1. ManagedClusterSetBinding リソースの作成
ManagedClusterSetBinding
リソースを作成して ManagedClusterSet
リソースを namespace にバインドします。同じ namespace で作成されたアプリケーションおよびポリシーがアクセスできるのは、バインドされたマネージドクラスターセットリソースに含まれるマネージドクラスターだけです。
namespace へのアクセスパーミッションは、その namespace にバインドされるマネージドクラスターセットに自動的に適用されます。マネージドクラスターセットがバインドされる namespace へのアクセス権限がある場合は、その namespace にバインドされているマネージドクラスターセットにアクセス権限が自動的に付与されます。ただし、マネージドクラスターセットへのアクセス権限のみがある場合は、対象の namespace にある他のマネージドクラスターセットにアクセスする権限は自動的に割り当てられません。マネージドクラスターセットが表示されない場合は、表示に必要なパーミッションがない可能性があります。
コンソールまたはコマンドラインを使用してマネージドクラスターセットバインディングを作成できます。
1.14.2.1.1. コンソールを使用した ManagedClusterSetBinding の作成
Red Hat Advanced Cluster Management コンソールを使用して、マネージドクラスターセットからクラスターを削除するには、以下の手順を実行します。
- メインナビゲーションで Infrastructure > Clusters を選択し、Cluster sets タブを選択します。
- バインディングを作成するクラスターセットの名前を選択し、クラスターセットの詳細を表示します。
- Actions > Edit namespace bindings を選択します。
- Edit namespace bindings ページで、ドロップダウンメニューからクラスターセットをバインドする namespace を選択します。このクラスターセットにバインディングされている既存の namespace は選択してあります。
1.14.2.1.2. コマンドラインを使用した ManagedClusterSetBinding の作成
コマンドラインを使用してマネージドクラスターセットバインディングを作成するには、以下の手順を実行します。
yaml
ファイルにManagedClusterSetBinding
リソースを作成します。クラスターセットバインディングの作成時には、クラスターセットバインディング名と、バインドするマネージドクラスターセット名を一致させる必要があります。ManagedClusterSetBinding
リソースは、以下の情報のようになります。apiVersion: cluster.open-cluster-management.io/v1beta1 kind: ManagedClusterSetBinding metadata: namespace: project1 name: clusterset1 spec: clusterSet: clusterset1
ターゲットのマネージドクラスターセットでのバインド権限を割り当てておく必要があります。以下の
ClusterRole
リソースの例を確認してください。この例には、ユーザーがclusterset1
にバインドできるように、複数のルールが含まれています。apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: clusterrole1 rules: - apiGroups: ["cluster.open-cluster-management.io"] resources: ["managedclustersets/bind"] resourceNames: ["clusterset1"] verbs: ["create"]
1.14.3. クラスターの ManagedClusterSet への追加
ManagedClusterSet
の作成後に、1 つ以上のマネージドクラスターを追加する必要があります。コンソールまたはコマンドラインのいずれかを使用して、マネージドクラスターをマネージドクラスターセットに追加できます。
1.14.3.1. コンソールを使用したクラスターの ManagedClusterSet への追加
Red Hat Advanced Cluster Management コンソールを使用してマネージドクラスターセットにクラスターを追加するには、以下の手順を実行します。
- マネージドクラスターセットを作成している場合は、Manage resource assignments を選択して、Manage resource assignments ページに直接移動します。この手順のステップ 6 に進みます。
- クラスターがすでに存在する場合は、メインのナビゲーションで Infrastructure > Clusters を選択してクラスターページにアクセスします。
- Cluster sets タブを選択して、利用可能なクラスターセットを表示します。
- マネージドクラスターセットに追加するクラスターセットの名前を選択し、クラスターセットの詳細を表示します。
- Actions > Manage resource assignments を選択します。
- Manage resource assignments ページで、クラスターセットに追加するリソースのチェックボックスを選択します。
- Review を選択して変更を確認します。
Save を選択して変更を保存します。
注記: マネージドクラスターを別のマネージドクラスターセットに移動する場合は、マネージドクラスター両方で RBAC パーミッションの設定が必要です。
1.14.3.2. コマンドラインを使用した ManagedClusterSet へのクラスターの追加
コマンドラインを使用してクラスターをマネージドクラスターに追加するには、以下の手順を実行します。
managedclustersets/join
の仮想サブリソースに作成できるように、RBACClusterRole
エントリーが追加されていることを確認します。このパーミッションがない場合は、マネージドクラスターをManagedClusterSet
に割り当てることはできません。このエントリーが存在しない場合は、
yaml
ファイルに追加します。サンプルエントリーは以下の内容のようになります。kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: clusterrole1 rules: - apiGroups: ["cluster.open-cluster-management.io"] resources: ["managedclustersets/join"] resourceNames: ["<clusterset1>"] verbs: ["create"]
clusterset1
はManagedClusterSet
の名前に置き換えます。注記: マネージドクラスターを別の
ManagedClusterSet
に移動する場合には、マネージドクラスターセット両方でパーミッションの設定が必要です。yaml
ファイルでマネージドクラスターの定義を検索します。ラベルの追加先のマネージドクラスター定義のセクションは、以下の内容のようになります。apiVersion: cluster.open-cluster-management.io/v1 kind: ManagedCluster metadata: name: cluster1 spec: hubAcceptsClient: true
この例では、
cluster1
はマネージドクラスターの名前です。ManagedClusterSet
の名前をcluster.open-cluster-management.io/clusterset: clusterset1
形式で指定してラベルを追加します。コードは以下の例のようになります。
apiVersion: cluster.open-cluster-management.io/v1 kind: ManagedCluster metadata: name: cluster1 labels: cluster.open-cluster-management.io/clusterset: clusterset1 spec: hubAcceptsClient: true
この例では、
cluster1
は、clusterset1
のマネージドクラスターセット名に追加するクラスターです。注記: マネージドクラスターが削除済みのマネージドクラスターセットにこれまでに割り当てられていた場合は、すでに存在しないクラスターが指定されたマネージドクラスターセットがマネージドクラスターに設定されている可能性があります。その場合は、名前を新しい名前に置き換えます。
1.14.4. ManagedClusterSet からのマネージドクラスターの削除
マネージドクラスターセットからマネージドクラスターを削除して別のマネージドクラスターセットに移動するか、セットの管理設定から削除する必要がある場合があります。コンソールまたはコマンドラインインターフェイスを使用して、マネージドクラスターセットからマネージドクラスターを削除できます。
注記: マネージドクラスターはすべて、マネージドクラスターセットに割り当てる必要があります。ManagedClusterSet
からマネージドクラスターを削除して、別の ManagedClusterSet
に割り当てない場合は、デフォルト
のマネージドクラスターセットに自動的に追加されます。
1.14.4.1. コンソールを使用した ManagedClusterSet からのマネージドクラスターの削除
Red Hat Advanced Cluster Management コンソールを使用して、マネージドクラスターセットからクラスターを削除するには、以下の手順を実行します。
- マネージドクラスターセットを作成している場合は、Manage resource assignments を選択して、Manage resource assignments ページに直接移動します。この手順のステップ 5 に進みます。
- クラスターがすでに存在する場合は、メインのナビゲーションで Infrastructure > Clusters を選択してクラスターページにアクセスし、Cluster sets タブが選択されていることを確認します。
- マネージドクラスターセットから削除するクラスターセットの名前を選択し、クラスターセットの詳細を表示します。
- Actions > Manage resource assignments を選択します。
Manage resource assignments ページで、クラスターセットから削除するリソースのチェックボックスを選択します。
この手順では、クラスターセットのメンバーであるリソースを削除するか、クラスターセットのメンバーでないリソースを追加します。マネージドクラスターの詳細を表示して、リソースがすでにクラスターセットのメンバーであるかどうかを確認できます。
注記: マネージドクラスターを別のマネージドクラスターセットに移動する場合には、マネージドクラスターセット両方で RBAC パーミッションの設定が必要です。
1.14.4.2. コマンドラインを使用した ManagedClusterSet からのクラスターの削除
マネージドクラスターセットからマネージドクラスターを削除するには、以下の手順を実行します。
以下のコマンドを実行して、マネージドクラスターセットでマネージドクラスターのリストを表示します。
oc get managedclusters -l cluster.open-cluster-management.io/clusterset=<clusterset1>
clusterset1
はマネージドクラスターセットの名前を置き換えます。- 削除するクラスターのエントリーを見つけます。
削除するクラスターの
yaml
エントリーからラベルを削除します。ラベルの例については、以下のコードを参照してください。labels: cluster.open-cluster-management.io/clusterset: clusterset1
注記: マネージドクラスターを別のマネージドクラスターセットに移動する場合には、マネージドクラスターセット両方で RBAC パーミッションの設定が必要です。
1.14.5. Placement での ManagedClusterSets の使用
Placement
リソースは、namespace レベルのリソースで、placement namespace にバインドされる ManagedClusterSets
から ManagedClusters
セットを選択するルールを定義します。
必要なアクセス権限: クラスター管理者またはクラスターセット管理者。
1.14.5.1. 配置の概要
マネージドクラスターによる配置の仕組みについては、以下を参照してください。
-
Kubernetes クラスターは、cluster スコープの
ManagedClusters
としてハブクラスターに登録されます。 -
managedcluster
は、クラスタースコープのManagedClusterSets
に編成されます。 -
ManagedClusterSets
はワークロード namespace にバインドされます。 -
namespace スコープの
Placements
は、ManagedClusterSets
の一部を指定して、ManagedClusters
候補の作業セットを選択します。 Placements
は、ラベルと要求セレクターを使用して作業セットから選択します。重要:
Placement
では、placement namespace にManagedClusterSet
がバインドされていない場合、ManagedCluster
は選択されません。-
ManagedClusters
の配置は、テイントおよび容認 (Toleration) を使用して制御できます。詳細は、テイントおよび容認を使用したマネージドクラスターの場所 を参照してください。
Placement
仕様には以下のフィールドが含まれます。
ClusterSets
は、ManagedClusters
の選択元のManagedClusterSets
を表します。-
指定されていない場合は、Placement namespace にバインドされる
ManagedClusterSets
からManagedClusters
が選択されます。 -
指定されている場合は、
ManagedClusters
がこのセットの交差部分から選択され、ManagedClusterSets
は Placement namespace にバインドされます。
-
指定されていない場合は、Placement namespace にバインドされる
NumberOfClusters
は、配置要件を満たすManagedClusters
の中から選択する数を表します。指定されていない場合は、配置要件を満たすすべての
ManagedClusters
が選択されます。-
Predicates
は、ラベルおよび要求セレクターでManagedClusters
を選択する述語のスライスを表します。述語は ORed です。 prioritizerPolicy
は優先順位のポリシーを表します。モード
はExact
、Additive、
または""
のいずれかになります。ここで""
はデフォルトでAdditive
になります。-
Additive
モードでは、設定値が特に指定されていない Prioritizer はデフォルト設定で有効になっています。現在のデフォルト設定では、Steady と Balance の重みは 1 で、他の Prioritizer は 0 になります。デフォルトの設定は、今後変更される可能性があるので、優先順位が変更される可能性があります。Additive
モードでは、すべての Prioritizer を設定する必要はありません。 -
Exact
モードでは、設定値で特に指定されていない Prioritizer の重みがゼロになります。Exact
モードでは、必要な Prioritizer の完全なセットを入力する必要がありますが、リリースごとに動作が変わることはありません。
-
設定
とは、Prioritizer の設定を表します。scoreCoordinate は prioritizer およびスコアソースの設定を表します。
-
type
は prioritizer スコアのタイプを定義します。タイプはBuiltIn
、AddOn
、または" "
です。" "
のデフォルトはBuiltIn
です。タイプがBuiltIn
の場合、prioritizer 名を指定する必要があります。タイプがAddOn
の場合、AddOn
でスコアソースを設定する必要があります。 builtin
は、BuiltIn prioritizer の名前を定義します。以下の一覧には、有効なBuiltIn
の prioritizer 名が含まれます。- Balance: クラスター間の決定を分散します。
- Steady: 既存の意思決定が安定していることを確認します。
- ResourceAllocatableCPU & ResourceAllocatableMemory: 割り当て可能なリソースに基づいてクラスターを分類します。
addOn
はリソース名およびスコア名を定義します。AddOnPlacementScore
は、アドオンスコアを記述するために導入されました。詳細は Extensible scheduling を参照してください。-
resourceName
はAddOnPlacementScore
のリソース名を定義します。Placement prioritizer は、この名前でAddOnPlacementScore
カスタムリソースを選択します。 -
scoreName
はAddOnPlacementScore
内でスコア名を定義します。AddOnPlacementScore
には、スコア名とスコア値の一覧が含まれます。scoreName
: prioritizer で使用されるスコアを指定します。
-
-
-
weight
は Prioritizer の重みを定義します。値は [-10,10] の範囲に指定する必要があります。それぞれの prioritizer は、[-100, 100] の範囲でクラスターの整数スコアを計算します。クラスターの最後のスコアは、以下の式sum(weight * prioritizer_score)
で決定されます。重みが大きい場合は、Prioritizer はクラスターの選択で重みの高いものを受け取ることを意味し、一方、重みが 0 の場合は Prioritizer が無効であることを示します。負の重みは、最後に選択されたものであることを示します。
注記: configurations.name
ファイルは v1beta1 で削除され、scoreCoordinate.builtIn
ファイルに置き換えられる予定です。name
と scoreCoordinate.builtIn
の両方が定義されている場合には、scoreCoordinate.builtIn
の値を使用して選択を決定します。
1.14.5.2. 配置の例
namespace に ManagedClusterSetBinding
を作成して、その namespace に ManagedClusterSet
を最低でも 1 つバインドする必要があります。注記: managedclustersets/bind
の仮想サブリソースの CREATE
に対してロールベースのアクセスが必要です。以下の例を参照してください。
labelSelector
でManagedClusters
を選択します。以下の例では、labelSelector
はラベルvendor: OpenShift
のクラスターだけに一致します。apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement1 namespace: ns1 spec: predicates: - requiredClusterSelector: labelSelector: matchLabels: vendor: OpenShift
claimSelector
でManagedClusters
を選択します。以下の例では、claimSelector
はregion.open-cluster-management.io
がus-west-1
のクラスターだけに一致します。apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement2 namespace: ns1 spec: predicates: - requiredClusterSelector: claimSelector: matchExpressions: - key: region.open-cluster-management.io operator: In values: - us-west-1
clusterSets
からManagedClusters
を選択します。以下の例では、claimSelector
はclusterSets:
clusterset1
clusterset2
だけに一致します。apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement3 namespace: ns1 spec: clusterSets: - clusterset1 - clusterset2 predicates: - requiredClusterSelector: claimSelector: matchExpressions: - key: region.open-cluster-management.io operator: In values: - us-west-1
任意の数の
ManagedClusters
を選択します。以下の例は、numberOfClusters
が3
の場合です。apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement4 namespace: ns1 spec: numberOfClusters: 3 predicates: - requiredClusterSelector: labelSelector: matchLabels: vendor: OpenShift claimSelector: matchExpressions: - key: region.open-cluster-management.io operator: In values: - us-west-1
割り当て可能なメモリーが最大のクラスターを選択します。
注記: Kubernetes Node Allocatable と同様に、allocatable は、各クラスターの Pod で利用可能なコンピュートリソースの量として定義されます。
apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement6 namespace: ns1 spec: numberOfClusters: 1 prioritizerPolicy: configurations: - scoreCoordinate: builtIn: ResourceAllocatableMemory
割り当て可能な CPU およびメモリーが最大のクラスターを選択し、配置がリソースの変更に厳密に対応するように設定します。
apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement7 namespace: ns1 spec: numberOfClusters: 1 prioritizerPolicy: configurations: - scoreCoordinate: builtIn: ResourceAllocatableCPU weight: 2 - scoreCoordinate: builtIn: ResourceAllocatableMemory weight: 2
最大割り当て可能なメモリーと最大のアドオンスコアの cpu 比率を持つ 2 つのクラスターを選択し、配置の決定を固定します。
apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement8 namespace: ns1 spec: numberOfClusters: 2 prioritizerPolicy: mode: Exact configurations: - scoreCoordinate: builtIn: ResourceAllocatableMemory - scoreCoordinate: builtIn: Steady weight: 3 - scoreCoordinate: type: AddOn addOn: resourceName: default scoreName: cpuratio
1.14.5.3. 配置のデシジョン
ラベルが cluster.open-cluster-management.io/placement={placement name}
の PlacementDecisions
が 1 つまたは複数作成され、Placement
で選択された ManagedClusters
を表します。
ManagedCluster
が選択され、PlacementDecision
に追加されると、この Placement
を使用するコンポーネントは、ManagedCluster
でワークロードを適用する可能性があります。ManagedCluster
が選択されなくなり、PlacementDecisions
から削除されると、この ManagedCluster
に適用されるワークロードも随時削除する必要があります。
以下の PlacementDecision
の例を参照してください。
apiVersion: cluster.open-cluster-management.io/v1beta1 kind: PlacementDecision metadata: labels: cluster.open-cluster-management.io/placement: placement1 name: placement1-kbc7q namespace: ns1 ownerReferences: - apiVersion: cluster.open-cluster-management.io/v1beta1 blockOwnerDeletion: true controller: true kind: Placement name: placement1 uid: 05441cf6-2543-4ecc-8389-1079b42fe63e status: decisions: - clusterName: cluster1 reason: '' - clusterName: cluster2 reason: '' - clusterName: cluster3 reason: ''
1.14.5.4. アドオンのステータス
デプロイ先のアドオンのステータスに合わせて、配置用のマネージドクラスターを選択できます。たとえば、クラスターで有効になっている特定のアドオンがある場合にのみ、配置のマネージドクラスターを選択します。
これは、アドオンのラベルと、必要に応じてそのステータスを指定して実行できます。クラスターでアドオンが有効になっている場合、ラベルは ManagedCluster
リソースで自動的に作成されます。アドオンが無効になると、ラベルは自動的に削除されます。
各アドオンは、feature.open-cluster-management.io/addon-<addon_name>=<status_of_addon>
の形式でラベルで表現します。
addon_name
は、選択するマネージドクラスターで有効にする必要があるアドオンの名前に置き換えます。
status_of_addon
は、クラスターが選択されている場合にアドオンに指定すべきステータスに置き換えます。status_of_addon
の使用可能な値は以下の一覧のとおりです。
-
Available
: アドオンが有効で利用可能である。 -
unhealthy
: アドオンは有効になっているが、リースは継続的に更新されない。 -
unreachable
: アドオンは有効になっているが、リースが見つからない。これは、マネージドクラスターがオフライン時にも発生する可能性があります。
たとえば、利用可能な application-manager
アドオンは、以下を読み取るマネージドクラスターのラベルで表されます。
feature.open-cluster-management.io/addon-application-manager: available
アドオンおよびそれらのステータスに基づいて配置を作成する以下の例を参照してください。
以下の YAML コンテンツを追加して、
application-manager
を有効化したマネージドクラスターすべてを含む配置を作成できます。apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement1 namespace: ns1 spec: predicates: - requiredClusterSelector: labelSelector: matchExpressions: - key: feature.open-cluster-management.io/addon-application-manager operator: Exists
以下の YAML コンテンツを追加して、
application-manager
がavailable
のステータスで有効化されているすべてのマネージドクラスターを含む配置を作成できます。apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement2 namespace: ns1 spec: predicates: - requiredClusterSelector: labelSelector: matchLabels: "feature.open-cluster-management.io/addon-application-manager": "available"
以下の YAML コンテンツを追加して、
application-manager
が無効にされているマネージドクラスターすべてを含む配置を作成できます。apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement3 namespace: ns1 spec: predicates: - requiredClusterSelector: labelSelector: matchExpressions: - key: feature.open-cluster-management.io/addon-application-manager operator: DoesNotExist
1.14.5.5. 拡張可能なスケジューリング
配置リソースベースのスケジューリングでは、マネージドクラスターのスコアを計算するために、prioritizer が MananagedCluster
リソースで提供されるデフォルト値よりも多くのデータを必要とする場合があります。たとえば、モニターリングシステム経由で取得されるクラスターの CPU またはメモリー使用量データに基づいてクラスターをスケジュールします。
API AddOnPlacementScore
は、カスタムのスコアをもとにスケジューリングする拡張可能な方法をサポートします。
-
placement.yaml
ファイルにスコアを指定して、クラスターを選択できます。 -
スコアプロバイダーとして、サードパーティーのコントローラーをハブクラスターまたはマネージドクラスターのいずれかで実行して、
AddOnPlacementScore
のライフサイクルを維持し、スコアを更新することができます。
詳細は、open-cluster-management
リポジトリーの 配置拡張可能なスケジューリングの拡張機能 を参照してください。
1.14.6. テイントおよび容認 (Toleration) を使用したマネージドクラスターの配置
テイントおよび容認 (Toleration) を使用して、マネージドクラスターまたはマネージドクラスターセットの配置を制御できます。Taint と Toleration は、特定の配置でマネージドクラスターが選択されないようにする方法を提供します。この制御は、特定のマネージドクラスターが一部の配置に含まれないようにする場合に役立ちます。Taint をマネージドクラスターに、Toleration を配置に追加できます。Taint と Toleration が一致しない場合は、マネージドクラスターはその配置には選択されません。
1.14.6.1. マネージドクラスターへの Taint の追加
Taint はマネージドクラスターのプロパティーで指定され、配置がマネージドクラスターまたはマネージドクラスターのセットを除外できます。以下の例のようなコマンドを入力して、Taint をマネージドクラスターに追加できます。
kubectl taint ManagedCluster <managed_cluster_name> key=value:NoSelect
Taint の仕様には以下のフィールドが含まれます。
-
(必須) key: クラスターに適用される Taint キー。この値は、その配置に追加される基準を満たすように、マネージドクラスターの Toleration の値と一致させる必要があります。この値は確認できます。たとえば、この値は
bar
またはfoo.example.com/bar
です。 -
(オプション) Value: Taint キーのTaint値。この値は、その配置に追加される基準を満たすように、マネージドクラスターの Toleration の値と一致させる必要があります。たとえば、この値は
value
とすることができます。 (必須) Effect: Taint を許容しない配置における Taint の効果、または配置の Taint と Toleration が一致しないときに何が起こるか。effect の値は、以下のいずれかの値である必要があります。
-
NoSelect
: 配置は、この Taint を許容しない限り、クラスターを選択できません。Taint の設定前に配置でクラスターが選択された場合は、クラスターは配置の決定から削除されます。 -
NoSelectIfNew
: スケジューラーは、クラスターが新しい場合にそのクラスターを選択できません。プレイスメントは、Taint を許容し、すでにクラスター決定にそのクラスターがある場合にのみ、そのクラスターを選択することができます。
-
-
(必須)
TimeAdded
: Taint を追加した時間。この値は自動的に設定されます。
1.14.6.2. マネージドクラスターのステータスを反映させる組み込み Taint の特定
マネージドクラスターにアクセスできない場合には、クラスターを配置に追加しないでください。以下の Taint は、アクセスできないマネージドクラスターに自動的に追加されます。
cluster.open-cluster-management.io/unavailable
: この Taint は、ステータスがFalse
のManagedClusterConditionAvailable
の条件がある場合にマネージドクラスターに追加されます。Taint にはNoSelect
と同じ効果があり、空の値を指定すると、利用不可のクラスターがスケジュールされないようにできます。この Taint の例は、以下の内容のようになります。apiVersion: cluster.open-cluster-management.io/v1 kind: ManagedCluster metadata: name: cluster1 spec: hubAcceptsClient: true taints: - effect: NoSelect key: cluster.open-cluster-management.io/unavailable timeAdded: '2022-02-21T08:11:54Z'
cluster.open-cluster-management.io/unreachable
-ManagedClusterConditionAvailable
の条件のステータスがUnknown
であるか、または条件がない場合に、この Taint はマネージドクラスターに追加されます。この Taint にはNoSelect
と同じ効果があり、空の値を指定すると、到達不可のクラスターがスケジュールされないようにできます。この Taint の例は、以下の内容のようになります。apiVersion: cluster.open-cluster-management.io/v1 kind: ManagedCluster metadata: name: cluster1 spec: hubAcceptsClient: true taints: - effect: NoSelect key: cluster.open-cluster-management.io/unreachable timeAdded: '2022-02-21T08:11:06Z'
1.14.6.3. Toleration の配置への追加
Toleration は配置に適用され、配置の Toleration と Taint が同じでないマネージドクラスターを配置から除外できます。Toleration の仕様には以下のフィールドが含まれます。
- (任意) Key: キーは配置ができるように Taint キーに一致します。
- (任意) Value: toleration の値は、配置を許可する Toleration の Taint の値と一致する必要があります。
(任意) Operator: 演算子はキーと値の関係を表します。有効な演算子は
equal
とexists
です。デフォルト値はequal
です。Toleration は、キーが同じ場合、効果が同じ場合、さらび演算子が以下の値のいずれかである場合に、Taint にマッチします。-
equal
: Operator はequal
で、値は Taint および Toleration と同じになります。 -
exists
: 値のワイルドカード。これにより、配置は特定のカテゴリーのすべての Taint を許容できます。
-
-
(任意) Effect: 一致する Taint の効果。空のままにすると、すべての Taint の効果と一致します。指定可能な値は、
NoSelect
またはNoSelectIfNew
です。 -
(任意) TolerationSeconds: マネージドクラスターを新しい配置に移動する前に、Taint を許容する時間の長さ (秒単位) です。effect 値が
NoSelect
またはPreferNoSelect
でない場合は、このフィールドは無視されます。デフォルト値はnil
で、時間制限がないことを示します。TolerationSeconds
のカウント開始時刻は、クラスターのスケジュール時刻やTolerationSeconds
加算時刻の値ではなく、自動的に Taint のTimeAdded
の値として記載されます。
以下の例は、Taint が含まれるクラスターを許容する Toleration を設定する方法を示しています。
この例のマネージドクラスターの Taint:
apiVersion: cluster.open-cluster-management.io/v1 kind: ManagedCluster metadata: name: cluster1 spec: hubAcceptsClient: true taints: - effect: NoSelect key: gpu value: "true" timeAdded: '2022-02-21T08:11:06Z'
Taint を許容できる配置の Toleration
apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: placement1 namespace: default spec: tolerations: - key: gpu value: "true" operator: Equal
Toleration の定義例では、
key: gpu
とvalue: "true"
が一致するため、配置でcluster1
を選択できます。
注記: マネージドクラスターは、Taint の Toleration が含まれる配置に置かれる保証はありません。他の配置に同じ Toleration が含まれる場合には、マネージドクラスターはそれらの配置のいずれかに置かれる可能性があります。
1.14.6.4. 一時的な Toleration の指定
TolerationSeconds
の値は、Toleration が Taint を許容する期間を指定します。この一時的な Toleration は、マネージドクラスターがオフラインで、このクラスターにデプロイされているアプリケーションを、許容時間中に別のマネージドクラスターに転送できる場合に役立ちます。
たとえば、以下の Taint を持つマネージドクラスターに到達できなくなります。
apiVersion: cluster.open-cluster-management.io/v1 kind: ManagedCluster metadata: name: cluster1 spec: hubAcceptsClient: true taints: - effect: NoSelect key: cluster.open-cluster-management.io/unreachable timeAdded: '2022-02-21T08:11:06Z'
以下の例のように、TolerationSeconds
の値で配置を定義すると、ワークロードは 5 分後に利用可能な別のマネージドクラスターに転送されます。
apiVersion: cluster.open-cluster-management.io/v1alpha1 kind: Placement metadata: name: demo4 namespace: demo1 spec: tolerations: - key: cluster.open-cluster-management.io/unreachable operator: Exists tolerationSeconds: 300 ----
マネージドクラスターに到達できなくなると、アプリケーションが 5 分間別のマネージドクラスターに移動されます。