Namespaces and Environments

Introduction: The Multi-Environment Challenge

Imagine you're working on a team that builds web applications. Your team develops new features, tests them, and eventually releases them to customers. Now, picture this scenario: a developer accidentally deploys an untested version of the application to production, causing an outage for thousands of users. This happens more often than you'd think, and it's exactly the kind of problem that Kubernetes namespaces help prevent. Organizations typically run multiple versions of their applications simultaneously — one for developers to experiment with (dev), one for testing (staging), and one that serves real customers (prod). Without a way to logically separate these environments, it's easy to mix them up. In this lesson, you'll learn how to use Kubernetes namespaces to create isolated environments within a single cluster, providing organizational clarity and a foundation for access control policies.

Understanding Kubernetes Namespaces

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Creating Namespaces

Creating a namespace in Kubernetes is straightforward. Like most Kubernetes resources, namespaces are defined using YAML files. Let's start by creating a namespace for our development environment. Here's what the YAML file looks like:

YAML

apiVersion: v1
kind: Namespace
metadata:
  name: dev

apiVersion: v1
kind: Namespace
metadata:
  name: dev

This file is remarkably simple compared to other Kubernetes resources. The apiVersion field tells Kubernetes which version of the API to use for this resource. For namespaces, it's just v1. The kind field specifies that we're creating a Namespace resource. The metadata section contains information about the namespace itself, and the most important field here is name, which defines what we'll call this namespace. In this case, we're calling it dev for development.

Let's save this file as namespace-dev.yaml and create a similar one for production:

YAML

apiVersion: v1
kind: Namespace
metadata:
  name: prod

apiVersion: v1
kind: Namespace
metadata:
  name: prod

Save this second file as namespace-prod.yaml. Now, you have two namespace definitions ready to deploy. To actually create these namespaces in your Kubernetes cluster, you use the kubectl apply command:

Shell

kubectl apply -f namespace-dev.yaml

kubectl apply -f namespace-dev.yaml

When you run this command, you should see output like:

text

namespace/dev created

namespace/dev created

Now, create the production namespace:

Shell

kubectl apply -f namespace-prod.yaml

kubectl apply -f namespace-prod.yaml

You'll see similar output:

text

namespace/prod created

namespace/prod created

To verify that both namespaces were created successfully, you can list all namespaces in your cluster:

Shell

kubectl get namespaces

kubectl get namespaces

The output will show all namespaces, including the ones you just created:

text

NAME              STATUS   AGE
default           Active   10d
dev               Active   30s
kube-node-lease   Active   10d
kube-public       Active   10d
kube-system       Active   10d
prod              Active   20s

NAME              STATUS   AGE
default           Active   10d
dev               Active   30s
kube-node-lease   Active   10d
kube-public       Active   10d
kube-system       Active   10d
prod              Active   20s

Notice that your new dev and prod namespaces appear alongside the default Kubernetes namespaces. The STATUS column shows "Active," which means they're ready to use. The AGE column shows how long ago each namespace was created.

Deleting Namespaces

Sometimes you need to clean up and remove a namespace you no longer need. Kubernetes makes this straightforward, but it's important to understand what happens when you delete a namespace. When you delete a namespace, all resources inside that namespace are automatically deleted — this includes deployments, pods, services, config maps, secrets, and everything else. This cascading deletion is a powerful cleanup mechanism, but it also means you need to be careful.

To delete a namespace, use the kubectl delete namespace command. For example, if you wanted to delete the dev namespace we created earlier:

Shell

kubectl delete namespace dev

kubectl delete namespace dev

You would see output like:

text

namespace "dev" deleted

namespace "dev" deleted

Behind the scenes, Kubernetes first marks the namespace for deletion, then systematically removes all resources within it, and finally removes the namespace itself. This process can take a few moments, especially if the namespace contains many resources. You can watch the deletion progress by trying to list resources in that namespace — they'll gradually disappear until the namespace itself is gone.

Warning: Be extremely careful when deleting namespaces, especially in shared or production environments. There's no confirmation prompt, and once you execute the command, all resources in that namespace will be deleted. This is why many organizations implement RBAC policies that restrict who can delete namespaces, particularly for critical environments like production.

If you accidentally set a namespace as your default and then delete it, kubectl will start returning errors when you run commands. You can fix this by setting a different namespace as your default, such as returning to the default namespace:

Shell

kubectl config set-context --current --namespace=default

kubectl config set-context --current --namespace=default

In practice environments like CodeSignal, deleting namespaces is safe and often useful for starting fresh or cleaning up after experiments.

Deploying Applications to Specific Namespaces

Now that we have our namespaces set up, let's deploy an application to one of them. The key to deploying resources into a specific namespace is adding the namespace field to the resource's metadata. Here's a deployment configuration for a simple web application using nginx:

YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  namespace: dev
spec:
  replicas: 2

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  namespace: dev
spec:
  replicas: 2

The crucial line here is namespace: dev in the metadata section. This tells Kubernetes to create this deployment in the dev namespace rather than the default namespace. Without this line, the deployment would go into whichever namespace is currently set as your default (usually the default namespace).

Let's look at the rest of the deployment configuration:

YAML

  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: nginx
          image: nginx:1.25
          ports:
            - containerPort: 80

  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: nginx
          image: nginx:1.25
          ports:
            - containerPort: 80

The replicas field specifies that we want two copies of our application running. The selector tells the deployment which pods it should manage (those with the label app: web-app). The template section defines what each pod should look like — in this case, a single container running nginx version 1.25, listening on port 80. This is a standard web server that will serve a default welcome page.

Save this complete configuration as deployment.yaml and apply it:

Shell

kubectl apply -f deployment.yaml

kubectl apply -f deployment.yaml

You should see:

text

deployment.apps/web-app created

deployment.apps/web-app created

Here's the important concept: because we specified namespace: dev in the deployment configuration, this deployment and its pods only exist in the dev namespace. If you wanted the same application running in production, you could create a copy of this file, change namespace: dev to namespace: prod, and apply it. The two deployments would be completely separate — scaling or deleting one wouldn't affect the other.

Viewing Resources Across Namespaces

Now comes the interesting part: observing how namespace isolation actually works. When you want to view resources in a specific namespace, you need to use the -n flag (short for --namespace) with kubectl commands. Let's check which deployments exist in our dev namespace:

Shell

kubectl get deployments -n dev

kubectl get deployments -n dev

You'll see output like:

text

NAME      READY   UP-TO-DATE   AVAILABLE   AGE
web-app   2/2     2            2           1m

NAME      READY   UP-TO-DATE   AVAILABLE   AGE
web-app   2/2     2            2           1m

This shows our web-app deployment with 2 out of 2 replicas ready. Now, let's check the prod namespace:

Shell

kubectl get deployments -n prod

kubectl get deployments -n prod

The output will be:

text

No resources found in prod namespace.

No resources found in prod namespace.

This demonstrates namespace isolation in action. Even though we created a deployment, it only exists in the dev namespace. The prod namespace is empty because we haven't deployed anything there yet. This isolation is exactly what prevents accidental changes to the wrong environment — you must explicitly specify which namespace you're working with.

Let's look at the actual pods running in the dev namespace:

Shell

kubectl get pods -n dev

kubectl get pods -n dev

You'll see something like:

text

NAME                       READY   STATUS    RESTARTS   AGE
web-app-7d4b6c9f8d-k7m2x   1/1     Running   0          2m
web-app-7d4b6c9f8d-p9n4k   1/1     Running   0          2m

NAME                       READY   STATUS    RESTARTS   AGE
web-app-7d4b6c9f8d-k7m2x   1/1     Running   0          2m
web-app-7d4b6c9f8d-p9n4k   1/1     Running   0          2m

There are two pods because we specified replicas: 2 in our deployment. Each pod has a unique name generated by Kubernetes, consisting of the deployment name plus a random suffix. If you try to view pods in the prod namespace:

Shell

kubectl get pods -n prod

kubectl get pods -n prod

You'll get:

text

No resources found in prod namespace.

No resources found in prod namespace.

This reinforces the concept that namespaces provide complete logical separation of resources. Your deployments, pods, services, and other resources in one namespace are invisible when you're looking at another namespace.

Introduction: The Multi-Environment Challenge

Understanding Kubernetes Namespaces

Join the 1M+ learners on CodeSignal

Creating Namespaces

Deleting Namespaces

Deploying Applications to Specific Namespaces

Viewing Resources Across Namespaces

Setting Your Default Namespace

Summary and Practice Preparation