希望长大对我而言，是可以做更多想做的事，而不是被迫做更多不想做的事...... 首页

k8s资源管理

丁D
学无止境
2019-11-15 11:07
54073已阅读

k8s 资源

摘要本文将详细介绍k8s的资源管理包括：计算资源管理（Compute Resources）、服务质量管理（QoS）、资源配置范围管理（LimitRange）、资源配额管理（ResourceQuota）

##资源管理
###计算资源（Requests和Limits参数）

Pod的两个重要参数：CPU Request与Memory Request来表示容器最少所需的CPU和Memory。
Pod的两个重要参数：CPU Limitst与Memory Limits来表示容器最多只能使用的CPU和Memory。

1.当我们没有为容器设置Request的时候，表示这个容器可以使用Node的所有CPU和Memory。

2.当我们没有为容器设置Request的时候，k8s会认为该容器使用很少的资源就可以调度到集群的任何Node，这个时候如果Node本来所剩的资源不多的时候，就会加大该Node的负载。

3.pod的requests和limits分别等于pod下所有的requests和limits之和。

4.pod所使用的的memory超过Limits就会被杀掉。

5.memory的单位支持十进制和二进制
◎ 1 KB（KiloByte）= 1000 Bytes = 8000 Bits；
◎ 1 KiB（KibiByte）= 210 Bytes = 1024 Bytes = 8192 Bits。

6.参数只能配置在容器中.
◎ spec.container[].resources.requests.cpu； 
◎ spec.container[].resources.limits.cpu； 
◎ spec.container[].resources.requests.memory； 
◎ spec.container[].resources.limits.memory。

![](/upload/20191120151830.png)

如上图所示定义了一个db容器  memory：64Mi~128Mi         cpu：250m~500m 
>**注意**
1核cpu=1000m,也就是说250m~500m为0.25~0.5核

调度前提：一个pod要能被调度到某个node的前提是，该node的容量-该node的pod的requests之和>等待调度的pod的requests。

Kubernetes调度器在集群中找不到合适的节点来运行Pod，那么这个Pod 会一直处于未调度状态，直到调度器找到合适的节点为止。Pod状态为Pending，错误信息为FailedScheduling。

###资源配置范围管理（LimitRange）
你想象一下当你有几百个pod，你要为每个pod里面的容器配置requests和limits，还要确定他们没有错。这个是很繁琐的工作。很多时候我们需要对集群内Requests和Limits的配置做一个全局限制。
所以出现了LimitRange定义**命名空间**里面所有的pod的默认requests和limits。

◎ 集群中的node没有一个内存超过2GB内存，所以所有的pod的Requests都不能超过2GB内存，因为没有一个node能够运行这个pod。

1.创建一个命名空间
![](/upload/微信图片_20191120154236.png)
2.创建一个LimitRange
![](/upload/微信图片_20191120154232.png)
3.将LimitRange绑定到命名空间。
![](/upload/微信图片_20191120154227.png)
4.查看效果
![](/upload/微信图片_20191120154223.png)

◎ 不论是CPU还是内存，在LimitRange中，Pod和Container都可 以设置Min、Max和Max Limit/Requests Ratio参数。Container还可以设置 Default Request和Default Limit参数，而Pod不能设置Default Request和 Default Limit参数。

◎ 参数必须满足关系： Min ≤ Default Request ≤ Default Limit ≤ Max

◎ Container的Min（上面的100m和3Mi）是Pod中所有容器的 Requests值下限；Container的Max（上面的2和1Gi）是Pod中所有容器的 Limits值上限；Container的Default Request（上面的200m和100Mi）是 Pod中所有未指定Requests值的容器的默认Requests值；Container的 Default Limit（上面的300m和200Mi）是Pod中所有未指定Limits值的容 器的默认Limits值。

◎ Pod的Min（上面的200m和6Mi）是Pod中所有容器的Requests 值的总和下限；Pod的Max（上面的4和2Gi）是Pod中所有容器的Limits 值的总和上限。当容器未指定Requests值或者Limits值时，将使用
Container的Default Request值或者Default Limit值

◎ Container的Max Limit/Requests Ratio（上面的5和4）限制了Pod 中所有容器的Limits值与Requests值的比例上限；而Pod的Max Limit/Requests Ratio（上面的3和2）限制了Pod中所有容器的Limits值总 和与Requests值总和的比例上限

◎ 如果设置了Container的Max，那么对于该类资源而言，整个 集群中的所有容器都必须设置Limits，否则无法成功创建。Pod内的容器 未配置Limits时，将使用Default Limit的值（本例中的300m CPU和 200MiB内存），如果也未配置Default，则无法成功创建。

◎ 如果设置了Container的Min，那么对于该类资源而言，整个集 群中的所有容器都必须设置Requests。如果创建Pod的容器时未配置该类 资源的Requests，那么在创建过程中会报验证错误。Pod里容器的 Requests在未配置时，可以使用默认值defaultRequest（本例中的200m CPU和100MiB内存）；如果未配置而又没有使用默认值 defaultRequest，那么会默认等于该容器的Limits；如果此时Limits也未 定义，就会报错。

◎ Pod里任何容器的Limits与Requests的比例都不能超过 Container的Max Limit/Requests Ratio；Pod里所有容器的Limits总和与 Requests的总和的比例不能超过Pod的Max Limit/Requests Ratio。

这句话感觉有问题啊？？？？Limits总和必须小于或等于1GiB； ？？？？CPU Limits总和必须小于或等于2。？？？
◎ 对于任意一个Pod而言，该Pod中所有容器的Requests总和必 须大于或等于6MiB，而且所有容器的Limits总和必须小于或等于1GiB； 同样，所有容器的CPU Requests总和必须大于或等于200m，而且所有容 器的CPU Limits总和必须小于或等于2。

###资源配额管理（ResourceQuota）
◎ ResourceQuota可以为每个命名空间都提供一个总体的资源使用的限制，比如设置dev命名空间使用1CPU,1Gi内存。
◎ ResourceQuota可以限制命名空间中某种类型的对象的 总数目上限，如pod的个数。

◎ 资源配额可以通过在kube-apiserver的--admission-control参数值中添 加ResourceQuota参数进行开启。

◎ 一个命名空间可以有多个ResourceQuota，ResourceQuota也是在namespace中的，绑定在namespace。

1.开启资源配额kube-apiserver配置--admission-control ResourceQuota（逗号隔开）
![](/upload/微信图片_20191120163603.png)
2.创建命名空间
![](/upload/微信图片_20191120163640.png)
3.创建ResourceQuota（这里创建2个）
![](/upload/微信图片_20191120163710.png)
![](/upload/微信图片_20191120163720.png)
4.将ResourceQuota绑定在namespace.
![](/upload/微信图片_20191120163802.png)
![](/upload/微信图片_20191120163812.png)
5.查看各ResourceQuota的详细信息
![](/upload/微信图片_20191120163905.png)
![](/upload/微信图片_20191120163911.png)

###服务质量管理（QoS）
在一个超用系统中，由于容器负载的波动可能导致操作系统的资源不足，最终可能导致部分容器被杀掉。在这种情况下，我们当然会希望优先杀掉那 些不太重要的容器，那么如何衡量重要程度呢？

◎ Kubernetes将容器划分 成3个QoS等级：Guaranteed（完全可靠的）、Burstable（较可靠的）和BestEffort（不太可靠的），这三种优先级依次递减。

![](/upload/微信图片_20191120165458.png)

**Guaranteed**
pod中所有容器都设置了requests和limites，并且requests=limites

**BestEffort**
pod中所有容器都没有设置了requests和limites
**Burstable**
去掉Guaranteed和BestEffort，剩余的就是Burstable。比如
1.pod有两个容器，一个配置了requests和limites（两者不一样相等），一个没有配置
2.pod有两个容器，两个都设置了但是最多只能一个requests=limites，

cpu是可压缩资源，所以当Pod的CPU Requests无法得到满足，容器得到的CPU会 被压缩限流。
内存是不可压缩的资源，所以内存不足时，会按照以下逻辑进行处理。

（1）BestEffort Pod的优先级最低，在这类Pod中运行的进程会在系 统内存紧缺时被第一优先杀掉。当然，从另外一个角度来看，BestEffort Pod由于没有设置资源Limits，所以在资源充足时，它们可以充分使用所有的闲置资源。
（2）Burstable Pod的优先级居中，这类Pod初始时会分配较少的可 靠资源，但可以按需申请更多的资源。当然，如果整个系统内存紧缺，又没有BestEffort容器可以被杀掉以释放资源，那么这类Pod中的进程可 能会被杀掉。
（3）Guaranteed Pod的优先级最高，而且一般情况下这类Pod只要 不超过其资源Limits的限制就不会被杀掉。当然，如果整个系统内存紧 缺，又没有其他更低优先级的容器可以被杀掉以释放资源，那么这类 Pod中的进程也可能会被杀掉。

>**注意**
BestEffort一定会优先会杀掉。。但是Burstable和Guaranteed不一样谁先被杀掉。。
后续会讲解pod的驱逐机制，参考：：https://www.cnblogs.com/ryanyangcs/p/11328697.html

###参考
以上内容来自《Kubernetes权威指南 第4版》
这个文章不错  https://cloud.tencent.com/developer/article/1501399

上一篇：k8s日志解决方案

下一篇：k8s命名空间和运行环境