kubernetes pod limit requestリソース制限
一、kubernetersにおけるRequestとLimit制限方式の説明
Request:コンテナ使用の最小リソース需要は,コンテナスケジューリング時のリソース割当の判断に依存する.コンテナをノードにスケジュールできるのは、ノードに割り当て可能なリソース量>=コンテナリソース要求数のみです.ただし、Requestパラメータはコンテナの最大使用可能リソースを制限しません.
Limit:コンテナがリソースを使用できるリソースの最大値を0に設定すると、使用リソースに上限がないことを示します.
RequestはPodが実行するのに十分なリソースがあることを保証し、LimitはあるPodが無制限にリソースを使用し、他のPodがクラッシュすることを防止する.両者の間には、0<=Request<=Limit<=Infinity(Limitが0の場合はリソースを制限しない場合、Requestより小さくすることができます)の関係を満たす必要があります.
リソース要件(Requests)と制限(Limits)
各リソースについてcontainerは、0からnodeノードの最大構成であるリクエストおよび制限(limits)を指定し、limitsのリクエスト範囲はrequestsから無限、すなわち0<=requests<=Node Allocatable、requests<=limits<=Infinityです.
CPUの場合、podのサービスでCPUが設定したlimitsを超えた場合、podはkillに落とされないが制限される.limitsが設定されていない場合、podはすべての空きcpuリソースを使用できます.
メモリの場合、podが設定したlimitsを超えてメモリを使用すると、podのcontainerのプロセスはkernelによってOOM killによって削除されます.containerがOOMのためにkillによって削除されると、システムは、元のマシン上でcontainerまたはネイティブまたは他のpodを再起動する傾向があります.
QoS分類
KubeletはQoSサービス品質管理を提供し、システムレベルのOOM制御をサポートする.Kubernetesでは、podのQoSレベルは、Guaranteed、Burstable、Best-Effortを含む.各レベルについて説明します.
Guaranteed:podのすべてのコンテナはcpuとmemoryに対してlimitsを同時に設定する必要があります.requestsを設定するコンテナがある場合、すべてのコンテナが設定され、設定パラメータがlimitsと一致すると、このpodのQoSはGuaranteedレベルになります.注意:1つのコンテナがlimitのみを指定し、requestが設定されていない場合、requestの値はlimitの値に等しくなります.
Guaranteed例1:コンテナはlimitsのみを示し、requestsは示さない).
Guaranteedの例2:requestsとlimitはいずれも指定され、値は等しい.
Burstable:podには1つの容器のrequestsとlimitsの設定が異なる限り、そのpodのQoSはBurstableとなる.例を次に示します.
Container barはresourcesを指定していません
Burstableの例2:podでは、cpuまたはmemoryのrequestおよびlimitsに対して明示的に指定されていないコンテナが1つある限り.
Burstable例3:Container fooはlimitsを設定していないが、bar requestsとlimitsは設定していない.
Best-Effort:requestsとlimitsがすべてのresourcesに対して設定されていない場合、podのQoSはBest-Effortとなります.例を次に示します.
圧縮可能リソースと非圧縮リソース
Kubernetesは,資源が伸縮できるか否かによって分類され,圧縮可能資源と非圧縮可能資源の2種類に分類される.CPUリソースは現在サポートされている圧縮可能なリソースであり、メモリリソースとディスクリソースは現在サポートされている非圧縮リソースである.
QoS優先度
3種類のQoS優先度が低いから高い(左から右へ):
Best-Effort pods -> Burstable pods -> Guaranteed pods
静的pod
Kubernetesには、api serverの介入を必要とせずにノード上で実行できるDaemonSetタイプpodがあります.静的podはRCを関連付ける必要もなく、完全にkubeletサービスによって監視され、kubeletが静的podの停止を発見すると、kubeletは静的podを再起動します.
この文書はリンクから作成されます.https://www.jianshu.com/p/4c0763967b3c
Kubernetesリソース割り当てのRequestとLimit解析リンクを参照https://www.cnblogs.com/robinunix/articles/11413059.html
例:
Containers:
cloud-gateway:
Container ID: docker://3ea58021ffef1416d508008a606e601234fe436ed600b36db4eb7b5fe729e861
Image: registry.cn-hangzhou.aliyuncs.com/fugle/cloud_gateway:2004101448
Image ID: docker-pullable://registry.cn-hangzhou.aliyuncs.com/fugle/cloud_gateway@sha256:c304c42e65dc3503131eda462ea05c49a7726ca1028c7b087419b87146496801
Port:
Host Port:
State: Running
Started: Thu, 30 Jul 2020 15:08:09 +0800
Ready: True
Restart Count: 0
Limits:
cpu: 4
Requests:
cpu: 1
Environment:
JAVA_OPTS: -Xms1024m -Xmx1024m -Xmn512m -XX:+UseConcMarkSweepGC -Dahas.namespace=default -Dproject.name=gateway-test -Drap.redis.server=r-bp1usanbbv4xldesxy.redis.rds.aliyuncs.com:6379 -Drap.redis.auth.password=GqdLSFUhnm6MpyeVKIu3 -Dspring.cloud.nacos.config.endpoint=addr-hz-internal.edas.aliyun.com -Dspring.cloud.nacos.config.access-key=LTAI4FouGjrhSaYJQx8v1icq -Dspring.cloud.nacos.config.secret-key=1zoLwDHTojELEVWmHaCzQFD58NcsIJ -Dspring.cloud.nacos.config.namespace=49e95a77-24e3-4b2a-b657-4d51463da9d0 -Dspring.cloud.nacos.config.file-extension=yaml -Dspring.application.name=gateway-test -Dspring.security.user.password=chrdwhdhxt -Dspring.profiles.active=test -Drap.cloud.gateway.test.enable=true -Drap.cloud.gateway.test.server=https://grafana-test.dingtax.cn -Dfile.encoding=utf-8
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-56rxd (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
default-token-56rxd:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-56rxd
Optional: false
QoS Class: Burstable
Node-Selectors:
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Events:
Request:コンテナ使用の最小リソース需要は,コンテナスケジューリング時のリソース割当の判断に依存する.コンテナをノードにスケジュールできるのは、ノードに割り当て可能なリソース量>=コンテナリソース要求数のみです.ただし、Requestパラメータはコンテナの最大使用可能リソースを制限しません.
Limit:コンテナがリソースを使用できるリソースの最大値を0に設定すると、使用リソースに上限がないことを示します.
RequestはPodが実行するのに十分なリソースがあることを保証し、LimitはあるPodが無制限にリソースを使用し、他のPodがクラッシュすることを防止する.両者の間には、0<=Request<=Limit<=Infinity(Limitが0の場合はリソースを制限しない場合、Requestより小さくすることができます)の関係を満たす必要があります.
リソース要件(Requests)と制限(Limits)
各リソースについてcontainerは、0からnodeノードの最大構成であるリクエストおよび制限(limits)を指定し、limitsのリクエスト範囲はrequestsから無限、すなわち0<=requests<=Node Allocatable、requests<=limits<=Infinityです.
CPUの場合、podのサービスでCPUが設定したlimitsを超えた場合、podはkillに落とされないが制限される.limitsが設定されていない場合、podはすべての空きcpuリソースを使用できます.
メモリの場合、podが設定したlimitsを超えてメモリを使用すると、podのcontainerのプロセスはkernelによってOOM killによって削除されます.containerがOOMのためにkillによって削除されると、システムは、元のマシン上でcontainerまたはネイティブまたは他のpodを再起動する傾向があります.
QoS分類
KubeletはQoSサービス品質管理を提供し、システムレベルのOOM制御をサポートする.Kubernetesでは、podのQoSレベルは、Guaranteed、Burstable、Best-Effortを含む.各レベルについて説明します.
Guaranteed:podのすべてのコンテナはcpuとmemoryに対してlimitsを同時に設定する必要があります.requestsを設定するコンテナがある場合、すべてのコンテナが設定され、設定パラメータがlimitsと一致すると、このpodのQoSはGuaranteedレベルになります.注意:1つのコンテナがlimitのみを指定し、requestが設定されていない場合、requestの値はlimitの値に等しくなります.
Guaranteed例1:コンテナはlimitsのみを示し、requestsは示さない).
containers:
name: foo
resources:
limits:
cpu: 10m
memory: 1Gi
name: bar
resources:
limits:
cpu: 100m
memory: 100MiGuaranteedの例2:requestsとlimitはいずれも指定され、値は等しい.
containers:
name: foo
resources:
limits:
cpu: 10m
memory: 1Gi
requests:
cpu: 10m
memory: 1Gi
name: bar
resources:
limits:
cpu: 100m
memory: 100Mi
requests:
cpu: 100m
memory: 100MiBurstable:podには1つの容器のrequestsとlimitsの設定が異なる限り、そのpodのQoSはBurstableとなる.例を次に示します.
Container barはresourcesを指定していません
containers:
name: foo
resources:
limits:
cpu: 10m
memory: 1Gi
requests:
cpu: 10m
memory: 1Gi
name: barBurstableの例2:podでは、cpuまたはmemoryのrequestおよびlimitsに対して明示的に指定されていないコンテナが1つある限り.
containers:
name: foo
resources:
limits:
memory: 1Gi
name: bar
resources:
limits:
cpu: 100mBurstable例3:Container fooはlimitsを設定していないが、bar requestsとlimitsは設定していない.
containers:
name: foo
resources:
requests:
cpu: 10m
memory: 1Gi
name: barBest-Effort:requestsとlimitsがすべてのresourcesに対して設定されていない場合、podのQoSはBest-Effortとなります.例を次に示します.
containers:
name: foo
resources:
name: bar
resources:圧縮可能リソースと非圧縮リソース
Kubernetesは,資源が伸縮できるか否かによって分類され,圧縮可能資源と非圧縮可能資源の2種類に分類される.CPUリソースは現在サポートされている圧縮可能なリソースであり、メモリリソースとディスクリソースは現在サポートされている非圧縮リソースである.
QoS優先度
3種類のQoS優先度が低いから高い(左から右へ):
Best-Effort pods -> Burstable pods -> Guaranteed pods
静的pod
Kubernetesには、api serverの介入を必要とせずにノード上で実行できるDaemonSetタイプpodがあります.静的podはRCを関連付ける必要もなく、完全にkubeletサービスによって監視され、kubeletが静的podの停止を発見すると、kubeletは静的podを再起動します.
この文書はリンクから作成されます.https://www.jianshu.com/p/4c0763967b3c
Kubernetesリソース割り当てのRequestとLimit解析リンクを参照https://www.cnblogs.com/robinunix/articles/11413059.html
例:
Containers:
cloud-gateway:
Container ID: docker://3ea58021ffef1416d508008a606e601234fe436ed600b36db4eb7b5fe729e861
Image: registry.cn-hangzhou.aliyuncs.com/fugle/cloud_gateway:2004101448
Image ID: docker-pullable://registry.cn-hangzhou.aliyuncs.com/fugle/cloud_gateway@sha256:c304c42e65dc3503131eda462ea05c49a7726ca1028c7b087419b87146496801
Port:
Host Port:
State: Running
Started: Thu, 30 Jul 2020 15:08:09 +0800
Ready: True
Restart Count: 0
Limits:
cpu: 4
Requests:
cpu: 1
Environment:
JAVA_OPTS: -Xms1024m -Xmx1024m -Xmn512m -XX:+UseConcMarkSweepGC -Dahas.namespace=default -Dproject.name=gateway-test -Drap.redis.server=r-bp1usanbbv4xldesxy.redis.rds.aliyuncs.com:6379 -Drap.redis.auth.password=GqdLSFUhnm6MpyeVKIu3 -Dspring.cloud.nacos.config.endpoint=addr-hz-internal.edas.aliyun.com -Dspring.cloud.nacos.config.access-key=LTAI4FouGjrhSaYJQx8v1icq -Dspring.cloud.nacos.config.secret-key=1zoLwDHTojELEVWmHaCzQFD58NcsIJ -Dspring.cloud.nacos.config.namespace=49e95a77-24e3-4b2a-b657-4d51463da9d0 -Dspring.cloud.nacos.config.file-extension=yaml -Dspring.application.name=gateway-test -Dspring.security.user.password=chrdwhdhxt -Dspring.profiles.active=test -Drap.cloud.gateway.test.enable=true -Drap.cloud.gateway.test.server=https://grafana-test.dingtax.cn -Dfile.encoding=utf-8
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-56rxd (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
default-token-56rxd:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-56rxd
Optional: false
QoS Class: Burstable
Node-Selectors:
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Events: