Kubernetes: CPU 制限を削除してサービスを高速化します

2016 年に私たちは Buffer にいた Kubernetes に切り替えましたそして現在、約 60 のノード (AWS 上) と 1500 のコンテナが、によって管理される k8s クラスター上で動作しています。 キック。 しかし、私たちは試行錯誤を繰り返しながらマイクロサービスに移行し、数年間 k8s を使用した後でも、依然として新たな問題に直面しています。 この投稿では次についてお話します プロセッサの制限: なぜそれらが良い実践法だと考えたのか、そしてなぜそれほど良くない結果になったのか。

プロセッサーの制限とスロットリング

他の多くの Kubernetes ユーザーと同様に、 GoogleはCPU制限を設定することを強く推奨しています。 このような設定がないと、ノード内のコンテナーがすべてのプロセッサー能力を占有する可能性があり、その結果、重要な Kubernetes プロセス (たとえば、 kubelet) リクエストへの応答が停止されます。 したがって、CPU 制限を設定することは、ノードを保護するための良い方法です。

プロセッサー制限により、コンテナーは特定の期間に使用できる最大 CPU 時間 (デフォルトは 100 ミリ秒) に設定され、コンテナーがこの制限を超えることはありません。 Kubernetes では スロットリング 容器の限界を超えないようにするには、専用のツールを使用します CFS クォータただし、これらの人為的な CPU 制限により、最終的にパフォーマンスが低下し、コンテナーの応答時間が増加します。

プロセッサー制限を設定しないと何が起こるでしょうか?

残念ながら、私たち自身もこの問題に直面しなければなりませんでした。 各ノードにはコンテナの管理を担当するプロセスがあります kubelet、そして彼はリクエストに応答しなくなりました。 これが発生すると、ノードは次の状態になります。 NotReady、そこからのコンテナは別の場所にリダイレクトされ、新しいノードで同じ問題が発生します。 控えめに言っても、理想的なシナリオではありません。

スロットリングと応答の問題の顕在化

コンテナ追跡の重要な指標は次のとおりです。 trottling、コンテナーがスロットルされた回数を示します。 プロセッサーの負荷が極端であるかどうかに関係なく、一部のコンテナーにスロットルが存在することに興味深く気づきました。 例として、主要な API の XNUMX つを見てみましょう。

以下に示すように、制限を次のように設定しました。 800m (0.8 または 80% コア)、最高のピーク値に達します 200m (コア 20%)。 サービスをスロットルする前はまだ十分なプロセッサーパワーがあるように見えますが...

プロセッサーの負荷が指定された制限を下回っている (大幅に下回っている) 場合でも、依然としてスロットルが発生していることに気づいたかもしれません。

これに直面して、私たちはすぐにいくつかのリソースを発見しました (github での問題, ザダノに関するプレゼンテーション, オミオに投稿する) スロットルによるサービスのパフォーマンスと応答時間の低下について。

CPU 負荷が低いときにスロットルが発生するのはなぜですか? 簡単に言うと、「Linux カーネルには、指定されたプロセッサ制限によるコンテナの不必要なスロットリングを引き起こすバグがあります。」 問題の性質に興味がある場合は、プレゼンテーション (ビデオ и 文章 オプション)、Dave Chiluk 著。

CPU 制限の解除 (細心の注意を払って)

長い議論の結果、ユーザーにとって重要な機能に直接的または間接的に影響を与えるすべてのサービスからプロセッサーの制限を削除することを決定しました。

私たちはクラスターの安定性を非常に重視しているため、この決断は簡単ではありませんでした。 過去に、クラスターの不安定性についてすでに実験を行ったことがありますが、その際、サービスが大量のリソースを消費し、ノード全体の動作が遅くなりました。 今ではすべてが多少異なりました。私たちはクラスターに何を期待しているのかを明確に理解しており、計画された変更を実装するための優れた戦略も持っていました。

差し迫った問題に関するビジネス上の連絡。

制限が解除されたときにノードを保護するにはどうすればよいですか?

「無制限」サービスの分離:

過去に、いくつかのノードが状態になるのをすでに確認しました。 notReady、主にリソースを消費しすぎたサービスが原因です。

私たちは、そのようなサービスを「関連する」サービスに干渉しないように、別個の (「ラベル付き」) ノードに配置することにしました。 その結果、一部のノードをマークし、「無関係な」サービスに許容パラメータを追加することで、クラスターをより細かく制御できるようになり、ノードの問題を特定しやすくなりました。 同様のプロセスを自分で実行するには、次のことを理解しておくことができます。 ドキュメンテーション.

正しいプロセッサとメモリリクエストの割り当て:

