Kubernetes の XNUMX つのレベルの自動スケーリング: それらを効果的に使用する方法

Kubernetes を完全にマスターするには、クラスター リソースをスケーリングするさまざまな方法を知る必要があります。 システム開発者によると、これは Kubernetes の主要なタスクの XNUMX つです。 水平および垂直の自動スケーリングとクラスターのサイズ変更メカニズムの概要と、それらを効果的に使用する方法に関する推奨事項を提供しました。

論文 Kubernetes オートスケーリング 101: クラスター オートスケーラー、水平オートスケーラー、および垂直ポッド オートスケーラー 自動スケーリングを実装したチームによって翻訳されました Mail.ru の Kubernetes aaS.

スケーリングについて考えることが重要な理由

Kubernetes - リソース管理とオーケストレーションのためのツール。 もちろん、ポッドのデプロイ、監視、管理の優れた機能をいじってみるのは良いことです (ポッドは、リクエストに応じて起動されるコンテナのグループです)。

ただし、次の質問についても考慮する必要があります。

1. モジュールとアプリケーションを拡張するにはどうすればよいですか?
2. コンテナの運用と効率を維持するにはどうすればよいでしょうか?
3. ユーザーによるコードやワークロードの継続的な変更にどのように対応するか?

リソースとパフォーマンスのバランスをとるように Kubernetes クラスターを構成することは困難な場合があり、Kubernetes の内部動作に関する専門知識が必要です。 アプリケーションまたはサービスのワークロードは、XNUMX 日を通して、または XNUMX 時間にわたって変動する可能性があるため、バランスをとることは継続的なプロセスであると考えるのが最善です。

Kubernetes 自動スケーリング レベル

効果的な自動スケーリングには、次の XNUMX つのレベル間の調整が必要です。

1. ポッド レベル。水平 (水平ポッド オートスケーラー、HPA) および垂直オートスケーラー (垂直ポッド オートスケーラー、VPA) を含みます。 これにより、コンテナーで使用できるリソースがスケーリングされます。
2. クラスター レベル。クラスター オートスケーラー (CA) によって管理され、クラスター内のノードの数を増減します。

水平オートスケーラー (HPA) モジュール

名前が示すように、HPA はポッド レプリカの数をスケーリングします。 ほとんどの Devops は、レプリカの数を変更するトリガーとして CPU とメモリの負荷を使用します。 ただし、以下に基づいてシステムを拡張することは可能です。 カスタムメトリック彼らの 組み合わせ あるいは 外部指標.

高レベルの HPA 動作図:

1. HPA は、インストール中に指定されたメトリック値をデフォルトの 30 秒間隔で継続的にチェックします。
2. 指定されたしきい値に達すると、HPA はモジュールの数を増やそうとします。
3. HPA は、デプロイメント/レプリケーション コントローラー内のレプリカの数を更新します。
4. 次に、展開/複製コントローラーは、必要な追加モジュールを展開します。

HPA は、メトリックしきい値に達するとモジュール展開プロセスを開始します。

HPA を使用する場合は、次の点を考慮してください。

• デフォルトの HPA チェック間隔は 30 秒です。 フラグによって設定されます 水平ポッドオートスケーラー同期期間 コントローラーマネージャーで。
• デフォルトの相対誤差は 10% です。
• モジュール数が最後に増加した後、HPA はメトリクスが XNUMX 分以内に安定すると予想します。 この間隔はフラグによって設定されます 水平ポッドオートスケーラーアップスケール遅延.
• 最後にモジュール数を減らした後、HPA は安定するまで XNUMX 分間待機します。 この間隔はフラグによって設定されます 水平ポッドオートスケーラーダウンスケール遅延.
• HPA は、レプリケーション コントローラーではなく展開オブジェクトで最もよく機能します。 水平自動スケーリングは、レプリケーション コントローラーを直接操作するローリング アップデートと互換性がありません。 デプロイメントの場合、レプリカの数はデプロイメント オブジェクトに直接依存します。

ポッドの垂直自動スケーリング

垂直自動スケーリング (VPA) は、より多くの (またはより少ない) CPU 時間またはメモリを既存のポッドに割り当てます。 ステートフルまたはステートレス ポッドに適していますが、主にステートフル サービスを対象としています。 ただし、最初に割り当てられたリソースの量を自動的に調整する必要がある場合は、ステートレス モジュールに VPA を使用することもできます。

