Kubernetes のベスト プラクティス。 リソースのリクエストと制限の設定

Kubernetes のベスト プラクティス。 小さなコンテナの作成
Kubernetes のベスト プラクティス。 名前空間を使用した Kubernetes の構成
Kubernetes のベスト プラクティス。 Readiness および Liveness テストによる Kubernetes の Liveness の検証

Kubernetes リソースごとに、リクエストと制限の XNUMX 種類の要件を構成できます。 XNUMX つ目は、コンテナーまたはポッドを実行するために必要な空きノード リソースの可用性に関する最小要件を説明し、XNUMX つ目は、コンテナーで使用できるリソースを厳密に制限します。

Kubernetes がポッドをスケジュールする場合、コンテナーが適切に機能するのに十分なリソースがあることが非常に重要です。 リソースに制約のあるノードに大規模なアプリケーションをデプロイすることを計画している場合、ノードのメモリが不足しているか、CPU パワーが不足しているためにアプリケーションが実行されない可能性があります。 この記事では、リソースの要求と制限を使用してコンピューティング能力の不足を解決する方法を見ていきます。

リクエストと制限は、Kubernetes が CPU やメモリなどのリソースを管理するために使用するメカニズムです。 リクエストは、コンテナがリクエストされたリソースを確実に受け取るようにするものです。 コンテナーがリソースをリクエストした場合、Kubernetes はそれを提供できるノード上でのみリソースをスケジュールします。 制限は、コンテナーによって要求されるリソースが特定の値を超えないように制御します。

コンテナーのコンピューティング能力は一定の制限までしか増加できず、それを超えると制限されます。 どのように機能するかを見てみましょう。 したがって、リソースにはプロセッサとメモリの XNUMX 種類があります。 Kubernetes スケジューラは、これらのリソースに関するデータを使用して、ポッドを実行する場所を判断します。 ポッドの一般的なリソース仕様は次のようになります。

ポッド内の各コンテナーは独自のクエリと制限を設定でき、すべて追加的です。 プロセッサ リソースはミリコアで定義されます。 コンテナーの実行に 2000 つの完全なコアが必要な場合は、値を 1m に設定します。 コンテナがコアの 4/250 の電力のみを必要とする場合、値は XNUMXm になります。 最大のノードのコア数よりも大きい CPU リソース値を割り当てると、ポッドの起動がまったくスケジュールされなくなることに注意してください。 XNUMX つのコアを必要とするポッドがあり、Kubernetes クラスターが XNUMX つのメイン仮想マシンのみで構成されている場合にも、同様の状況が発生します。

アプリケーションが複数のコアを活用するように特別に設計されていない限り (複雑な科学計算やデータベース操作などのプログラムが思い浮かびます)、ベスト プラクティスは、CPU リクエストを 1 以下に設定し、スケーラビリティを高めるためにより多くのレプリカを実行することです。 このソリューションにより、システムの柔軟性と信頼性が向上します。

CPU の制限に関しては、CPU は圧縮可能なリソースとみなされているため、事態はさらに興味深いものになります。 アプリケーションがプロセッサーの電力制限に近づき始めると、Kubernetes は CPU スロットリングを使用してコンテナーの速度を低下させ、プロセッサーの周波数を下げ始めます。 これは、CPU が人為的にスロットルされ、アプリケーションのパフォーマンスが低下する可能性がありますが、プロセスが終了したり削除されたりすることはないことを意味します。

メモリ リソースはバイト単位で定義されます。 通常、設定の値はメビバイト Mib 単位で測定されますが、バイトからペタバイトまでの任意の値を設定できます。 CPU の場合と同じ状況がここにも当てはまります。ノード上のメモリ量を超える量のメモリをリクエストすると、そのポッドは実行するようにスケジュールされません。 ただし、CPU リソースとは異なり、メモリの使用を制限する方法がないため、メモリは圧縮されません。 したがって、コンテナーに割り当てられたメモリを超えると、コンテナーの実行はすぐに停止されます。

ノードが提供できるリソースを超えるリクエストは構成できないことに注意してください。 GKE 仮想マシンの共有リソースの仕様については、この動画の下のリンクにあります。

理想的な世界では、コンテナーのデフォルト設定でワークフローをスムーズに実行し続けるのに十分です。 しかし、現実の世界はそうではありません。人々はリソースの使用の構成を簡単に忘れたり、ハッカーがインフラストラクチャの実際の機能を超えるリクエストや制限を設定したりする可能性があります。 このようなシナリオの発生を防ぐために、ResourceQuota および LimitRange リソース クォータを構成できます。

