In this Cloud Native Short Take, Christian Lacsina discusses the concepts and implications of Kubernetes namespaces. Namespaces in Kubernetes are like logical partitions of the Kubernetes API, allowing multiple users or teams to deploy resources while minimizing conflicts and providing lightweight security boundaries. Imagine having various teams sharing the same cluster; namespaces help organize it. Whether it’s per user, per team, or by application, namespaces offer flexibility for segmenting larger Kubernetes clusters into smaller logical clusters.
Video Transcript
Hello everyone, welcome to another RX-M Cloud Native Short Take. I’m Christian Lacsina and today I’ll be short taking the concept of namespaces in Kubernetes. We’ll be covering the concepts and implications of Kubernetes namespaces in this video. So what are Kubernetes namespaces? Kubernetes namespaces are logical partitions of the Kubernetes API. Namespaces allow multiple consumers of a single Kubernetes cluster to deploy resources while minimizing conflicts between each other. Think of maybe having multiple teams using the same cluster. It’s really up to the consumers of a Kubernetes cluster to decide how they should actually partition that cluster. Whether they do so on a per user, or per team basis, or on a per application basis, or maybe per group of applications: such as grouping all your observability tools or service mesh tools all in the same Kubernetes namespace.
Namespaces are an integral part of the resource identification in Kubernetes. Everything in Kubernetes must have a unique metadata.name field. This name is part of the object’s uniform resource identifier or URI in a Kubernetes cluster and these URIs must be unique within a given cluster. So the URI is going to reflect parts of the name and in some cases the namespace but also remember that some objects are cluster scoped–thus not namespaced. We can take a node for example: its URI is simply going to state /api/v1/nodes/my-node-name. That’s fine because nodes are most likely going to be uniquely identified in the network thanks to their hostnames. However in some other cases there will be a series of objects that are namespaced. Think of things such as Deployments for example. For these objects the namespace is part of their URI and thus the namespace serves as another unique identifier for that particular object. For example a Deployment will have the URI of /apis/apps/v1/namespaces/my-namespace/my-deployment. We see here that the namespace is an integral part of that object’s URI and thus regardless of how many other people create Deployments called my-deployment they will still be unique inside the Kubernetes cluster.
Now how can you see these URIs? Well you can always use the --verbose or -v followed by a number and that’s going to show your Kubernetes request including the URI of the object that you’re calling. Let’s go ahead and hop on over to a Kubernetes cluster and in this Kubernetes cluster we can see here that I have a series of namespaces. Namespaces themselves are actually also defined as objects in the Kubernetes API and in my current state all of my namespaces are reflecting certain applications that I’ve deployed onto my cluster. Things like the nginx Ingress, Longhorn for persistent storage, metalLB for my outside address setups. In my case, I’ve got a per-application namespacing solution.
Let’s say I wanted to onboard a couple of new teams. In order to ensure that these new teams can use my cluster I’m going to give them their own namespace and we’ll call that namespace teama. So now team A has their own namespace in my cluster and what this is going to allow me to do is let’s say I’m in control of my default namespace and I decide to create a Deployment called mydep. So let’s go ahead create that; we’ll go ahead and create that without my any namespacing directive. So we can see here that now I have a Deployment and if I were to get that Deployment with kubectl get deploy -v6 mydep, we can see that my kubectl request was sent over to find this specific URI and we can see that the namespace–the default namespace in my case–has been attached to this object’s URI.
Because my URI must be unique within the namespace and really throughout the cluster, if I try to create another deployment named mydep I’m going to get a “failed to create” error because it already exists.
Now let’s say “team A” doesn’t quite know exactly what I’m doing because I’m on a completely different team and they decide to create their Deployment called mydep. So the way that they can get around the fact that my Deployment already exists is by creating their Deployment using the same command or maybe the same yaml but we’ll scope it into their namespace. Now the teama namespace also has a Deployment called mydep. So if I were to get that Deployment in the teama namespace we can see that they have a Deployment called myep but because their Deployment has a different URI they are going to be unique in my Kubernetes cluster. This is how namespaces help ensure that multiple consumers of the same Kubernetes cluster can use it without potentially conflicting with others and that’s all thanks to namespaces!
This is just a sample of what you can learn in the Kubernetes Namespaces module. You can create your own customized Kubernetes course with this and many other modules using the courseware builder here on RX-M.com.
That’s our Cloud Native Short Take on Kubernetes namespaces!