VPA は OOM (メモリ不足) イベントにも応答します。 CPU 時間とメモリを変更するには、ポッドを再起動する必要があります。 再起動すると、VPA は割り当てバジェット (ポッド配布予算、PDB) 必要なモジュールの最小数を保証します。

各モジュールの最小リソースと最大リソースを設定できます。 したがって、割り当てられるメモリの最大量を 8 GB に制限できます。 これは、現在のノードがコンテナーごとに 8 GB を超えるメモリーを確実に割り当てることができない場合に役立ちます。 詳細な仕様と動作メカニズムについては、 公式 VPA ウィキ.

さらに、VPAには興味深いレコメンド機能（VPA Recommender）があります。 すべてのモジュールのリソース使用量と OOM イベントを監視し、履歴メトリクスに基づくインテリジェントなアルゴリズムに基づいて新しいメモリと CPU 時間の値を提案します。 ポッド ハンドルを取得して、推奨されるリソース値を返す API もあります。

VPA Recommender はリソースの「制限」を追跡しないことに注意してください。 これにより、モジュールがノード内のリソースを独占する可能性があります。 大量のメモリや CPU の消費を避けるために、名前空間レベルで制限を設定することをお勧めします。

高レベルの VPA 操作スキーム:

1. VPA は、インストール中に指定されたメトリック値をデフォルトの 10 秒間隔で継続的にチェックします。
2. 指定されたしきい値に達すると、VPA は割り当てられたリソースの量を変更しようとします。
3. VPA は、デプロイメント/レプリケーション コントローラー内のリソースの数を更新します。
4. モジュールが再起動されると、すべての新しいリソースが作成されたインスタンスに適用されます。

VPA は必要な量のリソースを追加します

VPA を使用する場合は、次の点に注意してください。

• スケーリングにはポッドの必須の再起動が必要です。 これは、変更後の動作が不安定になるのを避けるために必要です。 信頼性を確保するために、モジュールは再起動され、新しく割り当てられたリソースに基づいてノード間で分散されます。
• VPA と HPA はまだ相互に互換性がないため、同じポッド上で実行できません。 同じクラスター内で両方のスケーリング メカニズムを使用している場合は、それらのメカニズムが同じオブジェクト上でアクティブ化されないように設定してください。
• VPA は、過去と現在の使用状況のみに基づいて、リソースに対するコンテナーのリクエストを調整します。 リソース使用量の制限は設定されません。 アプリケーションが正しく動作せず、ますます多くのリソースを引き継ぎ始めるという問題が発生する可能性があります。これにより、Kubernetes がこのポッドをオフにすることになります。
• VPA はまだ開発の初期段階にあります。 近い将来にシステムが変更される可能性があることに備えてください。 について読むことができます 既知の制限事項 и 開発計画。 したがって、VPA と HPA の共同運用、およびそれらの垂直自動スケーリング ポリシー (たとえば、特別なラベル「VPA が必要」) を備えたモジュールの展開を実装する計画があります。

Kubernetes クラスターの自動スケーリング

クラスター オートスケーラー (CA) は、待機中のポッドの数に基づいてノードの数を変更します。 システムは保留中のモジュールを定期的にチェックし、より多くのリソースが必要であり、クラスターが設定された制限を超えていない場合はクラスター サイズを増やします。 CA はクラウド サービス プロバイダーと通信し、そこに追加のノードを要求したり、アイドル状態のノードを解放したりします。 CA の最初の一般利用可能なバージョンは、Kubernetes 1.8 で導入されました。

SA 操作の高レベルのスキーム:

1. CA は、デフォルトの 10 秒間隔で保留中のモジュールをチェックします。
2. クラスターに割り当てられる十分なリソースがないために XNUMX つ以上のポッドがスタンバイ状態になっている場合、クラスターは XNUMX つ以上の追加ノードのプロビジョニングを試みます。
3. クラウド サービス プロバイダーが必要なノードを割り当てると、そのノードはクラスターに参加し、ポッドを提供できるようになります。
4. Kubernetes スケジューラは、保留中のポッドを新しいノードに分散します。 この後も一部のモジュールが待機状態のままである場合、プロセスが繰り返され、新しいノードがクラスターに追加されます。

クラウド内のクラスターノードの自動プロビジョニング

CA を使用する場合は、次の点を考慮してください。

