命名空间资源限制
当多个用户或多个团队共用一个 CCE 集群时，需要为每个用户或团队所在的租户设置资源限制以防止某个用户或团队占用集群过多资源。集群管理员可以通过 Resource Quota 及 LimitRange 为每个租户设置资源限额：
- 通过 Resource Quotas 限制 Namespace 下总的资源数；
- 通过 Limit Range 限制单个 Pod 或 Container 的资源范围.
Resource Quota支持限制的资源
- 计算资源限制
| 资源名称 | 描述 |
|---|---|
| cpu | 本命名空间下，所有不处于 terminal 状态的 pod 资源的 CPU requests 总和不能超过该值 |
| limits.cpu | 本命名空间下，所有不处于 terminal 状态的 pod 资源的 CPU limits 总和不能超过该值 |
| limits.memory | 本命名空间下，所有不处于 terminal 状态的 pod 资源的 memory limits 总和不能超过该值 |
| memory | 本命名空间下，所有不处于 terminal 状态的 pod 资源的 memory requests 总和不能超过该值 |
| requests.cpu | 本命名空间下，所有不处于 terminal 状态的 pod 资源的 CPU requests 总和不能超过该值 |
| requests.memory | 本命名空间下，所有不处于 terminal 状态的 pod 资源的 memory requests 总和不能超过该值 |
- 存储资源限制
| 资源名称 | 描述 |
|---|---|
| requests.storage | 本命名空间下，所有的 persistent volume claims 的 storage requests 总和不能超过该值 |
| persistentvolumeclaims | 本命名空间下存在的 persistent volume claims 的总数不能超过该值 |
| requests.ephemeral-storage | 本命名空间下所有 pod 的本地临时存储的 storage requests 总和不能超过该值 |
| limits.ephemeral-storage | 本命名空间下所有 pod 的本地临时存储的 storage limits 总和不能超过该值 |
- API 资源数量限制
| 资源名称 | 描述 |
|---|---|
| configmaps | 本命名空间下能创建的 configmap 的数量 |
| secrets | 本命名空间下能创建的 secrets 的数量 |
| persistentvolumeclaims | 本命名空间下能创建的 persistent volume claims 的数量 |
| services | 本命名空间下能创建的 services 数量 |
| services.loadbalancers | 本命名空间下能创建的 load balancer 类型的 service 的数量 |
| services.nodeports | 本命名空间下能创建的 node port 类型的 service 的数量 |
| pods | 本命名空间下能存在的不处于 terminal 状态的 pod 数量 |
| deployments.apps | 本命名空间下能创建的 deployment 的数量 |
| statefulsets.apps | 本命名空间下能创建的 statefulset 的数量 |
| jobs.batch | 本命名空间下能创建的 job 的数量 |
| cronjobs.batch | 本命名空间下能创建的 cronjob 的数量 |
示例一：限制 Namespace Pod 个数
本示例演示使用 ResourceQuota 限制命名空间中 PersistentVolumeClaim 的创建数量。
（1）创建示例命名空间
kubectl create namespace quota-example
（2）创建 ResourceQuota
将以下 yaml 保存为 quota-demo.yaml，并创建 ResourceQuota kubectl create -f quota-demo.yaml：
apiVersion: v1
kind: ResourceQuota
metadata:
name: default-resource-quota
namespace: quota-example
spec:
hard:
pods: "4" ## 最多 4 个 Pod
configmaps: "10" ## 最多 10 个 ConfigMap
secrets: "10" ## 最多 10 个 secret
services: "10" ## 最多 10 个 service
services.loadbalancers: "2" ## 最多 2 个 Loadbanlacer 模式的 service
cpu: "1000" ## 该 Namespaces 下最多使用 1000 个 CPU 的资源
memory: 200Gi ## 该 Namespaces 下最多使用 200Gi 的内存
（3）验证 ResourceQuota
使用以下 YAML 创建 5 个 Pod，但最终只会创建 4 个 Pod 出来：
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-example
namespace: quota-example
labels:
app: nginx
spec:
replicas: 5
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
restartPolicy: Always
containers:
- name: nginx
image: hub.baidubce.com/cce/nginx-alpine-go:latest
imagePullPolicy: Always
resources:
limits:
cpu: 100m
memory: 128Mi
requests:
cpu: 100m
memory: 128Mi
最多只会创建 4 个 Pod：
$kubectl get deployment -n quota-example
NAME READY UP-TO-DATE AVAILABLE AGE
deployment-example 4/5 4 4 59s
示例二：使用 LimitRange 为 Container 设置默认 Resource
（1）创建 LimitRange YAML，声明 Container 内存的默认限制量和默认请求量：
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
namespace: quota-example
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256Mi
type: Container
创建 Pod 如果没有声明 memory，会默认设置上该值：
spec:
resources:
limits:
memory: 512Mi
requests:
memory: 256Mi
更多内容可以参考：通过 LimitRange 限制范围
示例三：使用 LimitRange 为 Container 限制 Limits/Requests 的比例
如果指定了 LimitRange 对象的 spec.limits.maxLimitRequestRatio 字段，名称空间中的 Pod/容器的 request 和 limit 都不能为 0，且 limit 除以 request 的结果必须小于或等于 LimitRange 的 spec.limits.maxLimitRequestRatio。
（1）创建 LimitRange YAML，声明名称空间中限制 Limits/Requests 的比例：
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
namespace: quota-example
spec:
limits:
- maxLimitRequestRatio:
memory: 2
type: Container
(2) 使用以下 YAML 创建 Deployment, 会发现 Pod 的最大内存限定（limit）超过最小内存请求（request）的两倍而无法创建 Pod ：
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-example
namespace: quota-example
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
restartPolicy: Always
containers:
- name: nginx
image: hub.baidubce.com/cce/nginx-alpine-go:latest
imagePullPolicy: Always
resources:
limits:
cpu: 100m
memory: 1280Mi
requests:
cpu: 100m
memory: 128Mi
