Resource Quotas are defined through the ResourceQuota object, which provides an overall resource limit for each namespace: it can limit the total number of objects of a certain type in the namespace, or it can set the total limit of computational resources that can be used by Pods in the namespace.
When using resource quotas, there are two things to keep in mind.
- If the total available resources in the cluster are less than the sum of the resource quotas in each namespace, then this may lead to resource contention. In the event of resource contention, the Kubernetes system will follow the first-come, first-served principle.
- Neither resource contention nor quota modification affects resource usage objects that have already been created.
1. Enabling Resource Quota Selection in Master
Resource quotas can be enabled by adding the
-ResourceQuota parameter to the value of the
-admission-control parameter of kube-apiserver. If ResourceQuota is present in the definition of a namespace, then it is enabled by default for that namespace. A namespace can have multiple ResourceQuota configuration items. (When restarting the service, it will prompt: -admission-control has been deprecated, Use –enable-admission-plugins or –disable-admission-plugins instead. Use –enable-admission-plugins or –disable-admission-plugins instead. (Will be removed in a future version.) Just replace
1 Compute Resource Quota (CRQ)
A resource quota can limit the sum of compute resources for all Pods in a namespace.
ResourceQuota currently supports the following types of idle compute resources.
|cpu||The sum of CPU Requests for all non-terminated Pods cannot exceed this value|
|requests.cpu||The sum of CPU Requests for all non-terminated Pods cannot exceed this value|
|limits.cpu||The sum of all non-terminated Pods, CPU Limits cannot exceed this value|
|memory||The sum of all non-terminating Pods, memory Requests cannot exceed this value|
|requests.memory||The sum of all non-terminating Pods, memory Requests cannot exceed this value|
|limits.memory||The sum of the memory Limits of all Pods that are not terminated cannot exceed this value|
2. Storage Resources Quota (Volume Count Quota)
You can limit the total amount of storage resources used in a given namespace.
|requests.storage||For all PVCs, the total demand for storage resources cannot exceed this value|
|persistentvolumeclaims||The total amount of PVC allowed in the namespace|
||The total amount of storage requested for all PVCs associated with
||The total number of all PVCs associated with
|ephemeral-storage、requests.ephemeral-storage、limits.ephemeral-storage||The total amount of local temporary storage (ephemeral-storage) is limited.|
3. Object Count Quota (OQQ)
The number of objects of a given type can be limited, for example, by a resource quota to limit the maximum number of Pods created in the namespace. This configuration prevents some users from creating a large number of Pods and rapidly exhausting the Pod IP and compute resources of the entire cluster. The following table lists the types of objects that ResourceQuota supports limiting.
|configmaps||The maximum number of ConfigMap allowed to exist in this namespace.|
|pods||The terminated status of a Pod is equivalent to the Pod’s status.phase in (Failed, Successded) = true|
|replicationcontrollers||The upper limit of the total number of RCs that can exist in the namespace.|
|resourcequotas||An upper limit on the total number of resource quotas that can exist in this namespace.|
|services||The maximum number of services that can exist in the namespace.|
|services.loadbalancers||The maximum number of services of type LoadBalancer that can exist in this namespace.|
|services.nodeports||The maximum number of services of type NodePort that can exist in this namespace。|
|secrets||The maximum number of Secret that can exist in the namespace.|
This is expressed as follows.
count/<resource>. <group>: Resources for non-core (core) compositions, e.g.
count/resource: resources for core groups, e.g.
2. Scopes for Quotas (Quota Scopes)
A separate set of scopes can be configured for each resource quota. Resource quotas with scopes configured will only measure and limit the usage of resources that match their scopes, and requests with scopes beyond the resource quota will be reported with validation errors. The following table lists the four scopes of ResourceQuota.
|Terminating||Match all Pods with spec.activeDeadlineSeconds less than 0|
|NotTerminating||Match all Pods whose spec.activeDeadlineSeconds is nil|
|BestEffort||Match all Pods whose Qos are BestEffort|
|NotBestEffort||Match all Pods whose Qos are not BestEffort|
|PriorityClass||Matches all Pods that reference the specified priority class|
- BestEffort scope can limit the resource quota to track Pod resource usage.
- And Terminating, NotTerminating, NotBestEffort, PriorityClass can track CPU, Limits.cpu, Limits.memory, memory, requests.cpu, requests. memory and other resources usage.
3. Setting Requests and Limits in ResourceQuota
Requests and Limits can also be set in ResourceQuota, if requests.cpu or limits.cpu is specified in ResourceQuota, then it forces each container to configure its own CPU Requests or CPU Limits (you can use the default values provided by LimitRange). Similarly, if requests.memory or limits.memory is specified in the resource quota, then it forces each container to configure its own memory Requests or memory Limits (you can use the default provided by LimitRange).
4. Definition of Resource Quota
Resource quotas are set and applied by example.
Similar to LimitRange, ResourceQuota is set in a namespace.
Create a namespace named myspace.
Create the ResourceQuota configuration file compute-resource.yaml.
Create a resource quota for the item.
Create another file called object-counts.yaml to set the quota for the number of objects.
Create this ResourceQuota.
View the details of each ResourceQuota.
5. Relationship between resource quotas and total cluster resources
Resource quotas are completely independent from the total number of cluster resources. Resource quotas are configured by absolute units, which means that if a new node is added to the cluster, the resource quota is not automatically updated, and the objects in the namespace corresponding to that resource quota cannot automatically increase the resource limit.