ネームスペースが作成されると、クォータを使用してネームスペースをブロックできます。 たとえば、prod 名前空間と dev 名前空間がある場合、運用クォータがまったくなく、開発クォータが非常に厳しいというパターンになります。 これにより、トラフィックが急増した場合に、prod が利用可能なリソース全体を引き継ぎ、dev を完全にブロックすることができます。

リソース割り当ては次のようになります。 この例には 4 つのセクションがあります。これらはコードの最後の 4 行です。

それぞれを見てみましょう。 Requests.cpu は、名前空間内のすべてのコンテナーから送信できる合計 CPU リクエストの最大数です。 この例では、50 万件のリクエストを含む 10 個のコンテナー、100m リクエストを含む 500 個のコンテナー、または 500m リクエストを含む XNUMX つのコンテナーのみが存在する可能性があります。 特定の名前空間のrequests.cpuの総数がXNUMXm未満であれば、すべて問題ありません。

要求されたメモリ requests.memory は、名前空間内のすべてのコンテナーが持つことができる合計メモリ要求の最大量です。 前のケースと同様、ネームスペースで要求されるメモリの合計量が 50 メビバイト未満であれば、2 mib コンテナーを 20 個、100 mib コンテナーを 100 つ、または XNUMX mib コンテナーを XNUMX つ使用できます。

Limits.cpu は、名前空間内のすべてのコンテナーが使用できる CPU 能力の最大合計量です。 これがプロセッサ電力要求の限界であると考えることができます。

最後に、limits.memory は、名前空間内のすべてのコンテナーが使用できる共有メモリの最大量です。 これは合計メモリ要求の制限です。
そのため、デフォルトでは、Kubernetes クラスター内のコンテナーは無制限のコンピューティング リソースで実行されます。 リソース クォータを使用すると、クラスター管理者は、名前空間に基づいてリソースの消費とリソースの作成を制限できます。 名前空間では、ポッドまたはコンテナは、名前空間のリソース割り当てによって決定される量の CPU パワーとメモリを消費できます。 ただし、XNUMX つのポッドまたはコンテナーが利用可能なすべてのリソースを独占する可能性があるという懸念があります。 この状況を防ぐために、名前空間内のリソース (ポッドまたはコンテナー用) の割り当てを制限するポリシーである制限範囲が使用されます。

制限範囲により、次のような制限が提供されます。

• 名前空間内の各モジュールまたはコンテナーのコンピューティング リソースの最小使用量と最大使用量を確保します。
• 名前空間内の各 PersistentVolumeClaim に対して最小および最大の Starage Request ストレージ リクエストを強制します。
• 名前空間内のリソースに対するリクエストと制限の間の関係を強制します。
• 名前空間内のコンピューティング リソースのデフォルトのリクエスト/制限を設定し、実行時にそれらをコンテナーに自動的に挿入します。

このようにして、名前空間に制限範囲を作成できます。 名前空間全体に適用されるクォータとは異なり、制限範囲は個々のコンテナーに使用されます。 これにより、ユーザーが名前空間内に非常に小さなコンテナーを作成したり、逆に巨大なコンテナーを作成したりすることができなくなります。 制限範囲は次のようになります。

前のケースと同様に、ここでも 4 つのセクションを区別できます。 それぞれを見てみましょう。
デフォルト セクションでは、ポッド内のコンテナーのデフォルト制限を設定します。 これらの値を極端な範囲に設定すると、これらの値が明示的に設定されていないコンテナはデフォルト値に従います。

デフォルトのリクエストセクションのdefaultRequestは、ポッド内のコンテナに対するデフォルトのリクエストを構成します。 繰り返しますが、これらの値を極端な範囲に設定すると、これらのオプションを明示的に設定していないコンテナーはデフォルトでこれらの値になります。

max セクションでは、ポッド内のコンテナーに設定できる最大制限を指定します。 デフォルトセクションの値とコンテナ制限は、この制限を超えて設定することはできません。 値が max に設定されており、デフォルト セクションがない場合は、最大値がデフォルト値になることに注意してください。

min セクションでは、ポッド内のコンテナーに設定できる最小リクエストを指定します。 ただし、コンテナのデフォルト セクションとクエリの値をこの制限未満に設定することはできません。

