Creating a LimitRange

To set the resource limitation of each Namespace, the admission controller LimitRanger should be added in the Kubernetes API server. Do not worry about this setting if you have minikube or kubeadm as your system manager.

The admission controller in the Kubernetes API server
Admission controller is a setting in the Kubernetes API server which defines more advanced functionality in the API server. There are several functions that can be set in the admission controller. Users can add the functions when starting the API server through the configuration file or using CLI with the flag --admission-control. Relying on minikube or kubeadm for system management, they have their own initial settings in the admission controller:
  • Default admission controller in kubeadm: Initializers, NamespaceLifecycle, LimitRanger, ServiceAccount, PersistentVolumeLabel, DefaultStorageClass, DefaultTolerationSeconds, NodeRestriction, ResourceQuota
  • Default admission controller in minikube: NamespaceLifecycle, LimitRanger, ServiceAccount, DefaultStorageClass, ResourceQuota
Based on the version of your API server, there is a recommended list in an official document at https://kubernetes.io/docs/admin/admission-controllers/#is-there-a-recommended-set-of-admission-controllers-to-use. Check for more ideas!

A plain new Namespace has no limitation on the resource quota. At the beginning, we start a Namespace and take a look at its initial settings:

// create a Namespace by YAML file
$ kubectl create -f my-first-namespace.yaml
namespace "my-namespace" created

$ kubectl describe ns my-namespace
Name: my-namespace
Labels: <none>
Annotations: <none>
Status: Active

No resource quota.

No resource limits.

After that, we create a resource called LimitRange for specifying the resource limitation of a Namespace. The following is a good example of creating a limit in a Namespace:

$ cat my-first-limitrange.yaml
apiVersion: v1
kind: LimitRange
metadata:
name: my-limitrange
spec:
limits:
- type: Pod
max:
cpu: 2
memory: 1Gi
min:
cpu: 200m
memory: 6Mi
- type: Container
default:
cpu: 300m
memory: 200Mi
defaultRequest:
cpu: 200m
memory: 100Mi
max:
cpu: 2
memory: 1Gi
min:
cpu: 100m
memory: 3Mi

We will then limit the resources in a Pod with the values of 2 as max and 200m as a min for CPU, and 1Gi as max and 6Mi as a min for memory. For the container, the CPU is limited between 100m - 2 and the memory is between 3Mi - 1Gi. If the max is set, then you have to specify the limit in the Pod/container spec during the resource creation; if the min is set, then the request has to be specified during the Pod/container creation. The default and defaultRequest section in LimitRange is used to specify the default limit and request in the container spec.

The value of CPU limitation in LimitRange
What do the values of 2 and 200m mean in the Pod limitation in the file my-first-limitrange.yaml? The integer value means the number of CPU; the "m" in the value means millicpu, so 200m means 0.2 CPU (200 * 0.001). Similarly, the default CPU limitation of the container is 0.2 to 0.3, and the real limitation is 0.1 to 2.

Afterwards, we create the LimitRange in our plain Namespace and check what will happen:

// create the limitrange by file with the flag of Namespace
// the flag --namespace can be abbreviated to "n"
$ kubectl create -f my-first-limitrange.yaml -n my-namespace
limitrange "my-limitrange" created

// check the resource by subcommand "get"
$ kubectl get limitrange -n my-namespace
NAME AGE
my-limitrange 23s

// check the customized Namespace
$ kubectl describe ns my-namespace
Name: my-namespace
Labels: <none>
Annotations: <none>
Status: Active

No resource quota.

Resource Limits
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
---- -------- --- --- --------------- ------------- -----------------------
Pod cpu 200m 2 - - -
Pod memory 6Mi 1Gi - - -
Container memory 3Mi 1Gi 100Mi 200Mi -
Container cpu 100m 2 200m 300m -

When you query the detail description of my-namespace, you will see the constraint attached to the Namespace directly. There is not any requirement to add the LimitRange. Now, all the Pods and containers created in this Namespace have to follow the resource limits listed here. If the definitions violate the rule, a validation error will be thrown accordingly:

// Try to request an overcommitted Pod, check the error message
$ kubectl run my-greedy-nginx --image=nginx --namespace=my-namespace --restart=Never --requests="cpu=4"
The Pod "my-greedy-nginx" is invalid: spec.containers[0].resources.requests: Invalid value: "4": must be less than or equal to cpu limit
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.17.76.175