クラスターノードの弾性スケーリング

弾性スケーリングには主に 3 つの側面があります。

HPAは使用率に基づいてポッドの数を自動的に調整します
VPAは履歴データに基づいてポッドのリクエストと制限を自動的に設定します
CAは、使用状況に応じてノードの数を自動的に調整します

この記事では主にノードの拡張と削減の部分について説明します。

1. オートスケーラー

オートスケーラーは、Kubernetes コミュニティによって管理されているプロジェクトです。現在、オートスケーラーコンポーネントは、VPA と CA のスケーリング機能をすでに提供しています。 EKS、CCE、ACK、TKE などの主流メーカーはすべて、CA エラスティック拡張にこのコンポーネントに依存しています。公式データは見つかりませんでしたが、同僚と話したところ、CA 拡張が完了するまでに約 2 ～ 3 分かかると言われました。

1.1 VPAの垂直拡張

HPA と同様に、デプロイメント用に VPA オブジェクトを作成する必要があります。

 apiVersion :自動スケーリング.k8s .io / v1
種類: VerticalPodAutoscaler
メタデータ:
 名前: my - app - vpa
仕様:
 ターゲットリファレンス:
 apiバージョン: "apps/v1"
 種類:デプロイメント
 名前:私のアプリ
 更新ポリシー:
 更新モード: 「自動」

VPA と HPA はどちらも、監視インジケーターデータを取得するために Metrics サーバーに依存します。オートスケーラーの VPA には、複数のリソース設定用の推奨機能が組み込まれており、リソース設定を制限することもできます。

VPA によって設定されたリソース値は、名前空間内の制限範囲の制約を超える可能性があることに注意してください。

また、VPA と HPA を同時に使用しないでください。これら 2 つの方法は互いに矛盾します。 Pod 数の水平方向の拡張と Pod 制限の垂直方向の拡張が同時にトリガーされる場合があります。

1.2 CA ノードのスケーリング

トリガー条件:

容量拡張中、ノードはポッド要求の要件を満たすことができず、保留状態になります。
スケールダウンすると、ノードの負荷が低くなり、ノード上のポッドを他のノードに移動できるようになります。

対応メーカー:

アリクラウド
AWS
アズール
百度クラウド
グーセ
ファーウェイクラウド
リノード
テンセントクラウド
...

多くのメーカーがコンポーネントにプロバイダーを提供しています。オートスケーラーは定期的な検出を使用して、スケールアップとスケールダウンのためのメーカーのインターフェースアクションをトリガーします。

また、CA とメーカーが提供するノード垂直スケーリングを同時に使用しないでください。水平スケーリングと垂直スケーリングは、連携して機能するためのバランスポイントを見つける必要があります。

2. クラウドファクトリーホスティングクラスターの弾力的なスケーリング

EKS、CCE、ACK、TKE はすべて、ノードの弾力的なスケーリングを実現するために、独自の IaaS サービスと組み合わせてオートスケーラーコンポーネントを使用します。

基礎レイヤーではオートスケーラーコンポーネントが使用されるため、これは製品レベルのプレゼンテーションにも反映されます。以下に示すように、EKS を例に挙げます。

EKS クラスターには複数のノードグループがあり、各ノードグループが弾力的にスケーラブルなユニットを構成します。次の図に示すように、ノードグループには少なくとも 1 個、最大 7 個のノードが含まれます。

EKS ノードの弾力性はノードグループ用です。同じノードグループ内のノードには、同じマシン構成、テイント、ラベル、およびホスト起動テンプレートがあります。 EKS はノード拡張が必要であると判断すると、ノードグループで許可されるノードの最大数に基づいて容量を拡張します。これにより、拡張されたノードが正しく汚染され、ラベル付けされ、Kubernetes スケジューラによって直接使用できるようになります。

さらに、ノードグループの概念は、製品レベルおよび使用レベルでスーパーノードにパッケージ化することもできます。ノード数の上限が十分に大きい限り、ノードグループは非常に大きなコンピューティングリソースとメモリリソースのプールを提供できます。

3. ノード予備戦略

クラウドファクトリーの使用範囲に応じて、クラスターは次の 3 つのカテゴリに分類されます。

完全に管理されており、クラスタ内のホストを直接管理することはできません。
セミマネージド、マスターノードを管理できない、クラウドファクトリーがコントロールプレーンを維持
非管理型、クラウドファクトリーIaaSセルフデプロイクラスタをベースとし、完全に自律制御

完全に管理されたクラスターの場合、クラウドファクトリーはスケールアップとスケールダウンの機能を提供します。以下では、主にセミマネージドクラスターとアンマネージドクラスターについて説明します。

3.1 コールドスタンバイ

新しいノードが必要な場合は、新しいマシンを申請して構成を初期化します。

利点:

低コスト、オンデマンドで新しいノードを申請
適応性に優れ、クラスタのバージョンを考慮する必要がなく、必要に応じて依存関係をインストールします。
インストールツールが提供する機能を使用した簡単な操作により、スムーズで完全な拡張が可能になります。
可用性ゾーンやファイアウォールなどを考慮する必要はありません。

欠点:

速度は遅く、通常は 10 分以上かかりますが、依存ソースが遅い場合はさらに時間がかかることがあります。
標準化が不可能、メンテナンスされたクラスタが単一のツールでインストールされていない、または Kubeadm を自分でパッケージ化する必要がある

3.2 ホットスタンバイ

ホットリソースプールを作成し、一定数のリソースを維持します。ホストリソースが必要な場合は、クラスターに直接追加されます。

利点:

速い

欠点:

コストが高く、クラスターバージョンごとに予備ノード (1.16、1.20、1.21 など) が必要です。
ホットスタンバイプールは複雑です。異なる IDC、異なるリージョン、異なる AZ のノードにはアクセスできないネットワークやファイアウォールが存在する可能性があり、ホットスタンバイプールが複雑になります。

3.3 セミホットスタンバイ

リージョンホットスタンバイプールを作成し、マシンを起動して、containerd、chrony、conntrack などの基本的な依存パッケージのみをインストールします。 Kubelet など、クラスターバージョンに関連する依存関係をインストールしないでください。同時に、リソースプールへの予備領域のファイアウォールを事前に解除し、ホットスタンバイプール内のホスト数を維持するためのコントローラが必要となります。

アドバンテージ：