通过设置命名空间级别的资源配额,实现多团队或多用户在共享集群资源的情况下限制团队、用户可以使用的资源总量,包括限制命名空间下创建某一类型对象的数量以及对象消耗计算资源(CPU、内存)的总量。
背景信息
默认情况下,运行中的Pod可以无限制的使用Node节点上的CPU和内存,这意味着任意一个Pod都可以无节制地使用集群的计算资源,某个命名空间的Pod可能会耗尽集群的所有资源。
kubernetes在一个物理集群上提供了多个虚拟集群,这些虚拟集群被称为命名空间。命名空间可用于多种工作用途,满足多用户的使用需求,通过为每个命名空间配置资源额度可以有效限制资源滥用,从而保证集群的可靠性。
您可为命名空间配置包括CPU、内存、Pod数量等资源的额度,更多信息请参见Resource Quotas。
其中,不同的集群规模对应的Pod数量推荐值如下:
集群规模 | Pod数量推荐值 |
---|---|
50节点 | 2500 Pod实例 |
200节点 | 1W Pod实例 |
1000节点 | 3W Pod实例 |
2000节点 | 5W Pod实例 |
从1.21版本集群开始,如果在集群配置管理中开启了enable-resource-quota参数,则创建命名空间将会同时创建默认的资源配额Resource Quotas,根据集群规格不同,各个资源的配额如下表所示。您可以根据实际需求修改。
表 默认资源配额
集群规模 | Pod | Deployment | Secret | ConfigMap | Service |
---|---|---|---|---|---|
50节点 | 2000 | 1000 | 1000 | 1000 | 1000 |
200节点 | 2000 | 1000 | 1000 | 1000 | 1000 |
1000节点 | 5000 | 2000 | 2000 | 2000 | 2000 |
2000节点 | 5000 | 2000 | 2000 | 2000 | 2000 |
约束与限制
在Kubernetes中,外部用户及内部组件频繁的数据更新操作采用乐观并行的控制方法。通过定义资源版本(resourceVersion)实现乐观锁,资源版本字段包含在对象的元数据(metadata)中。这个字段标识了对象的内部版本号,且对象被修改时,该字段将随之修改。kube-apiserver可以通过该字段判断对象是否已经被修改。当包含resourceVersion的更新请求到达apiserver,服务器端将对比请求数据与服务器中数据的资源版本号,如果不一致,则表明在本次更新提交时,服务端对象已被修改,此时apiserver将返回冲突错误(409)。客户端需重新获取服务端数据,重新修改后再次提交到服务器端;而资源配额对每个命名空间的资源消耗总量提供限制,并且会记录集群中的资源信息,因此开启资源配额后,在大规模并发场景下创建资源冲突概率会变高,会影响批创资源性能。
操作步骤
步骤 1 登录CCE控制台,单击集群名称进入集群。
步骤 2 在左侧导航栏中选择“命名空间”。
步骤 3 单击对应命名空间后的“管理配额”。
系统级别的命名空间kube-system、kube-public默认不支持设置资源配额。
步骤 4 设置资源配额,然后单击“确定”。
注意
命名空间设置了CPU或内存资源配额后,创建工作负载时,必须指定CPU或内存的请求值(request)和约束值(limit),否则CCE将拒绝创建实例。若设置资源配额值为0,则不限制该资源的使用。
配额累计使用量包含CCE系统默认创建的资源,如default命名空间下系统默认创建的kubernetes服务(该服务可通过后端kubectl工具查看)等,故建议命名空间下的资源配额略大于实际期望值以去除系统默认创建资源的影响。