クラスターの容量計画がアプリケーション Pod のスケジューリング要件を満たせない場合、ノードスケーリング機能を使用してノードリソースを自動的にスケーリングし、スケジューリング容量を増やすことができます。ACK は、ノードの自動スケーリングとノードのインスタントスケーリングという 2 つの弾性スケーリングソリューションを提供します。ノードのインスタントスケーリングは、ノードの自動スケーリングよりも高速なスケーリング、高い配信効率、そして低い導入障壁を提供します。
開始する前に
この概要は、ACK が提供するノードスケーリングソリューションを理解し、ノードスケーリング機能を有効にする前に、ビジネスニーズに最も適したものを選択するのに役立ちます。
このトピックを読む前に、Kubernetes の公式ドキュメントを読んで、手動スケーリング、自動スケーリング、水平スケーリング、垂直スケーリングなどのスケーリングの概念に慣れておくことをお勧めします。
仕組み
Kubernetes では、ノードスケーリングは使用量のしきい値に基づく従来のモデルとは異なる動作をします。この違いを理解することは、従来のデータセンターや他のオーケストレーションシステムから Kubernetes クラスターに移行する際に重要です。
従来の弾性スケーリングモデルは使用量に基づいています。たとえば、クラスター内のノードの CPU とメモリ使用量が特定のしきい値を超えると、システムは新しいノードを追加してスケールアウトします。しかし、このモデルには以下の問題があります。
これらの問題に対処するため、ACK は 2 層の弾性モデルを使用します。ノードスケーリング (リソースレイヤー) とワークロードスケーリング (スケジューリングレイヤー) です。たとえば、ノードスケーリング機能は、リソース使用量に基づいて、スケジューリング単位であるアプリケーションレプリカの変更をトリガーします。以下のセクションで技術的な詳細を説明します。
弾性スケーリングソリューション: ノードの自動スケーリングとノードのインスタントスケーリング
ノードスケーリングは、リソースレイヤーでの弾性スケーリング機能です。クラスターの容量がアプリケーション Pod のスケジューリング要件を満たせない場合に、ノードリソースを自動的にスケーリングしてスケジューリング容量を増やします。ACK は 2 つのノードスケーリングソリューションを提供します。
はじめに
クラスター内で実行できる弾性スケーリングコンポーネントは 1 つだけです。2 つの弾性スケーリングソリューションを併用することはできません。ノードスケーリング機能を有効にするには、「ノードの自動スケーリングを有効にする」または「ノードのインスタントスケーリングを有効にする」の標準的な手順に従ってください。
このトピックで提供される弾性スケーリングのパフォーマンスデータは、弾性スケーリング用に最適化されたカスタムイメージに基づく理論値です。実際のパフォーマンスは、ビジネス環境によって異なる場合があります。カスタムイメージの詳細については、「カスタムイメージで弾性スケーリングを最適化する」をご参照ください。
ソリューション | 弾性スケーリングコンポーネント | 説明 |
ソリューション 1: ノードの自動スケーリング | cluster-autoscaler コンポーネント | ポーリングを使用してクラスターの状態を定期的に維持およびチェックし、スケールアウトまたはスケールインの要件を満たす条件を見つけ、クラスターノードを自動的にスケーリングします。 |
ソリューション 2: ノードのインスタントスケーリング | ノードのインスタントスケーリングコンポーネント | イベント駆動型のノードスケーリングコントローラーです。大規模クラスター (たとえば、自動スケーリングが有効なノードプールに 100 を超えるノードがある、またはそのようなノードプールが 20 以上ある) や連続したスケールアウトアクティビティなどのシナリオで、より優れた弾性リソース配信を保証します。スケーリング速度 (最初の Pod スケジューリング失敗から成功したスケジューリングまで) は 45 秒で安定しており、成功率は 99% に達し、リソースの断片化は約 30% 削減されます。また、カスタムスケーリングポリシーに対する拡張性も向上しています。 |
ソリューションの比較
クラスター内のノードプールで自動弾性スケーリングが有効になっており、その [スケーリングモード] が [非スイフトモード] に設定されている場合、ノードのインスタントスケーリングはノード自動スケーリングコンポーネントのセマンティクスと動作に互換性があります。これにより、すべてのタイプのアプリケーションでシームレスな移行が可能になります。このセクションでは、ノードのインスタントスケーリングのノードの自動スケーリングと比較した最適化された機能について説明します。
強化された機能 | ノードの自動スケーリング | ノードのインスタントスケーリング |
スケーリング速度と効率 | 単一のスケーリングアクティビティの場合、スケーリング速度は標準モードで約 60 秒、swift モードで約 50 秒です。 | イベント駆動メカニズムを通じてスケーリング操作をトリガーし、Alibaba Cloud ContainerOS の機能を使用して弾性スケーリングを加速します。スケーリング速度は約 45±10 秒です。 |
スケーリング時間が 1 分に達すると、スケーリング速度はボトルネックに遭遇します。弾性スケーリング速度は、異なる規模 (複数のノードプール) や異なるシナリオ (連続スケーリング) でも大幅なジッターを示します。たとえば、ノードプールの数が 100 を超えると、スケーリング速度は 100 秒から 150 秒の範囲に低下します。 | ノードプールと Pod の数が増えても、パフォーマンスは大幅に低下しません。これにより、弾性配信速度に対する要件が高いシナリオにより適しています。 | |
ポーリングモデルを使用し、クラスター状態のメンテナンスへの依存によって制限されます。最小の弾性スケーリング感度は 5 秒です。 | イベント駆動型であり、応答モデルを使用します。弾性スケーリング感度は 1 秒から 3 秒です。 | |
リソース配信の確実性 | クラウドリソースの在庫は頻繁に変化します。複雑なインスタンスタイプの組み合わせや在庫不足などの問題により、ノードの自動スケーリングの弾性スケーリング成功率は約 97% です。 | 自動在庫選択ポリシーをサポートしています。設定したフィルター条件と順序に基づいて、何千もの Alibaba Cloud インスタンスタイプの組み合わせから在庫切れのインスタンスタイプを除外し、スケールアウトに最も適したタイプを選択するか、在庫が不十分な場合は適格なタイプで補います。これにより、O&M エンジニアがインスタンスタイプを選択する負担が大幅に軽減され、配信成功率が 99% に向上します。 |
ノードプールで設定されたものと同じインスタンスタイプのスケールアウトをサポートします。複数のタイプが設定されている場合、スケールアウトの要件を満たす最小のインスタンスタイプを選択します。 | 異なるインスタンスタイプのスケールアウトをサポートします。 | |
リソース配信が失敗した場合、定期的に再試行します。これはリアクティブなアプローチです。 | リソース配信が失敗した場合、在庫アラート機能をサポートし、インスタンスタイプの組み合わせに関連する潜在的なリスクを事前に通知します。 | |
使用と O&M のしきい値 | ノードの自動スケーリングと比較して、ノードのインスタントスケーリングは導入の障壁が低くなっています。これは主に以下の側面に反映されています。
| |
スケジューリングポリシー | ノードの自動スケーリングのすべてのスケジューリング機能に加えて、ノードのインスタントスケーリングは次の機能もサポートしています。
| |
ノードのインスタントスケーリングは、Pod に基づいて最適な Bin Packing および PreBind ポリシー (カスタム機能) を選択することをサポートしており、これによりスケジューリングの断片化率を最大 30% 削減できます。 | ||
ノードのインスタントスケーリングの制限
ノードのインスタントスケーリングの制限を理解することは、ノードのインスタントスケーリングソリューションを評価する上で重要な部分です。
swift モードはサポートされていません。
ノードプールは、1 回のバッチで 180 を超えるノードをスケールアウトすることはできません。
クラスターレベルでのスケールインの無効化は現在サポートされていません。
説明ノードレベルでスケールインを無効にする方法については、「特定のノードがノードのインスタントスケーリングによってスケールインされるのを防ぐにはどうすればよいですか？」をご参照ください。
ノードのインスタントスケーリングは、スポットインスタンスの在庫確認をサポートしていません。[課金方法] がスポットインスタンスに設定され、[スポットインスタンスの容量を補うためにオンデマンドインスタンスを使用する] が有効になっているノードプールでは、スポットインスタンスの在庫が十分であってもオンデマンドインスタンスがスケールアウトされる可能性があります。
ソリューション選択に関する提案
前述のソリューションの比較とノードのインスタントスケーリングの制限に基づいて、ニーズに適したソリューションを選択できます。ビジネスのスケーリング速度、リソース配信の確実性、および O&M コストに対する要件が比較的低く、ノードのインスタントスケーリングの制限を受け入れられない場合は、ノードの自動スケーリングで十分な場合があります。逆に、次のビジネス要件がある場合は、ノードのインスタントスケーリングが推奨されるソリューションです。
クラスターが大規模である。たとえば、自動スケーリングが有効なノードプールに 100 を超えるノードがある場合、またはそのようなノードプールが 20 以上ある場合、ノードの自動スケーリングのスケールアウト効率は、クラスターサイズが大きくなるにつれて大幅に低下します。対照的に、ノードのインスタントスケーリングのパフォーマンスの変動は少なくなります。
リソース配信速度 (弾性スケーリング速度) に対する要件が高い。単一のスケーリングシナリオでは、標準モードでのノードの自動スケーリングの弾性スケーリング速度は約 60 秒ですが、ノードのインスタントスケーリングでは約 45 秒です。
ビジネスワークロードのバッチは予測不可能であり、同じ弾性ノードプールに対して連続してスケールアウトを実行する必要が頻繁にあります。連続スケーリングモードでは、ノードの自動スケーリングのパフォーマンスは低下し、大幅なジッターを示します。対照的に、ノードのインスタントスケーリングは依然として約 45 秒のスケーリング速度を達成できます。
注
クォータと制限
仮想プライベートクラウド (VPC) のルートテーブルには、最大 200 のカスタムルートを追加できます。このクォータを増やすには、Quota Center に移動してリクエストを送信してください。他のリソースのクォータとその増やし方の詳細については、「基盤となるクラウド依存関係のクォータ」をご参照ください。
自動スケーリングが有効なノードプール内のノードの最大数を適切に設定することをお勧めします。VPC CIDR ブロックや vSwitch などの依存リソースとクォータが、指定されたノード数に対して十分であることを確認してください。そうしないと、スケールアウトアクティビティが失敗する可能性があります。ノードの最大数の設定方法の詳細については、「インスタンス数の設定」をご参照ください。ACK のネットワーク計画の詳細については、「ACK マネージドクラスターのネットワーク計画」をご参照ください。
ノードスケーリング機能はサブスクリプションノードをサポートしていません。新しい自動スケーリングが有効なノードプールを作成するときは、課金方法としてサブスクリプションを選択しないでください。既存のノードプールで自動スケーリングを有効にするには、ノードプールにサブスクリプションノードが含まれていないことを確認してください。
ノードスケーリング機能は現在 Sidecar Containers をサポートしていません。Sidecar Containers を使用するワークロードは、自動スケーリングが有効になっていないノードプールにデプロイしてください。
依存リソースのメンテナンス
EIP をノードにバインドする場合、ECS コンソールでノードスケーリングによってスケールアウトされた ECS ノードを直接削除しないでください。そうしないと、EIP を自動的にリリースできません。
次のステップ
ソリューションの紹介と比較に基づいて、ノードの自動スケーリングを有効にするか、ノードのインスタントスケーリングを有効にするかを選択できます。
ノードスケーリングの使用中に問題が発生した場合は、トラブルシューティングについて「ノードの自動スケーリングに関するよくある質問」をご参照ください。