Kubernetes の自動スケーリングとリソース管理 (レビューとビデオ レポート)

27月XNUMX日のカンファレンスにて ストライク2019では、「DevOps」セクションの一環として、「Kubernetes における自動スケーリングとリソース管理」というレポートが行われました。 K8 を使用してアプリケーションの高可用性を確保し、最高のパフォーマンスを確保する方法について説明します。

伝統に従って、私たちは喜んでご紹介します レポートのビデオ (44 分、記事よりもはるかに有益) とテキスト形式の主要な要約。 行く！

レポートのトピックを一言ずつ分析し、最後から始めましょう。

Kubernetes

ホスト上に Docker コンテナがあるとします。 何のために？ 再現性と分離性を確保し、これによりシンプルで適切な導入が可能になる、CI/CD。 当社ではコンテナを搭載したこのような車両を多数保有しています。

この場合、Kubernetes は何を提供しますか?

1. 私たちはこれらのマシンについて考えるのをやめ、「クラウド」を扱い始めます。 コンテナのクラスター またはポッド (コンテナーのグループ)。
2. さらに、個々のポッドについては考えず、より多くのポッドを管理しますоより大きなグループ。 そのような 高レベルのプリミティブ 特定のワークロードを実行するためのテンプレートがあり、それを実行するために必要なインスタンスの数がこれであるとします。 その後テンプレートを変更すると、すべてのインスタンスが変更されます。
3. ととも​​に 宣言型API 一連の特定のコマンドを実行する代わりに、Kubernetes によって作成される「世界の構造」を (YAML で) 記述します。 繰り返しますが、説明が変更されると、実際の表示も変更されます。

資源管理

CPU

サーバー上で nginx、php-fpm、mysql を実行してみましょう。 これらのサービスでは実際にはさらに多くのプロセスが実行されており、それぞれにコンピューティング リソースが必要です。

(スライド上の数字は「オウム」であり、各プロセスのコンピューティング能力に対する抽象的なニーズを示しています)

これを扱いやすくするには、プロセスをグループに結合するのが論理的です (たとえば、すべての nginx プロセスを XNUMX つのグループ「nginx」にします)。 これを行う簡単かつ明白な方法は、各グループをコンテナーに配置することです。

続行するには、コンテナー (Linux の場合) が何であるかを覚えておく必要があります。 これらの外観は、かなり前に実装されたカーネルの XNUMX つの主要な機能のおかげで可能になりました。 機能, 名前空間 и cgroup。 さらに、他のテクノロジー (Docker のような便利な「シェル」を含む) によってさらなる開発が促進されました。

レポートの文脈では、私たちが興味があるのは、 cgroup, コントロール グループは、リソース管理を実装するコンテナー (Docker など) の機能の一部であるためです。 希望通りにグループにまとめられたプロセスがコントロール グループです。

これらのプロセスの CPU 要件に戻り、今度はプロセスのグループについて説明します。

(繰り返しますが、すべての数字はリソースの必要性を抽象的に表現したものです)

同時に、CPU 自体には特定の有限のリソースがあります。 (この例では 1000 です)、誰もが欠けている可能性があります（すべてのグループのニーズの合計は 150+850+460=1460 です）。 この場合はどうなるのでしょうか？

カーネルはリソースの配布を開始し、それを「公平に」実行し、各グループに同じ量のリソースを与えます。 ただし、最初のケースでは、必要以上にそれらが存在するため (333>150)、超過分 (333-150=183) が予備として残り、これも他の XNUMX つのコンテナーに均等に分配されます。

その結果、最初のコンテナーには十分なリソースがあり、XNUMX 番目のコンテナーには十分なリソースがなく、XNUMX 番目のコンテナーには十分なリソースがありませんでした。 これは行動の結果です Linux の「正直な」スケジューラ - CFS。 その動作は割り当てを使用して調整できます。 体重 それぞれのコンテナ。 たとえば、次のようになります。

XNUMX 番目のコンテナー (php-fpm) でリソースが不足している場合を見てみましょう。 すべてのコンテナ リソースはプロセス間で均等に分散されます。 その結果、マスター プロセスは正常に動作しますが、すべてのワーカーの速度が低下し、必要なものの半分未満しか受信しません。

