Skip to main content
Welcome to this lesson on Kubernetes namespaces. Understanding namespaces is essential for managing resources and policies within a single Kubernetes cluster, especially in production environments. In this article, we use an everyday analogy to clarify the role and importance of namespaces. Imagine two boys named Mark. Within their own households, family members use only first names. However, outsiders refer to them by their full names (e.g., Mark Smith and Mark Williams) to avoid confusion. Similarly, in Kubernetes, each namespace acts like a separate household with its own rules and resources.

​
Default and System Namespaces

So far, you have been creating objects like Pods, Deployments, and Services in a single namespace—the default namespace, which is automatically created when the cluster is set up. In addition, Kubernetes creates several other namespaces at startup:
  • kube-system: Contains critical Pods and Services (such as networking solutions and DNS) that are isolated from the user to prevent accidental modifications.
  • kube-public: Contains resources that should be accessible to all users.
For smaller or learning environments, you might continue working in the default namespace. However, in enterprise or production setups, namespaces become crucial. For instance, if you have both development and production environments sharing the same cluster, isolating resources via separate namespaces can prevent accidental interference. Below is a diagram that illustrates how different namespaces provide isolation:
The image illustrates Kubernetes namespaces for isolation, showing five labeled houses: kube-system, Default, kube-public, Dev, and Prod, each containing a circle, triangle, and square.
Each namespace can enforce its own set of policies and resource quotas. The following diagram demonstrates how various environments (Default, Prod, Dev) are allocated resources such as nodes and containers:
The image illustrates Kubernetes namespace resource limits, showing different environments (Default, Prod, Dev) with nodes and containers, highlighting resource allocation and management.

​
DNS Service Discovery within Namespaces

Within a namespace, Pods and Services can address each other directly by name. For example, if a web application Pod needs to connect to a database service in the same namespace, it can simply use the service’s name. If the service is in a different namespace, the fully qualified DNS name must be used. For example, if a web Pod in the default namespace connects to a DB service in the dev namespace, the DNS name would be:   DB-service.dev.svc.cluster.local In this DNS name:
  • “cluster.local” is the default domain of the Kubernetes cluster.
  • “svc” indicates the service subdomain.
  • The namespace and the service name follow.

​
Operational Aspects and Kubectl Commands

Let’s explore some operational tasks using kubectl commands.

​
Connecting to a Service Using DNS

Below is an example Python snippet that connects to a database service by referencing its DNS name:

​
Listing Pods in Specific Namespaces

By default, the command kubectl get pods lists Pods in the default namespace. To view Pods in a different namespace (e.g., kube-system), append the --namespace option:
Output:
Output:
Remember, if you want to list Pods across all namespaces, use:

​
Creating Pods in Specific Namespaces

When you create a Pod using a definition file, it will be created in the default namespace unless specified otherwise. To create a Pod using the definition file in the default namespace:
Output:
To create a Pod in a different namespace (e.g., dev), specify the namespace on the command line:
Output:
Below is an example of a Pod definition file without a specified namespace:
To ensure that a Pod is always created in a specific namespace (like dev), include the namespace in the definition file:
Then, create the Pod as usual:

​
Creating a New Namespace

Just like other Kubernetes objects, you can create a namespace using a definition file. For example:
Create the namespace with:
Output:
Alternatively, create a namespace directly from the command line:

​
Switching the Active Namespace

By default, all kubectl commands operate in the default namespace. To permanently switch to a different namespace (e.g., dev) in your current context, run:
After setting the active namespace, executing:
will list the Pods in the dev namespace. To view resources from other namespaces, remember to use the --namespace flag.

​
Setting Resource Quotas

Resource quotas help limit the resources available within a namespace. The following YAML file sets quotas for the dev namespace by specifying limits on Pods, CPU, and memory:
Apply the resource quota using:
This configuration ensures that the dev namespace does not exceed the defined resource limits.

​
Conclusion

Namespaces in Kubernetes are a powerful tool to isolate resources, manage policies, and efficiently organize your cluster environment—whether for development, testing, or production. By leveraging namespaces, you can deploy applications securely and prevent accidental cross-environment interference. For more information on Kubernetes concepts, visit the following resources: Happy clustering!

Watch Video