Kubernetes の制限とリクエストを 1 つの記事で理解する

Kubernetes でコンテナを操作する場合、関係するリソースが何であるか、そしてそれらがどのように必要とされるかを把握することが重要です。一部のプロセスでは、他のプロセスよりも多くの CPU またはメモリが必要になります。いくつかは重要なので、飢えさせてはいけません。

これを踏まえて、コンテナとポッドを正しく構成し、両方のメリットを最大限に活用する必要があります。

この記事では、それを見ていきます。

Kubernetes の制限とリクエストの概要
実践事例
Kubernetes リクエスト
Kubernetes の制限
CPU の特殊性
記憶の特殊性
名前空間リソースQuta
名前空間の制限範囲
要約する

Kubernetes の制限とリクエストの概要

Kubernetes を使用する場合、制限とリクエストは、主に CPU とメモリの構成を含む重要な構成です。

Kubernetes では、制限をコンテナが使用するリソースの最大量として定義します。つまり、コンテナは、表示されているメモリまたは CPU の量を超えて消費することはできません。

一方、リクエストは、コンテナ用に予約されたリソースの最小保証量を指します。

画像.png

実践事例

2 つの異なるコンテナの CPU とメモリに制限とリクエストを設定する必要がある次のデプロイメントを見てみましょう。

種類:デプロイメント
apiバージョン:拡張機能/ v1beta1
 …
テンプレート：
 仕様:
 コンテナ:
 -名前: redis
 イメージ: redis : 5.0.3 -アルパイン
 リソース：
 制限:
 メモリ: 600 Mi
 CPU : 1
 リクエスト:
 メモリ: 300 Mi
 CPU : 500m
 -名前:ビジーボックス
 画像:ビジーボックス: 1.28
 リソース：
 制限:
 メモリ: 200マイル
 CPU : 300m
 リクエスト:
 メモリ: 100マイル
 CPU : 100m

このデプロイメントを 4C16G 構成のノードにデプロイする場合は、次の情報を取得できます。

ポッドの有効な要求は 400 MiB のメモリと 600 ミリコアの CPU であり、ポッドをスケジュールするには十分な空き割り当て可能領域を持つノードが必要です。
redisコンテナのCPUシェアは512、busyboxコンテナは102になります。Kubernetesは常に各コアに1024のシェアを割り当てるため、redis: 1024 * 0.5コア≅ 512、busybox: 1024 * 0.1コア≅ 102となります。
Redis コンテナが 600 MB を超える RAM を割り当てようとすると、OOM によって強制終了され、ポッドが失敗する可能性が高くなります。
Redis が 100 ミリ秒ごとに 100 ミリ秒を超える CPU を使用しようとすると (コアが 4 つあるため、使用可能な時間は 100 ミリ秒あたり 400 ミリ秒です)、CPU スロットリングが発生し、パフォーマンスが低下します。
Busybox コンテナが 200 MB を超える RAM を割り当てようとすると、OOM によって強制終了され、Pod が失敗します。
Busybox が 100 ミリ秒ごとに 30 ミリ秒を超える CPU を使用しようとすると、CPU スロットリングが発生し、パフォーマンスが低下します。

Kubernetes リクエスト

Kubernetes では、リクエストをコンテナが使用するリソースの最小保証量として定義します。

基本的に、コンテナが消費するリソースの最小量を設定します。

Pod がスケジュールされると、kube-scheduler は Kubernetes リクエストをチェックして、それを特定のノード (Pod 内のすべてのコンテナのうち少なくともこの数を満たすことができるノード) に割り当てます。要求された量が利用可能なリソースよりも大きい場合、ポッドはスケジュールされず、保留状態のままになります。

Pendingステータスの詳細については、「Kubernetes Podの保留中の問題の理解【1】」を参照してください。

この例では、コンテナ定義で、100m コアの CPU と 4Mi のメモリの要求を設定します。

リソース：
 リクエスト:
 CPU : 0.1
 メモリ: 4 Mi

リクエストは通常、次のシナリオで使用されます。

ポッドがノードに割り当てられると、ポッド内のコンテナに対するすべてのリクエストが満たされます。
実行時に、指定されたリクエスト量は、Pod 内のコンテナの最小値になることが保証されます。

Kubernetes の制限

Kubernetes では、コンテナが使用するリソースの最大量として制限を定義します。

つまり、コンテナは指定された量を超えるメモリまたは CPU を消費することはできません。

リソース：
 制限:
 CPU : 0.5
 メモリ: 100マイル

制限は通常、次のシナリオで使用されます。

ポッドをノードに割り当てるときに、リクエストが設定されていない場合、Kubernetes はデフォルトで request = limit を割り当てます。
実行時に、Kubernetes は、Pod 内のコンテナによって消費されるリソースの量が制限によって示される量よりも大きいかどうかを確認します。

CPU特性

CPU は圧縮可能なリソースであるため、あらゆる要求を満たすように拡張できます。プロセスが CPU を過剰に要求すると、一部のプロセスが調整されます。

CPU はコア数で測定される計算処理時間を表します。

コアよりも小さい量を表すには、ナノメートル (m) を使用できます (たとえば、500 m はコアの半分です)。
最小数量は1mです
ノードには複数のコアが利用可能であるため、CPU>1を要求することも可能である。

メモリ特性

メモリは圧縮できないリソースであるため、CPU のように拡張することはできません。プロセスが動作するために十分なメモリを取得できない場合、そのプロセスは強制終了されます。

Kubernetes では、メモリの単位はバイトです。

、E、P、T、G、M、k を使用してエクサバイト、ペタバイト、テラバイト、ギガバイト、メガバイト、キロバイトを表すことができますが、一般的に使用されるのは最後の 4 つだけです。 (例: 500M、4G)
警告: メモリに小文字の m を使用しないでください (これはミリバイトの略で、非常に低い値です)
メビバイトはMiで定義し、残りはEi、Pi、Tiで定義できます（例：500Mi）

!!メビバイト (および類似のキビバイト、ギビバイトなど) は、20 バイトの 2 乗です。キロやメガのメートル法の定義との混同を避けるために作成されました。これはバイトの一般的な定義であり、キロとメガは 1000 の倍数であるため、この表記を使用する必要があります。

ベストプラクティス

Kubernetes では、リソースの使用を制御するために制限を使用することはほとんどありません。これは、リソース不足を回避したい場合 (すべての重要なプロセスにリソースが割り当てられるようにする場合)、まず最初にリクエストを使用する必要があるためです。

制限を設定すると、特別な場合にプロセスが追加のリソースを取得できなくなるため、メモリ側で OOM による強制終了が発生し、CPU 側でスロットリングが発生します (プロセスは、CPU が再び使用できるようになるまで待機する必要があります)。

詳細については、OOMとスロットリングに関する記事【2】を参照してください。

ポッドのすべてのコンテナでリクエスト値を制限と同じに設定すると、ポッドは保証されたサービス品質を受け取ります。

また、リクエストよりも多くのリソースを使用するポッドは削除される可能性が高くなるため、リクエストを非常に低く設定すると、メリットよりもデメリットの方が大きくなる可能性があることに注意してください。これはPodの排除とサービス品質【3】で確認できます。

名前空間 ResourceQuata

名前空間のおかげで、Kubernetes リソースをテナントとも呼ばれるさまざまなグループに分離できます。

ResourceQuota を使用すると、名前空間全体にメモリまたは CPU の制限を設定して、その中のエンティティがその量を超えて消費できないようにすることができます。

 APIバージョン: v1
種類:リソースクォータ
メタデータ:
 名前:メモリ- CPU -デモ
仕様:
 難しい：
 リクエスト.CPU : 2
 リクエスト.memory : 1 Gi
 制限.cpu : 3
 メモリ制限: 2 Gi

request.cpu: この名前空間内のすべてのリクエストの CPU の最大数。
request.memory: この名前空間内のすべてのリクエストの最大メモリ量。
limits.cpu: この名前空間内のすべての制限の CPU の最大数。
limits.memory: この名前空間内のすべての制限の合計の最大メモリ量。

次に、それを名前空間に適用します。

 kubectl apply -fリソースクォータ.yaml --namespace=mynamespace

