すべてのプロダクト
Search
ドキュメントセンター

Container Service for Kubernetes:動的な分散とデスケジューリング

最終更新日:Apr 02, 2025

ACK One Fleet は、PropagationPolicy を使用して、関連付けられたクラスター全体で、Deployment、StatefulSet、Job などのワークロード レプリカを、使用可能なリソースに基づいて動的に分散できます。 デフォルトでは、ACK One Fleet インスタンスはデスケジューリングを有効にします。 クラスター リソースの可用性は時間とともに変動するため、関連付けられたクラスター内の一部のレプリカはスケジュールできなくなる可能性があります。 Fleet インスタンスは、スケジュールできないレプリカを 2 分ごとに自動的にチェックし、30 秒以上この状態が続くとデスケジューリングをトリガーします。

前提条件

手順

ステップ 1:Fleet でアプリケーションを作成する

  1. web-demo.yaml という名前のファイルを作成し、以下の内容を追加します。

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: web-demo
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: web-demo
      template:
        metadata:
          labels:
            app: web-demo
        spec:
          containers:
          - name: nginx
            image: registry-cn-hangzhou.ack.aliyuncs.com/acs/web-demo:0.5.0
            ports:
            - containerPort: 80
  2. 次のコマンドを実行して、アプリケーションをデプロイします。

    kubectl apply -f web-demo.yaml

ステップ 2:分散ポリシーを作成する

  1. 関連付けられたクラスター内のすべてのノードで使用可能なリソースに応じてレプリカの割り当て比率を自動的に調整する、動的な重みベースの 分散ポリシー を作成します。

    apiVersion: policy.one.alibabacloud.com/v1alpha1
    kind: PropagationPolicy
    metadata:
      name: web-demo
    spec:
      resourceSelectors:
      - apiVersion: apps/v1
        kind: Deployment
        name: web-demo
      placement:
        clusterAffinity:
          clusterNames:
          - ${cluster1-id} # クラスター ID。
          - ${cluster2-id} 
        replicaScheduling:
          replicaSchedulingType: Divided
          replicaDivisionPreference: Weighted
          weightPreference:
            dynamicWeight: AvailableReplicas
  2. 次のコマンドを実行して、アプリケーションの分散ステータスを確認します。

    kubectl amc get deploy web-demo -M

    予想される出力 (結果は、関連付けられたクラスターの使用可能なリソース比率によって異なる場合があります):

    NAME       CLUSTER      READY   UP-TO-DATE   AVAILABLE   AGE   ADOPTION
    web-demo   cxxxxxxxx1   2/2     2            2           11s   Y
    web-demo   cxxxxxxxx2   3/3     3            3           11s   Y

ステップ 3:デスケジューリング機能を確認する

ノードを汚染し、既存のデプロイメントを再起動することで、リソース不足のためにワークロードが Pending 状態になるシナリオをシミュレートできます。

  1. 次のコマンドを実行して、すべてのノードを NoSchedule で汚染します。

    kubectl --kubeconfig=<cluster1.config> taint nodes foo=bar:NoSchedule --all=true
  2. 次のコマンドを実行して、既存のワークロードを再起動します。 ワークロードは失敗することが予想されます。

    kubectl --kubeconfig=<cluster1.config> rollout restart deploy web-demo
  3. 約 3 分待機した後、次のコマンドを実行してスケジューリング結果を確認します。

    kubectl amc get deploy web-demo -M

    予想される出力:

    NAME       CLUSTER      READY   UP-TO-DATE   AVAILABLE   AGE   ADOPTION
    web-demo   cxxxxxxxx2   5/5     5            5           11s   Y

    予想される出力は、Cluster1 内のワークロードのレプリカが Cluster2 に再スケジュールされたことを示しています。