Container Service for Kubernetes:弾性リソースの優先度スケジューリングの設定

spec フィールド

units フィールド

elastic リソースタイプは非推奨となっています。代わりに、podLabels に k8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true" を設定してオートスケーリングノードプールを使用してください。

acs タイプは、デフォルトで alibabacloud.com/compute-class: default および alibabacloud.com/compute-class: general-purpose ラベルを Pod に追加します。podLabels で異なる値を指定することで上書きできます。podAnnotations で alpha.alibabacloud.com/compute-qos-strategy が指定されている場合、alibabacloud.com/compute-class: default ラベルは追加されません。

acs および eci タイプは、デフォルトで仮想ノードの Taint に対する Toleration を追加します。これらの Toleration は内部的に追加されるため、Pod の spec には表示されず、追加の Toleration 設定なしで Pod を仮想ノードにスケジューリングできます。

ユニットの podLabels に k8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true" が含まれている場合、または Pod 数が max を下回っている場合、スケジューラーは条件が満たされるまで Pod を現在のユニットに保持します。待機時間は whenTryNextUnits で設定します。k8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true" ラベルは Pod に適用されず、Pod 数のカウントには使用されません。

高度な設定フィールド

whenTryNextUnits ポリシー

timeout は、policy が TimeoutOrExceedMax の場合にのみ適用されます。デフォルト: 15 分。ACS ユニットではサポートされていません (max によってのみ制限されます)。

あるノードプールを別のノードプールより優先する

目標： Deployment を 2 つのノードプールにデプロイします。プール A を最初に使用し、プール B をオーバーフロー先とします。スケールイン時には、プール B の Pod を最初に削除します。

この例では、ノード cn-beijing.10.0.3.137 および cn-beijing.10.0.3.138 がプール A に属し、cn-beijing.10.0.6.47 および cn-beijing.10.0.6.46 がプール B に属します。すべてのノードは 2 vCPU と 4 GB のメモリを持ちます。

1. ノードプールのスケジューリング順序を設定する ResourcePolicy を作成します。nodepool-id の値は、[ノード管理 > ノードプール] ページ (ノードプールの作成と管理) の実際のノードプール ID に置き換えます。

   apiVersion: scheduling.alibabacloud.com/v1alpha1
   kind: ResourcePolicy
   metadata:
     name: nginx
     namespace: default
   spec:
     selector:
       app: nginx # 以下の Deployment の Pod ラベルと一致する必要があります
     strategy: prefer
     units:
     - resource: ecs
       nodeSelector:
         alibabacloud.com/nodepool-id: np7ec79f2235954e879de07b780058****
     - resource: ecs
       nodeSelector:
         alibabacloud.com/nodepool-id: npab2df797738644e3a7b7cbf532bb****

2. Deployment を作成します。ポッドラベル app: nginx は、ResourcePolicy の selector と一致する必要があります。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx
     labels:
       app: nginx
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         name: nginx
         labels:
           app: nginx # ResourcePolicy の selector と一致する必要があります
       spec:
         containers:
         - name: nginx
           image: nginx
           resources:
             limits:
               cpu: 2
             requests:
               cpu: 2

3. Deployment を適用し、Pod の配置を確認します。

   1. YAML ファイルを適用します。

      kubectl apply -f nginx.yaml

      期待される出力：

      deployment.apps/nginx created

   2. Pod がどのノードにスケジューリングされているかを確認します。

      kubectl get pods -o wide

      期待される出力：

      NAME                    READY   STATUS    RESTARTS   AGE   IP               NODE                    NOMINATED NODE   READINESS GATES
      nginx-9cdf7bbf9-b****   1/1     Running   0          17s   172.29.112.216   cn-beijing.10.0.3.137   <none>           <none>
      nginx-9cdf7bbf9-k****   1/1     Running   0          17s   172.29.113.24    cn-beijing.10.0.3.138   <none>           <none>

      両方の Pod は予想通りプール A のノードに配置されています。

