カスタム弾性リソース優先度スケジューリングは、Alibaba Cloud が提供する弾性スケジューリングポリシーです。アプリケーションのデプロイメントまたはスケールアウト中に、ResourcePolicy を定義して、アプリケーションインスタンスの Pod が異なるタイプのノードリソースにスケジューリングされる順序を指定できます。スケールイン中、Pod はスケジューリングとは逆の順序で削除されます。
ワークロードのラベルセレクター (Deployment の spec.selector.matchLabels フィールドなど) では、alibabacloud.com/compute-class や alibabacloud.com/compute-qos などのシステム予約ラベルを使用しないでください。これらのラベルは、カスタム優先度スケジューリング中にシステムによって変更される可能性があり、コントローラーが頻繁に Pod を再構築してアプリケーションの安定性に影響を与える原因となります。
前提条件
バージョン 1.20.11 以降の Container Service for Kubernetes (ACK) Pro 版マネージドクラスターが作成されていること。クラスターをアップグレードするには、「クラスターの手動アップグレード」をご参照ください。
スケジューラのバージョンは、ACK クラスターのバージョンごとに次の要件を満たす必要があります。各スケジューラバージョンでサポートされている機能の詳細については、「kube-scheduler」をご参照ください。
ACK バージョン
スケジューラバージョン
1.20
v1.20.4-ack-7.0 以降
1.22
v1.22.15-ack-2.0 以降
1.24 以降
すべてのバージョンがサポートされています
Elastic Container Instance (ECI) リソースを使用するには、ack-virtual-node コンポーネントがデプロイされている必要があります。詳細については、「ACK で ECI を使用する」をご参照ください。
注意事項
スケジューラバージョン v1.x.x-aliyun-6.4 以降、カスタム弾性リソース優先度の
ignorePreviousPodフィールドのデフォルト値はFalseに、ignoreTerminatingPodはTrueに変更されました。既存の ResourcePolicy オブジェクトとその後の更新は影響を受けません。この機能は pod-deletion-cost と競合するため、同時に使用することはできません。
この機能は、ElasticResource を介して実装される ECI 弾性スケジューリングと併用することはできません。詳細については、「ElasticResource を使用した ECI Pod の弾性スケジューリング」をご参照ください。
この機能は BestEffort ポリシーを使用しており、Pod が厳密に逆の順序でスケールインされることを保証するものではありません。
max フィールドは、バージョン 1.22 以降のクラスターで、スケジューラバージョンが 5.0 以降の場合にのみ使用できます。
弾性ノードプールと併用すると、この機能によりノードプールが無効なノードを作成する可能性があります。これを防ぐには、弾性ノードプールをユニットに含め、そのユニットの max フィールドを設定しないでください。
ご利用のスケジューラのバージョンが 5.0 より前、またはクラスターのバージョンが 1.20 以前の場合、ResourcePolicy が作成される前に存在していた Pod が最初にスケールインされることにご注意ください。
ご利用のスケジューラのバージョンが 6.1 より前、またはクラスターのバージョンが 1.20 以前の場合、関連する Pod が完全に削除されるまで ResourcePolicy を変更しないでください。
使用方法
ResourcePolicy を作成して、弾性リソースの優先度を定義します：
apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
name: test
namespace: default
spec:
selector:
key1: value1
strategy: prefer
units:
- nodeSelector:
unit: first
podLabels:
key1: value1
podAnnotations:
key1: value1
resource: ecs
- nodeSelector:
unit: second
max: 10
resource: ecs
- resource: eci
# Optional, Advanced Configurations
preemptPolicy: AfterAllUnits
ignorePreviousPod: false
ignoreTerminatingPod: true
matchLabelKeys:
- pod-template-hash
whenTryNextUnits:
policy: TimeoutOrExceedMax
timeout: 1mselector：ResourcePolicy が同じ名前空間内のlabelkey1=value1を持つ Pod に適用されることを指定します。selectorが空の場合、ポリシーは名前空間内のすべての Pod に適用されます。strategy：スケジューリング戦略。現在、preferのみがサポートされています。units：ユーザー定義のスケジューリングユニット。スケールアウト中、Pod はunitsで定義された順序でリソースにスケジューリングされます。スケールイン中、Pod は逆の順序で削除されます。resource：弾性リソースのタイプ。サポートされているタイプはeci、ecs、elastic、およびacsです。elasticタイプは、バージョン 1.24 以降のクラスターで、スケジューラバージョンが 6.4.3 以降の場合に使用できます。acsタイプは、バージョン 1.26 以降のクラスターで、スケジューラバージョンが 6.7.1 以降の場合に使用できます。説明elasticタイプは非推奨になっています。`podLabels` にk8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true"を設定することで、自動スケーリングノードプールを使用できます。説明デフォルトでは、
acsタイプは Pod にalibabacloud.com/compute-class: defaultラベルとalibabacloud.com/compute-class: general-purposeラベルを追加します。`podLabels` に異なる値を指定することで、これらのデフォルト値を上書きできます。ただし、`podAnnotations` にalpha.alibabacloud.com/compute-qos-strategyが指定されている場合、alibabacloud.com/compute-class: defaultラベルは追加されません。説明acsおよびeciタイプは、デフォルトで仮想ノードの Taint に対する Toleration を Pod に追加します。スケジューラはこれらの Toleration を内部的に追加し、Pod の spec には反映されません。Pod は、追加の Taint Toleration 設定を必要とせずに仮想ノードにスケジューリングできます。重要スケジューラバージョン 6.8.3 より前では、複数の
acsタイプのユニットを同時に使用することはできません。nodeSelector：node上のlabelsを使用して、このスケジューリングユニット内のノードを識別します。max(スケジューラバージョン 5.0 以降で利用可能)：このユニットでスケジューリングできる Pod レプリカの最大数。maxResources(スケジューラバージョン 6.9.5 以降で利用可能)：このユニット内の Pod にスケジューリングできるリソースの最大量。podAnnotations：タイプはmap[string]string{}です。podAnnotationsで設定されたキーと値のペアは、スケジューラによって Pod に更新されます。ユニット内の Pod 数を計算する際には、これらのキーと値のペアを持つ Pod のみがカウントされます。podLabels：タイプはmap[string]string{}です。podLabelsで設定されたキーと値のペアは、スケジューラによって Pod に更新されます。ユニット内の Pod 数を計算する際には、これらのキーと値のペアを持つ 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 のカウントにも必要ありません。説明ResourcePolicy を自動スケーリングと併用する場合は、インスタントエラスティシティと併用する必要があります。そうしないと、Cluster Autoscaler が誤ったノードプールのスケーリングをトリガーする可能性があります。
preemptPolicy：`ResourcePolicy` に複数のunitが含まれる場合のプリエンプションポリシーを指定します。`BeforeNextUnit` は、スケジューラがユニットのスケジューリングに失敗するたびにプリエンプションを試行することを示します。`AfterAllUnits` は、スケジューラが最後のユニットのスケジューリングに失敗した後にのみプリエンプションを試行することを示します。デフォルト値は `AfterAllUnits` です。このパラメーターはスケジューラ v6.1 以降で利用可能で、ACS には適用されません。ACK スケジューラのパラメーターを設定することで、プリエンプションを有効にできます。詳細については、「プリエンプションの有効化」をご参照ください。
ignorePreviousPod(スケジューラバージョン 6.1 以降で利用可能)：unitsのmaxと一緒に使用する必要があります。この値がtrueの場合、ResourcePolicy が作成される前にスケジューリングされた Pod は、Pod のカウント時に無視されます。ignoreTerminatingPod(スケジューラバージョン 6.1 以降で利用可能)：unitsのmaxと一緒に使用する必要があります。この値がtrueの場合、Terminating 状態の Pod は、Pod のカウント時に無視されます。matchLabelKeys(スケジューラバージョン 6.2 以降で利用可能)：unitsのmaxと一緒に使用する必要があります。Pod はラベルの値に基づいてグループ化されます。maxカウントは、Pod の各グループに個別に適用されます。matchLabelKeysで宣言されたラベルが Pod にない場合、その Pod はスケジューラによって拒否されます。whenTryNextUnits(バージョン 1.24 以降のクラスターで、スケジューラバージョンが 6.4 以降の場合に利用可能)：Pod が後続のユニットのリソースを使用できる条件を記述します。policy：Pod が使用するポリシー。有効な値はExceedMax、LackResourceAndNoTerminating、TimeoutOrExceedMax、およびLackResourceOrExceedMax(デフォルト) です。ExceedMax: 現在のユニットに `max` および `maxResources` フィールドが設定されていない場合、現在のユニットの Pod 数が `max` 値以上の場合、または現在のユニットで使用されているリソースと現在の Pod のリソースの合計が `maxResources` 値を超える場合、Pod は次のユニットのリソースを使用できます。このポリシーをオートスケーリングおよび ECI とともに使用することで、ノードプールのオートスケーリングを優先できます。重要自動スケーリングノードプールが長期間ノードを作成できない場合、このポリシーにより Pod が Pending 状態のままになる可能性があることにご注意ください。
現在、Cluster Autoscaler は ResourcePolicy の max 制限を認識していません。実際に作成されるインスタンス数が max の値より大きくなる可能性があります。この問題は将来のバージョンで最適化される予定です。
TimeoutOrExceedMax：次のいずれかの条件が満たされた場合：現在のユニットの max フィールドが設定されており、ユニット内の Pod 数が max の値より少ない場合、または maxResources フィールドが設定されており、スケジュール済みのリソースと現在の Pod のリソースの合計が maxResources の値より少ない場合。
現在のユニットの max フィールドが設定されておらず、現在のユニットの podLabels に
k8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true"が含まれている場合。
現在のユニットに Pod をスケジューリングするためのリソースが不足している場合、Pod は
timeoutで指定された最大期間、現在のユニットで待機します。このポリシーは、自動スケーリングと ECI と組み合わせて、ノードプールのスケールアウトを優先し、タイムアウト後に自動的に ECI を使用するために使用できます。重要タイムアウト期間中にノードが作成されても Ready 状態になく、Pod が NotReady Taint を許容しない場合、Pod は依然として ECI にスケジューリングされることにご注意ください。
LackResourceOrExceedMax: 現在のユニットの Pod 数が `max` 値以上の場合、または現在のユニットのリソースが不足した場合に、Pod が次のユニットのリソースを使用できるようにします。これはデフォルトのポリシーであり、ほとんどの基本的な要件に適しています。LackResourceAndNoTerminating: 現在のユニットに使用可能なリソースがないか、最大 Pod 数 (`max`) に達し、かつ現在のユニット内のどの Pod も `Terminating` 状態にない場合に、Pod が次のユニットのリソースを使用することを許可します。このポリシーは、現在のユニット内の Pod が終了中の間、新しい Pod が後続のユニットにスケジュールされるのを防ぐため、ローリングアップデート戦略に適しています。
timeout(このパラメーターは、`max` によってのみ制限される ACS ユニットではサポートされていません): `policy` がTimeoutOrExceedMaxに設定されている場合のタイムアウト期間です。このフィールドが空の場合、デフォルト値は 15 分です。
シナリオ例
シナリオ 1：ノードプール優先度に基づくスケジューリング
Deployment をデプロイする必要があります。クラスターにはノードプール A とノードプール B の 2 つのノードプールがあります。Pod をまずノードプール A にスケジューリングし、ノードプール A のリソースが不足している場合は、Pod をノードプール B にスケジューリングしたいと考えています。スケールイン時には、まずノードプール B から Pod を削除し、次にノードプール A から削除したいと考えています。この例では、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 のメモリを持っています。以下の手順では、ノードプールの優先度に基づいてスケジューリングする方法について説明します：
次の YAML コンテンツを使用して ResourcePolicy を作成し、ノードプールのスケジューリング順序をカスタマイズします。
apiVersion: scheduling.alibabacloud.com/v1alpha1 kind: ResourcePolicy metadata: name: nginx namespace: default spec: selector: app: nginx # This must be associated with the label of the pod that you will create later. strategy: prefer units: - resource: ecs nodeSelector: alibabacloud.com/nodepool-id: np7ec79f2235954e879de07b780058**** - resource: ecs nodeSelector: alibabacloud.com/nodepool-id: npab2df797738644e3a7b7cbf532bb****説明ノードプール ID は、クラスターの [ノード管理] > [ノードプール] ページから取得できます。詳細については、「ノードプールの作成と管理」をご参照ください。
次の YAML コンテンツを使用して、2 つの Pod を持つ 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 # This must be associated with the selector of the ResourcePolicy created in the previous step. 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 つの Pod がノードプール A のノードにスケジューリングされたことを示しています。
Pod をスケールアウトします。
次のコマンドを実行して、Pod を 4 つのレプリカにスケールアウトします。
kubectl scale deployment nginx --replicas 4期待される出力：
deployment.apps/nginx scaled次のコマンドを実行して、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 のノードにリソースが不足している場合、新しい Pod がノードプール B のノードにスケジューリングされることを示しています。
Pod をスケールインします。
次のコマンドを実行して、Pod を 4 つのレプリカから 2 つにスケールインします。
kubectl scale deployment nginx --replicas 2期待される出力：
deployment.apps/nginx scaled次のコマンドを実行して、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 が最初に削除されることを示しており、これはスケジューリング順序の逆です。
シナリオ 2：ECS と ECI のハイブリッドスケジューリング
Deployment をデプロイする必要があります。クラスターには、サブスクリプション Elastic Compute Service (ECS) インスタンス、従量課金 ECS インスタンス、ECI インスタンスの 3 種類のリソースがあります。リソースコストを削減するため、サービスのデプロイメントが次の優先順位に従うようにしたいと考えています：サブスクリプション ECS、従量課金 ECS、そして ECI。スケールイン時には、まず ECI インスタンスから、次に従量課金 ECS インスタンスから、最後にサブスクリプション ECS インスタンスから Pod を削除したいと考えています。この例では、ノードは 2 vCPU と 4 GB のメモリを持っています。以下の手順では、ECS と ECI のハイブリッドスケジューリングを実行する方法について説明します：
次のコマンドを実行して、異なる課金方法のノードに異なる
labelsを追加します。ノードプール機能を使用して自動的にlabelsを追加することもできます。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次の YAML コンテンツを使用して ResourcePolicy を作成し、ノードプールのスケジューリング順序をカスタマイズします。
apiVersion: scheduling.alibabacloud.com/v1alpha1 kind: ResourcePolicy metadata: name: nginx namespace: default spec: selector: app: nginx # This must be associated with the label of the pod that you will create later. strategy: prefer units: - resource: ecs nodeSelector: paidtype: subscription - resource: ecs nodeSelector: paidtype: pay-as-you-go - resource: eci次の YAML コンテンツを使用して、2 つの Pod を持つ 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 # This must be associated with the selector of the ResourcePolicy created in the previous step. 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 つの Pod が
labelpaidtype=subscriptionを持つノードにスケジューリングされたことを示しています。
Pod をスケールアウトします。
次のコマンドを実行して、Pod を 4 つのレプリカにスケールアウトします。
kubectl scale deployment nginx --replicas 4期待される出力：
deployment.apps/nginx scaled次のコマンドを実行して、Pod のステータスを確認します。
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>出力は、
labelpaidtype=subscriptionを持つノードにリソースが不足している場合、新しい Pod がlabelpaidtype=pay-as-you-goを持つノードにスケジューリングされることを示しています。次のコマンドを実行して、Pod を 6 つのレプリカにスケールアウトします。
kubectl scale deployment nginx --replicas 6期待される出力：
deployment.apps/nginx scaled次のコマンドを実行して、Pod のステータスを確認します。
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 リソースにスケジューリングされることを示しています。
Pod をスケールインします。
次のコマンドを実行して、Pod を 6 つのレプリカから 4 つにスケールインします。
kubectl scale deployment nginx --replicas 4期待される出力：
deployment.apps/nginx scaled次のコマンドを実行して、Pod のステータスを確認します。
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 が最初に削除されることを示しており、これはスケジューリング順序の逆です。
次のコマンドを実行して、Pod を 4 つのレプリカから 2 つにスケールインします。
kubectl scale deployment nginx --replicas 2期待される出力：
deployment.apps/nginx scaled次のコマンドを実行して、Pod のステータスを確認します。
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>出力は、
labelpaidtype=pay-as-you-goを持つノード上の Pod が次に削除されることを示しており、これはスケジューリング順序の逆です。次のコマンドを実行して、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>出力は、
labelpaidtype=subscriptionを持つノード上の Pod のみが残っていることを示しています。
参考資料
ACK クラスターでサービスをデプロイする際、Toleration とノードアフィニティを使用して、ECS または ECI 弾性リソースのみを使用することを宣言したり、ECS リソースが不足している場合に自動的に ECI リソースをリクエストしたりできます。スケジューリングポリシーを設定することで、さまざまなワークロードシナリオにおける弾性リソースのさまざまな要件を満たすことができます。詳細については、「ECS と ECI のリソース割り当ての指定」をご参照ください。
高可用性 (HA) と高パフォーマンスは、分散タスクを実行するための重要な要件です。ACK Pro 版マネージドクラスターでは、ネイティブの Kubernetes スケジューリングセマンティクスを使用して、ゾーン間で分散タスクを離散化し、HA デプロイメント要件を満たすことができます。また、ネイティブの Kubernetes スケジューリングセマンティクスを使用して、指定されたゾーンで分散タスクのアフィニティベースのデプロイメントを実装し、高パフォーマンスのデプロイメント要件を満たすこともできます。詳細については、「ECI Pod のゾーンベースの離散化とアフィニティスケジューリングの実装」をご参照ください。