Kubernetes 学習メモ - コンピューティング リソース管理 (3) 名前空間で利用可能なリソースの総量を制限する 20230219

前のセクションで学習した本では、LimitRange を使用して個々のポッドのリソースを制限します。名前空間で利用可能なリソースの総量を制限する必要がある場合、それを満たすことはできないため、それを達成するには ResourceQuota オブジェクトを作成する必要があります。

1. ResourceQuota リソース

ResourceQuota 制御プラグインは、LimitRange および LimitRange プラグインと同様に、新しく追加されたポッドによってリソースの合計が ResourceQuota を超えるかどうかを確認できます。新しく作成されたポッドのみが対象で、既存のポッドには影響しません。

リソース クォータは、名前空間内のポッドおよび PVC ストレージによって使用できるリソースの総量を制限します。同時に、ユーザーがこの名前空間で作成できるポッド、PVC、およびその他の API オブジェクトの数を制限することもできます。最も処理されるリソースは CPU とメモリです。

CPUとメモリのResourceQuotaを作成する

yaml文件:quota-cpu-memory.yaml

APIバージョン:v1

種類:リソースクォータ

metaData:

名前:cpu-and0mem

仕様:

難しい:

リクエスト.CPU:400m

リクエストメモリ:200Mi

制限.CPU:600m

制限.メモリ:500Mi

上記のように、リクエストと制限の合計量は、各リソースの合計量を単純に定義するのではなく、CPU とメモリに対して定義されます。LimitRange と比較すると構造が異なり、すべてのリソースのリクエストと制限が 1 つのフィールドで定義されます。

limitRange と同様に、ResourceQuota オブジェクトは作成した名前空間に適用されますが、異なる点は、ResourceQuota はリソース リクエストの総量と、個々のポッドやコンテナーではなく、すべてのポッドの制限を制限できることです。

クォータとクォータの使用状況を表示する

kubectl はクォータを記述します

ResourceQuota と同時に LimitRange を作成します

注: ResourceQuota を作成するには、LimitRange オブジェクトの作成も必要です。そうでない場合は、リソース要求と制限を固定していないため、正常に作成できません。

2. 永続ストレージのクォータを指定する

ResourceQuota exclusive は、名前空間で宣言できる永続ストレージの最大量を制限できます。

yaml文件:quota-storage.yaml

APIバージョン:v1

種類:リソースクォータ

metadata:

名前:ストレージ

仕様:

難しい:

リクエストのストレージ:500Gi

ssd.storageclass.storage.k8s.io/requests.storage:300Gi

standard.storageclass.storage.k8s.io/requests.storage:1Ti

3. 作成できるオブジェクトの数を制限する

ResourceQuota は、ネームスペース内のポッド、ReplicationController、サービス、およびその他のオブジェクトの数を制限できます。鶏群管理者は、支払いプランなどに基づいてユーザーが作成できるオブジェクトの数を制限したり、パブリック ネットワーク IP またはサービスで使用できるノード ポートの数を制限したりすることもできます。

yaml文件:quota-object-count.yaml

APIバージョン:v1

種類:リソースクォータ

metadata:

名前:オブジェクト

仕様:

難しい:

ポッド:10

レプリケーションコントローラー:5

秘密:10

構成マップ:10

永続ボリュームクレーム:4

サービス:5

サービス.ロードバランス:1

サービス.ノードポート:2

ssd.storageclass.storage.k8s.io/persistentvolumeclains:2

現在、オブジェクト数の割り当てによりオブジェクト構成が制限される可能性があります。

  • ポッド

  • レプリケーションコントローラー

  • ひみつ

  • 構成マップ

  • 永続ボリュームの要求

  • サービス (一般)、および LoadBalancer サービス (service.loadbalances) や NodePort サービス (services.nodeports) などの 2 つの特定のタイプのサービス

現時点では、ReplicaSet、Job、Deployment、Ingress などの制限はまだ最新のドキュメントを読む必要があります

4. 特定のポッド状態または Qos レベルのクォータを指定する

作成されたクォータは、ポッドの現在の状態や QoS レベルに関係なく、すべてのポッドに適用されます。

ただし、クォータは一連のクォータ スコープによって制限される場合があります。現在、クォータ スコープには 4 種類があります。

BestEffort、NotBestEffort、終了および非終了

BestEffort および NotBestEffort の範囲は、クォータが BestEffort Qos レベルのポッドに適用されるか、または両方のレベル (バースト可能および保証) に適用されるかを決定します。

これら 2 つの範囲の説明は、Terminated と NotTermination です。

各ポッドについて、ポッドは失敗としてマークされ、実際に停止するまでの実行可能時間は、ポッド仕様で構成された activeDeadlineSeconds によって実現されます。このプロパティは、ポッドが停止を試み始めてから失敗とマークされて実際に停止するまで、ノード上でポッドの実行を継続できる秒数を定義します。終了クォータは、activeDeadlineSeconds で構成されたポッドに適用されます。また、NotTermination は、この構成が指定されていないポッドに適用されます。

例証します:

ResourceQuota を作成するときに、そのスコープを指定できます。ターゲット ポッドは、クォータによって構成されたすべてのスコープと一致する必要があります。さらに、クォータ範囲によって、クォータによって制限できる内容も決まります。BestEffort 範囲ではポッドの数のみを制限できますが、他の 3 つの範囲ではポッドの数に加えてリクエストと CPU/メモリの制限を制限できます。ポッドの。

おすすめ

転載: blog.csdn.net/wwxsoft/article/details/129108956