私たちの最大の懸念は、プロセスが大量のリソースを消費し、ノードがリクエストに応答しなくなることでした。 (Datadog のおかげで) クラスター上のすべてのサービスを明確に監視できるようになったので、「無関係」として指定する予定だったサービスの数か月間の運用を分析しました。 私は単に最大 CPU 使用率を 20% のマージンで設定し、k8s が他のサービスをノードに割り当てようとした場合に備えてノードにスペースを割り当てました。

グラフからわかるように、プロセッサーの最大負荷に達しています。 242m CPU コア (0.242 プロセッサ コア)。 プロセッサー要求の場合は、この値よりわずかに大きい数値を取るだけで十分です。 サービスはユーザー中心であるため、ピーク負荷値はトラフィックと一致することに注意してください。

メモリ使用量とクエリについても同じことを行います。これで準備完了です。 セキュリティを強化するために、水平ポッド自動スケーリングを追加できます。 したがって、リソースの負荷が高くなるたびに、自動スケーリングによって新しいポッドが作成され、kubernetes によって空き領域のあるノードにポッドが分散されます。 クラスター自体にスペースが残っていない場合は、アラートを設定したり、自動スケーリングを通じて新しいノードの追加を構成したりできます。

マイナスのうち、「」で負けたことは注目に値します。コンテナ密度"、つまりXNUMX つのノードで実行されているコンテナの数。 また、トラフィック密度が低い場合には多くの「緩和」が発生する可能性があり、プロセッサ負荷が高くなる可能性もありますが、自動スケーリング ノードは後者に役立つはずです。

結果

過去数週間にわたる実験から得られたこれらの優れた結果を公開できることをうれしく思います。変更されたすべてのサービスで応答が大幅に改善されていることがすでに確認されています。

私たちはホームページで最高の結果を達成しました (buffer.com）、そこでサービスが加速されました 二十二回！

Linux カーネルのバグは修正されましたか?

はい、 バグはすでに修正されており、修正がカーネルに追加されています ディストリビューションのバージョン 4.19 以降。

しかし、読んでみると、 github 上の Kubernetes の問題 2020年XNUMX月XNUMX日 同様のバグを持ついくつかの Linux プロジェクトについての言及が今でも見かけられます。 一部の Linux ディストリビューションにはまだこのバグがあり、修正に取り組んでいるところだと思います。

ディストリビューションのバージョンが 4.19 より前の場合は、最新に更新することをお勧めしますが、いずれの場合も、プロセッサの制限を解除して、スロットルが継続するかどうかを確認してください。 以下に、Kubernetes 管理サービスと Linux ディストリビューションのリストの一部を示します。

• Debian: ディストリビューションの最新バージョンに修正が統合されました。 バスター、とても新鮮に見えます（8月2020年）。 一部の以前のバージョンも修正される可能性があります。
• Ubuntu: 最新バージョンに修正が統合されました Ubuntu フォーカルフォッサ 20.04
• EKS はまだ修正済み 2019年XNUMX月に。 バージョンがこれより低い場合は、AMI を更新する必要があります。
• コップ: 2020年XNUMX月より у kops 1.18+ メインのホスト イメージは Ubuntu 20.04 になります。 kops のバージョンが古い場合は、修正が行われるまで待つ必要がある場合があります。 私たち自身も今を待っています。
• GKE (Google Cloud): 修正が統合されました 2020年XNUMX月ただし、スロットルには問題があります まだ観察されています.

修正によりスロットリングの問題が解決された場合はどうすればよいですか?

問題が完全に解決されたかどうかはわかりません。 修正が適用されたカーネル バージョンに到達したら、クラスターをテストして投稿を更新します。 すでに更新した人がいる場合は、結果を読んでみたいと思います。

まとめ

• Linux 上で Docker コンテナを操作する場合 (Kubernetes、Mesos、Swarm などに関係なく)、スロットリングによりコンテナのパフォーマンスが低下する可能性があります。
• バグがすでに修正されていることを期待して、ディストリビューションの最新バージョンに更新してみてください。
• プロセッサの制限を削除すると問題は解決しますが、これは危険な手法であり、細心の注意を払って使用する必要があります (最初にカーネルを更新して結果を比較することをお勧めします)。
• CPU 制限を削除した場合は、CPU とメモリの使用状況を注意深く監視し、CPU リソースが消費量を超えていることを確認してください。
• 安全なオプションは、ハードウェア負荷が高い場合にポッドを自動スケールして新しいポッドを作成し、kubernetes がそれらを空きノードに割り当てることです。

この投稿がコンテナ システムのパフォーマンスの向上に役立つことを願っています。

PS それは 著者は読者および解説者と通信します（英語）。


出所： habr.com