これが CFS スケジューラの仕組みです。 さらに、コンテナに割り当てる重みを次のように呼びます。 リクエスト。 なぜそうなるのか - 詳細を参照してください。

全体の状況を反対側から見てみましょう。 ご存知のとおり、すべての道はローマに通じており、コンピュータの場合は CPU に通じています。 XNUMX つの CPU、多くのタスク - 信号機が必要です。 リソースを管理する最も簡単な方法は「信号機」です。つまり、あるプロセスに CPU への固定アクセス時間を与え、次に次のプロセスにというように与えます。

このアプローチはハード クォータと呼ばれます (ハード制限)。 単純にこう覚えましょう 限界。 ただし、すべてのコンテナーに制限を分散すると、問題が発生します。mysql は道路を走行していて、ある時点で CPU の必要性が終了しましたが、他のすべてのプロセスは CPU が使用できるまで待機する必要があります。 アイドル状態.

Linux カーネルとその CPU とのやり取りに戻りましょう。全体像は次のとおりです。

cgroup には XNUMX つの設定があります。基本的に、これらは XNUMX つの単純な「ひねり」で、次のことを決定できます。

1. コンテナ（リクエスト）の重量は 株式;
2. コンテナタスクの作業にかかる合計 CPU 時間の割合 (制限) は次のとおりです。 クォータ.

CPUを測定するにはどうすればよいですか?

さまざまな方法があります。

1. 何ですか オウム、誰も知りません - 毎回交渉する必要があります。
2. 興味 より明確ですが、相対的です。50 コアのサーバーと 4 コアのサーバーの 20% は完全に異なります。
3. すでに述べたものを使用できます 体重、Linux はそれを認識していますが、それらは相対的なものでもあります。
4. 最も適切なオプションは、コンピューティング リソースを測定することです。 秒。 それらの。 リアルタイムの秒数に対するプロセッサ時間の秒数: 1 秒あたりのプロセッサ時間は 1 秒あたりに与えられます。これは XNUMX つの CPU コア全体に相当します。

さらに話しやすくするために、彼らは直接測定し始めました。 カーネル、つまり、実際の CPU 時間と比較して同じ CPU 時間を意味します。 Linux は重みを理解しますが、CPU 時間/コアはあまり理解できないため、一方から他方に変換するメカニズムが必要でした。

3 つの CPU コアを持つサーバーの簡単な例を考えてみましょう。500 つのポッドには重み (1000、1500、および 0,5) が与えられ、それらのポッドは、それらに割り当てられたコアの対応する部分 (1、1,5、および XNUMX) に簡単に変換されます。

コアの数が 6 倍 (2) になる 1 番目のサーバーを用意し、そこに同じポッドを配置すると、単純に 2 を掛けるだけでコアの分散を簡単に計算できます (それぞれ 3、3000、XNUMX)。 しかし、このサーバーに XNUMX 番目のポッドが表示されるときに重要な瞬間が発生します。便宜上、その重みは XNUMX になります。これにより CPU リソースの一部 (コアの半分) が奪われ、残りのポッドについては再計算 (半分) されます。

Kubernetes と CPU リソース

Kubernetes では、通常、CPU リソースは次の単位で測定されます。 ミリアドラックス、つまり0,001 コアが基本重量として使用されます。 (Linux/cgroups 用語では同じものを CPU シェアと呼びますが、より正確には 1000 ミリコア = 1024 CPU シェアです。) K8s は、すべてのポッドの重みの合計に相当する CPU リソースを超えるポッドをサーバー上に配置しないようにします。

これはどうして起こるのでしょうか? Kubernetes クラスターにサーバーを追加すると、使用可能な CPU コアの数が報告されます。 新しいポッドを作成するとき、Kubernetes スケジューラは、このポッドに必要なコアの数を認識します。 したがって、ポッドは十分なコアがあるサーバーに割り当てられます。

どうなるか ノー リクエストが指定されていますか (つまり、ポッドに必要なコアの数が定義されていません)? Kubernetes が一般的にどのようにリソースをカウントするかを見てみましょう。

