- Project Calico
- Products
- Solutions
- Learn
- Support
- Company
A Kubernetes namespace is a logical division within a Kubernetes cluster that allows you to partition resources into logically named groups. This feature is useful for managing multiple environments within the same cluster, such as development, testing, and production, without interference. It helps organize resources by providing a unique scope for names, enabling resource sharing and isolation among different namespaces.
Namespaces also help in controlling access to resources. They allow administrators to apply policies, limit resource consumption, and segregate duties within teams. By using namespaces, it becomes easier to manage permissions across different segments of your cluster, ensuring that users and applications have access only to the necessary resources.
This is part of a series of articles about Kubernetes security.
In this article:
In Kubernetes, the “default” namespace is the initial namespace that automatically receives all Kubernetes resources unless they are explicitly assigned to a different one. This namespace is intended for objects and resources not belonging to any other namespace. It serves as the primary workspace for Kubernetes operations when no specific namespace is designated.
By default, operations on resources like pods, services, and deployments occur within this namespace if another is not specified. It acts as a starting point for deploying and managing applications within a Kubernetes cluster.
However, as projects grow in complexity or when multiple teams share a cluster, the need to organize resources with more granularity leads to the creation and use of additional namespaces.
There are several reasons to create additional namespaces.
Namespaces in Kubernetes serve as a mechanism for isolating resources and operations within a cluster. This isolation is critical for ensuring that activities or resources in one namespace do not interfere with those in another. For example, two different teams can deploy applications with the same name within their respective namespaces without conflict.
Namespace isolation also supports security policies and limits resource access, ensuring that users and applications operate within their designated environments. By leveraging Kubernetes’ Role-Based Access Control (RBAC), administrators can define permissions at the namespace level, further enhancing the isolation and security of resources.
However, it’s important to note that Kubernetes namespace isolation does not guarantee security, and it is technically possible to gain access to resources on another namespace. Therefore additional security measures should be taken to protect sensitive resources.
In Kubernetes, permissions within namespaces are managed through RBAC, enabling fine-grained control over who can access what resources. Administrators can define roles with specific permissions and assign them to users or groups within a namespace. This ensures that only authorized personnel can perform actions like reading, creating, or modifying resources within their designated namespaces.
RBAC policies can be tailored to meet the needs of different teams or applications, allowing for a flexible and secure multi-tenant environment. By managing permissions at the namespace level, organizations can prevent unauthorized access and potential security breaches.
Administrators can manage the allocation and limits of resources such as CPU and memory for each namespace. By defining resource quotas, administrators ensure that a single namespace does not consume more than its fair share of cluster resources, preventing resource starvation for other namespaces.
This is particularly important in environments where multiple teams or projects share a cluster, as it ensures equitable access to resources and maintains overall cluster performance. Additionally, limit ranges can be set within a namespace to restrict the size of resources (like pods, PersistentVolumeClaims, or containers) that can be created or requested.
Using namespaces in Kubernetes can lead to improved cluster performance by reducing the scope of operations and queries. When a cluster is organized into multiple namespaces, each tailored for different projects or teams, the Kubernetes API has fewer objects to search through when performing actions. This results in quicker response times for deployments, updates, and management tasks within each namespace.
By isolating resources into namespaces, administrators can more effectively manage the load on the cluster. This prevents any single namespace from overconsuming resources, which could impact the performance of applications running in other namespaces. Through careful resource allocation and quota enforcement within each namespace, clusters can maintain optimal performance levels even as they scale up in size and complexity.
Related content: Read our guide to Kubernetes compliance
Here’s a walkthrough of how to view, create, and delete namespaces in Kubernetes.
To view the namespaces in a Kubernetes cluster, you can use the kubectl get namespaces command. This will list all the current namespaces along with their status and age.
This command outputs something like:
NAME STATUS AGE default Active 8d kube-node-lease Active 8d kube-public Active 8d kube-system Active 8d
The output shows Kubernetes starts with four initial namespaces: default, kube-node-lease, kube-public, and kube-system. Each serves a specific purpose, from being the default space for objects without a namespace (default) to containing system objects created by Kubernetes itself (kube-system).
To get more detailed information about a particular namespace, you can use commands like kubectl get namespaces <name> for a brief summary or kubectl describe namespaces <name> for detailed information, including resource quotas and limits.
To create a namespace, you can use either a YAML file or a direct kubectl command.
For the YAML method, create a file like example-namespace.yaml in this format:
apiVersion: v1 kind: Namespace metadata: name: example-namespace
Then, apply this configuration using:
kubectl create -f ./example-namespace.yaml
This command creates a namespace named example-namespace. Alternatively, you can achieve the same result more directly with:
kubectl create namespace my-namespace
The latter command does not require an external file. However, the namespace name must be a valid DNS label as it will be used in DNS entries for services within the namespace.
Deleting a namespace in Kubernetes involves removing not just the namespace, but all resources within it. This action is irreversible and should be approached with caution. To delete a namespace, use the following kubectl command:
kubectl delete namespaces example-namespace
Upon execution, Kubernetes marks the namespace for deletion and begins to terminate all associated resources. This process is asynchronous, meaning the command returns immediately, but the actual deletion of resources occurs in the background. You can verify the status of a namespace by listing namespaces:
kubectl get namespaces
A namespace in the process of deletion appears with a status of Terminating. During this phase, you cannot create new resources in that namespace. Once all resources are successfully terminated, Kubernetes removes the namespace from the cluster entirely.
Here are some of the ways to make the best use of namespaces in Kubernetes.
Names should reflect the namespace’s purpose, environment, team, or application they are intended for. For example, using dev, test, and prod distinguishes environments within the same application lifecycle. Additionally, incorporating project or team names can further specify the namespace’s use, such as payment-dev or user-service-prod.
This naming convention enables easier identification and management of resources across different teams and projects within a cluster. Adhering to a consistent naming pattern also helps automate processes and policies across namespaces. Automation tools and scripts can use these patterns to apply configurations, permissions, or policies at scale.
Resource quotas allow administrators to define the maximum amount of resources, like CPU and memory, that a namespace can use. This prevents any single project or team from monopolizing cluster resources, ensuring fair usage across all namespaces. To set a resource quota, define a ResourceQuota object within a namespace. For example:
apiVersion: v1
kind: ResourceQuota
metadata:
name: example-quota
namespace: example-namespace
spec:
hard:
requests.cpu: "1"
requests.memory: 1Gi
limits.cpu: "2"
limits.memory: 2Gi
This configuration restricts the example-namespace to using up to 1 CPU and 1Gi of memory in requests, and up to 2 CPUs and 2Gi of memory in limits.
Similarly, limit ranges specify default request and limit values for CPU and memory per container in a namespace. They ensure that every container has reasonable resource boundaries, which helps prevent any container from becoming a resource hog.
Network policies act as a firewall for pods, allowing you to specify ingress (incoming) and egress (outgoing) rules based on pod selectors and namespace labels. This ensures that only authorized traffic can flow to and from pods, enhancing the cluster’s security posture.
To define a network policy, create a YAML file specifying the desired traffic flow rules. For example, to allow incoming HTTP traffic from any pod within the same namespace:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-http
namespace: example-namespace
spec:
podSelector: {}
ingress:
- from:
- podSelector: {}
ports:
- protocol: TCP
port: 80
This network policy applies to all pods within example-namespace, allowing them to receive TCP traffic on port 80 from any other pod in the same namespace.
Monitoring and logging in Kubernetes namespaces enable administrators to track the performance and health of applications and infrastructure. By deploying monitoring tools like Prometheus and logging solutions like Fluentd within specific namespaces, teams can collect metrics and logs at a granular level.
This data is crucial for identifying trends, diagnosing issues, and ensuring that applications are running as expected. Effective monitoring setups often include dashboards using Grafana, which can visualize metrics from Prometheus, allowing for real-time observation of resource consumption, request rates, and error rates.
Learn more in our detailed guides to:
Kubernetes monitoring
Prometheus monitoring
Tigera’s commercial solutions provide Kubernetes security and observability for multi-cluster, multi-cloud, and hybrid-cloud deployments. Both Calico Enterprise and Calico Cloud provide the following features for security and observability:
Security
Observability
Next steps:
