设置默认的 requests & limits

为命名空间中的 pod 设置默认的 requests 和 limits

LimitRange 资源简介

可以通过创建一个 LimitRange 资源来避免必须配置每个容器。LimitRange 资源不仅允许用户（为每个命名空间）指定能给容器配置的每种资源的最小和最大限额，还支持在没有显式指定资源 requests 时为容器设置默认值。

LimitRange 资源被 LimitRanger 准入控制插件。API服务器接收到带有 pod 描述信息的 POST请求时，LimitRanger 插件对 pod spec 进行校验。如果校验失败，将直接拒绝。因此，LimitRange 对象的一个广泛应用场景就是阻止用户创建大于单个节点资源量的 pod。如果没有 LimitRanger，API服务器将欣然接收 pod 创建请求，但永远无法调度成功。
LimitRange 资源中的 limits 应用于同一个命名空间中每个独立的 pod、容器，或者其他类型的对象。它并不会限制这个命名空间中所有 pod 可用资源的总量，总量是通过 Resou rceQuota #F44336 对象指定的。

LimitRange 对象的创建

apiVersion: v1
kind: LimitRange
metadata:
  name: example
spec:
  limits:
  - type: Pod     # 指定整个 pod 的资源limits
    min:         # pod 中所有容器的 CPU 和内存的请求量之和的最小值
      cpu: 50m      
      memory: 5Mi
    max:         # pod 中所有容器的 CPU 和内存的请求量之和的最大值
      cpu: 1
      memory: 1Gi
  - type: Container   # 指定容器的资源限制
    defaultRequest:    # 容器没有指定 CPU 或内存请求量时设置的默认值
      cpu: 100m  
      memory: 10Mi
    default:        # 没有指定 limits 时设置的默认值
      cpu: 200m
      memory: 100Mi 
    min:          # 容器的CPU和内存的资源requests和limits的最小值和最大值 
      cpu: 50m
      memory: 5Mi
    max:          # 
      cpu: 1
      memory: 1Gi
    maxLimitRequestRatio:  #每种资源requests与limits的最大比值
      cpu: 4
      memory: 10
  - type: PersistentVolumeClaim     # LimitRange还可以指定请求PVC存储容量的最小值和最大值
    min:
      storage: 1Gi
    max:
      storage: 10Gi

整个pod资源限制的最小值和最大值是可以配置的。它应用于 pod 内所有容器的 requests 和 limits 之和。
在更低一层的容器级别，用户不仅可以设置最小值和最大值，还可以为没有显示指定的容器设置资源 requests（ defaultRequest）和 limits ( default ) 的默认值。
除了最小值、最大值和默认值，用户甚至可以设置 limits 和 requests 的最大比例（maxLimitRequestRatio）。上例中设置为4，表示容器的 CPU limits 不能超过 CPU requests 的 4 倍。因此，对于一个申请了200豪核的容器，如果它的 CPU 限额设置为801豪核或者更大就无法创建。

由于 LimitRange 对象中配置的校验（和默认值）信息在 API 服务器接收到新的 pod 或 PVC 创建请求时执行，如果之后修改了限制，已经存在的 pod 和 PVC 将不会再次进行校验，新的限制只会应用于之后创建的 pod 和 PVC 。

强制进行限制

在设置了限制的情况下，我们尝试创建一个 CPU 申请量大于 LimitRange 允许值的 pod。

apiVersion: v1
kind: Pod
metadata:
  name: too-big
spec:
  containers:
  - image: busybox
    args: ["sleep", "9999999"]
    name: main
    resources:
      requests:
        cpu: 2
		
The Pod "too-big" is invalid: spec.containers[0].resources.requests: Invalid value: "2": must be less than or equal to cpu limit

CPU requests 超过限制

应用资源 requests 和 limits 的默认值

cat kubia-manual.yaml
apiVersion: v1
kind: Pod
metadata:
  name: kubia-manual
spec:
  containers:
  - image: luksa/kubia
    name: kubia
    ports:
    - containerPort: 8080
      protocol: TCP

在我们设置 LimitRange 对象之前，所有 pod 创建后都不包含资源 requests 或 limits。
但现在我们通过 describe 确认一下刚刚创建的 kubia-manual pod。

# kubectl  describe pod kubia-manual 
...
Containers:
  kubia:
    Container ID:   
    Image:          luksa/kubia
    Image ID:       
    Port:           8080/TCP
    Host Port:      0/TCP
    State:          Waiting
      Reason:       ContainerCreating
    Ready:          False
    Restart Count:  0
    Limits:
      cpu:     200m
      memory:  100Mi
    Requests:
      cpu:        100m
      memory:     10Mi
    Environment:  <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-zjh4g (ro)
...

容器的 requests 和 limits 与我们在 LimitRange 对象中设置的一致。如果我们在另一个命名空间中指定不同的 LimitRange, 那么这个命名空间中创建的pod就会拥有不同的 requests和 limits。这样管理员就可以为每个命名空间的pod配置资源的默认值、最小值和最大值。
LimitRange 中配置的 limits 只能应用于单独的 pod 或容器 #F44336。用户仍然可以创建大量的 pod 吃掉集群所有可用资源。ResourceQuota 对象可以做到这点。

__EOF__

本文作者：何时&明月
本文链接：https://www.cnblogs.com/kiyalone/p/15957162.html
关于博主：当你发现自己的才华支撑不起野心时，就请安静下来学习吧！
版权声明：本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！
声援博主：如果您觉得文章对您有帮助，可以点击文章右下角【推荐】一下。您的鼓励是博主的最大动力！