Container Service for Kubernetes (ACK) クラスターのサイズがポッドスケジューリング要件を満たさない場合、ACKのノードスケーリング機能を使用してノードリソースを自動的にスケーリングできます。 ACKは、ノードオートスケーリングとノードインスタントスケーリングのソリューションを提供します。 ノードインスタントスケーリングと比較して、ノードオートスケーリングはより効率的で使いやすいです。
あなたが始める前に
ACKのノードスケーリングソリューションをより適切に使用し、ビジネスに最適なソリューションを選択するには、ノードスケーリング機能を有効にする前にこのトピックを読むことをお勧めします。
このトピックを読む前に、手動スケーリング、自動スケーリング、水平スケーリング、および垂直スケーリングの用語を理解することをお勧めします。 詳細については、「Kubernetes公式ドキュメント」をご参照ください。
ノードのスケーリングのしくみ
Kubernetesでのノードスケーリングは、リソース使用率のしきい値に基づく従来のスケーリングモデルとは異なります。 通常、データセンターや他のオーケストレーションシステムからKubernetesにビジネスを移行した後、ノードスケーリングの問題を修正する必要があります。
従来のスケーリングモデルは、リソース利用に基づいて機能します。 例えば、クラスタは3つのノードを含む。 ノードのCPU使用率とメモリ使用率がしきい値を超えると、システムは新しいノードをクラスターに追加します。 しかしながら、このモデルには以下の問題がある。
ACKは、ノードスケーリング (リソースレイヤー) モデルとワークロードスケーリング (スケジューリングレイヤー) モデルを使用して、上記の問題を修正します。 ノードスケーリングモデルは、リソース使用率に基づいてポッド (スケジュール可能ユニット) のスケーリングをトリガーします。 次のセクションでは、ノードのスケーリングについて詳しく説明します。
スケーリングソリューション: node auto Scalingとnode instant scaling
ノードスケーリングモデルは、リソース層でリソースをスケーリングします。 クラスターのサイズがポッドスケジューリング要件を満たさない場合、モデルはノードリソースをスケーリングします。 ACKは、2つのノードスケーリングソリューションを提供します。
概要
このトピックで使用されるスケーリング統計は理論値であり、自動スケーリングはカスタムイメージに基づいて実装されます。 ビジネス環境の実際の統計が優先されます。 カスタムイメージの詳細については、「カスタムイメージの作成」をご参照ください。
解決策 | コンポーネント | 説明 |
解決策1: ノードの自動スケーリング | cluster-autoscaler | コンポーネントは、ラウンドロビン方式でクラスタのステータスをチェックおよび更新します。 スケーリング条件が満たされると、コンポーネントは自動的にノードをスケーリングします。 |
解決策2: ノードのインスタントスケーリング | ACK GOATScaler | イベント駆動型ノードの自動スケーラー。 大規模なクラスターまたは連続したスケールアウトシナリオでは、コンポーネントは効率的なリソース配信を保証できます。 クラスターで自動スケーリング機能が有効になっているノードプールに100を超えるノードが含まれている場合、またはクラスター内の20を超えるノードプールで自動スケーリング機能が有効になっている場合、クラスターは大規模と見なされます。 このコンポーネントのスケーリング速度 (最初のスケジューリングの失敗からスケジューリングの成功までにかかる時間) 、成功率、およびリソースフラグメント削減は、それぞれ45秒、99% 、および30% である。 このコンポーネントは、カスタムスケーリングポリシーで使用する場合、拡張性が高くなります。 |
ソリューションの比較
クラスター内のノードプールで自動スケーリング機能が有効になっており、高速スケーリングモードを使用していない場合、node instant scaling機能は、ノードプール構成の元のセマンティクスと動作と互換性があります。 さらに、すべてのタイプのポッドに対してノードインスタントスケーリング機能をシームレスに有効にできます。 このセクションでは、node instant scalingとnode auto scalingを比較します。
メリット | ノードの自動スケーリング | ノードの即時スケーリング |
スケーリング速度と効率 | スケーリングアクティビティには、標準モードで60秒、高速モードで50秒かかります。 | Alibaba Cloud ContainerOSと一緒にイベント駆動型スケーリングを使用して、リソーススケーリングを高速化できます。 この場合、各スケーリングアクティビティは35〜55秒を必要とする。 |
スケーリングアクティビティの期間が1分に達すると、自動スケーリングでパフォーマンスのボトルネックが発生します。 自動スケーリングの効率は、ノードプールの数とスケーリングシナリオに基づいて変動します。 たとえば、ノードプールの数が100を超えると、スケーリングアクティビティの期間は100〜150秒に増加します。 | ノードプールまたはポッドの数が増加しても、スケーリングアクティビティの期間は大幅に増加しません。 したがって、このソリューションは高速スケーリングが必要なシナリオに適しています。 | |
このソリューションはラウンドロビンモードを使用し、クラスターステータスの更新に依存します。 オートスケーリングの最小レイテンシは5秒です。 | このソリューションはイベント駆動型です。 オートスケーリングのレイテンシは1〜3秒です。 | |
リソースのスケーリング成功率 | クラウドリソースのインベントリは頻繁に変更されます。 異なるインスタンスタイプの使用やインベントリ不足などの問題により、ノードオートスケーリングの成功率は約97% です。 | 自動インベントリ選択ポリシーを設定して、事前定義されたフィルター条件と優先順位に基づいて数千のAlibaba Cloudインスタンスタイプの中から不十分なインスタンスタイプを除外し、最適なインスタンスタイプを選択するか、指定されたすべてのインスタンスタイプが不十分な場合にスケールアウト条件を満たす他のインスタンスタイプを追加できます。 これにより、O&M作業が大幅に簡素化され、自動スケーリングの成功率が99% に向上します。 |
スケールアウトアクティビティは、ノードプール構成で指定されたインスタンスタイプに基づいて実行されます。 複数のインスタンスタイプが指定される場合、最も低い仕様を有するインスタンスタイプが、スケールアウトアクティビティ中に選択されることが好ましい。 | スケールアウトアクティビティには、複数のインスタンスタイプを指定できます。 | |
リソースのスケーリングが失敗すると、オートスケーラは定期的に再試行します。 | 指定されたインスタンスタイプが不十分な場合、オートスケーラはアラートを生成できます。 | |
使用とO&M | node auto scalingと比較して、node instant scalingは次の点で使いやすいです。
| |
スケジューリングポリシー | node auto scalingソリューションが提供するスケジューリング機能に加えて、node instant scalingソリューションは次の機能もサポートしています。 | |
node instant scalingソリューションでは、Bin PackingおよびPreBind (カスタム機能) ポリシーを使用して、リソースフラグメント率を30% に下げることができます。 | ||
ノードのインスタントスケーリングの制限
node instant scalingソリューションを使用する場合は、node instant scalingの制限も理解する必要があります。
ノードインスタントスケーリングは、迅速モードをサポートしていません。
ノードプールには、スケールアウトバッチごとに最大180個のノードを含めることができます。
特定のクラスターに対してスケールインを無効にすることはできません。
説明特定のノードのスケールインを無効にするには、ノードのインスタントスケーリングによるノードの削除を防ぐにはどうすればよいですか?
ノードスケーリングソリューションの選択に関する提案
[ソリューションの比較] と [ノードのインスタントスケーリングの制限] のセクションを読んだ後、ビジネスがスケーリング速度、スケーリング成功率、およびO&Mコストに左右されず、ノードのインスタントスケーリングの制限に準拠できない場合は、ノードの自動スケーリングを使用できます。 ビジネスに次の要件がある場合は、ノードインスタントスケーリングを使用することを推奨します。
クラスターのサイズが大きくなると、ノードオートスケーリングの効率が大幅に低下します。 大規模なクラスターを使用する場合は、クラスターサイズがスケーリング効率に与える影響が小さいため、[node instant scaling] を選択します。 クラスターで自動スケーリング機能が有効になっているノードプールに100を超えるノードが含まれている場合、またはクラスター内の20を超えるノードプールで自動スケーリング機能が有効になっている場合、クラスターは大規模と見なされます。
ビジネスには、より高速なリソーススケーリング速度が必要です。 ノードオートスケーリングの標準モードのスケーリングアクティビティには60秒かかり、ノードインスタントスケーリングの標準モードのスケーリングアクティビティには45秒しかかかりません。
スケールアウトバッチの数は制御できません。 ノードプールは、通常、複数の連続したスケールアウトアクティビティに関与する。 連続したスケーリングシナリオでは、ノードオートスケーリングのパフォーマンスが低下し、スケーリング効率が頻繁に変動します。 ただし、ノードのインスタントスケーリングは、スケーリングアクティビティを完了するのにまだ約45秒かかります。
使用上の注意
クォータと制限
仮想プライベートクラウド (VPC) のルートテーブルに最大200のカスタムルートエントリを追加できます。 クォータ制限を増やすには、クォータセンターコンソールにログインし、アプリケーションを送信します。 他のリソースのクォータとクォータ制限を増やす方法の詳細については、「クォータと制限」トピックの「依存クラウドサービスのクォータ」セクションをご参照ください。
自動スケーリング機能を有効にして、ノードプール内のノードの最大数を適切に設定することを推奨します。 VPC CIDRブロックやvSwitchなど、指定された数のノードに対して依存リソースとクォータが十分であることを確認してください。 そうしないと、スケールアウト活動が失敗する可能性があります。 自動スケーリング機能が有効になっているノードプールでサポートされるノードの最大数の詳細については、「ノード自動スケーリングの有効化」をご参照ください。 ACKネットワークを計画する方法の詳細については、「ACKクラスターのネットワークを計画する」をご参照ください。
ノードスケーリング機能はサブスクリプションノードをサポートしていません。 自動スケーリング機能を有効にしてノードプールを作成する場合は、ノードプールの課金方法をサブスクリプションに設定しないでください。 既存のノードプールの自動スケーリング機能を有効にする場合は、ノードプールにサブスクリプションノードがないことを確認してください。
依存リソースのメンテナンス
ノードスケーリング機能によって追加されたECSノードにEIPアドレス (EIP) が関連付けられている場合、ECSコンソールでECSノードを直接削除しないでください。 そうしないと、EIPは自動的にリリースできません。
関連ドキュメント
ノードオートスケーリングとノードインスタントスケーリングの詳細とその違いについては、「ノードオートスケーリングの有効化」と「ノードインスタントスケーリングの有効化」をご参照ください。
ノードスケーリングに関するよくある質問 (FAQ) の詳細については、「ノードオートスケーリングに関するFAQ」をご参照ください。