繰り返しますが、この値が設定されていてデフォルトが設定されていない場合、最小値がデフォルトのプロンプトになることに注意することが重要です。

これらのリソース リクエストは、最終的に Kubernetes スケジューラによってワークロードを実行するために使用されます。 コンテナを正しく構成するには、コンテナがどのように機能するかを理解することが非常に重要です。 クラスター内で複数のポッドを実行したいとします。 ポッドの仕様が有効であると仮定すると、Kubernetes スケジュールはラウンド ロビン バランシングを使用して、ワークロードを実行するノードを選択します。

Kubernetes は、ノード 1 にポッド コンテナからのリクエストを満たすのに十分なリソースがあるかどうかを確認し、ない場合は次のノードに移動します。 システム内のどのノードもリクエストを満たすことができない場合、ポッドは保留状態になります。 ノードの自動スケーリングなどの Google Kubernetes エンジンの機能を使用すると、GKE は待機状態を自動的に検出し、さらにいくつかの追加ノードを作成できます。

その後ノードの容量が足りなくなった場合、自動スケーリングによってノードの数が減り、費用が節約されます。 これが、Kubernetes がリクエストに基づいてポッドをスケジュールする理由です。 ただし、制限はリクエストよりも高くなる可能性があり、場合によってはノードが実際にリソースを使い果たす可能性があります。 この状態をオーバーコミット状態と呼びます。

先ほども述べたように、CPU に関して言えば、Kubernetes はポッドの制限を開始します。 各ポッドは要求しただけの量を受け取りますが、制限に達しない場合は、スロットリングが適用され始めます。

メモリ リソースに関しては、Kubernetes はシステム リソースを解放するまで、どのポッドを削除し、どのポッドを保持するかを決定する必要があります。そうしないとシステム全体がクラッシュします。

マシンのメモリが不足しているシナリオを想像してみましょう。Kubernetes はそれをどのように処理するでしょうか?

Kubernetes は、要求したよりも多くのリソースを使用しているポッドを探します。 したがって、コンテナーにリクエストがまったくない場合、それは単にコンテナーが何もリクエストしていないという理由で、デフォルトでリクエストした以上のリクエストを使用していることを意味します。 このようなコンテナはシャットダウンの主な候補になります。 次の候補は、すべてのリクエストを満たしているものの、まだ最大制限を下回っているコンテナです。

そのため、Kubernetes はリクエスト パラメーターを超えた複数のポッドを見つけた場合、それらを優先度で並べ替えて、最も優先度の低いポッドを削除します。 すべてのポッドの優先度が同じ場合、Kubernetes はリクエストを超えるポッドを他のポッドよりも終了します。

非常にまれなケースですが、Kubernetes はリクエストの範囲内にあるポッドを中止することがあります。 これは、Kubelet エージェントや Docker などの重要なシステム コンポーネントが、それらに予約されているリソースを超えるリソースを消費し始めると発生する可能性があります。
したがって、小規模企業の初期段階では、Kubernetes クラスターはリソースのリクエストや制限を設定しなくても問題なく機能しますが、チームやプロジェクトの規模が大きくなり始めると、この領域で問題が発生するリスクが生じます。 モジュールと名前空間にクエリと制約を追加するのに余分な労力はほとんど必要なく、多くの手間を省くことができます。

Kubernetes のベスト プラクティス。 正しいシャットダウン 終了

いくつかの広告 🙂

いつもご宿泊いただきありがとうございます。 私たちの記事が気に入っていますか? もっと興味深いコンテンツを見たいですか? 注文したり、友人に勧めたりして私たちをサポートしてください。 開発者向けのクラウド VPS は 4.99 ドルから, 当社があなたのために発明した、エントリーレベルのサーバーのユニークな類似物です。 VPS (KVM) E5-2697 v3 (6 コア) 10GB DDR4 480GB SSD 1Gbps 19 ドルからの真実、またはサーバーを共有する方法? (RAID1 および RAID10、最大 24 コア、最大 40GB DDR4 で利用可能)。

アムステルダムのエクイニクス Tier IV データセンターでは Dell R730xd が 2 倍安い? ここだけ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV 199 ドルから オランダで！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 ドルから! について読む インフラストラクチャー企業を構築する方法730 ペニーで 5 ユーロの価値がある Dell R2650xd E4-9000 vXNUMX サーバーを使用したクラスですか?

出所： habr.com