Namespaces and Quotas

Introduction

A Kubernetes cluster is like a Large Apartment Building.

If everyone lived in the lobby, it would be chaotic. You wouldn't know whose furniture is whose, and one loud neighbor could disturb everyone.

Namespaces partition a cluster logically so different teams, environments, or applications can organize resources separately.

ResourceQuotas restrict how much of certain resources a namespace may consume. This helps prevent one team or workload from exhausting shared cluster capacity.

In this lab, you will:

• Build a new "apartment" (Namespace) called dev.
• Set a strict "electricity limit" (ResourceQuota) for that apartment.
• Try to move furniture (Pods) into the apartment and see if it fits.

Create a Namespace

In this step, you will create a new namespace to isolate resources for a development team.

A namespace is a logical boundary inside one cluster, not a separate cluster. Teams still share the same control plane and underlying nodes, but names, policies, and many resource views can be separated so that work stays organized.

By default, everything goes into the default namespace (the lobby). Let's see what namespaces currently exist:

kubectl get namespaces

You should see default, kube-system (where the building managers live), and a few others.

Now, let's build the dev apartment:

kubectl create namespace dev

Verify it exists:

kubectl get namespaces

You will see dev in the list. It's currently an empty apartment with no walls or limits—you can put anything inside it.

Apply Resource Limits

Now we need to set the rules. We don't want the dev team to use up the entire cluster's CPU and Memory.

We will create a ResourceQuota object. This helps us say: "In the dev namespace, you can use at most 2 CPUs and 2Gi of Memory."

Quotas are especially important in shared clusters because CPU and memory are finite. Without quotas, one noisy workload can consume more than its fair share and make the cluster unreliable for everyone else. In that sense, quotas are not only about accounting. They are also a stability tool.

Create a file named quota.yaml:

nano quota.yaml

Paste the following configuration:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-quota
  namespace: dev
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi

Save and exit (Ctrl+X, Y, Enter).

Apply this rule to the cluster:

kubectl apply -f quota.yaml

You can view the rule details. It will show you the "Hard" limit (what you set) and the "Used" amount (currently 0).

kubectl describe resourcequota dev-quota --namespace=dev

Deploy a Pod

Now that the rules are set, let's try to move in.

Critical Rule: When an apartment has a limit, every piece of furniture you bring in must have its size declared. In Kubernetes terms: if a Namespace has a Quota, every Pod must specify explicit resources (requests and limits). If you don't, the building manager (Kubernetes) will block you at the door.

This is where two related ideas meet. A request tells the scheduler how much resource the Pod should be guaranteed when it is placed. A limit is the maximum amount the container is allowed to use. Quotas add up those requests and limits across a namespace to keep the total within policy.

Create a file named pod.yaml:

nano pod.yaml

Paste the following. Notice we explicitly state the size of this pod:

apiVersion: v1
kind: Pod
metadata:
  name: dev-pod
  namespace: dev ## <-- Putting it in the 'dev' apartment
spec:
  containers:
    - name: nginx
      image: nginx
      resources:
        requests:
          memory: "128Mi"
          cpu: "250m"
        limits:
          memory: "256Mi"
          cpu: "500m"

Save and exit (Ctrl+X, Y, Enter).

Deploy the Pod:

kubectl apply -f pod.yaml

Check if it is running inside the dev namespace:

kubectl get pods --namespace=dev

Wait until you see Running.

Now, check the Quota usage again. You will see the "Used" column has increased!

kubectl describe resourcequota dev-quota --namespace=dev

You are successfully tracking your resource usage against your budget.

Verify Isolation

Finally, let's verify that our "Apartment" walls are real.

Namespace isolation is mostly about names, policies, and scope of operations. It does not mean the workloads are running on physically separate hardware by default. That distinction matters later when you learn node selection and stronger isolation mechanisms.

We put dev-pod inside dev. It should not be visible from the lobby (default).

List the pods in the default namespace:

kubectl get pods

You should see "No resources found in default namespace" (or at least, not dev-pod).

Now, check for the Quota in the default namespace:

kubectl get resourcequota

You should see nothing. The electricity limit we set applies only to the dev apartment, not the whole building.

This confirms that Namespaces provide true isolation for your teams.

Summary

In this lab, you became a Building Manager for your Kubernetes cluster.

You successfully:

1. Built a private Namespace (dev) for a team.
2. Set a strict ResourceQuota (Electricity Limit) to prevent over-consumption.
3. Deployed an application that respected these limits.
4. Verified that the walls between namespaces kept things isolated.

This is how large organizations share a single Kubernetes cluster among hundreds of teams without them stepping on each other's toes.