カスタム伸縮自在リソース優先度スケジューリングは、Alibaba Cloud の伸縮自在なスケジューリングポリシーです。このポリシーを使用すると、アプリケーションのデプロイメントまたはスケールアウト中にカスタムリソースポリシー (ResourcePolicy) を定義できます。ResourcePolicy は、アプリケーションインスタンスの Pod をさまざまなタイプのノードリソースにスケジューリングする順序を指定します。スケールイン中、Pod はスケジューリング順序の逆順で削除されます。
デプロイメントなどのワークロードの spec.selector.matchLabels フィールドでは、alibabacloud.com/compute-class や alibabacloud.com/compute-qos などのシステム予約ラベルを使用しないでください。システムは、カスタム優先度スケジューリング中にこれらのラベルを変更する可能性があります。これにより、VPC コントローラーが Pod を頻繁に再作成し、アプリケーションの安定性に影響を与える可能性があります。
前提条件
v1.20.11 以降を実行する ACK マネージドクラスター (Pro 版) が作成されていること。クラスターをアップグレードするには、「クラスターを手動でアップグレードする」をご参照ください。
スケジューラのバージョンは、ACK クラスターのバージョン要件を満たす必要があります。さまざまなスケジューラバージョンでサポートされている機能の詳細については、「kube-scheduler」をご参照ください。
ACK バージョン
スケジューラバージョン
1.20
v1.20.4-ack-7.0 以降
1.22
v1.22.15-ack-2.0 以降
1.24 以降
すべてのバージョンがサポートされています
ECI リソースを使用するには、[ack-virtual-node] コンポーネントがデプロイされていることを確認してください。詳細については、「ACK で ECI を使用する」をご参照ください。
注
スケジューラバージョン v1.x.x-aliyun-6.4 以降、カスタム伸縮自在リソース優先度の
ignorePreviousPodフィールドのデフォルト値はFalseに変更され、ignoreTerminatingPodフィールドのデフォルト値はTrueに変更されます。この変更は、既存の ResourcePolicy 構成やその後の更新には影響しません。この機能は pod-deletion-cost と競合するため、同時に使用することはできません。
この機能は、「ElasticResource を介した ECI の伸縮自在なスケジューリング」と併用できません。
この機能は BestEffort ポリシーを使用しており、スケールイン操作が厳密に逆の順序に従うことを保証するものではありません。
`max` フィールドは、v5.0 以降のスケジューラを搭載した v1.22 以降を実行するクラスターでのみ使用できます。
伸縮自在なノードプールと併用すると、この機能によりノードプールがノードを誤って強制排除する可能性があります。この機能を伸縮自在なノードプールで使用するには、伸縮自在なノードプールを Unit に含め、その Unit の `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: ユーザー定義のスケジューリングユニット。スケールアウト中、リソースはunitsで定義された順序で作成されます。スケールイン中、リソースは逆の順序で削除されます。resource: 伸縮自在なリソースのタイプ。サポートされている値はeci、ecs、elastic、acsです。elasticタイプは、v6.4.3 以降のスケジューラを搭載した v1.24 以降のクラスターで利用できます。acsタイプは、v6.7.1 以降のスケジューラを搭載した v1.26 以降のクラスターで利用できます。説明elasticタイプは非推奨になります。Pod ラベルにk8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true"を設定して、自動スケーリングノードプールを使用することをお勧めします。説明acsタイプは、デフォルトでalibabacloud.com/compute-class: defaultおよびalibabacloud.com/compute-class: general-purposeラベルを Pod に追加します。Pod ラベルで異なる値を宣言することで、デフォルト値を上書きできます。Pod アノテーションでalpha.alibabacloud.com/compute-qos-strategyが宣言されている場合、alibabacloud.com/compute-class: defaultラベルはデフォルトでは追加されません。説明acsおよびeciタイプは、デフォルトで仮想ノードの Taint に対する Toleration を Pod に追加します。Pod は、追加の Taint Toleration 構成を必要とせずに仮想ノードにスケジュールできます。重要6.8.3 より前のスケジューラバージョンでは、複数の
acsUnit を同時に使用することはできません。nodeSelector: スケジューリングユニットのノードを選択するためにnodeのlabelを指定します。このパラメーターはECSリソースにのみ適用されます。max(スケジューラ v5.0 以降で利用可能): このスケジューリングユニットでスケジュールできる Pod レプリカの最大数。maxResources(スケジューラ v6.9.5 以降で利用可能): このスケジューリングユニット内の Pod にスケジュールできるリソースの最大量。podAnnotations: タイプはmap[string]string{}です。podAnnotationsで構成されたキーと値のペアは、スケジューラによって Pod に追加されます。この Unit 内の Pod の数をカウントする場合、これらのキーと値のペアを持つ Pod のみがカウントされます。podLabels: タイプはmap[string]string{}です。podLabelsで構成されたキーと値のペアは、スケジューラによって Pod に追加されます。この Unit 内の Pod の数をカウントする場合、これらのキーと値のペアを持つ Pod のみがカウントされます。説明Unit の `podLabels` に
k8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true"が含まれており、現在の Unit の Pod 数が指定された `max` 値より少ない場合、スケジューラは Pod を現在の Unit で待機させます。待機時間はwhenTryNextUnitsで設定できます。ラベルk8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true"は Pod に追加されません。また、Pod の数をカウントする際に、このラベルは Pod に必要ありません。説明ResourcePolicy を自動スケーリングで使用する場合は、インスタント弾力性も使用する必要があります。そうしないと、cluster-autoscaler が誤ったノードプールのスケーリングをトリガーする可能性があります。
preemptPolicy(スケジューラ v6.1 以降で利用可能。このパラメーターは ACS には効果がありません。): ResourcePolicy に複数のunitが含まれている場合、このフィールドは、Unit のスケジューリングが失敗したときにスケジューラがプリエンプションを試行できるかどうかを指定します。`BeforeNextUnit` は、いずれかの Unit のスケジューリングが失敗した場合にスケジューラがプリエンプションを試行することを示します。`AfterAllUnits` は、最後の Unit のスケジューリングが失敗した場合にのみスケジューラがプリエンプションを試行することを示します。デフォルト値は AfterAllUnits です。ACK Scheduler パラメーターを構成してプリemptionを有効にすることができます。
ignorePreviousPod(スケジューラ v6.1 以降で利用可能): このフィールドはunitsのmaxと一緒に使用する必要があります。このフィールドがtrueに設定されている場合、ResourcePolicy が作成される前にスケジュールされた Pod は、Pod の数をカウントするときに無視されます。ignoreTerminatingPod(スケジューラ v6.1 以降で利用可能): このフィールドはunitsのmaxと一緒に使用する必要があります。このフィールドがtrueに設定されている場合、Terminating 状態の Pod は、Pod の数をカウントするときに無視されます。matchLabelKeys(スケジューラ v6.2 以降で利用可能): このフィールドはunitsのmaxと一緒に使用する必要があります。Pod は、指定されたラベルの値に基づいてグループ化されます。Pod のグループが異なれば、maxのカウントも異なります。この機能が使用され、Pod にmatchLabelKeysで宣言されたラベルがない場合、その Pod はスケジュールできません。whenTryNextUnits(スケジューラ v6.4 以降を搭載したクラスター v1.24 以降で利用可能): Pod が次の Unit のリソースを使用できる条件を記述します。policy: Pod を次の Unit にスケジュールできるタイミングを決定するポリシー。有効な値はExceedMax、LackResourceAndNoTerminating、TimeoutOrExceedMax、およびLackResourceOrExceedMax(デフォルト) です。ExceedMax: 現在の Unit の `max` および `maxResources` フィールドが設定されていない場合、または現在の Unit の Pod 数が指定された `max` 値以上である場合、または現在の Unit の使用済みリソース量に現在の Pod のリソースを加えたものが `maxResources` を超える場合に、Pod は次の Unit のリソースを使用できます。このポリシーは、自動スケーリングおよび ECI と 使用して、ノードプールの自動スケーリングを優先させることができます。重要自動スケーリングノードプールが長時間ノードを作成できない場合、このポリシーにより Pod が Pending 状態のままになる可能性があります。
Cluster Autoscaler は ResourcePolicy の `max` 制限を認識しないため、実際に作成されるインスタンスの数が指定された `max` 値より大きくなる可能性があります。この問題は将来のリリースで修正される予定です。
TimeoutOrExceedMax: 次のいずれかの条件が満たされた場合に、このエラーが発生します:現在の Unit の `max` 値が設定されており、Unit 内の Pod の数が `max` 値未満である。または、`maxResources` が設定されており、スケジュールされたリソース量と現在の Pod のリソースの合計が `maxResources` 未満である。
現在の Unit の `max` 値が設定されておらず、現在の Unit の `podLabels` に
k8s.aliyun.com/resource-policy-wait-for-ecs-scaling: "true"が含まれている。
現在の Unit に Pod をスケジュールするためのリソースが不足している場合、Pod は
timeout値で指定された最大期間、その Unit で保留中のままになります。オートスケーリングおよび ECI とともに使用される場合、このポリシーはノードプールのオートスケーリングを優先し、タイムアウト後に自動的に ECI を使用します。重要タイムアウト期間中にノードが作成されても Ready 状態にならず、Pod が NotReady Taint を許容しない場合でも、Pod は ECI インスタンスにスケジュールされます。
LackResourceOrExceedMax: 現在の Unit の Pod 数が指定された `max` 値以上である場合、または現在の Unit に利用可能なリソースがなくなった場合に、Pod は次の Unit のリソースを使用できます。これはデフォルトのポリシーであり、ほとんどの基本的なシナリオに適しています。LackResourceAndNoTerminating: 現在の Unit の Pod 数が指定された `max` 値以上である場合、または現在の Unit に利用可能なリソースがなく、かつ現在の Unit に Terminating 状態の Pod がない場合に、Pod は次の Unit のリソースを使用できます。このポリシーは、ローリングアップデート戦略と 使用して、終了中の Pod が原因で新しい Pod が後続の Unit にロールアウトされるのを防ぐのに適しています。
timeout: `timeout` パラメーターは `acs` Unit ではサポートされていません。`acs` Unit は `max` によってのみ制限されます。`policy` がTimeoutOrExceedMaxに設定されている場合、このフィールドはタイムアウト期間を指定します。このフィールドが空の場合、デフォルト値は 15 分です。
シナリオ例
シナリオ 1: ノードプールの優先度に基づいて Pod をスケジュールする
2 つのノードプール (ノードプール A とノードプール B) を持つクラスターにデプロイメントをデプロイしたいとします。Pod をノードプール A に優先的にスケジュールしたいとします。ノードプール A のリソースが不足している場合、Pod はノードプール B にスケジュールされます。デプロイメントをスケールインすると、ノードプール B の Pod が最初に削除され、次にノードプール A の 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 コア、4 GB です。次の手順で手順を説明します:
次の YAML コンテンツを使用して、ノードプールのスケジューリング順序をカスタマイズする ResourcePolicy を作成できます。
apiVersion: scheduling.alibabacloud.com/v1alpha1 kind: ResourcePolicy metadata: name: nginx namespace: default spec: selector: app: nginx # これは後で作成する Pod のラベルに関連付ける必要があります。 strategy: prefer units: - resource: ecs nodeSelector: alibabacloud.com/nodepool-id: np7ec79f2235954e879de07b780058**** - resource: ecs nodeSelector: alibabacloud.com/nodepool-id: npab2df797738644e3a7b7cbf532bb****説明ノードプール ID は、クラスターの [ノード管理 > ノードプール] ページで取得できます。詳細については、「ノードプールの作成と管理」をご参照ください。
次の YAML コンテンツを使用して、デプロイメントを作成し、2 つの Pod をデプロイできます。
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 のセレクターに関連付ける必要があります。 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 のハイブリッドスケジューリングを使用する
サブスクリプション ECS インスタンス、従量課金 ECS インスタンス、ECI インスタンスの 3 種類のリソースを持つクラスターにデプロイメントをデプロイしたいとします。リソースコストを削減するために、スケジューリングの優先順位を、サブスクリプション ECS インスタンス、従量課金 ECS インスタンス、ECI インスタンスの順に設定したいとします。デプロイメントをスケールインする場合、まず ECI インスタンスから Pod を削除し、次に従量課金 ECS インスタンスから、最後にサブスクリプション ECS インスタンスから削除したいとします。この例では、ノードの仕様は 2 コア、4 GB です。ECS と ECI のハイブリッドスケジューリングの手順は次のとおりです:
次のコマンドを実行して、異なる課金方法を使用するノードに異なる
labelを追加します。ノードプール機能を使用してlabelを自動的に追加することもできます。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 # これは後で作成する Pod のラベルに関連付ける必要があります。 strategy: prefer units: - resource: ecs nodeSelector: paidtype: subscription - resource: ecs nodeSelector: paidtype: pay-as-you-go - resource: eci次の YAML コンテンツを使用して、デプロイメントを作成し、2 つの Pod をデプロイできます。
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 のセレクターに関連付ける必要があります。 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 が
labelがpaidtype=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>出力は、
paidtype=subscriptionlabelを持つノードのリソースが不足している場合、新しい Pod がpaidtype=pay-as-you-golabelを持つノードにスケジュールされることを示しています。次のコマンドを実行して、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>出力は、
paidtype=pay-as-you-golabelを持つノード上の 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>出力は、
paidtype=subscriptionlabelを持つノード上の Pod のみが残っていることを示しています。
参考資料
ACK クラスターにサービスをデプロイする場合、Toleration とノードアフィニティを使用して、ECS または ECI の伸縮自在なリソースのみを使用するように指定したり、ECS リソースが不足している場合に ECI リソースを自動的にリクエストしたりできます。スケジューリングポリシーを構成することで、さまざまなワークロードシナリオにおける伸縮自在なリソースのさまざまな要件を満たすことができます。詳細については、「ECS と ECI のリソース割り当てを指定する」をご参照ください。
高可用性 (HA) とパフォーマンス専有型は、分散タスクを実行するために重要です。ACK マネージドクラスター (Pro 版) では、ネイティブの Kubernetes スケジューリングセマンティクスを使用して、分散タスクをゾーン全体に分散させ、HA デプロイメント要件を満たすことができます。また、ネイティブの Kubernetes スケジューリングセマンティクスを使用して、指定されたゾーンでの分散タスクのアフィニティベースのデプロイメントを実装し、パフォーマンス専有型デプロイメント要件を満たすこともできます。詳細については、「ECI Pod のゾーンベースのアンチアフィニティおよびアフィニティスケジューリングを実装する」をご参照ください。