Kubernetes Namespaces, Resource Quota, and Limits for QoS in Cluster

By default, all resources in Kubernetes cluster are created in a default namespace. A pod will run with unbounded CPU and memory requests/limits. A Kubernetes namespace allows to partition created resources into a logically named group. Each namespace provides:

• a unique scope for resources to avoid name collisions
• policiesto ensure appropriate authority to trusted users
• ability to specify constraints for resource consumption

This allows a Kubernetes cluster to share resources by multiple groups and provide different levels of QoS each group. Resources created in one namespace are hidden from other namespaces. Multiple namespaces can be created, each potentially with different constraints.

Default Kubernetes Namespace

By default, each resource created by user in Kubernetes cluster runs in a default namespace, called default.

Any pod, service or replication controller will be created in this namespace. kube-system namespace is reserved for resources created by the Kubernetes cluster. More details about the namespace can be seen:

This description shows resource quota (if present), as well as resource limit ranges. So let’s create a Couchbase replication controller as:

Check the existing replication controller:

By default, only resources in user namespace are shown. Resources in all namespaces can be shown using --all-namespaces option:

As you can see, the arungupta/couchbase image runs in the default namespace. All other resources run in the kube-system namespace. Lets check the context of this replication controller:

Look for contexts.context.name attribute to see the existing context. This will be manipulated later.

Create a Resource in New Kubernetes Namespace

Lets create a new namespace first. This can be done using the following configuration file:

Namespace is created as:

Then querying for all the namespaces gives:

A new replication controller can be created in this new namespace by using --namespace option:

List of resources in all namespaces looks like:

As seen, there are two replication controllers with arungupta/couchbase image – one in default namespace and another in development namespace.

Set Kubernetes Namespace For an Existing Resource

If a resource is already created then it can be assigned a namespace. On a previously created resource, new context can be set in the namespace:

Viewing the context now shows:

The second attribute in contexts.context array shows that a new context has been created. It also shows that the current context is still couchbase-on-kubernetes_kubernetes. Since no namespace is specified in that context, it belongs to the default namespace. Change the context:

See the list of replication controllers:

Obviously, no replication controllers are running in this context. Lets create a new replication controller in this new namespace:

And see the list of replication controllers in all namespaces:

Now you can see two arungupta/couchbase replication controllers running in two difference namespaces.

Delete a Kubernetes Resource in Namespace

A resource can be deleted by fully-qualifying the resource name:

Similarly the other replication controller can be deleted as:

Finally, see the list of all replication controllers in all namespaces:

This confirms that all user created replication controllers are deleted.

Resource Quota and Limit using Kubernetes Namespace

Each namespace can be assigned resource quota. By default, a pod will run with unbounded CPU and memory requests/limits. Specifying quota allows to restrict how much of cluster resources can be consumed across all pods in a namespace. Resource quota can be specified using a configuration file:

The following resources are supported by the quota system:

This resource quota can be created in a namespace:

The created quota can be seen as:

Now, if you try to create the replication controller that works:

But describing the quota again shows:

We expected a new pod to be created as part of this replication controller but it’s not there. So lets describe our replication controller:

By default, pod consumes all the cpu and memory available. With resource quotas applied, an explicit value must be specified. Alternatively a default value for the pod can be specified using the following configuration file:

This restricts the CPU and memory that can be consumed by a pod. Lets apply these limits as:

Now when you describe the replication controller again, it shows:

This shows successful creation of the pod. And now when you describe the quota, it shows correct values as well:

Resource Quota provide more details about how to set/update these values. Creating another quota gives the following error:

Specifying Limits During Pod Creation

Limits can be specified during pod creation as well: If memory limit for each pod is restricted to 1g, then a valid pod definition would be:

This is because the pod request 0.5G of memory only. And an invalid pod definition would be:

This is because the pod requests 2G of memory. Creating such a pod gives the following error:

Hope you can apply namespaces, resource quotas, and limits for sharing your clusters across different environments.