仮想ノードのスケジューリング方法は、ACK マネージドクラスター (Pro および Basic エディション) と 専用クラスターで異なります。これらのソリューションは、Pod を仮想ノードにのみスケジュールしたり、ゾーンをまたいで Pod を分散させたりするなど、特定のユースケース向けに設計されています。このトピックでは、スケジューリングシナリオとクラスタータイプに基づいて、適切なスケジューリング方法を選択するのに役立ちます。
一般的な仮想ノードスケジューリングシナリオ
Pod を仮想ノードにのみスケジュールする。
ECS ノードへのスケジューリングを優先し、ECS ノードのリソースが不足している場合にのみ仮想ノードにスケジュールする。
ACK マネージドクラスター (Basic Edition) の場合、最初のシナリオではラベル alibabacloud.com/eci=true を使用することをお勧めします。2 番目のシナリオでは、クラスターを ACK マネージドクラスター (Pro Edition) にアップグレードすることをお勧めします。
ACK マネージドクラスター (Pro Edition) は、2 番目のシナリオの要件をより満たすことができるスケジューリング機能を提供し、より高い信頼性、サービスレベルアグリーメント (SLA) 保証、およびより大きなクラスター容量を提供します。ACK は、ACK マネージドクラスター (Basic Edition) から ACK マネージドクラスター (Pro Edition) へのシームレスな移行をサポートしています。詳細については、「ACK マネージドクラスター (Basic Edition) を ACK マネージドクラスター (Pro Edition) にホットマイグレーションする」をご参照ください。
使用上の注意
ラベル
alibabacloud.com/eci=trueの使用は最も高い優先度を持ちます。このラベルを使用すると、次のスケジューリング方法が上書きされます:nodeSelector、アフィニティとアンチアフィニティ、Pod トポロジースプレッド制約などの Kubernetes ネイティブのスケジューリングセマンティクス
ResourcePolicy
ElasticResource (アノテーション:
alibabacloud.com/burst-resource)
ElasticWorkload と ElasticResource (アノテーション:
alibabacloud.com/burst-resource) は開発がアクティブでない状態にあるため、使用することをお勧めしません。virtual-kubelet-autoscaler コンポーネントはメンテナンスされなくなりました。ACK マネージドクラスター (Basic Edition) を ACK マネージドクラスター (Pro Edition) にアップグレードし、このコンポーネントをアンインストールしてノードリソースを解放することをお勧めします。Kubernetes ネイティブのスケジューリングセマンティクスに基づいて、ECI Pod の分散デプロイメントとアフィニティベースのデプロイメントを実装できます。詳細については、「ゾーンをまたいで ECI Pod の分散デプロイメントとアフィニティベースのスケジューリングを実装する」をご参照ください。
仮想ノードにスケジュールされた Pod が動的にプロビジョニングされたディスクボリュームを使用する必要がある場合、
WaitForFirstConsumerタイプの StorageClass は、次のスケジューリング方法ではサポートされません:ラベル:
alibabacloud.com/eci=trueを使用する。nodeName を使用して仮想ノードを指定する。
ソリューションの比較と選択方法に関する提案
比較表では次の用語が使用されています:
優先度ベースのスケジューリング: クラスター内に異なるタイプのノードが存在する場合、Pod を異なるタイプのノードにスケジューリングする優先度を設定できます。たとえば、ECS ノードへのスケジューリングを優先し、ECS ノードのリソースが不足している場合にのみ仮想ノードにスケジュールすることができます。
あるメソッドが優先度ベースのスケジューリングをサポートしていない場合、異なるノードコレクションに対する優先度を調整することはできません。たとえば、
alibabacloud.com/eci=trueラベルを使用する場合、指定された Pod を仮想ノードにのみスケジュールできます。ECS ノードへの Pod のスケジューリングを優先し、ECS リソースが不足している場合にのみ仮想ノードにスケジュールするようにシステムを設定することはできません。厳密なスケジューリングポリシー: 異なるタイプのノードプールへのスケジューリングルールがハードな制約であるかどうかを指定します。
非厳密なスケジューリングポリシーはソフトな制約です。たとえば、ノードアフィニティの preferredDuringSchedulingIgnoredDuringExecution フィールドは、Pod を ECS ノードに優先的にスケジューリングします。ただし、包括的なノードスコアリングポリシーのため、ECS ノードのリソースが利用可能であっても Pod が仮想ノードにスケジュールされることがあります。
厳密なスケジューリングポリシーはハードな制約です。たとえば、ResourcePolicy は、ECS ノードが Pod の要件を満たすのに十分なリソースを持っている場合、Pod が ECS ノードにスケジュールされることを保証できます。
ACK マネージドクラスター (Pro Edition)
スケジューリング方法 | 典型的なシナリオ | 優先度ベースのスケジューリング | ECI Pod の優先的なスケールイン | 推奨 | 関連操作 | |
ラベル: | Pod を仮想ノードにのみスケジュールします。Pod をどの仮想ノードにスケジュールするかは指定できません。 | サポートされていません | N/A | 推奨 | ||
Kubernetes ネイティブのスケジューリングセマンティクス | nodeSelector | Toleration を追加した後、Pod を仮想ノードにのみスケジュールし、Pod をどの仮想ノードにスケジュールするかを指定できます。 | サポートされていません | N/A | 推奨 | |
アフィニティとアンチアフィニティ | Taint、Toleration、および NodeAffinity を使用して、Pod が ECI のみ、ECS のみ、または ECS に優先的にスケジュールされるように指定できます (たとえば、ECS ノードのリソースが不足している場合に仮想ノードにスケジュールするなど)。これは弾力的なスケジューリングポリシーです。 このメソッドは、ECI を最初にスケールインし、次に ECS をスケールインすることもサポートしています (そしてそれのみをサポートします)。 | サポートされています (非厳密なスケジューリングポリシー) | サポートされています | 推奨 | ||
Pod トポロジースプレッド制約 | 高可用性とパフォーマンス専有型のスケジューリング要件を満たすために、ゾーンをまたいで Pod を分散させます。 | サポートされていません | サポートされています | 推奨 | ||
ResourcePolicy 重要 v1.20 では、スケジューラは仮想ノードを処理する際に、仮想ノードに対する Pod のスケジューリング不能チェックを無視します。v1.22 以降では、仮想ノード上の Taint チェックのみが無視されます。 v1.20 の動作を維持するには、スケジューラパラメーターで仮想ノードのスケジューリング機能を無効にする必要があります。 |
| サポートされています (厳密なスケジューリングポリシー) | サポートされています | 推奨 | ||
UnitedDeployment | デプロイメントのレプリカ数に基づいて Pod を ECS または仮想ノードにスケジュールするポリシーの作成をサポートします。たとえば、レプリカ数が 10 未満の場合はサブスクリプション ECS リソースが優先的に使用されます。レプリカ数が 10 より大きく 20 以下の場合、Spot リソースが使用されます。レプリカ数が 20 より大きい場合、ECI リソースが使用されます。 | サポートされています | サポートされています | 推奨 | ||
ElasticWorkload (開発がアクティブでない状態です。UnitedDeployment の使用をお勧めします。) | デプロイメントのレプリカをグループ単位で ECS または仮想ノードにスケジュールします。 | サポートされています | サポートされています | 非推奨 | ||
ElasticResource (アノテーション: (開発がアクティブでない状態) | 2 つの弾力的なスケジューリングポリシーのみがサポートされています:
| サポートされています | サポートされています | 非推奨 | ||
virtual-kubelet-autoscaler コンポーネント (廃止) | ECS ノードへのスケジューリングを優先し、ECS ノードのリソースが不足している場合にのみ仮想ノードにスケジュールすることのみをサポートします。 | サポートされています | サポートされています | 非推奨 | なし | |
ACK マネージドクラスター (Basic Edition) および 専用クラスター
スケジューリング方法 | 典型的なシナリオ | 優先度ベースのスケジューリング | ECI Pod の優先的なスケールイン | 推奨 | 関連操作 | |
ラベル: | Pod を仮想ノードにのみスケジュールします。Pod をどの仮想ノードにスケジュールするかは指定できません。 | サポートされていません | N/A | 推奨 | ||
UnitedDeployment | デプロイメントのレプリカ数に基づいて Pod を ECS または仮想ノードにスケジュールするポリシーの作成をサポートします。たとえば、レプリカ数が 10 未満の場合はサブスクリプション ECS リソースが優先的に使用されます。レプリカ数が 10 より大きく 20 以下の場合、Spot リソースが使用されます。レプリカ数が 20 より大きい場合、ECI リソースが使用されます。 | サポートされています | サポートされています | 推奨 | ||
Kubernetes ネイティブのスケジューリングセマンティクス | nodeSelector | Toleration を追加した後、Pod を仮想ノードにのみスケジュールし、Pod をどの仮想ノードにスケジュールするかを指定できます。 | サポートされていません | サポートされています | 非推奨 ACK マネージドクラスター (Pro Edition) と比較して、ACK マネージドクラスター (Basic Edition) および 専用クラスター の kube-scheduler は、Pod のスケジューリング中に基盤となるインベントリを認識できません。そのため、作成が成功する確実性が低下します。 | |
アフィニティとアンチアフィニティ | Taint、Toleration、および NodeAffinity を使用して、Pod が ECI のみ、ECS のみ、または ECS に優先的にスケジュールされるように指定できます (たとえば、ECS ノードのリソースが不足している場合に仮想ノードにスケジュールするなど)。これは弾力的なスケジューリングポリシーです。 | サポートされています (非厳密なスケジューリングポリシー) | サポートされています | |||
Pod トポロジースプレッド制約 | 高可用性とパフォーマンス専有型のスケジューリング要件を満たすために、ゾーンをまたいで Pod を分散させます。 | サポートされていません | サポートされています | |||
ElasticWorkload (開発がアクティブでない状態です。UnitedDeployment の使用をお勧めします。) | デプロイメントのレプリカをグループ単位で ECS または仮想ノードにスケジュールします。 | サポートされています | サポートされています | 非推奨 | ||
ElasticResource (アノテーション: (開発がアクティブでない状態) | 2 つの弾力的なスケジューリングポリシーのみがサポートされています:
| サポートされています | サポートされています | 非推奨 | ||
virtual-kubelet-autoscaler コンポーネント (廃止) | ECS ノードへのスケジューリングを優先し、ECS ノードのリソースが不足している場合にのみ仮想ノードにスケジュールすることのみをサポートします。 | サポートされています | サポートされています | 非推奨 | なし | |