1.ポッドのQOSレベル
すべてのポッドで指定されたリソース制限の合計と同じ量のリソースを提供できない場合があります。たとえば、2 つのポッドで、podA がノード メモリの 90% を使用し、podB が突然より多くのメモリを必要とする場合、これはノードが十分なリソースを提供できないことを意味します。メモリ、どのコンテナが強制終了されるか、kubernetes は正しい決定を下すことができないため、優先順位を付ける必要があります。
Kubernetes はポッドを 3 つの Qos レベルに分割します。
BestEffort (優先度が最も低い)
バースト可能
保証（最優先）
ポッドの BestEffort レベル
最も優先度の低い Qos クラスは BestEffort です
コンテナーはリクエストを設定せず、ポッドを制限します。また、このレベルで実行されるコンテナーにはリソースの保証がありません。最悪の場合、CPU 時間がまったく得られず、同時に、他のポッドのためにメモリを解放する必要があるときに、これらのコンテナが最初に強制終了されます。ただし、BestEffort ポッドにはメモリ制限がないため、十分なメモリがあれば、これらのコンテナは必要なだけメモリを使用できます。
保証レベル
このレベルでは、すべてのリソースのリクエストと制限が同じであるポッドが割り当てられます。保証レベルのポッドには、いくつかの条件があります。
CPU とメモリの両方でリクエストと制限を設定する必要がある
各コンテナはリソースの量を設定する必要があります
それらは等しくなければなりません (各リソースのリクエストと制限は各コンテナーで等しくなければなりません)
コンテナのリソースリクエストに設定が表示されない場合はデフォルトが制限と同じになるため、全リソース（ポッド内の各コンテナの各リソース）の制限を設定するだけでポッドのQosレベルを保証することができます。 。これらのポッドのコンテナーは、要求したのと同じ量のリソースを使用できますが、それ以上のリソースを消費することはできません (要求と制限が等しいため)。
バースト可能レベル
ベストエフォートと保証の間。他のすべてのポッドはこのクラスに属します。これには、異なるリクエストと制限を持つ単一コンテナーのポッド、リクエストを定義するが制限がないコンテナーが少なくとも 1 つあるポッド、リクエストと制限が等しいが別のコンテナーがリクエストと制限のポッドを指定しないコンテナーが含まれます。限界。バースト可能なポッドは、要求したのと同じ量のリソースを取得でき、追加のリソースを (制限まで) 使用できます。
コンテナのQOSレベル
CPU リクエストと制限 |
メモリ要求と制限 |
コンテナのQOSレベル |
設定されていません |
設定されていません |
最大限の努力 |
設定されていません |
リクエスト<制限 |
バースト可能 |
設定されていません |
リクエスト＝限界 |
バースト可能 |
リクエスト<制限 |
設定されていません |
バースト可能 |
リクエスト<制限 |
リクエスト<制限 |
バースト可能 |
リクエスト<制限 |
リクエスト＝限界 |
バースト可能 |
リクエスト＝限界 |
リクエスト＝限界 |
保証されています |
マルチコンテナポッドのQosクラス
コンテナ1のQOSレベル |
コンテナ1のQOSレベル |
ポッドの Qos コンテナ |
最大限の努力 |
最大限の努力 |
最大限の努力 |
最大限の努力 |
バースト可能 |
バースト可能 |
最大限の努力 |
保証されています |
バースト可能 |
バースト可能 |
バースト可能 |
バースト可能 |
バースト可能 |
保証されています |
バースト可能 |
保証されています |
保証されています |
保証されています |
メモリが少ない場合にどのプロセスが強制終了されるか
売られすぎたシステムでは、BestEffort ポッドが最初に強制終了され、次に Burstable ポッド、そして EAN 保証型ポッドが最後に終了します。保証されたポッドは、システム プロセスがメモリを必要とする場合にのみ強制終了されます。
同じQOSレベルのコンテナを扱う方法
実行中のすべてのプロセスには、OutOfMemory (OOM) スコアと呼ばれる値があります。システムは、実行中のすべてのプロセスの OOM スコアを比較して、どのプロセスを強制終了するかを選択します。メモリを解放する必要がある場合、最も高いスコアを持つプロセスが強制終了されます。
OOM スコアは、プロセスによって消費される使用可能なメモリの割合と、ポッド QoS レベルとコンテナによって要求されたメモリ量に基づく固定 OOM スコア調整係数という 2 つのパラメータから計算されます。Burstable レベルに属する 2 つの単一コンテナー ポッドの場合、システムは実際のメモリ使用量がメモリ アプリケーションのより高い割合を占めるポッドを強制終了します。
これは、リクエストと制限の関係に注意を払うだけでなく、リクエストと予想される実際のメモリ消費量の関係にも注意を払う必要があることを示しています。
2. 名前空間内のポッドのデフォルトのリクエストと制限を設定します。
単一のコンテナーに対するリソースのリクエストと制限の設定について説明しました。
可以通过创建一个LimitRange资源来避免必须配置每个容器。LimitRange资源不仅允许用户（为每个命名空间）指定能给容器配置的每种资源的最小和最大限额，还支持在没有显式指定资源requests时为容器设置默认值。
LimitRange资源
LimitRange资源被LimitRanger准入控制插件。API服务器接收到带有pod描述信息的POST请求时，LimitRanger插件队pod spec进行校验。如果校验失败，将直接拒绝。因此，LimitRange对象的一个广泛应用场景就是阻止用户创建大于单个节点资源量的pod。如果没有LimitRange，api服务器将欣然接收pod创建请求，但永远无法调度成功。
LimitRange资源中的limits应用于同一命名空间中每个独立的pod、容器，或者其它类型的对象，但他并不会限制这个命名空间中所有pod可用资源的总量，总量时通过ResourceQuota对象指定。
LimitRange对象创建
yaml文件：limits.yaml
apiVersion:v1
kind:LimitRange
metadata:
name:example
spec:
limits:
-type:pd
min:
cpu:50m
memory:5mi
max:
cpu:1
memory:1Gi
-type:Container
defaultRequest:
cpu:100m
memory:10Mi
default:
cpu:200m
memory:100mi
min:
cpu:50m
memroy:5Mi
max:
cpu:1
memroy:1Gi
maxLimitRequestRatio:
cpu:4
memroy:10
-type:PersistentVolumeClaim
min:
storage:1Gi
max:
storage:10Gi
LimitRange对象中配置的校验（和默认值）信息在api服务器接收到新的pod和pvc创建请求时执行，如果之后修改了限制，已经存在的pod和pvc将不会再次进行校验，新的限制只会应用于之后创建的pod和pvc。
强制进行限制
创建一个cpu申请量大于limitRange允许值的pod，会限制创建成功