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

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

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

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

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

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

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

Fleet Manager では、 KubeFleet ドキュメント サイトで詳細を確認できるオープンソースの KubeFleet ソリューションに基づいて、これらのカスタム リソースがサポートされています。

ClusterResourcePlacement の概要

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

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

• 伝達するリソースを選択します。 これらには、 Kubernetes Group Version Kind (GVK) 参照を使用して定義されたクラスター スコープの Kubernetes リソース、または名前空間とそのすべてのリソースを伝達する名前空間を指定できます。
• メンバー クラスターを選択する配置ポリシーを指定します。 これらのポリシーでは、名前によってクラスターを明示的に選択したり、クラスターのラベルとプロパティに基づいてクラスターを動的に選択したりできます。
• 選択した Kubernetes リソースの更新プログラムを複数のターゲット クラスターに安全にロールアウトするためのロールアウト戦略を指定する。
• 各ターゲット クラスターの伝達の進行状況を表示します。

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

リソースのカプセル化

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

配置の種類

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

詳細については、 トポロジの分散制約に関する KubeFleet のドキュメントを参照してください。

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

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

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

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

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

ラベル

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

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

プロパティ

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

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

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

選択の一致条件の指定

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

• Name: プロパティの名前。この記事の「プロパティ」に記載されているプロパティのいずれかです。

• Operator: 制約値または目的の値と、クラスターで観察された値の間にある条件を表すために使う演算子です。 現在サポートされている演算子は次のとおりです。

  • Gt (より大きい): 指定されたプロパティのクラスターの監視対象の値は、リソースの配置に対して選択する前に、条件の値より大きくする必要があります。
  • Ge (以上): 指定されたプロパティのクラスターの監視対象の値は、リソースの配置に対して選択する前に、条件の値以上にする必要があります。
  • Lt (より小さい): 指定されたプロパティのクラスターの監視対象の値は、リソースの配置に対して選択する前に、条件の値より小さくする必要があります。
  • Le (以下): 指定されたプロパティのクラスターの監視対象の値は、リソースの配置に対して選択する前に、条件の値以下にする必要があります。
  • Eq (等しい): 指定されたプロパティのクラスターの監視対象の値は、リソースの配置に対して選択する前に、条件の値と等しくする必要があります。
  • Ne (等しくない): 指定されたプロパティのクラスターの監視対象の値は、リソースの配置に対して選択する前に、条件の値と等しくなくする必要があります。

  演算子 Gt、Ge、Lt、Le、Eq、または Ne を使用する場合、条件内の値の一覧には、正確に 1 つの値がある必要があります。

• Values: プロパティの使用可能な値の一覧です。

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

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 つのクラスターのフリートがあるとします。

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

昇順

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

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

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

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

リソース スナップショット

Fleet Manager は、最近使用された 10 個の配置スケジュール ポリシーと、配置が選択したリソース バージョンの履歴を保持します。

これらのスナップショットは、 段階的なロールアウト戦略 と共に使用して、デプロイされたバージョンを制御できます。

詳細については、 スナップショットに関するドキュメントを参照してください。

容認の使用

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

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

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

詳細については、 容認に関するドキュメントを参照してください。

ロールアウト戦略の構成

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

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

次の例は、ClusterResourcePlacement 名前空間と test ConfigMap を、test-1 を使用して 2 つのメンバー クラスターにデプロイした PickN を示しています。 配置が正常に完了し、リソースが 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 ポリシーなど) を満たしている場合は、配置がトリガーされる可能性があります。
  • 配置のあるクラスターはフリートから削除されます。 スケジューラは、ポリシーに応じて、既存の配置に影響を与えることなく、影響を受けるすべてのワークロードを残りのクラスターに配置しようと試みます。

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

次のステップ

• クラスター リソース配置を使用して、複数のクラスターにワークロードをデプロイします。
• メンバー クラスターのプロパティに基づくインテリジェントなクラスター間 Kubernetes リソースの配置。
• クラスター リソースの配置に対する削除と中断の制御。
• クラスター リソース配置のロールアウト戦略を定義する。
• クラスター リソースの配置に関する FAQ。