ハブクラスターからメンバークラスターへの Kubernetes リソース配置

[アーティクル]
11/22/2024

この記事では、Azure Kubernetes Fleet Manager (Kubernetes Fleet) を使用した、ハブクラスターからメンバークラスターへの Kubernetes リソース配置の概念について説明します。

多くの場合、プラットフォーム管理者は、次の例のようなさまざまな理由で Kubernetes リソースを複数のクラスターにデプロイする必要があります。

複数のクラスターでロールとロールバインドを使用してアクセス制御を管理する。
すべてのクラスター上に必要な、Prometheus や Flux などのインフラストラクチャアプリケーションを実行する。

多くの場合、アプリケーション開発者は、次の例のようなさまざまな理由で Kubernetes リソースを複数のクラスターにデプロイする必要があります。

ビデオサービスアプリケーションを異なるリージョンの複数のクラスターにデプロイし、待ち時間の短い視聴エクスペリエンスを実現する。
ショッピングカートアプリケーションをペアになっている 2 つのリージョンにデプロイし、1 つのリージョンの停止中に顧客が買い物を続けられるようにする。
安価なスポットノードプールを使用できるクラスターにバッチコンピューティングアプリケーションをデプロイする。

複数のクラスターでこれらの Kubernetes リソースを手動で作成、更新、追跡するのは手間がかかります。 Fleet では、Kubernetes リソースの大規模な管理を可能にする Kubernetes リソースの伝達が実現します。 Kubernetes Fleet を使用すると、ハブクラスター内に Kubernetes リソースを作成し、Kubernetes カスタムリソース MemberCluster と ClusterResourcePlacement を使用して選択したメンバークラスターに伝達できます。

Kubernetes Fleet は、オープンソースのクラウドネイティブソリューションに基づいてこれらのカスタムリソースをサポートします。詳細については、オープンソース Fleet のドキュメントを参照してください。

ClusterResourcePlacement の概要

ClusterResourcePlacement オブジェクトは、フリートハブクラスターからメンバークラスターにクラスタースコープオブジェクトの特定のセットを配置する方法をフリートスケジューラに指示するために使用されます。 Deployments、StatefulSets、DaemonSets、ConfigMaps、Secrets、PersistentVolumeClaims などの名前空間スコープのオブジェクトは、それぞれが含む名前空間が選択されたときに含まれます。

ClusterResourcePlacement を使用すると、以下のことができます。

メンバークラスターに伝達するクラスタースコープの Kubernetes リソースを選択する。
手動で、または自動的に、ターゲットクラスターとしてメンバークラスターを選択する配置ポリシーを指定する。
選択した Kubernetes リソースの更新プログラムを複数のターゲットクラスターに安全にロールアウトするためのロールアウト戦略を指定する。
各ターゲットクラスターへの伝達の進行状況を表示する。

次の図で、例を示します。

リソースのカプセル化

ClusterResourcePlacement は、ConfigMap を使用して特定の Kubernetes リソースの種類をエンベロープすることをサポートしているため、ハブクラスターに予期しない副作用が生じることなく、ハブクラスターでステージングできます。リソースの種類の一覧とこの機能のしくみについては、エンベロープオブジェクトのドキュメントを参照してください

配置の種類

Kubernetes リソースの伝播先とするクラスターの数を制御する場合は、次の配置の種類を使用できます。

PickFixed を使用すると、リソースを名前別のメンバークラスターの特定の一覧に配置できます。
PickAll を使用すると、リソースをすべてのメンバークラスター、または条件を満たすすべてのメンバークラスターに配置できます。このポリシーは、クラスターの監視やレポートアプリケーションなどのインフラストラクチャワークロードを配置する場合に役立ちます。
PickN は最も柔軟な配置オプションであり、アフィニティまたはトポロジ分散制約に基づいてクラスターを選択できます。また、可用性を確保するために、複数の適切なクラスターにワークロードを分散する必要がある場合に役立ちます。

PickFixed 配置の種類

ワークロードを既知のメンバークラスターセットにデプロイする場合は、PickFixed 配置ポリシーを使用して、名前でクラスターを選択できます。

この配置の種類で有効なポリシーオプションは clusterNames のみです。

次の例は、test-deployment 名前空間をメンバークラスター cluster1 と cluster2 にデプロイする方法を示しています。

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-fixed
spec:
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: test-deployment
      version: v1

