The book learned in the previous section limits the resources of individual pods, using LimitRange. If we need to limit the total amount of resources available in the namespace, we can't satisfy it. We need to create a ResourceQuota object to achieve it.
1. ResourceQuota resource
The ResourceQuota control plugin can check whether the newly added pod will cause the total resources to exceed the ResourceQuota, similar to the LimitRange and LimitRange plugins. Only for newly created pods and does not affect existing pods.
Resource quotas limit the total amount of resources that can be used by pods and PVC storage in a namespace. At the same time, you can also limit the number of pods, PVCs, and other API objects that users are allowed to create in this namespace. The most processed resources are CPU and memory.
Create ResourceQuota for cpu and memory
yaml file: quota-cpu-memory.yaml
apiVersion：v1
kind:ResourceQuota
metaData:
name:cpu-and0mem
spec:
hard:
requests.cpu:400m
requests.memory:200Mi
limits.cpu:600m
limits.memory:500Mi
As above, the total amount of requests and limits is defined for cpu and memory, instead of simply defining a total amount for each resource. Compared with LimitRange, the structure is different. The requests and limits of all resources are defined under one field.
Like limitRange, the ResourceQuota object is applied to the namespace he created, but the difference is that ResourceQuota can limit the total amount of resource requests and limits of all pods, not each individual pod and container.
View quota and quota usage
kubectl describe quota
Create LimitRange at the same time as ResourceQuota
Note: Creating a ResourceQuota also requires creating a LimitRange object. If not, it cannot be created successfully, because he has not pinned any resource requests and limits.
2. Specify a quota for persistent storage
ResourceQuota exclusive can limit the maximum amount of persistent storage that can be declared in a namespace.
yaml document: quota-storage.yaml
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
3. Limit the number of objects that can be created
ResourceQuota can limit the number of pods, ReplicationControllers, Services, and other objects in a namespace. Chicken flock administrators can limit the number of objects that users can create based on, for example, payment plans, and can also be used to limit the number of node ports that can be used by public network IP or Service.
yaml文件：quota-object-count.yaml
apiVersion:v1
kind:ResourceQuota
metadata:
name:objects
spec:
hard:
pods:10
replicationcontrollers:5
secrets:10
configmaps:10
persistentvolumeclaims:4
services:5
services.loadbalances:1
services.nodeports:2
ssd.storageclass.storage.k8s.io/persistentvolumeclains:2
The object number quota can currently limit the object configuration:
pod
ReplicationController
Secret
ConfigMap
Persistent Volume Claim
Service (general), and two specific types of Service, such as LoadBalancer Service (service.loadbalances) and NodePort Service (services.nodeports)
At present, the limitations of ReplicaSet, Job, Deployment, Ingress, etc. still need to read the latest documents
4. Specify quotas for specific pod states or Qos levels
The created Quota is applied to all pods regardless of the pod's current state and QoS level.
But Quota can be limited by a set of quota scopes. There are currently 4 types of quota scopes:
BestEffort、NotBestEffort、Termination和NotTerminating
The BestEffort and NotBestEffort ranges determine whether the quota is applied to pods of the BestEffort Qos level or both levels (Burstable and Guaranteed)
The two ranges of Terminating and NotTerminating describe:
For each pod, it is marked as Failed and how long it can run before it is actually stopped. This is achieved through the activeDeadlineSeconds configured in the pod spec. This property defines the number of seconds a pod is allowed to continue running on a node from the time it starts trying to stop until it is marked as Failed and then actually stopped. The Terminating quota applies to pods configured with activeDeadlineSeconds. And NotTerminating applies to pods that do not specify this configuration.
illustrate:
When creating a ResourceQuota, you can specify a scope for it, and the target pod must match all the scopes configured by the quota. In addition, the quota range also determines the content that can be limited by the quota: the BestEffort range only allows to limit the number of pods, while the other three ranges can limit the requests and limits of CPU/memory in addition to the number of pods.