ポッドの場合、リクエスト (CFS スケジューラ) と制限 (信号機を覚えていますか?) の両方を指定できます。

• それらが等しいと指定された場合、ポッドには QoS クラスが割り当てられます。 保証。 常に利用可能なこの数のコアが保証されています。
• リクエストが制限値未満の場合 - QoS クラス 破裂しやすい。 それらの。 たとえば、ポッドは常に 1 コアを使用することが予想されますが、この値は制限ではありません。 時々 ポッドはさらに多くのリソースを使用できます (サーバーに空きリソースがある場合)。
• QoSクラスもあります ベストエフォート — リクエストが指定されていないポッドそのものが含まれます。 リソースは最後に与えられます。

メモリ

メモリの場合も状況は似ていますが、わずかに異なります。結局のところ、これらのリソースの性質は異なります。 一般に、この類推は次のとおりです。

リクエストがメモリ内でどのように実装されるかを見てみましょう。 いずれかのポッドが大きくなりすぎてメモリが不足するまで、ポッドをサーバー上に常駐させ、メモリ消費量を変更します。 この場合、OOM キラーが現れ、最大のプロセスを強制終了します。

これは常に私たちに適しているわけではないため、どのプロセスが私たちにとって重要で、強制終了すべきではないかを規制することが可能です。 これを行うには、パラメータを使用します oom_score_adj.

CPU の QoS クラスに戻って、ポッドのメモリ消費の優先順位を決定する oom_score_adj 値から類推してみましょう。