PickAll 配置の種類

PickAll 配置の種類を使用すると、ワークロードのデプロイ先をフリート内のすべてのメンバークラスターにしたり、設定した条件に一致するクラスターのサブセットにしたりすることができます。

この配置の種類を作成する場合、次のクラスターアフィニティの種類を指定できます。

requiredDuringSchedulingIgnoredDuringExecution: このポリシーはスケジュール中に必須であるため、指定された条件に基づいてクラスターはフィルター処理されます。

次の例は、prod-deployment 名前空間とそのすべてのオブジェクトを、environment: production のラベルが付いたすべてのクラスターにデプロイする方法を示しています。

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pickall
spec:
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                        environment: production
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1

PickN 配置の種類

PickN 配置の種類は最も柔軟なオプションであり、アフィニティとトポロジ分散制約の両方に基づいて、構成可能な数のクラスターにリソースを配置できます。

この配置の種類を作成する場合、次のクラスターアフィニティの種類を指定できます。

requiredDuringSchedulingIgnoredDuringExecution: このポリシーはスケジュール中に必須であるため、指定された条件に基づいてクラスターはフィルター処理されます。
preferredDuringSchedulingIgnoredDuringExecution: このポリシーは優先されますが、スケジュール中に必須ではないため、指定した条件に基づいてクラスターにランク付けされます。

必須と優先の両方のアフィニティを設定できます。必須のアフィニティを使用すると、一致しないクラスターへの配置を防ぎ、優先アフィニティを使用すると、有効なクラスターに順序を付けることができます。

アフィニティと `PickN`

PickN 配置ポリシーと共にアフィニティを使用すると、ポッドのスケジュール設定でアフィニティを使用する場合と同様の動作になります。

次の例では、ワークロードを 3 つのクラスターにデプロイする方法を示します。 critical-allowed: "true" ラベルを持つクラスターのみが有効な配置ターゲットであり、ラベル critical-level: 1 を持つクラスターが優先されます。

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pickn-01
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/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pickn-02
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickN
    topologySpreadConstraints:
    - maxSkew: 2
      topologyKey: region
      whenUnsatisfiable: DoNotSchedule
    - maxSkew: 2
      topologyKey: updateDay
      whenUnsatisfiable: ScheduleAnyway

詳細については、オープンソース Fleet のドキュメントのトポロジ分散制約に関する記事を参照してください。

配置ポリシーのオプション

この表は、各配置の種類で使用できるスケジュールポリシーフィールドをまとめたものです。

ポリシーフィールド	PickFixed	PickAll	PickN
`placementType`	✅	✅	✅
`affinity`	❌	✅	✅
`clusterNames`	✅	❌	❌
`numberOfClusters`	❌	❌	✅
`topologySpreadConstraints`	❌	❌	✅

ラベルとプロパティに基づいたクラスターの選択

クラスターを選択するために使用できるラベルとプロパティ

PickN と PickAll の配置の種類を使用する場合、ポリシーの一部として次のラベルとプロパティを使用できます。

Labels

次のラベルはすべてのメンバークラスターに自動的に追加され、リソース配置ポリシーでのターゲットクラスターの選択に使用できます。

Label	説明
fleet.azure.com/location	クラスターの Azure リージョン (westus)
fleet.azure.com/resource-group	クラスターの Azure リソースグループ (rg_prodapps_01)
fleet.azure.com/subscription-id	クラスターが存在する Azure サブスクリプション識別子。 UUID/GUID 形式です。

クラスターに適用するカスタムラベルを使用することもできます。

プロパティ

次のプロパティは、配置ポリシーの一部として使用できます。

CPU とメモリのプロパティは、Kubernetes リソースユニットとして表されます。

コストプロパティは、クラスター内のノードに使用される Azure コンピューティングの 1 時間あたりのコストを米ドルで表す 10 進数です。コストは Azure の公開価格に基づいています。

プロパティ名	説明
kubernetes-fleet.io/node-count	メンバークラスター上で使用できるノード。
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 あたりのメモリコスト。

選択の一致条件の指定

ポリシー条件でクラスターのプロパティを使用する場合は、次を指定します。

Name: プロパティの名前。この記事の「プロパティ」に記載されているプロパティのいずれかです。
Operator: 制約値または目的の値と、クラスターで観察された値の間にある条件を表すために使う演算子です。現在サポートされている演算子は次のとおりです。
- Gt (より大きい): 指定されたプロパティのクラスターの監視対象の値は、リソースの配置に対して選択する前に、条件の値より大きくする必要があります。
- Ge (以上): 指定されたプロパティのクラスターの監視対象の値は、リソースの配置に対して選択する前に、条件の値以上にする必要があります。
- Lt (より小さい): 指定されたプロパティのクラスターの監視対象の値は、リソースの配置に対して選択する前に、条件の値より小さくする必要があります。
- Le (以下): 指定されたプロパティのクラスターの監視対象の値は、リソースの配置に対して選択する前に、条件の値以下にする必要があります。
- Eq (等しい): 指定されたプロパティのクラスターの監視対象の値は、リソースの配置に対して選択する前に、条件の値と等しくする必要があります。
- Ne (等しくない): 指定されたプロパティのクラスターの監視対象の値は、リソースの配置に対して選択する前に、条件の値と等しくなくする必要があります。
演算子 Gt、Ge、Lt、Le、Eq、または Ne を使用する場合、条件内の値の一覧には、正確に 1 つの値がある必要があります。
Values: プロパティの使用可能な値の一覧です。

Fleet は、条件で指定されたプロパティに基づいて各クラスターを評価します。 requiredDuringSchedulingIgnoredDuringExecution に一覧されている条件を満たさない場合、このメンバークラスターはリソースの配置から除外されます。

Note

メンバークラスターに条件で表されたプロパティがない場合、その条件は自動的に失敗します。

5 つ以上のノードを持つクラスターのみを選択する配置ポリシーの例を次に示します。

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  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 順序を使用すると、監視対象の値が高いメンバークラスターが優先されます。

降順

並べ替え順序が [降順] の場合、比例重みは次の式を使用して計算されます。

((Observed Value - Minimum observed value) / (Maximum observed value - Minimum observed value)) * Weight

たとえば、使用可能な CPU 容量のプロパティに基づいてクラスターを降順にランク付けし、次の使用可能な CPU を持つ 3 つのクラスターのフリートがあるとします。

クラスター	使用可能な CPU 容量
`cluster-a`	100
`cluster-b`	20
`cluster-c`	10

この場合、ソーターは次の重みを計算します。

クラスター	使用可能な CPU 容量	計算	体重
`cluster-a`	100	(100 - 10) / (100 - 10)	100%
`cluster-b`	20	(20 - 10) / (100 - 10)	11.11%
`cluster-c`	10	(10 - 10) / (100 - 10)	0%

昇順

並べ替え順序が [照準] の場合、比例重みは次の式を使用して計算されます。

(1 - ((Observed Value - Minimum observed value) / (Maximum observed value - Minimum observed value))) * Weight

たとえば、per-CPU-core-cost に基づいてクラスターを昇順にランク付けし、次の CPU コアコストを持つ 3 つのクラスターのフリートがあるとします。

クラスター	CPU あたりのコアコスト
`cluster-a`	1
`cluster-b`	0.2
`cluster-c`	0.1

この場合、ソーターは次の重みを計算します。

クラスター	CPU あたりのコアコスト	計算	体重
`cluster-a`	1	1 - ((1 - 0.1) / (1 - 0.1))	0%
`cluster-b`	0.2	1 - ((0.2 - 0.1) / (1 - 0.1))	88.89%
`cluster-c`	0.1	1 - (0.1 - 0.1) / (1 - 0.1)	100%

容認の使用

ClusterResourcePlacement オブジェクトは、ClusterResourcePlacement オブジェクトに適用される容認の指定をサポートします。各容認オブジェクトは、次のフィールドで構成されます。

key: 容認の鍵。
value: 容認の値。
effect: NoSchedule など、容認の効果。
operator: Exists や Equalなど、容認の演算子。

各容認は、ClusterResourcePlacement に適用される 1 つ以上の特定のテイントを容認するために使用されます。 MemberCluster 上のすべてのテイントが許容されると、スケジューラはリソースをクラスターに伝達できます。 ClusterResourcePlacement オブジェクトの作成後は、その容認を更新または削除することはできません。

