设置默认的 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 对象可以做到这点。