• ポッドの最も低い oom_score_adj 値 - 998 - は、そのようなポッドが最後に強制終了される必要があることを意味します。 保証.
• 最高の - 1000 - は ベストエフォート、そのようなポッドは最初に強制終了されます。
• 残りの値を計算するには(破裂しやすい）公式があり、その本質は、ポッドがより多くのリソースを要求するほど、ポッドが強制終了される可能性が低くなるという事実に要約されます。

XNUMX番目の「ひねり」 - limit_in_bytes - 限界のために。 これを使用すると、すべてが簡単になります。発行されるメモリの最大量を割り当てるだけであり、ここでは（CPU とは異なり）それ（メモリ）をどのように測定するかという問題はありません。

合計で

Kubernetes の各ポッドには次のものが与えられます requests и limits - CPU とメモリの両方のパラメータ:

1. リクエストに基づいて、Kubernetes スケジューラが機能し、サーバー間でポッドを分散します。
2. すべてのパラメータに基づいて、ポッドの QoS クラスが決定されます。
3. 相対的な重みは CPU リクエストに基づいて計算されます。
4. CFS スケジューラは CPU リクエストに基づいて設定されます。
5. OOM キラーはメモリ要求に基づいて構成されます。
6. 「信号機」は CPU の制限に基づいて設定されます。
7. メモリ制限に基づいて、cgroup に制限が設定されます。

一般に、この図は、リソース管理の主要部分が Kubernetes でどのように行われるかに関するすべての質問に答えます。

自動スケーリング

K8s クラスター オートスケーラー

クラスター全体がすでに占有されており、新しいポッドを作成する必要があると想像してみましょう。 ポッドが表示されない間、ステータスがハングアップします 保留中。 これを表示するには、新しいサーバーをクラスターに接続するか、クラスター オートスケーラーをインストールします。これは自動的に実行されます。クラウド プロバイダーから (API リクエストを使用して) 仮想マシンを注文し、クラスターに接続します。その後、ポッドが追加されます。

これは Kubernetes クラスターの自動スケーリングであり、(私たちの経験では) うまく機能します。 ただし、他の場所と同様に、ここでもいくつかのニュアンスがあります...

クラスターのサイズを増やしている限りはすべて問題ありませんでしたが、クラスターのサイズが大きくなると何が起こるでしょうか。 自分自身を解放し始めた? 問題は、(ホストを解放するための) ポッドの移行が技術的に非常に難しく、リソースの点で高価であることです。 Kubernetes はまったく異なるアプローチを使用します。

デプロイメントを備えた 3 台のサーバーからなるクラスターを考えてみましょう。 ポッドは 6 つあります。現在は各サーバーに 2 つあります。 何らかの理由で、サーバーの XNUMX つをオフにしたいと考えました。 これを行うには、次のコマンドを使用します kubectl drain、 どれの：

• このサーバーに新しいポッドを送信することを禁止します。
• サーバー上の既存のポッドを削除します。

Kubernetes はポッドの数 (6) を維持する責任があるため、単に 再作成します それらは他のノードにはありますが、無効になっているノードにはありません。これは、新しいポッドをホストするためにすでに使用不可としてマークされているためです。 これは Kubernetes の基本的な仕組みです。

ただし、ここにもニュアンスがあります。 同様の状況で、(Deployment ではなく) StatefulSet の場合、アクションは異なります。 これで、すでにステートフル アプリケーションが完成しました。たとえば、MongoDB を備えた XNUMX つのポッドがあり、そのうちの XNUMX つには何らかの問題があります (データが破損しているか、ポッドが正しく起動できない別のエラーがあります)。 そして、再び XNUMX 台のサーバーを無効にすることにしました。 何が起こるか？

MongoDBの できた クォーラムが必要なため、停止します。XNUMX つのインストールからなるクラスターの場合、少なくとも XNUMX つが機能する必要があります。 ただし、これは 起きていません -ありがとう ポッド中断予算。 このパラメータは、動作するポッドの最小必要数を決定します。 MongoDB ポッドの XNUMX つが動作しなくなっていることがわかり、PodDisruptionBudget が MongoDB に設定されていることを確認します。 minAvailable: 2, Kubernetes ではポッドを削除することはできません。

結論: クラスターが解放されたときにポッドの移動 (実際には再作成) が正しく機能するには、PodDisruptionBudget を構成する必要があります。

水平スケーリング

別の状況を考えてみましょう。 Kubernetes でデプロイメントとして実行されているアプリケーションがあります。 ユーザー トラフィックはポッド (たとえば、ポッドが XNUMX つあります) に到着し、ポッド内の特定の指標 (CPU 負荷など) を測定します。 負荷が増加した場合は、スケジュールに記録し、リクエストを分散するポッドの数を増やします。

現在の Kubernetes では、これを手動で行う必要はありません。ポッド数の自動増減は、測定された負荷インジケーターの値に応じて構成されます。

ここでの主な質問は次のとおりです。 正確に何を測定するか и どう解釈するか 取得した値 (ポッドの数の変更を決定するため)。 多くのことを測定できます。

これを技術的に行う方法 - メトリクスの収集など。 ――レポートでも詳しくお話しましたが、 モニタリングとKubernetes。 最適なパラメータを選択するための主なアドバイスは次のとおりです。 実験!

あり 使用方法 (使用率の飽和とエラー）の意味は以下の通りです。 php-fpm などのスケーリングはどのような根拠に基づいて行うのが合理的ですか? 労働者が不足しているという事実に基づいて、これは 利用。 そして、ワーカーが終了し、新しい接続が受け入れられない場合、これはすでに完了しています 飽和。 これらのパラメータは両方とも測定する必要があり、値に応じてスケーリングを実行する必要があります。

代わりに、結論の

このレポートには、垂直方向のスケーリングと適切なリソースの選択方法についての続きがあります。 これについては今後のビデオでお話します 私たちのYouTube - 見逃さないように購読してください!

ビデオとスライド

パフォーマンスのビデオ (44 分):

報告書のプレゼンテーション:

PS

Kubernetes に関するその他のレポートはブログにあります。

• «Kubernetesの拡張と補完» (Andrey Polovov、8 年 2019 月 XNUMX 日、Saint HighLoad++);
• «データベースとKubernetes» (Dmitry Stolyarov、8 年 2018 月 XNUMX 日 HighLoad++);
• «モニタリングとKubernetes» (ドミトリー・ストリャロフ、28 年 2018 月 XNUMX 日、RootConf にて);
• «Kubernetes と GitLab を使用した CI/CD のベスト プラクティス» (Dmitry Stolyarov、7 年 2017 月 XNUMX 日 HighLoad++);
• «小規模プロジェクトにおける Kubernetes の経験» (ドミトリー・ストリャロフ、6 年 2017 月 XNUMX 日、RootConf にて).

出所： habr.com