Kubernetes の CPU 制限と積極的なスロットル

ノート。 翻訳。: ヨーロッパの旅行アグリゲーターである Omio のこの目を見張るような歴史は、基礎理論から Kubernetes 構成の魅力的で実践的な複雑さまで読者を導きます。 このようなケースに精通していれば、視野が広がるだけでなく、重大な問題を防ぐことにも役立ちます。

アプリケーションが所定の位置で動かなくなったり、ヘルスチェックに応答しなくなったり、その理由が分からなくなったりしたことはありませんか? 考えられる説明の XNUMX つは、CPU リソースの割り当て制限に関連していると考えられます。 これがこの記事で説明する内容です。

TL; DR：
CFS クォータのバグがあるバージョンの Linux カーネルを使用している場合は、Kubernetes で CPU 制限を無効にする (または Kubelet で CFS クォータを無効にする) ことを強くお勧めします。 核心に あります 深刻で よく知られている 過剰なスロットリングと遅延を引き起こすバグ.

Omioで インフラストラクチャ全体が Kubernetes によって管理されます。 ステートフルおよびステートレス ワークロードはすべて、Kubernetes 上でのみ実行されます (Google Kubernetes Engine を使用します)。 過去 XNUMX か月間で、ランダムな速度低下が観察され始めました。 アプリケーションがフリーズしたり、ヘルスチェックに応答しなくなったり、ネットワークへの接続が切断されたりします。 この行動は長い間私たちを困惑させましたが、最終的に私たちはこの問題を真剣に受け止めることに決めました。

記事の要約：

• コンテナーと Kubernetes について少し説明します。
• CPU リクエストと制限がどのように実装されるか。
• マルチコア環境での CPU 制限の仕組み。
• CPU スロットリングを追跡する方法。
• 問題の解決策とニュアンス。

コンテナとKubernetesについて一言

Kubernetes は本質的に、インフラストラクチャの世界における最新の標準です。 その主なタスクはコンテナのオーケストレーションです。

コンテナ

以前は、サーバー上で実行するために、Java JAR/WAR、Python Egg、または実行可能ファイルなどのアーティファクトを作成する必要がありました。 ただし、それらを機能させるには、ランタイム環境 (Java/Python) のインストール、必要なファイルの適切な場所への配置、オペレーティング システムの特定のバージョンとの互換性の確保など、追加の作業を行う必要がありました。 言い換えれば、構成管理には細心の注意を払う必要がありました (これは、開発者とシステム管理者の間でしばしば争いの原因となりました)。

コンテナがすべてを変えました。 これで、アーティファクトはコンテナー イメージになりました。 これは、プログラムだけでなく、本格的な実行環境 (Java/Python/...)、および必要なファイル/パッケージが事前にインストールされ、すぐに使用できる、一種の拡張実行可能ファイルとして表すことができます。走る。 追加の手順を行わずに、コンテナーをさまざまなサーバーにデプロイして実行できます。

さらに、コンテナは独自のサンドボックス環境で動作します。 これらは独自の仮想ネットワーク アダプタ、アクセスが制限された独自のファイル システム、独自のプロセス階層、CPU とメモリに関する独自の制限などを持っています。これらはすべて、Linux カーネルの特別なサブシステムである名前空間のおかげで実装されています。

Kubernetes

前述したように、Kubernetes はコンテナ オーケストレーターです。 それは次のように機能します。マシンのプールを与えて、「ねえ、Kubernetes、2 つのプロセッサと 3 GB のメモリをそれぞれ搭載したコンテナのインスタンスを XNUMX 個起動して、実行し続けましょう!」と言います。 残りは Kubernetes が処理します。 空き容量を見つけ、必要に応じてコンテナを起動して再起動し、バージョン変更時に更新をロールアウトします。 基本的に、Kubernetes を使用すると、ハードウェア コンポーネントを抽象化し、アプリケーションのデプロイと実行に適したさまざまなシステムを作成できます。

素人の視点から見た Kubernetes

Kubernetes のリクエストと制限とは何ですか

さて、コンテナと Kubernetes について説明しました。 また、複数のコンテナーが同じマシン上に存在できることもわかっています。

共同アパートに例えることができます。 広々とした敷地（マシン/ユニット）を複数のテナント（コンテナ）に貸し出します。 Kubernetes は不動産業者として機能します。 テナント同士の衝突をどうやって防ぐかという疑問が生じます。 たとえば、そのうちの一人が半日トイレを借りることにしたらどうなるでしょうか?

ここで、リクエストと制限が関係します。 CPU リクエスト 計画の目的のみに必要です。 これはコンテナの「ウィッシュリスト」のようなもので、最適なノードを選択するために使用されます。 同時にCPUも リミット レンタル契約と比較することができます。コンテナのユニットを選択するとすぐに、 できなくなります 確立された限界を超えてください。 そしてここで問題が発生します...

