How to configure LimitRanger and deploy it in Kubernetes

In this article, we introduce what the LimitRanger admission controller is, how it is different from ResourceQuota, and how you can use it to manage resources in your Kubernetes cluster.

Kubernetes is an open-source container orchestration platform that allows you to deploy, manage, and scale containerized applications with ease. It automates the deployment, scaling, and management of containerized applications and services, providing a consistent and predictable environment for running them. 

Kubernetes can run on any infrastructure, whether it's on-premises or in the cloud, and can manage any type of containerized application, regardless of the container runtime or programming language used. 

At the heart of Kubernetes is a cluster, which is a group of nodes that run containerized applications. The cluster is managed by a Kubernetes control plane, which consists of several components that work together to provide the desired state of the cluster. 

One such component is the Kubernetes API Server, which serves as the primary interface for users and other components to interact with the Kubernetes cluster.  The API server provides authorization and authentication, object schema validation, and also implements admission controllers. 

For anyone interested in learning more about Kubernetes, a great place to start is this video course: Introduction to Kubernetes

Kubernetes admission controllers are a set of plugins that can be configured to run before or after a Kubernetes resource is created, modified, or deleted. They are responsible for intercepting requests to the Kubernetes API server and enforcing custom validation rules, policies, or default behaviors on the incoming resources. 

Admission controllers come in two types - mutating and validating. 

• Mutating Admission controllers are able to modify resources before they are persisted to the etcd database.
• Validating admission controllers are used to accept or reject a request based on a set of rules. 

Generally, admission controllers will either be mutating or validating, but, sometimes they can be both, which is the case for the LimitRanger admission controller. 

The LimitRanger admission controller is a built-in admission controller that enforces resource constraints on Kubernetes namespaces. It allows administrators to specify resource requests and limits for a namespace and limits the amount of compute resources that can be used by pods in that namespace. 

The LimitRanger admission controller can enforce constraints on CPU, memory, and ephemeral storage resources, as well as the number of pods and services that can be created in a namespace.  When a pod is created in a namespace, the LimitRanger admission controller verifies that the pod's resource requests and limits do not exceed the constraints defined in the namespace's LimitRange.  

Just in case there is any confusion, the Kubernetes object is called “LimitRange” and the admission controller is called “LimitRanger”. 

If you have any familiarity with Kubernetes admission controllers you may be wondering how LimitRanger is different from ResourceQuota. Both of the admission controllers are used to enforce resource constraints and quotas, but they differ in their scope and level of control. 

LimitRanger is used to limit the resources that can be used by pods in a specific namespace; whereas, ResourceQuota is used to limit the total amount of resources that can be consumed by all the pods in a namespace.

LimitRanger is a built-in admission controller, which means that it ships with Kubernetes and is enabled by default. As long as it is not being explicitly disabled, you will have access to use it. Run the following command to view enabled or disabled admission controllers (built-in controllers will not be listed):

Enabled and disabled admission controllers will appear in a comma delimited list beside the following options:

Once you’ve validated that the admission controller is enabled, the next step is to create a manifest file for the LimitRange object. Below is an example of what the file should look like:

In this example, we're creating a LimitRange object called "mem-cpu-limit-range". This object sets constraints on the CPU and memory resources that can be used by pods in the “my-namespace” namespace.

The limits field is an array that can contain multiple limit definitions. In this case, we have only one limit definition, which applies to all containers in the namespace (type: Container).

The max field specifies the maximum amount of CPU and memory resources that can be used by a container. In this example, we're setting a maximum limit of 0.5 CPU and 500Mi memory.

The min field specifies the minimum amount of CPU and memory resources that a container must request. In this example, we're setting a minimum request of 0.1 CPU and 50Mi memory.

Next you need to deploy the object by running the following command:

By creating and applying this LimitRange object to a namespace, we can ensure that pods running in that namespace do not consume more than the specified CPU and memory resources. If a pod attempts to exceed these limits, Kubernetes will reject the creation of the pod and display an error message.

I hope that I’ve been able to show you how useful the LimitRanger admission controller can be in helping manage resources in your Kubernetes cluster. This is just one of the many admission controllers that are working in the background to keep your Kubernetes system running smoothly and efficiently. 

If you would like to learn more about LimitRanger and admission controllers in general, please check out my course Hands-On with Kubernetes Admission Controllers at A Cloud Guru.