4. 4 つのレプリカにスケールアウトし、プール B へのオーバーフローを確認します。

   1. Deployment をスケールします。

      kubectl scale deployment nginx --replicas 4

   2. Pod の配置を確認します。

      kubectl get pods -o wide

      期待される出力：

      NAME                    READY   STATUS    RESTARTS   AGE    IP               NODE                    NOMINATED NODE   READINESS GATES
      nginx-9cdf7bbf9-b****   1/1     Running   0          101s   172.29.112.216   cn-beijing.10.0.3.137   <none>           <none>
      nginx-9cdf7bbf9-k****   1/1     Running   0          101s   172.29.113.24    cn-beijing.10.0.3.138   <none>           <none>
      nginx-9cdf7bbf9-m****   1/1     Running   0          18s    172.29.113.156   cn-beijing.10.0.6.47    <none>           <none>
      nginx-9cdf7bbf9-x****   1/1     Running   0          18s    172.29.113.89    cn-beijing.10.0.6.46    <none>           <none>

      プール A が容量上限に達したため、2 つの新しい Pod はプール B のノードにオーバーフローしています。

5. 2 つのレプリカにスケールインし、プール B の Pod が最初に削除されることを確認します。

   1. Deployment をスケールします。

      kubectl scale deployment nginx --replicas 2

   2. Pod の状態を確認します。

      kubectl get pods -o wide

      期待される出力：

      NAME                    READY   STATUS        RESTARTS   AGE     IP               NODE                    NOMINATED NODE   READINESS GATES
      nginx-9cdf7bbf9-b****   1/1     Running       0          2m41s   172.29.112.216   cn-beijing.10.0.3.137   <none>           <none>
      nginx-9cdf7bbf9-k****   1/1     Running       0          2m41s   172.29.113.24    cn-beijing.10.0.3.138   <none>           <none>
      nginx-9cdf7bbf9-m****   0/1     Terminating   0          78s     172.29.113.156   cn-beijing.10.0.6.47    <none>           <none>
      nginx-9cdf7bbf9-x****   0/1     Terminating   0          78s     172.29.113.89    cn-beijing.10.0.6.46    <none>           <none>

      プール B の Pod が最初に削除されています。これはスケジューリング順序の逆順です。

サブスクリプション ECS を最初に使用し、次に従量課金 ECS、最後に ECI にフォールバックする

目標： サブスクリプション ECS の容量をすべて使用し、次に従量課金 ECS、最後に ECI を使用することでコストを最小化します。スケールイン時には、逆の順序で Pod を削除します。ECI を最初に、次に従量課金 ECS、最後にサブスクリプション ECS を削除します。

この例では、すべてのノードが 2 vCPU と 4 GB のメモリを持ちます。

1. 課金タイプを示すラベルをノードに付けます。ノードプールを使用している場合は、代わりにノードプールレベルでラベルを設定してください。

   kubectl label node cn-beijing.10.0.3.137 paidtype=subscription
   kubectl label node cn-beijing.10.0.3.138 paidtype=subscription
   kubectl label node cn-beijing.10.0.6.46 paidtype=pay-as-you-go
   kubectl label node cn-beijing.10.0.6.47 paidtype=pay-as-you-go

2. 課金タイプでユニットを順序付ける ResourcePolicy を作成します。

   apiVersion: scheduling.alibabacloud.com/v1alpha1
   kind: ResourcePolicy
   metadata:
     name: nginx
     namespace: default
   spec:
     selector:
       app: nginx # 以下の Deployment の Pod ラベルと一致する必要があります
     strategy: prefer
     units:
     - resource: ecs
       nodeSelector:
         paidtype: subscription
     - resource: ecs
       nodeSelector:
         paidtype: pay-as-you-go
     - resource: eci