Kubernetes でのリクエストと制限の実装方法

Kubernetes は、カーネルに組み込まれたスロットル メカニズム (クロック サイクルをスキップする) を使用して、CPU 制限を実装します。 アプリケーションが制限を超えると、スロットルが有効になります (つまり、受け取る CPU サイクルが減ります)。 メモリのリクエストと制限は異なる方法で編成されるため、検出が容易になります。 これを行うには、ポッドの最後の再起動ステータス、つまり「OOMKilled」かどうかを確認するだけです。 K8s は cgroup ではなく使用状況によってのみメトリクスを利用できるようにするため、CPU スロットルはそれほど単純ではありません。

CPUリクエスト

CPUリクエストの実装方法

わかりやすくするために、例として 4 コア CPU を搭載したマシンを使用してプロセスを見てみましょう。

K8s は、制御グループ メカニズム (cgroups) を使用して、リソース (メモリとプロセッサ) の割り当てを制御します。 これには階層モデルが使用できます。子は親グループの制限を継承します。 配布の詳細は仮想ファイル システム (/sys/fs/cgroup）。 プロセッサの場合、これは /sys/fs/cgroup/cpu,cpuacct/*.

K8s はファイルを使用します cpu.share プロセッサリソースを割り当てます。 この例では、ルート cgroup は CPU リソースの 4096 シェアを取得します。これは、利用可能なプロセッサ能力の 100% (1 コア = 1024、これは固定値です) です。 ルート グループは、ルート グループに登録されている子孫のシェアに応じてリソースを比例的に分配します。 cpu.share、そして彼らは、今度は自分の子孫に対して同じことを行います。 一般的な Kubernetes ノードでは、ルート cgroup には XNUMX つの子があります。 system.slice, user.slice и kubepods。 最初の 8 つのサブグループは、重要なシステム負荷と KXNUMX の外部のユーザー プログラムの間でリソースを分散するために使用されます。 最後の一つ - kubepods — ポッド間でリソースを分散するために Kubernetes によって作成されます。

上の図は、最初と XNUMX 番目のサブグループがそれぞれの 1024 kuberpod サブグループが割り当てられた共有 4096 株式これはどのようにして可能ですか: 結局のところ、root グループは次のものにのみアクセスできます。 4096 彼女の子孫の株式の合計はこの数を大幅に超えています (6144）？ 重要なのは、この値が論理的に意味があるため、Linux スケジューラ (CFS) がその値を使用して CPU リソースを比例的に割り当てるということです。 私たちの場合、最初の XNUMX つのグループが受け取ります。 680 実質株式 (16,6 の 4096%)、kubepod が残りを受け取ります。 2736 株式ダウンタイムが発生した場合、最初の XNUMX つのグループは割り当てられたリソースを使用しません。

幸いなことに、スケジューラには、未使用の CPU リソースの無駄を回避するメカニズムが備わっています。 「アイドル」容量をグローバル プールに転送し、そこから追加のプロセッサ能力を必要とするグループに分散します (丸め損失を避けるために、転送はバッチで行われます)。 同様の方法が子孫のすべての子孫に適用されます。

このメカニズムにより、プロセッサーのパワーが公平に配分され、どのプロセスも他のプロセスからリソースを「盗む」ことがなくなります。

CPU リミット

K8 の制限とリクエストの構成は似ているにもかかわらず、その実装は根本的に異なります。 最も誤解を招きやすい そして最も文書化されていない部分。

K8s はエンゲージします CFS クォータ メカニズム 制限を実装します。 それらの設定はファイルで指定されます cfs_period_us и cfs_quota_us cgroup ディレクトリ内 (ファイルもそこにあります) cpu.share).

とは異なり、 cpu.share、割り当てはに基づいています 期間、利用可能なプロセッサーの能力ではありません。 cfs_period_us 期間 (エポック) の継続時間を指定します。常に 100000 μs (100 ミリ秒) です。 K8s にはこの値を変更するオプションがありますが、現時点ではアルファ版でのみ利用可能です。 スケジューラはエポックを使用して、使用済みクォータを再開します。 XNUMX番目のファイル cfs_quota_us、各エポックで利用可能な時間 (クォータ) を指定します。 マイクロ秒単位でも指定されることに注意してください。 クォータはエポック長を超える可能性があります。 言い換えれば、100 ミリ秒を超える可能性があります。

16 コア マシン (Omio で使用している最も一般的なタイプのコンピュータ) での XNUMX つのシナリオを見てみましょう。

シナリオ 1: 2 つのスレッドと 200 ミリ秒の制限。 スロットリングなし

シナリオ 2: 10 スレッドと 200 ミリ秒の制限。 20 ミリ秒後にスロットルが開始され、さらに 80 ミリ秒後にプロセッサ リソースへのアクセスが再開されます。

CPU 制限を次のように設定したとします。 2 カーネル。 Kubernetes はこの値を 200 ミリ秒に変換します。 これは、コンテナーがスロットルなしで最大 200 ミリ秒の CPU 時間を使用できることを意味します。

ここからが楽しみの始まりです。 前述したように、使用可能な割り当ては 200 ミリ秒です。 並行して作業している場合 10 12 コア マシン上のスレッド (シナリオ 2 の図を参照)、他のすべてのポッドがアイドル状態である間、クォータはわずか 20 ミリ秒で使い果たされ (10 * 20 ミリ秒 = 200 ミリ秒であるため)、このポッドのすべてのスレッドがハングします。 » （スロットル） 次の 80 ミリ秒間。 すでに述べた スケジューラのバグ、これにより過剰なスロットリングが発生し、コンテナーは既存のクォータを満たすことさえできなくなります。

ポッドのスロットリングを評価するにはどうすればよいですか?

ポッドにログインして実行するだけです cat /sys/fs/cgroup/cpu/cpu.stat.

• nr_periods — スケジューラ期間の合計数。
• nr_throttled — コンポジション内のスロットルされた期間の数 nr_periods;
• throttled_time — 累積スロットル時間 (ナノ秒)。

本当に何が起こっているのでしょうか？

その結果、すべてのアプリケーションで高いスロットリングが発生します。 時々彼は入っている XNUMX回 計算以上に強い！

これにより、準備状況チェックの失敗、コンテナのフリーズ、ネットワーク接続の切断、サービス呼び出し内のタイムアウトなど、さまざまなエラーが発生します。 これにより、最終的に遅延が増加し、エラー率が高くなります。

決定と結果

ここではすべてがシンプルです。 私たちは CPU の制限を放棄し、クラスター内の OS カーネルをバグが修正された最新バージョンに更新し始めました。 私たちのサービスにおけるエラー (HTTP 5xx) の数はすぐに大幅に減少しました。

HTTP 5xx エラー

5 つの重要なサービスの HTTP XNUMXxx エラー

応答時間 p95

クリティカル サービス リクエストのレイテンシ、95 パーセンタイル

運用費用

費やされたインスタンス時間数

キャッチは何ですか？

記事の冒頭で述べたように、

共同アパートに類似したものを考えることができます... Kubernetes は不動産業者の役割を果たします。 しかし、テナント同士の衝突を防ぐにはどうすればよいでしょうか? たとえば、そのうちの一人が半日トイレを借りることにしたらどうなるでしょうか?

ここに問題があります。 XNUMX つの不注意なコンテナが、マシン上で使用可能な CPU リソースをすべて使い果たす可能性があります。 スマートなアプリケーション スタック (たとえば、JVM、Go、Node VM が適切に構成されている場合) がある場合、これは問題ではありません。そのような状況でも長時間作業できます。 ただし、アプリケーションの最適化が不十分であるか、まったく最適化されていない場合 (FROM java:latest）、状況は制御不能になる可能性があります。 Omio では、主要な言語スタックに対して適切なデフォルト設定を使用してベース Dockerfile を自動化しているため、この問題は存在しませんでした。

メトリクスを監視することをお勧めします USE (使用量、飽和、エラー)、API の遅延、エラー率。 結果が期待どおりであることを確認します。

リファレンス

これは私たちの物語です。 次の資料は、何が起こっているかを理解するのに非常に役立ちました。

• kernel.org → CFS スケジューラ;
• kernel.org → CFS 帯域幅制御;
• Linux コンテナのスケジューリングについて;
• Linux コンテナーについて知っておくべきことすべて、パート I: Linux コントロール グループとプロセス分離;
• Kubernetes の失敗談 - 「CPU スロットリング」を探します。

Kubernetes のバグレポート:

• #51135: 保証されたポッドの CPU 制限の設定を避ける;
• #67577: CFS クォータにより不必要なスロットルが発生する可能性がある;
• 過度に攻撃的な CFS.

実務で同様の問題に遭遇したことはありますか、またはコンテナ化された実稼働環境でのスロットルに関連した経験はありますか? コメントであなたのストーリーを共有してください！

翻訳者からの追伸

私たちのブログもお読みください:

• «Kubernetes の自動スケーリングとリソース管理 (レビューとビデオ レポート)";
• «Kubernetes での CPU マネージャーの仕組み";
• «kubectl run を実行すると、Kubernetes では何が起こりますか? パート2'。

出所： habr.com