一  为啥需要为命名空间里面添加pod添加默认的requests和limits？

　　

　　通过前面的学习我们已经知道，如果节点上面的pod没有设置requests和limits，这些容器就会受那些设置了的控制，一旦出现节点内存资源超卖，这些未被设置的pod则会优先被kubernetes清除，所以对于每个pod而言，都应当给设定requests和limits值是个不错的选择。

 

　　1.1 介绍limitRange资源

　　　　limitRange不仅支持用户给命名空间里面的pod每种资源配置最大最小值，甚至还会在没有显性的申明下，还会给容器添加系统的默认配值，更详细的描述如图所示

                

 

• 图中很好的显示了，当创建podA的时候，由于里面的requests和Limits值超过了LimitRange的预设置，所以无法成功的创建
• 而在创建pod B的时候由于没有设置默认的requests和limits的值在，则准入插件会根据默认值为它添加这2项
• 如果命名空间里面没有LimitRange的话，当pod申请的资源大于节点的资源的时候API服务器还是会接收这个请求，但是却无法进行调度
• limitRange资源参数limit的作用对象始终是每个独立的pod，容器或者是其他类型对象，始终不会是某个命名空间的limits总和，实际上总和是由ResourceQuota对象来指定

 

　　1.2  创建一个LimitRange对象

apiVersion: v1
kind: LimitRange
metadata:
  name: example
spec:
  limits:
  - type: Pod
    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
     memory: 5Mi
    max:
      cpu: 1
      memory: 1Gi
    maxLimitRequestRatio:
      cpu: 4
      memory: 10
  - type: PersistentVolumeClaim
    min:
      storage: 1Gi
    max:
      storage: 10Gi

• LimitRange中以type为分类可以限制各种各种类型的资源，第一项限制了pod中容器requests和limits之和最大值和最小值区间
• 第二项设置了pod中每个容器在没有配置的时候默认添加的requests和limits的值以及每个容器的内存以及cpu最小最大值，和最大值与最小值的比值限制等
• 并且可以限制pvc的最大值以及最小值
• 也可以单独的将这些type进行拆分，之后pod在通过API的准入插件的时候，会将所有的这些type合并起来
• 如果在修改了LimitRange之后，之前集群已经创建的pod规则不会收到影响(这里有个疑问，如果pod在LimitRange资源创建之前就已经好了，后来由于某种原因需要重新调度，并且还是沿用之前pod的requests和limits，我觉得还是会受到影响)