3. 2 つのレプリカを持つ Deployment を作成します。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx
     labels:
       app: nginx
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         name: nginx
         labels:
           app: nginx # ResourcePolicy の selector と一致する必要があります
       spec:
         containers:
         - name: nginx
           image: nginx
           resources:
             limits:
               cpu: 2
             requests:
               cpu: 2

4. 適用し、サブスクリプションノードへの初期配置を確認します。

   1. YAML ファイルを適用します。

      kubectl apply -f nginx.yaml

   2. Pod の配置を確認します。

      kubectl get pods -o wide

      期待される出力：

      NAME                    READY   STATUS    RESTARTS   AGE   IP               NODE                    NOMINATED NODE   READINESS GATES
      nginx-9cdf7bbf9-b****   1/1     Running   0          66s   172.29.112.215   cn-beijing.10.0.3.137   <none>           <none>
      nginx-9cdf7bbf9-r****   1/1     Running   0          66s   172.29.113.23    cn-beijing.10.0.3.138   <none>           <none>

      両方の Pod はサブスクリプションノードに配置されています。

5. スケールアウトして、従量課金 ECS、次に ECI へのオーバーフローを確認します。

   1. 4 つのレプリカにスケールし、Pod の配置を確認します。

      kubectl scale deployment nginx --replicas 4

      kubectl get pods -o wide

      期待される出力：

      NAME                    READY   STATUS    RESTARTS   AGE     IP               NODE                    NOMINATED NODE   READINESS GATES
      nginx-9cdf7bbf9-4****   1/1     Running   0          16s     172.29.113.155   cn-beijing.10.0.6.47    <none>           <none>
      nginx-9cdf7bbf9-b****   1/1     Running   0          3m48s   172.29.112.215   cn-beijing.10.0.3.137   <none>           <none>
      nginx-9cdf7bbf9-f****   1/1     Running   0          16s     172.29.113.88    cn-beijing.10.0.6.46    <none>           <none>
      nginx-9cdf7bbf9-r****   1/1     Running   0          3m48s   172.29.113.23    cn-beijing.10.0.3.138   <none>           <none>

      オーバーフローした Pod は従量課金ノードにスケジューリングされています。

   2. 6 つのレプリカにスケールし、Pod の配置を確認します。

      kubectl scale deployment nginx --replicas 6

      kubectl get pods -o wide

      期待される出力：

      NAME                    READY   STATUS    RESTARTS   AGE     IP               NODE                           NOMINATED NODE   READINESS GATES
      nginx-9cdf7bbf9-4****   1/1     Running   0          3m10s   172.29.113.155   cn-beijing.10.0.6.47           <none>           <none>
      nginx-9cdf7bbf9-b****   1/1     Running   0          6m42s   172.29.112.215   cn-beijing.10.0.3.137          <none>           <none>
      nginx-9cdf7bbf9-f****   1/1     Running   0          3m10s   172.29.113.88    cn-beijing.10.0.6.46           <none>           <none>
      nginx-9cdf7bbf9-r****   1/1     Running   0          6m42s   172.29.113.23    cn-beijing.10.0.3.138          <none>           <none>
      nginx-9cdf7bbf9-s****   1/1     Running   0          36s     10.0.6.68        virtual-kubelet-cn-beijing-j   <none>           <none>
      nginx-9cdf7bbf9-v****   1/1     Running   0          36s     10.0.6.67        virtual-kubelet-cn-beijing-j   <none>           <none>

      すべての ECS 容量が使い果たされたため、残りの Pod は ECI (virtual-kubelet ノード) にスケジューリングされています。

