一 为啥需要为命名空间里面添加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，我觉得还是会受到影响)
二 限制命名空间的资源总量
2.1 kubernetes通过ResourceQuota资源对命名空间的资源总量进行控制
资源配额的作用是限制某个命名空间里面各种资源的最大使用量，已经创建的pod不会被限制，例如当在创建某个pod的时候，申请的pod的内存加上集群中已经存在的pod的内存总量超过ResourceQuota,那么API服务器将会决绝接收这个pod的申请，并且除了容器的cpu，内存等这些基础资源，同时也可以限制其他的API类型资源，例如RC，RS等等一系列的资源使用量
2.2 为CPU和内存使用量创建ResourceQuota
apiVersion: v1 kind: ResourceQuota metadata: name: cpu-and-mem spec: hard: requests.cpu: 400m requests.memory: 200Mi limits.cpu: 600m limits.memory: 500Mi
- 这个ResourceQuota分别对命名空间里面的requests.cpu,requests.memory,limits.cpu,limits.memory的总量总出了限制
- 区别于LimitRange针对的对象是pod以及容器，ResourceQuota针对的对象是命名空间这些资源的总量
2.3 查看配额以及配额使用情况
[root@node01 Chapter14]# k describe quota Name: cpu-and-mem Namespace: default Resource Used Hard -------- ---- ---- limits.cpu 1 600m limits.memory 20Mi 500Mi requests.cpu 2 400m requests.memory 50Mi 200Mi
- 这些资源是之前就已经创建了的，后面创建的ResourceQuota无法对其起到限制作用
- 需要注意的一点是在创建的ResourceQuota的时候集群里面必须已经有LimitRange资源，否则在创建那些未设定requests和limits的pod的时候无法纳入统计，或者导致ResourceQuota统计的资源不准确
2.4 为持久化存储指定配额
apiVersion: v1 kind: ResourceQuota metadata: name: storage spec: hard: requests.storage: 500Gi ssd.storageclass.storage.k8s.io/requests.storage: 300Gi standard.storageclass.storage.k8s.io/requests.storage: 1Ti
- 系统允许在这个命名空间里面添加最大的存储为500Gi
- 第二项是ssd的storage的配置最大为300Gi
- 第三项是低性能的磁盘的额度为1Ti
2.5 限制集群资源可创建对象
apiVersion: v1 kind: ResourceQuota metadata: name: quota-objects spec: hard: pods: 10 replicationcontrollers: 5 secrets: 10 configmaps: 10 persistentvolumeclaims: 4 services: 5 services.loadbalancers: 1 services.nodeports: 2 ssd.storageclass.storage.k8s.io/persistenevolumeclaims: 2
- 上面的代码不言而喻，分别对命名空间里面的每种资源的数量数额进行限制
2.6 为特定的状态的pod或者Qos等级的pod指定配额
先来解释一下，可以选择的状态有哪几种
-
- BestEffort 前面已经介绍过，即pod未被设置任何的requests和limits
- NotBestEffort，即所有的配置了requests和limits的pod
- Termination,这个不好理解，可以直接理解为pod的spec中配置了activeDeadlineSecond属性的pod，而这个属性意思就是当pod被标记为failed的时候pod还可以在节点上运行的时间
- NotTermination，这个意思是pod未加入这个activeDeadlineSecond属性的pod
对于BestEffort和NotTermination的范围，只需要pod在集群中的数量，而对于NotBestEffort以及Termination状态的pod除了需要添加数量外，还需要添加requests以及limits，一个示范例子如下所示
apiVersion: v1 kind: ResourceQuota metadata: name: besteffort-notterminating-pods spec: scopes: - BestEffort - NotTerminating hard: pods: 40
三 监控集群中pod的资源使用量
注意:这里只对原理进行说明，不对实际的操作以及如何部署相关的应用进行展开
3.1 如何收集每个节点上面的pod的资源使用情况
kubelet自身包含一个cAdvisor的agent，它会收集整个节点上容器的消耗情况，之后将信息汇报给Heapster的组件