Pro EditionクラスターやBasic Editionクラスターなど、ACKマネージドクラスターでサポートされている仮想ノードベースのスケジューリングソリューションは、ACK専用クラスターでサポートされているものとは異なります。 さまざまなソリューションがさまざまなシナリオと要件に適しています。 例えば、ポッドを仮想ノードのみにスケジューリングするのに適した解決策は、ポッドをゾーンに分散させるのに適した解決策とは異なる。 このトピックでは、クラスタータイプとシナリオに基づいて仮想ノードベースのスケジューリングソリューションを選択する方法について説明します。
一般的な仮想ノードベースのスケジューリングシナリオ
ポッドを仮想ノードにのみスケジュールします。
ポッドスケジューリングのためにElastic Compute Service (ECS) インスタンスに優先順位を付け、ECSインスタンスが不足している場合にのみ仮想ノードを使用します。
ACK Basicクラスターを使用するとします。 シナリオ1では、ポッド設定にalibabacloud.com/eci=trueラベルを追加することを推奨します。 シナリオ2では、クラスターをACK Proクラスターにアップグレードすることを推奨します。 ACK Basicクラスターと比較して、ACK Proクラスターはより多くの機能を提供し、クラスターの信頼性とサービスレベル契約 (SLA) の保証を強化し、より多くのポッドをデプロイできます。 ACKを使用すると、ACK BasicクラスターからACK Proクラスターにシームレスに移行できます。 詳細については、「ACK BasicクラスターからACK Proクラスターへのホットマイグレーション」をご参照ください。
使用上の注意
ラベル
alibabacloud.com/eci=trueは優先度が高い。 このラベルが次のスケジューリング方法で使用されている場合、これらのスケジューリング方法は適用されません。nodeSelector、affinity、anti-affinityなどのKubernetesネイティブスケジューリングセマンティクス、およびポッドトポロジ拡散制約
ResourcePolicy
ElasticResource (アノテーション:
alibabacloud.com/burst-resource)
弾性ワークロードの作成にack-kubernetes-elastic-workloadコンポーネントを使用したり、
alibabacloud.com/burst-resourceアノテーションを使用して弾性リソースを設定したりしないことを推奨します。 ack-kubernetes-elastic-workloadコンポーネントとe alibabacloud.com/burst-resourceアノテーションは非アクティブな開発状態です。Alibaba Cloudは、virtual-kubelet-autoscalerのメンテナンスを中止しました。 ACK Basicクラスターを使用する場合は、クラスターをACK Proクラスターにアップグレードし、virtual-kubelet-autoscalerをアンインストールしてノードリソースを節約することを推奨します。 Kubernetesネイティブスケジューリングセマンティクスを使用して、Elastic Container Instanceベースのポッドをゾーン全体に分散したり、アフィニティ設定に基づいて特定のゾーンにElastic Container Instanceベースのポッドをデプロイしたりできます。 詳細については、「Elastic Container Instanceベースのポッドのゾーン間での拡散とアフィニティの設定」をご参照ください。
ソリューションの比較とソリューションの選択方法に関する提案
次の表には、次の用語が含まれています。
優先度ベースのスケジューリング: クラスターに異なるタイプのノードが含まれている場合、ポッドスケジューリング用に異なるノードタイプの優先度を設定できます。 たとえば、ポッドスケジューリングのために仮想ノードよりもECSインスタンスに優先順位を付けることができます。 このように、ACKはポッドをECSインスタンスに優先的にスケジュールし、ポッドをECSインスタンスが不足している場合にのみ仮想ノードにスケジュールします。
スケジューリング方法が優先度ベースのスケジューリングポリシーをサポートしていない場合、スケジューリング方法では異なるタイプのノードの優先度を指定できないことを意味します。 たとえば、ポッド設定に
alibabacloud.com/eci=trueラベルを追加した場合、ポッドは仮想ノードにのみスケジュールでき、ECSインスタンスはポッドスケジューリングに使用されません。 この場合、優先度ベースのスケジューリングを有効にすることはできない。厳密なスケジューリングポリシー: このポリシーでは、ポッドを異なるタイプのノードプールにスケジューリングするための優先ルールと必須ルールを指定できます。
好ましいルール。 たとえば、preferredDuringSchedulingIgnoredDuringExecutionノードアフィニティルールをポッド設定に追加した場合、ポッドは優先的にECSノードにスケジュールされます。 ただし、ノードスコアリングポリシーにより、ECSノードが十分であれば、ポッドを仮想ノードにスケジュールすることができます。
必須ルール。 たとえば、ポッドのResourcePolicyを作成して、ECSノードが十分な場合にのみポッドがECSノードにスケジュールされるようにすることができます。
ACK Proクラスターs
スケジューリング方法 | 典型的なシナリオ | 優先度ベースのスケジューリング | Elastic Containerインスタンスベースのポッドで優先スケール | 推奨 | 関連ドキュメント | |
ラベル: | この方法を使用して、仮想ノードにのみポッドをスケジュールできます。 ただし、ポッドをスケジュールする仮想ノードを指定することはできません。 | 非対応 | 非該当 | 可 | ||
Kubernetes-ネイティブスケジューリングセマンティクスを使用します。 | nodeSelector | 許容範囲ルールをポッド構成に追加して、ポッドを仮想ノードにのみスケジュールすることができます。 さらに、ポッドをスケジュールする仮想ノードを指定できます。 | 非対応 | 非該当 | 可 | |
アフィニティとアンチアフィニティ | テイント、許容ルール、およびノードアフィニティルールを設定して、ポッドをエラスティックコンテナインスタンスのみ、またはECSインスタンスのみにスケジュールすることができます。 上記の設定を設定して、ECSインスタンスにポッドを優先的にスケジュールし、ECSインスタンスが不足している場合にのみポッドを仮想ノードにスケジュールすることもできます。 これにより、ポッドスケジューリングの弾力性が向上する。 このスケジューリング方法は、柔軟なコンテナインスタンスを優先的にスケーリングします。 | 優先ルールをサポート | 対応 | 可 | ||
ポッドトポロジーの広がりの制約 | ポッドをゾーンに分散して、高可用性と高パフォーマンスのポッドスケジューリングを実装できます。 | 非対応 | 対応 | 可 | ||
ResourcePolicy |
| 必要なルールをサポート | 対応 | 可 | ||
UnitedDeployment | デプロイ用に作成されたレプリケートされたポッドの数に基づいて、ポッドをECSインスタンスおよび仮想ノードにスケジュールできます。 たとえば、レプリカ数が10未満の場合はサブスクリプションECSインスタンスを使用し、レプリカ数が10を超えるが20を超えない場合はプリエンプティブルインスタンスを使用し、レプリカ数が20を超える場合はエラスティックコンテナインスタンスを使用するようにシステムを設定できます。 | 対応 | 対応 | 可 | ||
ElasticWorkload (この方法は、非アクティブ現像状態にある。 UnitedDeploymentコントローラーの使用を推奨します。 | デプロイのレプリケートされたポッドを、グループ内のECSインスタンスまたは仮想ノードにスケジュールできます。 | 対応 | 対応 | 不可 | ||
ElasticResource (アノテーション: (非アクティブな開発状態) | 次のエラスティックスケジューリングポリシーのみがサポートされています。
| 対応 | 対応 | 不可 | ||
virtual-kubelet-autoscaler (メンテナンス中止) | ECSインスタンスにポッドを優先的にスケジュールし、ECSインスタンスが不足している場合にのみポッドを仮想ノードにスケジュールするようにシステムを設定できます。 | 対応 | 対応 | ✕ | なし | |
ACK基本クラスターおよびACK専用クラスターs
スケジューリング方法 | 典型的なシナリオ | 優先度ベースのスケジューリング | Elastic Containerインスタンスベースのポッドで優先スケール | 推奨 | 関連ドキュメント | |
ラベル: | この方法を使用して、仮想ノードにのみポッドをスケジュールできます。 ただし、ポッドをスケジュールする仮想ノードを指定することはできません。 | 非対応 | 非該当 | 可 | ||
UnitedDeployment | デプロイ用に作成されたレプリケートされたポッドの数に基づいて、ポッドをECSインスタンスおよび仮想ノードにスケジュールできます。 たとえば、レプリカ数が10未満の場合はサブスクリプションECSインスタンスを使用し、レプリカ数が10を超えるが20を超えない場合はプリエンプティブルインスタンスを使用し、レプリカ数が20を超える場合はエラスティックコンテナインスタンスを使用するようにシステムを設定できます。 | 対応 | 対応 | 可 | ||
Kubernetes-ネイティブスケジューリングセマンティクスを使用します。 | nodeSelector | 許容範囲ルールをポッド構成に追加して、ポッドを仮想ノードにのみスケジュールすることができます。 さらに、ポッドをスケジュールする仮想ノードを指定できます。 | 非対応 | 対応 | いいえ。 ACK Proクラスターのkube-schedulerコンポーネントと比較して、ACK BasicクラスターおよびACK専用クラスターのkube-schedulerコンポーネントは、ポッドスケジューリング中に基になるリソースのインベントリを認識しません。 その結果、ACK Proクラスターではポッドの作成が成功する確率が低くなります。 | |
アフィニティとアンチアフィニティ | テイント、許容ルール、およびノードアフィニティルールを設定して、ポッドをエラスティックコンテナインスタンスのみ、またはECSインスタンスのみにスケジュールすることができます。 上記の設定を設定して、ECSインスタンスにポッドを優先的にスケジュールし、ECSインスタンスが不足している場合にのみポッドを仮想ノードにスケジュールすることもできます。 これにより、ポッドスケジューリングの弾力性が向上する。 | 優先ルールをサポート | 対応 | |||
ポッドトポロジーの広がりの制約 | ポッドをゾーンに分散して、高可用性と高パフォーマンスのポッドスケジューリングを実装できます。 | 非対応 | 対応 | |||
ElasticWorkload (この方法は、非アクティブ現像状態にある。 UnitedDeploymentコントローラーの使用を推奨します。 | デプロイのレプリケートされたポッドを、グループ内のECSインスタンスまたは仮想ノードにスケジュールできます。 | 対応 | 対応 | 不可 | ||
ElasticResource (アノテーション: (非アクティブな開発状態) | 次のエラスティックスケジューリングポリシーのみがサポートされています。
| 対応 | 対応 | 不可 | ||
virtual-kubelet-autoscaler (メンテナンス中止) | ECSインスタンスにポッドを優先的にスケジュールし、ECSインスタンスが不足している場合にのみポッドを仮想ノードにスケジュールするようにシステムを設定できます。 | 対応 | 対応 | ✕ | なし | |