• CA は、CPU 負荷に関係なく、クラスター内のすべてのポッドが実行できる余地を確保します。 また、クラスター内に不必要なノードがないことを確認しようとします。
• CA は、約 30 秒後にスケーリングの必要性を登録します。
• ノードが不要になると、CA はデフォルトで 10 分間待機してからシステムをスケールアウトします。
• 自動スケーリング システムにはエクスパンダという概念があります。 これらは、新しいノードを追加するノードのグループを選択するためのさまざまな戦略です。
• オプションは責任を持って使用してください クラスターオートスケーラー.kubernetes.io/safe-to-evict (true)。 多数のポッドをインストールする場合、またはそれらの多くがすべてのノードに分散している場合、クラスターをスケールアウトする機能が大幅に失われます。
• 使用 ポッド破壊予算ポッドが削除されるのを防ぐためです。ポッドが削除されると、アプリケーションの一部が完全に破損する可能性があります。

Kubernetes オートスケーラーが相互に対話する方法

完全に調和させるには、自動スケーリングをポッド レベル (HPA/VPA) とクラスター レベルの両方で適用する必要があります。 これらは比較的簡単に相互作用します。

1. HPA または VPA は、ポッド レプリカまたは既存のポッドに割り当てられたリソースを更新します。
2. 計画されたスケーリングに十分なノードがない場合、CA は待機状態のポッドの存在に気づきます。
3. CA は新しいノードを割り当てます。
4. モジュールは新しいノードに配布されます。

協調的な Kubernetes スケールアウト システム

Kubernetes 自動スケーリングでよくある間違い

自動スケーリングを実装しようとすると、devops が遭遇する一般的な問題がいくつかあります。

HPA と VPA は、メトリクスと一部の履歴データに依存します。 割り当てられたリソースが不十分な場合、モジュールは最小化され、メトリクスを生成できなくなります。 この場合、自動スケーリングは決して行われません。

スケーリング操作自体は時間に敏感です。 ユーザーが問題や障害に気づく前に、モジュールとクラスターを迅速に拡張したいと考えています。 したがって、ポッドとクラスターの平均スケーリング時間を考慮する必要があります。

理想的なシナリオ - 4 分:

1. 30秒。 ターゲット メトリックの更新: 30 ～ 60 秒。
2. 30秒。 HPA はメトリック値をチェックします: 30 秒。
3. 2秒未満です。 ポッドが作成され、1 秒間の待機状態になります。
4. 2秒未満です。 CA は待機中のモジュールを確認し、プロビジョニング ノードに呼び出しを送信します: 1 秒。
5. 3分。 クラウド プロバイダーがノードを割り当てます。 K8 は、準備ができるまで最大 10 分間待機します (いくつかの要因によって異なります)。

最悪の (より現実的な) シナリオ - 12 分:

1. 30秒。 ターゲット指標を更新します。
2. 30秒。 HPA はメトリック値をチェックします。
3. 2秒未満です。 ポッドが作成され、スタンバイ状態になります。
4. 2秒未満です。 CA は待機中のモジュールを確認し、ノードをプロビジョニングするための呼び出しを行います。
5. 10分。 クラウド プロバイダーがノードを割り当てます。 K8s は準備ができるまで待機します。 待ち時間は、ベンダーの遅延、OS の遅延、サポート ツールなどのいくつかの要因によって異なります。

クラウドプロバイダーのスケーリングメカニズムと当社の CA を混同しないでください。 後者は Kubernetes クラスター内で実行され、クラウド プロバイダー エンジンはノード分散ベースで動作します。 ポッドやアプリケーションで何が起こっているのかはわかりません。 これらのシステムは並行して動作します。

Kubernetes でスケーリングを管理する方法

1. Kubernetes は、リソース管理およびオーケストレーション ツールです。 ポッドとクラスター リソースを管理するための操作は、Kubernetes をマスターするための重要なマイルストーンです。
2. HPA と VPA を考慮したポッドのスケーラビリティのロジックを理解します。
3. CA は、ポッドとコンテナーのニーズをよく理解している場合にのみ使用してください。
4. クラスターを最適に構成するには、さまざまなスケーリング システムがどのように連携して機能するかを理解する必要があります。
5. スケーリング時間を見積もるときは、最悪の場合と最良の場合のシナリオを念頭に置いてください。

出所： habr.com