kubernetes之为每个命名空间的pod设置默认的requests以及limits
堇牧安年 人气:0一 为啥需要为命名空间里面添加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,我觉得还是会受到影响)
加载全部内容