Defining Resource Defaults and Limitations within a Namespace

Why we need resource defaults and limitations?#

We already learned how to leverage Kubernetes Namespaces to create clusters within a cluster. When combined with RBAC, we can create Namespaces and give users permissions to use them without exposing the whole cluster. Still, one thing is missing.

We can, let’s say, create a test Namespace and allow users to create objects without permitting them to access other Namespaces. Even though that is better than allowing everyone full access to the cluster, such a strategy would not prevent people from bringing the whole cluster down or affecting the performance of applications running in other Namespaces. The piece of the puzzle we’re missing is resource control on the Namespace level.

We already discussed that every container should have resource limits and requests defined. That information helps Kubernetes schedule Pods more efficiently. It also provides it with the information it can use to decide whether a Pod should be evicted or restarted.

Still, the fact that we can specify resources does not mean that we are forced to define them. We should have the ability to set default resources that will be applied when we forget to specify them explicitly.

Even if we define default resources, we also need a way to set limits. Otherwise, everyone with permissions to deploy a Pod can potentially run an application that requests more resources than we’re willing to give.

Defining default requests and limits#

Our next task is to define default requests and limits as well as to specify minimum and maximum values someone can define for a Pod.

Creating a namespace#

We’ll start by creating a test Namespace.

Looking into the definition#

With a playground Namespace created, we can take a look at a new definition limit-range.yml.

We specified that the resource should be of LimitRange kind. It’s spec has four limits.

default and defaultRequest#

The default limit and defaultRequest entries will be applied to the containers that do not specify resources. If a container does not have memory or CPU limits, it’ll be assigned the values set in the LimitRange. The default entries are used as limits, and the defaultRequest entries are used as requests.

min and max#

When a container does have the resources defined, they will be evaluated against LimitRange thresholds specified as max and min. If a container does not meet the criteria, the Pod that hosts the containers will not be created.

Creating the resource#

We’ll see a practical implementation of the four limits soon. For now, the next step is to create the limit-range resource.

We created the LimitRange resource.

Looking into the description#

Let’s describe the test Namespace where the resource was created.

The output, limited to the relevant parts, is as follows.

We can see that the test Namespace has the resource limits we specified. We set four out of five possible values.

The maxLimitRequestRatio is missing and we’ll describe it only briefly. When MaxLimitRequestRatio is set, container request and limit resources must both be non-zero, and the limit divided by the request must be less than or equal to the enumerated value.

Looking into updated definition#

Let’s take a look at yet another variation of the go-demo definition go-demo-2-no-res.yml.

The only thing to note is that none of the containers have any resources defined.

Creating resources#

Next, we’ll create the objects defined in the go-demo-2-no-res.yml file.

We created the objects inside the test Namespace and waited until the deployment "go-demo-2-api" was successfully rolled out.

Looking into the description#

Let’s describe one of the Pods we created.

The output, limited to the relevant parts, is as follows.

Even though we did not specify the resources of the db container inside the go-demo-2-db Pod, the resources are set. The db container was assigned the default limits of the test Namespace as the container limit. Similarly, the defaultRequest limits were used as container requests.

As we can see, any attempt to create Pods hosting containers without resources will result in the Namespace limits applied.

We should still define container resources instead of relying on Namespace default limits. They are, after all, only a fallback in case someone forgot to define resources.

Try it yourself#

A list of all the commands used in the lesson is given below.