Namespaces and Environments

Namespaces and Environments | CodeSignal Learn

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 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 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 When you run this command, you should see output like: text namespace/dev created Now, create the production namespace: Shell kubectl apply -f namespace-prod.yaml You'll see similar output: text namespace/prod created To verify that both namespaces were created successfully, you can list all namespaces in your cluster: Shell 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 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 You would see output like: text 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 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 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 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 You should see: text 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 You'll see output like: text 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 The output will be: text 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 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 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 You'll get: text 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.

Setting Your Default Namespace

Typing -n dev or -n prod every time you run a kubectl command can get tedious, especially when you're working primarily in one namespace. Kubernetes allows you to set a default namespace for your current context, which means kubectl will use that namespace automatically unless you explicitly specify a different one. Here's how to set the dev namespace as your default: Shell kubectl config set-context --current --namespace=dev When you run this command, you'll see: text Context "minikube" modified. The exact context name might be different depending on your Kubernetes setup, but the message confirms that your context has been updated. Now, when you run kubectl commands without the -n flag, they'll automatically operate on the dev namespace. Let's test this: Shell kubectl get deployments You'll see: text NAME READY UP-TO-DATE AVAILABLE AGE web-app 2/2 2 2 5m Notice that we didn't use the -n dev flag, but kubectl still showed us the deployments in the dev namespace. This is because dev is now our default namespace. However, you can still explicitly specify a different namespace when needed: Shell kubectl get deployments -n prod This will still show you the prod namespace contents (which is empty in our case). Setting a default namespace is particularly useful when you're focusing on a specific environment for an extended period. Just remember which namespace is set as default to avoid confusion — you can always check your current context and namespace with kubectl config view --minify | grep namespace: .

Namespaces and Environments

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