Kubernetes使用
前言
当用多个团队或者用户共用同一个集群的时候难免会有资源竞争的情况发生,这时候就需要对不同团队或用户的资源使用配额做出限制。
开启资源配额限制功能,目前有两种资源分配管理相关的控制策略插件 ResourceQuota和LimitRange,两种控制策略的作用范围都是基于namespace。
- ResourceQuota用来限制namespace中所有的Pod占用的总的资源 request和limit;
- LimitRange是用来设置namespace中Pod的默认的资源request和limit值。
一、资源配额
Kubernetes的众多发行版本默认开启了资源配额的支持。在apiserver的–admission-control配置中添加ResourceQuota参数后即启用资源配额功能。 当一个命名空间中含有ResourceQuota对象时,资源配额强制执行,一个命名空间最多只能有一个ResourceQuota对象。
资源配额类型
资源配额分为三种类型:
- 计算资源配额
- 存储资源配额
- 对象数量配额
1.计算资源的配额
资源名称 | 描述 |
---|---|
cpu | 非终止态的所有pod,cpu请求总量不能超出此值。 |
limits.cpu | 非终止态的所有pod,cpu限制总量不能超出此值。 |
limits.memory | 非终止态的所有pod,内存限制总量不能超出此值。 |
memory | 非终止态的所有pod,内存请求总量不能超出此值。 |
requests.cpu | 非终止态的所有pod,cpu请求总量不能超出此值。 |
requests.memory | 非终止态的所有pod,内存请求总量不能超出此值。 |
2.计算资源的配额
存储资源的配额
资源名称 | 描述 |
---|---|
requests.storage | 所有PVC, 存储请求总量不能超出此值。 |
persistentvolumeclaims | 命名空间中可以存在的PVC(persistent volume claims)总数。 |
.storageclass.storage.k8s.io/requests.storage | 和该存储类关联的所有PVC, 存储请求总和不能超出此值。 |
.storageclass.storage.k8s.io/persistentvolumeclaims | 和该存储类关联的所有PVC,命名空间中可以存在的PVC(persistent volume claims)总数。 |
例如,如果一个操作人员想要分别定额gold存储类和bronze存储类,则这个操作人员可以按照下面这样定义配额:
- gold.storageclass.storage.k8s.io/requests.storage: 500Gi
- bronze.storageclass.storage.k8s.io/requests.storage: 100Gi
3. 对象数量的配额
资源名称 | 描述 |
---|---|
congfigmaps | 命名空间中可以存在的配置映射的总数。 |
persistentvolumeclaims | 命名空间中可以存在的PVC总数。 |
pods | 命名空间中可以存在的非终止态的pod总数。如果一个pod的status.phase 是 Failed, Succeeded, 则该pod处于终止态。 |
replicationcontrollers | 命名空间中可以存在的rc总数。 |
resourcequotas | 命名空间中可以存在的资源配额(resource quotas)总数。 |
services | 命名空间中可以存在的服务总数量。 |
services.loadbalancers | 命名空间中可以存在的服务的负载均衡的总数量。 |
services.nodeports | 命名空间中可以存在的服务的主机接口的总数量。 |
secrets | 命名空间中可以存在的secrets的总数量。 |
例如,pod 数量配额表示在单个命名空间中可以创建的pod的最大值。 比如在一个命名空间中定义一个pod限额来避免一个用户创建许多的pod从而耗光这个集群Pod IPs 的情况。
4. 限额的作用域
每个配额可以有一组关联的作用域。如果一个限额匹配枚举的作用的交集,它将只衡量一个资源的利用率。 当一个作用域被添加到配额时,它将会限制它支持的涉及到该作用域的资源的数量。在不允许设置的限额上指定资源将会导致一个验证错误。
作用域 | 描述 |
---|---|
Terminating | 匹配 spec.activeDeadlineSeconds >= 0 的pod |
NotTerminating | 匹配 spec.activeDeadlineSeconds is nil 的pod |
BestEffort | 匹配具有最佳服务质量的pod |
NotBestEffort | 匹配具有非最佳服务质量的pod |
BestEffort作用域禁止限额跟踪以下的资源:
- Pods
Terminating 、NotTerminating和NotBestEffort作用域禁止限额跟踪以下的资源:
- cpu
- limits.cpu
- limits.memory
- memory
- pods
- requests.cpu
- requests.memory
二、示例
1. LimitRange
命名空间配置默认的内存请求与限额
如果在一个拥有默认内存限额的命名空间中创建一个容器,并且这个容器未指定它自己的内存限额, 它会被分配这个默认的内存限额值
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256Mi
type: Container
命名空间配置配置默认的CPU请求与限额
在一个拥有默认CPU限额的命名空间中创建一个容器,则这个容器不需要指定它自己的CPU限额, 它会被分配这个默认的CPU限额值
apiVersion: v1
kind: LimitRange
metadata:
name: cpu-limit-range
spec:
limits:
- default:
cpu: 1
defaultRequest:
cpu: 0.5
如果命名空间具有资源配额, 它为内存和CPU限额设置默认值是有意义的。 以下是资源配额对命名空间施加的两个限制:
- 在命名空间运行的每一个容器必须有它自己的内存或CPU限额。
- 在命名空间中所有的容器使用的内存或CPU总量不能超出指定的限额。
如果一个容器没有指定它自己的内存或CPU限额,它将被赋予默认的限额值,然后它才可以在被配额限制的命名空间中运行
Namespace 设置最小和最大内存限制
可以设置 LimitRange 对象中内存的最小和最大值。如果 Pod 没有符合 LimitRange 施加的限制,那么就不能在 namespace中创建。
apiVersion: v1
kind: LimitRange
metadata:
name: mem-min-max-demo-lr
spec:
limits:
- max:
memory: 1Gi
min:
memory: 500Mi
type: Container
Namespace 配置最小和最大 CPU 限制,设置 LimitRange 对象中 CPU 的最小和最大值。如果 Pod 没有符合 LimitRange 施加的限制,那么它就不能在 namespace中创建。
总结
Pod和容器的max、min、maxLimitRequestRatio ResourceQuota
适用场景:
控制容器或Pod的CPU或内存资源使用,如容器的CPU的request不得小于多少,limit不得大于多少,不满足条件则创建失败。
容器部分:
- defaultRequest:容器默认的request值,若不指定request值,则默认为此值
- max:容器的实际设置的limit值应小于等于此值
- min:容器实际设置的request值应大于等于此值
- defaultLimit:Pod中所有未指定Limits值的容器的默认Limits值
- maxLimitRequestRatio:Max Limit/Request Ratio,为容器CPU或内存的Limit/Request值应小于等于此值
Pod部分:
- max:Pod中所有容器的实际设置的limit之和值应小于等于此值
- min:Pod中所有容器实际设置的request值之和应大于等于此值
- maxLimitRequestRatio:Max Limit/Request Ratio,为Pod中所有容器CPU或内存的Limit之和/Request之和值应小于等于此值
- max表示pod中所有容器资源的Limit值和的上限,也就是整个pod资源的最大Limit,如果pod定义中的Limit值大于LimitRange中的值,则pod无法成功创建。
- min表示pod中所有容器资源请求总和的下限,也就是所有容器request的资源总和不能小于min中的值,否则pod无法成功创建。
- maxLimitRequestRatio表示pod中所有容器资源请求的Limit值和request值比值的上限,例如该pod中cpu的Limit值为3,而request为0.5,此时比值为6,创建pod将会失败。