次のメソッドを使用して、名前空間の現在の ResourceQuota を一覧表示できます。

 kubectl get resourcequota - n mynamespace

名前空間内の特定のリソースに対して ResourceQuota を設定する場合は、その名前空間内の各 Pod に対して対応する制限またはリクエストを指定する必要があることに注意してください。そうでない場合、Kubernetes は「クォータ失敗」エラーを返します。

サーバーからのエラー(禁止) : 「mypod.yaml」の作成中にエラーが発生しました:ポッド「mypod」は禁止されています:クォータに失敗しました: mem - cpu - demo : limits .cpu、limits .memory、requests .cpu 、 requests .memoryを指定する必要があります

コンテナ制限またはリクエストが現在の ResourceQuota を超える新しい Pod を追加しようとすると、Kubernetes は「クォータ超過」エラーを返します。

サーバーからのエラー(禁止) : 「mypod.yaml」の作成中にエラーが発生しました:ポッド「mypod」は禁止されています:クォータを超えました: mem - cpu - demo 、要求されました: limits .memory = 2 Gi 、 requests .memory = 2 Gi 、使用されました: limits .memory = 1 Gi 、 requests .memory = 1 Gi 、制限されています: limits .memory = 2 Gi 、 requests .memory = 1Gi

名前空間の制限範囲

ResourceQuotas は、名前空間に割り当てることができるリソースの合計量を制限したい場合に便利です。しかし、内部の要素にデフォルト値を提供したい場合はどうなるでしょうか?

LimitRanges は、名前空間内の各エンティティのリソース設定を制限する Kubernetes ポリシーです。

 APIバージョン: v1
種類:制限範囲
メタデータ:
 名前: CPU -リソース-制約
仕様:
 制限:
 -デフォルト：
 CPU : 500m
 デフォルトリクエスト:
 CPU : 500m
 分:
 CPU : 100m
 最大:
 CPU : "1"
 タイプ:コンテナ

デフォルト。指定しない場合は、作成されたコンテナにこの値が割り当てられます。
min: これより小さい制限またはリクエストではコンテナを作成できません。
max: この値より大きい制限またはリクエストではコンテナを作成できません。

後で、リクエストや制限を設定せずに新しい Pod を作成すると、LimitRange はすべてのコンテナに対してそれらの値を自動的に設定します。

制限:
 CPU : 500m
 リクエスト:
 CPU : 100m

ここで、1200M の制限を持つ新しい Pod を追加するとします。次のエラーが発生します。

サーバーからのエラー(禁止) : 「pods/mypod.yaml」の作成中にエラーが発生しました:ポッド「mypod」は禁止されています:コンテナあたりの最大 CPU 使用量は1ですが、制限は1200 mです

デフォルトでは、LimitRanges が設定されていない場合でも、Pod 内のすべてのコンテナは実質的に 100m CPU を要求することに注意してください。

要約する

エネルギー消費とコストを最適に抑えるには、Kubernetes クラスターに最適な制限を選択することが重要です。

ポッドに割り当てているリソースが多すぎると、コストが急増する可能性があります。

スケーリングが小さすぎたり、CPU やメモリの割り当てが少なすぎたりすると、アプリケーションが適切に実行されなかったり、Pod が削除されたりする可能性があります。

前述したように、Kubernetes の制限は、メリットよりもデメリットをもたらす可能性があるため、非常に特殊な状況を除いて使用しないでください。メモリが不足している場合はコンテナが強制終了される可能性があり、CPU が不足している場合はコンテナが調整される可能性があります。

リクエストの場合、プロセスがリソースの保証された共有を確実に取得する必要がある場合に使用します。

書類

【1】https://sysdig.com/blog/kubernetes-pod-pending-problems/
【2】https://sysdig.com/blog/troubleshoot-kubernetes-oom/
【3】https://sysdig.com/blog/kubernetes-pod-evicted/

元記事: https://sysdig.com/blog/kubernetes-limits-requests/ 著者: JAVIER MARTÍNEZ

<<: Kubernetes に基づく CICD の実践

>>: 2022年のOracle Cloudのベストな動き