Defining Resource Defaults and Limitations within a Namespace

Why we need resource defaults and limitations?

We have 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.

Let’s say we 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 missing piece of the puzzle 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 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 and to specify minimum and maximum values someone can define for a Pod.

Creating a namespace

We’ll start by creating a test Namespace.