優先度ベースのリソーススケジューリングは、ポッドスケジューリングの柔軟性要件を満たすためにAlibaba Cloudによって提供されます。 ResourcePolicyは、ポッドスケジューリングの降順でノードの優先度を指定します。 システムがアプリケーションのポッドをデプロイまたはスケールアウトすると、ポッドはResourcePolicyにリストされているノードの優先順位に基づいてノードにスケジュールされます。 システムがアプリケーションのポッドでスケーリングすると、ポッドはノードの優先順位に基づいて昇順でノードから削除されます。
kube-scheduler v1.x.x-aliyun-6.4以降では、ResourcePolicyのignorePreviousPodパラメーターはFalseに設定され、ignoreTerminatingPodパラメーターは既定でTrueに設定されます。 上記のパラメーターを使用する既存のResourcePoliciesは、この変更やさらなる更新の影響を受けません。
前提条件
Kubernetes 1.20.11以降を実行するContainer Service for Kubernetes (ACK) Proクラスターが作成されます。 ACKクラスターのKubernetesバージョンを更新する方法の詳細については、「ACKクラスターのKubernetesバージョンの更新」をご参照ください。
必要なスケジューラーバージョンは、クラスターのKubernetesバージョンによって異なります。 次の表に、Kubernetesのバージョンごとに必要なスケジューラーバージョンを示します。 さまざまなスケジューラーバージョンの機能の詳細については、「kube-scheduler」をご参照ください。
Kubernetesバージョン
スケジューラのバージョン
1.20
1.20.4-ack-7.0以降
1.22
1.22.15-ack-2.0以降
1.24以降
すべてのバージョンがサポートされています
エラスティックコンテナインスタンスを使用する場合は、ack-virtual-nodeがデプロイされます。 詳細については、「ACKクラスターでのElastic Container Instanceの使用」をご参照ください。
制限事項
優先度ベースのリソーススケジューリングは、ポッド削除コスト機能と相互に排他的です。 ポッド削除コスト機能の詳細については、「ポッド削除コスト」をご参照ください。
優先度ベースのリソーススケジューリングとElastic Container Instanceベースのスケジューリングを同時に使用することはできません。 Elastic Container Instanceベースのスケジューリングの詳細については、「Elastic Container Instanceベースのスケジューリングの使用」をご参照ください。
この機能はBestEffortポリシーを使用しており、システムがアプリケーションのポッドでスケーリングするときに、ノードの優先順位に基づいてポッドがノードから昇順に削除されることを保証しません。
maxパラメーターは、クラスターがKubernetes 1.22以降を実行し、クラスターにインストールされているスケジューラのバージョンが5.0以降の場合にのみ使用できます。
この機能をエラスティックノードプールと一緒に使用すると、エラスティックノードプールに無効なノードが追加される可能性があります。 エラスティックノードプールがユニットに含まれていることを確認します。 単位にmaxパラメーターを指定しないでください。
5.0以前のスケジューラーバージョンを使用している場合、またはクラスターのKubernetesバージョンが1.20以前の場合、ResourcePolicyが作成される前にすでに存在しているポッドは、スケールインアクティビティ中に優先順位が付けられます。
6.1以前のスケジューラーバージョンを使用している場合、またはクラスターのKubernetesバージョンが1.20以前の場合は、ResourcePolicyによって選択されたすべてのポッドが削除される前に、ResourcePolicyを変更しないでください。
優先度ベースのリソーススケジューリングを設定する方法
次のテンプレートでResourcePolicyを作成します。
apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
name: test
namespace: default
spec:
ignorePreviousPod: false
ignoreTerminatingPod: true
matchLabelKeys:
- pod-template-hash
preemptPolicy: AfterAllUnits
selector:
key1: value1
strategy: prefer
units:
- nodeSelector:
unit: first
resource: ecs
- nodeSelector:
unit: second
max: 10
resource: ecs
- resource: eci
whenTryNextUnits:
policy: TimeoutOrExceedMax
timeout: 1mselector: 名前空間内のポッドを選択するために使用されるセレクター。 選択したポッドにResourcePolicyが適用されます。 この例では、key1=value1ラベルを持つポッドが選択されています。selectorを空のままにすると、ResourcePolicyは名前空間内のすべてのポッドに対して有効になります。strategy: スケジューリングポリシー。 値をpreferに設定します。units: スケジューリング可能なユニット。 スケールアウトアクティビティでは、ポッドは、単位の下に降順でリストされているノードの優先度に基づいてノードにスケジュールされます。 スケールインアクティビティでは、ポッドはノードの優先順位に基づいて昇順でノードから削除されます。resource: エラスティックリソースのタイプ。 有効な値:eci、ecs、およびelastic。elasticは、クラスターが1.24以降のKubernetesバージョンを実行し、スケジューラーバージョンが6.4.3以降の場合に使用できます。nodeSelector: 指定されたノードラベルを持つノードを選択するために使用されるセレクター。 このパラメーターは、resourceパラメーターがecsに設定されている場合にのみ有効です。max(スケジューラーバージョンが5.0以降の場合に使用可能): 現在のユニットにスケジュールできるレプリケートポッドの最大数を指定します。
preemptPolicy(スケジューラーバージョンが6.1以降の場合に使用可能): ResourcePolicyに複数のユニットが含まれている場合に使用されるプリエンプションポリシー。 ポリシーは、スケジューラがポッドをユニットにスケジュールできないたびにノードをプリエンプトするかどうかを指定します。 プリエンプションポリシーをBeforeNextUnitに設定した場合、スケジューラはポッドをユニットにスケジュールできないたびにノードをプリエンプトしようとします。 プリエンプションポリシーをAfterAllUnitsに設定した場合、スケジューラはポッドをすべてのユニットにスケジュールできなかった場合にのみ、ノードをプリエンプションしようとします。 デフォルトはAfterAllUnitsです。ignorePreviousPod(スケジューラーバージョンが6.1以降の場合に使用可能): このパラメーターは、unitsセクションのmaxパラメーターと一緒に使用する必要があります。 このパラメーターがtrueに設定されている場合、maxパラメーターの値には、ResourcePolicyが作成される前にスケジュールされたポッドは含まれません。ignoreTerminatingPod(スケジューラーバージョンが6.1以降の場合に使用可能): このパラメーターは、unitsセクションのmaxパラメーターと一緒に使用する必要があります。 このパラメーターがtrueに設定されている場合、maxパラメーターの値には終了状態のポッドは含まれません。matchLabelKeys(スケジューラーバージョンが6.2以降の場合に使用可能): このパラメーターは、unitsセクションのmaxパラメーターと一緒に使用する必要があります。 このパラメーターは、maxパラメーターで指定したポッドのラベルキーを指定します。matchLabelKeysパラメーターを設定すると、指定されたラベルキーのないポッドはスケジュールされません。whenTryNextUnits(クラスターのKubernetesバージョンが1.24以降で、スケジューラーバージョンが6.4以降の場合に使用可能): このパラメーターは、ポッドが任意の条件下で後続のユニットでリソースを使用できるように指定します。policy: ポッドのスケジューリングポリシー。 有効な値:ExceedMax、LackResourceAndNoTerminating、TimeoutOrExceedMax、およびLackResourceOrExceedMax(デフォルト値) 。ExceedMax: 現在のユニットに最大制限が設定されていない場合、または現在のユニット内のポッド数が最大制限より大きい場合、ポッドは次のレベルのリソースを使用できます。 このポリシーは、Auto ScalingおよびElastic Container Instanceと一緒に使用して、Auto Scalingを使用してノードプールをスケーリングすることができます。重要このポリシーを使用した後、オートスケーラーがノードプールにノードを長期間追加できない場合、保留中のポッドが存在する可能性があります。
オートスケーラは、ResourcePolicyのMax制限を認識していません。 追加されるインスタンスの実際の数は、最大制限より大きい場合があります。 この問題は、後のバージョンで解決されます。
TimeoutOrExceedMax: 次のいずれかの条件が満たされた場合。最大制限は現在のユニットに設定されており、ユニット内のポッドの数は最大制限よりも小さくなっています。
最大制限は現在のユニットに設定されておらず、ユニットのリソースタイプは
エラスティックです。
現在のユニットにポッドスケジューリング用の十分なリソースがない場合、現在のユニット内のポッドはリソースを待機します。 最大待機時間は
timeoutの値に等しくなります。 このポリシーをAuto ScalingおよびElastic Container Instanceと一緒に使用すると、Auto Scalingを使用してノードプールをスケーリングし、タイムアウト期間が終了したときにelastic containerインスタンスを使用することができます。- 重要
タイムアウト期間が終了する前に新しく追加されたノードが準備完了状態に到達できず、ポッドがNotReadyテイントを許容するように構成されていない場合、ポッドは引き続きエラスティックコンテナインスタンスにスケジュールされます。
LackResourceOrExceedMax: 現在のユニットのポッド数が最大制限以上の場合、またはユニットにアイドルリソースがない場合、ポッドは次のレベルのリソースを使用できます。 これはデフォルトのポリシーであり、ほとんどのシナリオに適しています。LackResourceAndNoTerminating: 現在のユニット内のポッド数が最大制限以上の場合、またはユニットにアイドルリソースがなく、ユニット内に終了ポッドが存在しない場合、ポッドは次のレベルのリソースを使用できます。 このポリシーは、現在のユニットに終了ポッドが存在する場合に、後続のユニットへの新しいポッドのスケジューリングを防ぐために、ローリング更新ポリシーと一緒に使用できます。
timeout:timeoutOrExceedMaxPolicyポリシーを使用する場合、このパラメーターはタイムアウト期間を指定します。 このパラメーターが空の文字列に設定されている場合、タイムアウト時間は15分です。
例
例1: 指定したノードプールへのポッドのスケジュール
ノードプールaの使用に優先順位を付け、ノードプールAのコンピューティングリソースが不十分な場合にのみ、ポッドをノードプールBにスケジュールします。 スケールインアクティビティでは、まずノードプールBのノードからポッドを削除します。 この例では、ノードプールAには、cn-beijing.10.0.3.137とcn-beijing.10.0.3.138のノードが含まれています。 ノードプールBは、cn-beijing.10.0.6 47とcn-beijing.10.0.6 46のノードを含む。 これらの各ノードには2 vCoresと4 GBのメモリがあります。 優先度ベースのリソーススケジューリングを設定するには、次の手順を実行します。
次のテンプレートでResourcePolicyを作成します。
apiVersion: scheduling.alibabacloud.com/v1alpha1 kind: ResourcePolicy metadata: name: nginx namespace: default spec: selector: app: nginx # You must specify the label of the pods to which you want to apply the ResourcePolicy. strategy: prefer units: - resource: ecs nodeSelector: alibabacloud.com/nodepool-id: np7ec79f2235954e879de07b780058**** - resource: ecs nodeSelector: alibabacloud.com/nodepool-id: npab2df797738644e3a7b7cbf532bb****説明ノードプールのIDを表示するには、ACKコンソールのクラスターの詳細ページで [ノード]> [ノードプール] を選択します。 詳細については、「ノードプールの作成」をご参照ください。
次のテンプレートを使用して、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 # The pod label must be the same as the one that you specified for the selector in the ResourcePolicy. spec: containers: - name: nginx image: nginx resources: limits: cpu: 2 requests: cpu: 2NGINXアプリケーションをデプロイし、ポッドを照会します。
次のコマンドを実行してNGINXアプリケーションをデプロイします。
kubectl apply -f nginx.yaml期待される出力:
deployment.apps/nginx created次のコマンドを実行してポッドを照会します。
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>出力は、2つのポッドがノードプールAにスケジュールされていることを示します。
NGINXアプリケーション用のポッドをスケールアウトします。
次のコマンドを実行して、ポッド数を4に増やします。
kubectl scale deployment nginx --replicas 4期待される出力:
deployment.apps/nginx scaled次のコマンドを実行して、ポッドのステータスを照会します。
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のコンピューティングリソースが不十分であるため、新しいポッドがノードプールBにスケジュールされていることを示しています。
NGINXアプリケーションのポッドをスケールインします。
次のコマンドを実行して、ポッドの数を2つに減らします。
kubectl scale deployment nginx --replicas 2期待される出力:
deployment.apps/nginx scaled次のコマンドを実行して、ポッドのステータスを照会します。
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のノードで実行されるポッドが削除されることを示しています。
例2: ECSインスタンスとelasticコンテナインスタンスへのポッドのスケジュール
サブスクリプションElastic Compute Service (ECS) インスタンス、従量課金ECSインスタンス、elastic containerインスタンスなど、複数のタイプのリソースにデプロイのポッドをスケジュールする場合。 リソースコストを削減するには、ECSインスタンスのサブスクリプション> 従量課金ECSインスタンス> エラスティックコンテナインスタンスの優先順位に基づいて、ポッドをリソースにスケジュールします。 スケールインアクティビティでは、エラスティックコンテナインスタンス、従量課金ECSインスタンス、サブスクリプションECSインスタンスのシーケンスに基づいて、これらのリソースからポッドを削除します。 この例では、各ECSインスタンスに2 vCoresと4 GBのメモリがあります。 優先度ベースのリソーススケジューリングを設定するには、次の手順を実行します。
次のコマンドを実行して、異なる課金方法を示す
ラベルをノードに追加します。 ノードプールを使用して、ノードにラベルを自動的に追加することもできます。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次のテンプレートでResourcePolicyを作成します。
apiVersion: scheduling.alibabacloud.com/v1alpha1 kind: ResourcePolicy metadata: name: nginx namespace: default spec: selector: app: nginx # You must specify the label of the pods to which you want to apply the ResourcePolicy. strategy: prefer units: - resource: ecs nodeSelector: paidtype: subscription - resource: ecs nodeSelector: paidtype: pay-as-you-go - resource: eci次のテンプレートを使用して、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 # The pod label must be the same as the one that you specified for the selector in the ResourcePolicy. spec: containers: - name: nginx image: nginx resources: limits: cpu: 2 requests: cpu: 2NGINXアプリケーションをデプロイし、ポッドを照会します。
次のコマンドを実行してNGINXアプリケーションをデプロイします。
kubectl apply -f nginx.yaml期待される出力:
deployment.apps/nginx created次のコマンドを実行してポッドを照会します。
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>出力は、2つのポッドが
paidtype=subscriptionラベルを持つノードにスケジュールされていることを示しています。
NGINXアプリケーション用のポッドをスケールアウトします。
次のコマンドを実行して、ポッド数を4に増やします。
kubectl scale deployment nginx --replicas 4期待される出力:
deployment.apps/nginx scaled次のコマンドを実行して、ポッドのステータスを照会します。
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>出力は、新しいポッドが
paidtype=従量課金ラベルを持つノードがpaidtype=サブスクリプションラベルが不十分です。次のコマンドを実行して、ポッド数を6に増やします。
kubectl scale deployment nginx --replicas 6期待される出力:
deployment.apps/nginx scaled次のコマンドを実行して、ポッドのステータスを照会します。
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ノードが不足しているため、新しいポッドがエラスティックコンテナインスタンスにスケジュールされていることを示しています。
NGINXアプリケーションのポッドをスケールインします。
次のコマンドを実行して、ポッド数を4に減らします。
kubectl scale deployment nginx --replicas 4期待される出力:
deployment.apps/nginx scaled次のコマンドを実行して、ポッドのステータスを照会します。
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>出力は、エラスティックコンテナインスタンスで実行されるポッドが削除されたことを示します。
次のコマンドを実行して、ポッドの数を2つに減らします。
kubectl scale deployment nginx --replicas 2期待される出力:
deployment.apps/nginx scaled次のコマンドを実行して、ポッドのステータスを照会します。
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>出力は、
paidtype=pay-as-you-goラベルを持つノードのポッドが削除されたことを示しています。次のコマンドを実行して、ポッドのステータスを照会します。
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>出力は、ポッドが
paidtype=subscriptionラベルを持つノードでのみ実行されることを示しています。
関連トピック
ACKクラスターにサービスをデプロイするときに、許容範囲とノードアフィニティを設定して、スケジューラがElastic Compute Service (ECS) インスタンスまたはelasticコンテナインスタンスのみを使用できるようにするか、ECSインスタンスが不足している場合にスケジューラがelasticコンテナインスタンスを自動的に申請できるようにすることができます。 さまざまなスケジューリングポリシーを設定して、さまざまなシナリオでリソースをスケーリングできます。 詳細については、「Elastic Container Instanceベースのスケジューリングの設定」をご参照ください。
高可用性と高性能は、分散ジョブに不可欠です。 ACK Proクラスターでは、Kubernetesネイティブのスケジューリングセマンティクスを使用して、分散ジョブをゾーン全体に分散して高可用性を実現できます。 また、Kubernetesネイティブのスケジューリングセマンティクスを使用して、アフィニティ設定に基づいて特定のゾーンに分散ジョブをデプロイし、高いパフォーマンスを実現することもできます。 詳細については、「Elastic Container Instanceベースのポッドのゾーン間での拡散とアフィニティの設定」をご参照ください。