詳細については、容認に関するオープンソース Fleet のドキュメントを参照してください。

ロールアウト戦略の構成

Fleet は、クラスター全体に更新プログラムをロールアウトする方法を制御するために、ローリング更新戦略を使用しています。

次の例のフリートスケジューラでは、更新プログラムを各クラスターに順番にロールアウトし、クラスター間で unavailablePeriodSeconds 以上は待機します。すべてのリソースがクラスターに正しく適用された場合、ロールアウトの状態は成功と見なされます。ロールアウトの状態チェックは子リソースに連鎖しません。そのため、たとえば、デプロイによって作成されたポッドが準備完了になっているかどうかは確認されません。

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    ...
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

詳細については、ロールアウト戦略に関するオープンソース Fleet のドキュメントを参照してください。

配置の状態を確認する

Fleet スケジューラは、配置の決定に関する詳細と状態を ClusterResourcePlacement オブジェクトに対し更新します。出力には次の情報が含まれています。

配置に現在適用されている条件 (配置が正常に完了したかどうかなど)。
各メンバークラスターについての配置状態セクション。ここには、そのクラスターへのデプロイの状態が表示されます。

次の例は、test 名前空間と test-1 ConfigMap を、PickN を使用して 2 つのメンバークラスターにデプロイした ClusterResourcePlacement を示しています。配置が正常に完了し、リソースが aks-member-1 と aks-member-2 のクラスターに配置されました。

この情報は、kubectl describe crp <name> コマンドを使って確認できます。

kubectl describe crp 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

配置変更トリガー

Fleet スケジューラでは、既存のワークロード配置の安定性に優先度を付けます。このように優先度付けすると、ワークロードの削除と再スケジュールの原因となる変更の数を制限できます。次のシナリオでは、配置の変更がトリガーされる可能性があります。

ClusterResourcePlacement オブジェクトの配置ポリシーが変更されると、ワークロードの削除と再スケジュールがトリガーされる可能性があります。
- スケールアウト操作 (numberOfClusters を増加し、その他は変更なし) の場合、ワークロードは新しいクラスターにのみ配置され、既存の配置には影響がありません。
クラスターの変更 (次を含む):
- 新しいクラスターが対象になり、その新しいクラスターが配置ポリシー (PickAll ポリシーなど) を満たしている場合は、配置がトリガーされる可能性があります。
- 配置のあるクラスターはフリートから削除されます。スケジューラは、ポリシーに応じて、既存の配置に影響を与えることなく、影響を受けるすべてのワークロードを残りのクラスターに配置しようと試みます。

リソースのみの変更 (リソースの更新または ClusterResourcePlacement オブジェクト内での ResourceSelector の更新) は、既存の配置で徐々にロールアウトされますが、ワークロードの再スケジュールはトリガーされません。

次の方法で共有

ハブクラスターからメンバークラスターへの Kubernetes リソース配置

ClusterResourcePlacement の概要

リソースのカプセル化

配置の種類

PickFixed 配置の種類

PickAll 配置の種類

PickN 配置の種類

アフィニティと `PickN`

トポロジ分散制約と `PickN`

配置ポリシーのオプション

ラベルとプロパティに基づいたクラスターの選択

クラスターを選択するために使用できるラベルとプロパティ

Labels

プロパティ

選択の一致条件の指定

プロパティのランク付けのしくみ

降順

昇順

容認の使用

ロールアウト戦略の構成

配置の状態を確認する

配置変更トリガー

次のステップ

その他のリソース

次の方法で共有

ハブ クラスターからメンバー クラスターへの Kubernetes リソース配置

ClusterResourcePlacement の概要

リソースのカプセル化

配置の種類

PickFixed 配置の種類

PickAll 配置の種類

PickN 配置の種類

アフィニティと PickN

トポロジ分散制約と PickN

配置ポリシーのオプション

ラベルとプロパティに基づいたクラスターの選択

クラスターを選択するために使用できるラベルとプロパティ

Labels

プロパティ

選択の一致条件の指定

プロパティのランク付けのしくみ

降順

昇順

容認の使用

ロールアウト戦略の構成

配置の状態を確認する

配置変更トリガー

次のステップ

その他のリソース

ハブクラスターからメンバークラスターへの Kubernetes リソース配置

アフィニティと `PickN`

トポロジ分散制約と `PickN`