次の方法で共有

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

  • [アーティクル]

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

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

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

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

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

複数のクラスターでこれらの Kubernetes リソースを手動で作成、更新、追跡するのは手間がかかります。 Fleet では、Kubernetes リソースの大規模な管理を可能にする Kubernetes リソースの伝達が実現します。 Fleet を使用すると、ハブ クラスター内に Kubernetes リソースを作成し、Kubernetes カスタム リソース MemberCluster と ClusterResourcePlacement を使用して選択したメンバー クラスターに伝達できます。 Fleet では、オープンソースのクラウドネイティブ マルチクラスター ソリューションに基づいて、これらのカスタム リソースがサポートされています。 詳細については、アップストリームの Fleet ドキュメントを参照してください。

重要

Azure Kubernetes Fleet Manager のプレビュー機能は、セルフサービス、オプトイン ベースで利用できます。 プレビューは、"現状有姿のまま" および "利用可能な限度" で提供され、サービス レベル アグリーメントおよび限定保証から除外されるものとします。 Azure Kubernetes Fleet Manager のプレビューは、ベストエフォート ベースでカスタマー サポートによって部分的にカバーされます。 そのため、これらの機能は、運用環境での使用を意図していません。

リソース伝達ワークフロー

Kubernetes リソースをメンバー クラスターに反映する方法を示す図。

MemberCluster とは

クラスターがフリートに参加すると、対応する MemberCluster カスタム リソースがハブ クラスターに作成されます。 このカスタム リソースを使用して、リソース伝達でターゲット クラスターを選択できます。

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

  • fleet.azure.com/location
  • fleet.azure.com/resource-group
  • fleet.azure.com/subscription-id

詳細については、MemberCluster API のリファレンスを参照してください。

ClusterResourcePlacement とは

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

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

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

ClusterResourcePlacement オブジェクトでは ConfigMap を使用してオブジェクトをエンベロープに入れることができ、意図しない副作用が生じないようにして、メンバー クラスターに伝達できるようにします。 選択方法には次のようなものがあります。

  • グループ、バージョン、種類: 特定の種類のすべてのリソースを選択して配置します。
  • グループ、バージョン、種類、名前: 特定の種類の 1 つの特定のリソースを選択して配置します。
  • グループ、バージョン、種類、ラベル: 指定されたラベルに一致する特定の種類のすべてのリソースを選択して配置します。

詳細については、ClusterResourcePlacement API リファレンスに関するページを参照してください。

ClusterResourcePlacement を作成する際は、次の型のアフィニティを指定できます。

  • requiredDuringSchedulingIgnoredDuringExecution: この型のアフィニティはスケジュール設定時に必須です。これによって、クラスターはそのプロパティに基づいてフィルター処理されます。
  • preferredDuringSchedulingIgnoredDuringExecution: この型のアフィニティは、スケジュール設定時には、推奨されるに過ぎず、必須ではありません。これを使用すると、コストやリソースの可用性など、ユーザーが指定したプロパティに基づいて、クラスターに優先順位が付けられます。

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

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

PickAll 配置ポリシー

PickAll 配置ポリシーを使用すると、フリート内の (必要に応じて一連の条件を満たす) すべてのメンバー クラスターにワークロードをデプロイできます。

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

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

この単純なポリシーは、prod-deployment 名前空間とその中に含まれるすべてのリソースを受け取り、指定された environment ラベルを持つフリート内のすべてのメンバー クラスターにデプロイします。 すべてのクラスターを対象にする必要がある場合は、affinity 項目を完全に削除できます。

PickFixed 配置ポリシー

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

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

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

PickN 配置ポリシー

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

アフィニティと PickN

PickN 配置ポリシーと共にアフィニティを使用すると、ポッドのスケジュール設定でアフィニティを使用する場合と同様の動作になります。 必須と優先の両方のアフィニティを設定できます。 必須アフィニティを使用すると、指定されたそれらのアフィニティと一致しないクラスターには配置できません。優先アフィニティを使用すると、配置の決定を行う際に、有効なクラスター セットに順位を付けることができます。

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

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

詳細については、アップストリームのトポロジ分散制約の Fleet ドキュメントを参照してください。

戦略を更新する

Fleet では、ローリング更新戦略を使用して、複数のクラスター配置間で更新プログラムをどのようにロールアウトするかを制御します。

次の例は、既定の設定を使用してローリング更新戦略を構成する方法を示しています。

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

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

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

配置の状態

Fleet スケジューラは、配置の決定に関する詳細と状態を ClusterResourcePlacement オブジェクトに対し更新します。 この情報は、kubectl describe crp <name> コマンドを使って確認できます。 出力には次の情報が含まれています。

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

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

Name:         crp-1
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  placement.kubernetes-fleet.io/v1beta1
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 の更新) は、既存の配置で徐々にロールアウトされますが、ワークロードの再スケジュールはトリガーされません。

容認

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

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

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

詳細については、アップストリームの Fleet ドキュメントを参照してください。

フリート リソース クラスターの Kubernetes API にアクセスする

ハブ クラスターを有効にして Azure Kubernetes Fleet Manager リソースを作成した場合は、それを使用して Kubernetes オブジェクトの伝達などのシナリオを一元管理できます。 Fleet リソース クラスターの Kubernetes API にアクセスするには、Azure Kubernetes Fleet Manager を使用して Fleet リソース クラスターの Kubernetes API にアクセスする方法に関するページの手順に従います。

次のステップ

ハブ クラスターからメンバー クラスターへの Kubernetes リソース伝達を設定します。