ご存知のとおり、Kubernetes QOS は次の 3 つのレベルに分かれています。
Google のベスト プラクティスでは、リソースが不足したときに重要なサービスが削除されないように、重要なサービスは Guaranteed で構成する必要があるとされています。 ベストプラクティスでは、運用と保守の観点からこのように構成する必要があります。チームが立ち上がったばかりのときは、基本的にリソース要求や制限を設定しなくても正常に動作できますが、チームやプロジェクトが拡大するにつれて、安定性の問題が発生し始めます。サービスは互いに影響を及ぼし合うため、サービスに制限を追加するのに適したタイミングかもしれません。そうすることで、多くの悩みから解放されるかもしれません。 ここで明らかなのは、ベスト プラクティスに従うことで、クラスター全体の柔軟性と信頼性が向上するということです。 しかし、CPU の制限に関しては興味深いことが起こります。 CPU は圧縮可能なリソースです。アプリケーションが CPU 制限に達し始めると、Kubernetes はコンテナの調整を開始します。つまり、CPU が人為的に制限され、アプリケーションのパフォーマンスが低下する可能性があります。 1. なぜこのようなことが起こるのでしょうか?コンテナ オーケストレーターでハード CPU 制限を設定すると、カーネルは Completely Fair Scheduler (CFS) Cgroup を使用してそれらの制限を適用するためです。 CFS cgroup メカニズムは、クォータとサイクルという 2 つの設定を使用して CPU 割り当てを管理します。アプリケーションが特定の期間内に割り当てられた CPU クォータを超えて使用した場合、次の期間まで制限されます。 cgroup のすべての CPU メトリックは、 制限メトリック cpu.stat を表示することもできます。 cpu.stat には次の情報が表示されます:
2. 簡単な例を挙げてみましょうシングルスレッド アプリケーションは、cgroup 制約のある CPU 上で実行されます。このアプリケーションでは、リクエストを完了するのに 200 ミリ秒の処理時間が必要です。制約がない場合、その応答は次の図のようになります。 設定制限のないリクエスト ここで、アプリケーションに 0.4 CPU の CPU 制限を割り当てるとします。これは、CPU がその期間中に他の作業を行っていなかったとしても、アプリケーションは 100 ミリ秒サイクルごとに 40 ミリ秒の実行時間を取得することを意味します。 200 ミリ秒かかっていたリクエストが完了するまでに 440 ミリ秒かかるようになりました。 制限されたリクエストの設定 このとき、コンテナパス下の cpu.stat throttled_time を確認すると、240ms に制限されていることがわかります (100ms サイクルごとに、アプリケーションは 40ms しか実行できず、60ms に制限されています。4 サイクルに制限されているため、4 * 60 = 240ms です)。 より一般的な言葉で言えば、1 つの CPU を要求すると、アプリケーションは 1 秒あたり 1 つの CPU コアを使用できることを意味します。シングルスレッドの場合は、常に 1 つのコアを使用できます。ただし、スレッドが 2 つある場合は、制限なく 1 秒あたり 2 つのコアを使用できます。したがって、この制限により、2 つのコアを 1/2 秒間完全に使用してから、調整される可能性があります。 (これは実際には秒単位で測定されるのではなく、私たちの中に存在しますが、このようにすると理解しやすいと思います)。 これを見ると、これは単なる制約であると言うかもしれません。範囲外のリソースは使用できません。そうでない場合は制限されます。 3. 不必要な制限はありますか?それはそんなに単純なことではありません。多くの人が、不要な cgroup 制限や、CPU 上限がないことを報告しています。ここでは白熱した議論が交わされています:
コンテナを実行するときにチェックする重要なメトリックはスロットリングです。これは、コンテナが調整されている回数を示します。 CPU 使用率が制限に近いかどうかに関係なく、多くのコンテナが調整されていることがわかりました。熱心なネットユーザーによって報告された事例は次のとおりです。 アニメーションでは、CPU 制限が 800m (0.8 コア、コアの 80%) に設定されており、ピーク使用率は 200m (コアの 20%) で最高になることがわかります。これを見ると、サービスがスロットルされる前に実行するのに十分な CPU があると思うかもしれませんね。 。さて、これを見てください: CPU 使用率が CPU 制限を下回っていても、CPU スロットリングが発生することがわかります。最大 CPU 使用率は CPU 制限に近づいていません。 制限があると、サービスのパフォーマンスが低下し、待ち時間が長くなります。 4. 原因は何ですか?本質的に、この問題は Linux カーネルによって発生します。詳細については、このビデオをご覧ください: ビデオが意味しているのはだいたいこれです。 以下は、それぞれ独自のコアに固定された 2 つのワーカー スレッドを持つマルチスレッド デーモンの例です。次の図に示すように、最初の図は一定期間にわたる cgroup のグローバル クォータを示しています。これは 20 ミリ秒のクォータから始まり、0.2 CPU に関連付けられます。中央のグラフは各 CPU キューに割り当てられたクォータを示し、下のグラフはワーカー スレッドが CPU で実行に費やした実際の時間を示します。 10 ミリ秒の場合:
17 ミリ秒:
ワーカー 1 が要求に応答するのにちょうど 5 ミリ秒かかる可能性は非常に非現実的です。リクエストに追加の処理時間がかかった場合はどうなりますか? 30 ミリ秒後:
38 ミリ秒で:
41 ミリ秒:
49 ミリ秒:
1 ミリ秒はデュアルコア マシンでは大きな影響がないかもしれませんが、コア数が多いマシンではそれらのミリ秒が積み重なって大きな影響を及ぼします。 88 コア (n) のマシンでこの動作が発生した場合、サイクルごとに 87 (n-1) ミリ秒かかる可能性があります。これは、潜在的に使用できない 87 ミリ秒または 0.87 CPU (コンテナーあたり) になります。これは、過剰スロットリングによって低いクォータ使用量を実現する方法です。最良の場合、修正により、影響を受けるアプリケーションのインスタンスあたりの使用可能な CPU が 0.87 増加するか、必要な CPU クォータがそれに応じて削減されます。これらの利点により、アプリケーション密度が向上し、クラスター内のアプリケーション応答時間が改善されます。 8 コアおよび 10 コアのマシンでは、この問題はほとんど気付かれませんでした。コア数が流行している現在、この問題はさらに顕著になっています。そのため、コア数の多いマシンで同じアプリケーションを実行すると、制限が増加することがわかりました。 要約すると、クロック スキュー制限の問題により、各期間の割り当てが厳しく制限されます。この問題は、少なくともコミット 512ac999 およびカーネル v4.18 以降では、常に存在していました。 5. Linux カーネルはこの問題をどのように解決しますか?パッチ適用前のコードは、CPU ごとの有効期限がグローバル有効期限 cfs_rq->runtime_expires - if ( cfs_rq - > runtime_expires != cfs_b - > runtime_expires ) { 5.4 以降のメインライン カーネルの一部である問題を修正しました。これらは、利用可能な多くのカーネルにバックポートされています。
このバグ ただし、kubernetes の問題 Linux ディストリビューションのカーネル バージョンが 4.19 より低い場合は、ノードを最新の Linux ディストリビューションにアップグレードすることをお勧めしますが、いずれの場合でも、CPU 制限を削除して制限があるかどうかを確認する必要があります。 6. 結論コンテナを監視して、スロットルによりパフォーマンスが低下していないかどうかを確認します。この場合は、カーネル バージョンを一括でアップグレードするのが最適です。これが不可能な場合は、次の方法で解決できます。 制限を解除する(個人的にはこれは良い考えではないと思う)
リソースの追加さらに、CPU スロットルは主に CPU 制限の低下によって発生します。その制限は Cgroup の動作に影響します。したがって、この問題を素早く解決するには、監視に基づいて制限を 10 ~ 25% 増やし、ピークが確実に低減されるか完全に回避されるようにします。 自動拡張CPU 要求と制限を同じ値に設定すると、通常は期待どおりの動作が得られるため、この問題の簡単な解決策は、CPU 要求と制限を同じ値に設定し、HPA を追加することです。負荷に応じて Pod が自動的にスケールアップおよびスケールダウンできるようにします。 |
ウェブサイトのPR価値とはウェブサイトのPR値(正式名称:PageRank)は、Google検索ラン...
[[345825]] 1. 何が配布されますか?分散は、単一の物理サーバーの容量とパフォーマンスのボ...
最近、Tencent Cloud TStackは公安部の「サイバーセキュリティレベル保護」レベル4資...
翻訳者 |チェン・ジュンレビュー |チョンロウコンテナ化とクラウド コンピューティングの文脈では、分...
GNTCグローバルネットワークテクノロジーカンファレンス(www.theGNTC.com)は、201...
企業の発展と成長は、ユーザーの評判の浸透から切り離すことはできません。特に、成長段階にある新興企業は...
「百度鉄破 - 世界最大の中国コミュニティ」、これは鉄破のタイトル部分であり、確かに最大です。中国最...
AWS、Google Cloud、Microsoft Azure などのパブリック クラウド サービ...
Hostus はメーデーに VPS の特別バージョンを発送しました。メモリ + スワップは 4G、3...
リッチ スニペットを使用すると、検索エンジンは検索結果をユーザーに表示する際に、デフォルトのスタイル...
この記事では、なぜますます多くの企業のマーケティング予算が徐々に e コマース プラットフォームに移...
QQは中国で最もアクセス数の多い中国語ポータルサイトです。国内の何十億もの人々にとって、ほぼ欠かせな...
最近、青島SEOはドメイン名投資に関連するいくつかの事柄を扱っているので、それについて話し、私の見解...
このようなタイトルを使うのは大げさに聞こえるかもしれないが、Baidu のドロップダウン ボックスは...
GoogleはC2C教育製品の発売を計画しており、「Taobao Classmates」が正式に発売...