6. スケールインして、逆順での削除を確認します。

   1. 4 つのレプリカにスケールします。ECI Pod が最初に削除されます。

      kubectl scale deployment nginx --replicas 4

      kubectl get pods -o wide

      期待される出力：

      NAME                    READY   STATUS        RESTARTS   AGE     IP               NODE                           NOMINATED NODE   READINESS GATES
      nginx-9cdf7bbf9-4****   1/1     Running       0          4m59s   172.29.113.155   cn-beijing.10.0.6.47           <none>           <none>
      nginx-9cdf7bbf9-b****   1/1     Running       0          8m31s   172.29.112.215   cn-beijing.10.0.3.137          <none>           <none>
      nginx-9cdf7bbf9-f****   1/1     Running       0          4m59s   172.29.113.88    cn-beijing.10.0.6.46           <none>           <none>
      nginx-9cdf7bbf9-r****   1/1     Running       0          8m31s   172.29.113.23    cn-beijing.10.0.3.138          <none>           <none>
      nginx-9cdf7bbf9-s****   1/1     Terminating   0          2m25s   10.0.6.68        virtual-kubelet-cn-beijing-j   <none>           <none>
      nginx-9cdf7bbf9-v****   1/1     Terminating   0          2m25s   10.0.6.67        virtual-kubelet-cn-beijing-j   <none>           <none>

      ECI Pod が最初に削除されています。

   2. 2 つのレプリカにスケールします。従量課金 ECS Pod が次に削除されます。

      kubectl scale deployment nginx --replicas 2

      kubectl get pods -o wide

      期待される出力：

      NAME                    READY   STATUS        RESTARTS   AGE     IP               NODE                    NOMINATED NODE   READINESS GATES
      nginx-9cdf7bbf9-4****   0/1     Terminating   0          6m43s   172.29.113.155   cn-beijing.10.0.6.47    <none>           <none>
      nginx-9cdf7bbf9-b****   1/1     Running       0          10m     172.29.112.215   cn-beijing.10.0.3.137   <none>           <none>
      nginx-9cdf7bbf9-f****   0/1     Terminating   0          6m43s   172.29.113.88    cn-beijing.10.0.6.46    <none>           <none>
      nginx-9cdf7bbf9-r****   1/1     Running       0          10m     172.29.113.23    cn-beijing.10.0.3.138   <none>           <none>

   3. 終了が完了すると、サブスクリプション ECS Pod のみが残ります。

      kubectl get pods -o wide

      期待される出力：

      NAME                    READY   STATUS    RESTARTS   AGE   IP               NODE                    NOMINATED NODE   READINESS GATES
      nginx-9cdf7bbf9-b****   1/1     Running   0          11m   172.29.112.215   cn-beijing.10.0.3.137   <none>           <none>
      nginx-9cdf7bbf9-r****   1/1     Running   0          11m   172.29.113.23    cn-beijing.10.0.3.138   <none>           <none>

ResourcePolicy の適用後に Pod が Pending のままになる

スケジューラが ResourcePolicy を正しいポッドに関連付けられない場合があります。selector がワークロードのポッドラベルと正確に一致することを確認してください。セレクターがシステム予約ラベル (例えば alibabacloud.com/compute-class など) を使用している場合、システムがそれを変更し、関連付けが損なわれる可能性があります。

また、kube-scheduler のバージョンがクラスターのバージョンの最小要件を満たしていることを確認してください (前提条件を参照)。

スケールインが想定した逆順で行われない

この機能はベストエフォートです。厳密な逆順での削除は保証されません。たとえば、プリエンプションが有効な場合や、複数の Pod が同時に削除対象になった場合などです。

より厳密な順序付けが必要な場合は、whenTryNextUnits.policy の設定を確認し、ローリングアップデートのシナリオでは LackResourceAndNoTerminating を検討してください。

ResourcePolicy が pod-deletion-cost と競合する

同じワークロード内のポッドに pod-deletion-cost アノテーションが設定されている場合、2 つの機能が競合します。pod-deletion-cost アノテーションを削除してから ResourcePolicy を適用してください。

弾性ノードプールと併用すると、ノードプールが予期しないノードを作成する

オートスケーリングノードプールが max が設定されたユニット内にある場合、Cluster Autoscaler は ResourcePolicy の max 制限を考慮しないため、max を超えるノードを作成する可能性があります。これを回避するには、弾性ノードプールをユニットに含め、そのユニットに max を設定しないでください。