Namespaces in Kubernetes Explained: 🔍 Understanding Isolation and Sharing

Kubernetes Namespace?

If you've worked with Kubernetes long enough, you’ve probably seen how quickly things can spiral out of control. One team deploys a new service, another updates their staging environment, and suddenly, production is down because someone accidentally messed with the wrong resources. Sound familiar?

That’s where Kubernetes namespaces come in. Instead of stuffing everything into one disorganized cluster or deploying individual clusters for each project, namespaces help maintain order, enforce security boundaries, and enhance resource management efficiency.

In this article, we’ll explore:

• What Kubernetes namespaces are and how they work.
• Why they’re essential for managing multi-team, multi-application clusters.
• Resources that can and can't be shared across namespaces.

By the end, you’ll have a solid grasp of how to use namespaces to keep your cluster structured and scalable. Let’s dive in. 🚀

---

What Are Kubernetes Namespaces, Really?

A namespace in Kubernetes is basically a way to split your cluster into separate environments. At their core, namespaces are like virtual partitions in your cluster. They let you split your resources; pods, services, deployments, and more into separate, logical groups.

The Default Namespace

When you first start with Kubernetes, everything you deploy lands in the default namespace. It’s quick, easy, and works fine for small project.

Kubernetes comes with a few built-in namespaces:

- default – The catch-all for resources if you don’t specify a namespace.
- kube-system – Reserved for critical system components (like the Kubernetes API server).
- kube-public – Mostly unused, but contains publicly accessible resources.
- kube-node-lease – Helps track node health and optimize performance.

For example , you could create your own namespaces. Here’s how:

kubectl create namespace dev  
kubectl create namespace staging  
kubectl create namespace production  

This way, dev doesn’t interfere with staging, and staging doesn’t break production.

When to Use Namespaces (and When Not To)

✅ Use namespaces if:

• You have multiple teams sharing the same cluster.
• You need clear separation between environments (dev, staging, prod).
• You want to enforce security policies and resource limits per group.

❌ Don’t bother with namespaces if:

• Your cluster is small and managed by a single team.
• You need hard isolation—separate clusters might be the better option.
• You’re dealing with global resources like cluster-wide CRDs.

At the end of the day, namespaces help keep your Kubernetes setup clean and organized.

---

Working with Namespaces: Let’s Get Hands-On

Now that you understand the concept of namespaces, let’s dive into how you can actually work with them in your Kubernetes cluster. This section will cover the essential commands you need to list, create, and manage namespaces, as well as how to deploy resources to specific namespaces.

Listing Existing Namespaces

To see what namespaces you’ve got in your cluster, run this:

kubectl get namespaces

This command will give you a list of namespaces, including the default ones like default, kube-system, and any you’ve created yourself. It's a quick way to check what namespaces are active and available.

Creating a New Namespace

Creating a new namespace is super straightforward. Just run the kubectl create namespace command followed by the name you want for your new namespace:

kubectl create namespace my-namespace

And that’s it! Your new namespace is ready to go. Now you can deploy your resources into it, keeping everything organized.

Deploying Resources to a Namespace

If you want to deploy resources like pods, services, or deployments into a specific namespace, you can use the -n flag with kubectl apply. For example, to apply a YAML configuration to the my-namespace namespace:

kubectl apply -f app.yaml -n my-namespace

This will create the resources defined in app.yaml within the my-namespace namespace. Just make sure your YAML file doesn’t already have a namespace field in the metadata unless you want to override the command-line flag.

Switching Between Namespaces

Sometimes you’ll need to switch between namespaces while working with kubectl. To make this easier, you can set the default namespace for your session with this command:

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

After running this, all your subsequent kubectl commands will default to my-namespace, so you won’t have to keep adding the -n flag. To switch back to the default namespace, just run:

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

---

Resources That Can and Can’t Be Shared Across Namespaces

In Kubernetes, namespaces help isolate different resources within a cluster, but not all resources are confined to a single namespace. Some can be shared across namespaces, while others stay restricted. Knowing which resources can be shared (and which can't) is crucial when it comes to managing your cluster effectively. Let's break it down.

Resources That Can’t Be Shared Across Namespaces

Some resources are strictly bound to a specific namespace. These are isolated within their own namespace to ensure everything remains organized and secure.

Pods

Pods are created within a namespace, and they can’t be directly accessed by pods in other namespaces. They’re local to the namespace they reside in, which means if you want to let pods in other namespaces communicate, you'll need to set up things like network policies.

Why is this important? Pods are isolated by default, so if you need cross-namespace communication, you'll have to jump through a few hoops, like using services or network policies.

Services

In Kubernetes, services are tied to specific namespaces. They expose resources like pods only within their own namespace. If you need a service accessible across multiple namespaces, you'll have to either create an external service or configure DNS settings between the namespaces.

Why is this important? For inter-namespace communication, managing service discovery becomes key. You’ll have to reference the service using a fully qualified domain name, like my-service.my-namespace.svc.cluster.local.

ConfigMaps & Secrets

Both ConfigMaps and Secrets are tied to namespaces. While you can reference them within the same namespace or copy them to another namespace, you can't share them directly across namespaces.

Note: It’s important to scope things like app configuration and sensitive data to the correct namespace. While you can replicate or reference them elsewhere, they can’t just be shared freely across namespaces.

Deployments and StatefulSets

Just like pods, Deployments and StatefulSets live within a namespace. These resources manage pods within that namespace, so they won’t span multiple namespaces.

Why this matters: This helps keep things isolated and manageable, especially when you're scaling applications or managing their lifecycle.

Resources That Can Be Shared Across Namespaces

Not everything in Kubernetes is namespace-bound. There are a few resources that can span multiple namespaces, which helps Kubernetes maintain global management while respecting the boundaries that namespaces provide.

Nodes

Nodes exist at the cluster level, not tied to any specific namespace. Every pod, regardless of which namespace it belongs to, can run on any available node in the cluster.
Nodes make it possible to efficiently manage resources across the whole cluster without worrying about namespace boundaries.

Cluster-wide Resources (e.g., CRDs, ClusterRoles)

Resources like Custom Resource Definitions (CRDs) and ClusterRoles are not limited to namespaces. These resources are designed to work across the entire cluster, whether you’re defining custom resources or setting cluster-wide access policies.
CRDs let you create custom objects that can be accessed from anywhere, while ClusterRoles manage permissions at the cluster level, allowing users and services to access resources across namespaces.

Network Policies

While network policies are generally scoped to namespaces, they can still define how pods in different namespaces communicate with each other. By setting up cross-namespace rules, you can control traffic between pods in different namespaces.

Why this is important: Network policies allow you to maintain control over which namespaces can talk to each other, even if they’re isolated.

Persistent Volumes (PVs)

Persistent Volumes are another cluster-level resource that isn’t tied to a specific namespace. However, Persistent Volume Claims (PVCs) are namespace-bound, and while PVCs can request storage from a PV, the PV itself can be accessed by resources in multiple namespaces (depending on access mode).

Why this matters: While you can manage storage across namespaces with PVs, the data and requests are still scoped to namespaces through PVCs.

Ingress Resources

Ingress resources allow external access to services and can be configured to route traffic to services across different namespaces. By setting up the right rules, a single Ingress controller can manage traffic to services across multiple namespaces.

Note: You can centralize traffic management with one Ingress, even when your services span multiple namespaces.

Thanks for reading! Stay tuned for more deep dives into Kubernetes concepts!

Feel free to dm let's talk devOps on X