Namespace in Kubernetes: Tutorial & Instructions

Kubernetes is one of the most popular container orchestration platforms that simplifies the deployment and management of containerized applications at scale. One of the core features of Kubernetes is its support for namespaces, which is a way to logically partition the cluster depending on need.

Each namespace has its own set of resources, such as pods, services, and replication controllers, isolated from other namespaces. This allows different teams or projects to run their workloads in a shared Kubernetes cluster without interfering with each other. This way, namespaces provide a powerful tool for organizing and managing resources in a Kubernetes cluster. This article introduces key concepts regarding namespaces and how it enables operational and administrative actions.

A Kubernetes cluster is a group of physical servers or virtual machines (nodes) that provide a way to run, manage and orchestrate containerized applications and services at scale. A Kubernetes cluster consists of several components, like:

• A control plane
• Worker nodes that run the containers
• Etcd, a key value store that stores the cluster's configuration data.

On the other hand, a Kubernetes namespace is a way to partition a single Kubernetes cluster’s resources among different projects, teams, and organizations. Namespaces provide logical isolation and allow different teams or projects to use the same cluster without interfering with each other. In addition, each namespace offers a unique scope for Kubernetes resources, such as pods, services, and replication controllers.

In other words, a Kubernetes cluster is a collection of resources, while a Kubernetes namespace is a way to organize those resources within the cluster. A cluster is a low-level abstraction representing the entire Kubernetes physical or virtual environment. Namespaces are a higher-level abstraction providing logical control over resource allocation within the cluster.

Here are some common use cases for Kubernetes namespaces below:

Multi-tenant applications

Multiple users or organizations share a common infrastructure in a multi-tenant environment. In this scenario, namespaces create virtual dev space for each tenant. Each tenant can have resources, such as services, deployments, and storage, managed within its namespace, ensuring that resources are logically isolated and preventing any interference between tenants.

Multiple application environments

Developers typically use multiple environments like development, testing, and production when building and deploying applications. Namespaces separate these environments from each other, ensuring that changes made in one environment do not affect the others.

Multiple projects or teams

Organizations with multiple projects or teams use namespaces to isolate resources for each project or team logically. This ensures that resources are uniformly distributed between projects according to resource requirements. Each project or group can have its namespace, allowing them to manage resources independently.

Security and resource management

Namespaces can enforce security policies and resource limits. For example, you can create namespaces for applications requiring higher security or more demanding resource requirements. You can also enforce resource quotas on namespaces to prevent applications from using too many resources.

Version Control

Namespaces can manage multiple versions of an application. Each version can be deployed in its namespace, allowing developers to test and compare different versions ensuring that changes made in one version do not affect the other.

Three key features of Kubernetes namespaces are given below.

Logical Isolation

Namespaces in Kubernetes allow you to create multiple spaces within a single Kubernetes cluster. Every cluster has a namespace called "default," where it creates resources. However, you can create additional namespaces to organize resources based on different criteria, such as applications, environments, or teams.

Each namespace can have its own set of pods, services, and other resources, which are not visible or accessible from other namespaces unless explicitly configured to be. For example, you create multiple namespaces to deploy and test customer-facing and business applications separately.

Resource Quota

A resource quota is a set of constraints or limits that specify the maximum amount of resources a namespace can use. For example, you can define quotas for CPU, memory, storage, and network bandwidth in every namespace. You can configure them per resource and express them in absolute terms (e.g., 1GB of memory) or relative terms (e.g., a percentage of the total available resources).

The below example limits the maximum number of pods and the amount of memory and CPU resources. The requests section sets a pod's minimum resource requirements before being scheduled, while the limits section sets the maximum amount of resources a pod can use.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: namespace-resource-quota
spec:
  hard:
    pods: "10"
    requests.cpu: "2"
    requests.memory: 2Gi
    limits.cpu: "4"
    limits.memory: 4Gi

Quotas are particularly useful when multiple teams or applications share the same Kubernetes cluster. They prevent one application from consuming too many resources and impacting the performance of other applications. However, incorrect settings also cause applications to fail if they exceed their allocated quota. To mitigate this risk, Kubernetes provides several mechanisms for monitoring and alerting on resource usage. For example, administrators can use Kubernetes' built-in monitoring tools to track resource usage over time or configure alerts to notify them when resource usage exceeds a certain threshold.

Access Control with RBAC

Kubernetes Role-Based Access Control (RBAC) is a security mechanism allowing administrators to control access to Kubernetes resources based on a user's role or permissions. RBAC works at both the cluster level and the namespace level. By configuring RBAC on namespaces, administrators limit access to specific resources, such as pods, services, or secrets.

Administrators define roles and bindings that specify the permissions and access levels for different users or groups to configure RBAC on namespaces. Roles define a set of permissions for specific resources within the namespace, while bindings map users or groups to particular roles. In the below example, a “pod-reader” role is created within the “my-namespace” namespace. The role grants permissions to read (get, watch, and list) pods within the namespace

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: my-namespace
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

To bind the Role to a user or group, you create a RoleBinding. Here's an example of a RoleBinding that grants the pod-reader Role to a user named John:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: pod-reader-binding
  namespace: my-namespace
subjects:
- kind: User
  name: john
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

A RoleBinding which grants access to a user at the namespace level, should not be confused with a ClusterRoleBinding, which grants access cluster wide.

RBAC on namespaces is critical when multiple teams or applications share the same Kubernetes cluster. It prevents unauthorized access to sensitive data or resources while allowing different teams to work within the namespace.

To create a new namespace in Kubernetes, you can use the kubectl create namespace command. For example, to create a namespace called “my-namespace”, you can run the following command:

kubectl create namespace my-namespace

Once you create the namespace, you can use it to deploy resources. For example, if you want to deploy a pod in the “my-namespace” namespace, you can use the --namespace flag:

kubectl run my-pod --image=my-image --namespace=my-namespace

You can also view the resources in a namespace using the kubectl get command with the --namespace flag:

kubectl get pods --namespace=my-namespace

By default, if you don't specify a namespace when running a command, Kubernetes will use the “default” namespace. To switch to the newly created namespace, run the following command:

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

The above command will set the current context to the "my-namespace" namespace so that all subsequent commands will be executed in that namespace, and you don't need to use the --namespace flag.

To get detailed information on the namespace, use the below command with the "describe" keyword.

kubectl describe namespaces my-namespace

You can set resource limits and requests for a pod or container using the kubectl command with the limits and requests flags. For example, to set a limit of 1 CPU and 512MB of memory for a container in a pod, you can use the following command:

kubectl run my-pod --image=my-image --limits=cpu=1,memory=512Mi --requests=cpu=0.5,memory=256Mi

The above command creates a new pod called “my-pod” with an image called “my-image” and sets a limit of 1 CPU and 512MB of memory and a request of 0.5 CPU and 256MB of memory for the container.

You can also set resource limits and requests for an existing pod or container using the kubectl patch command. For example, to update the resource limits and requests for a container in a pod, you can use the following command:

kubectl patch pod my-pod -p '{"spec" :{ "containers":[{"name": "my-container", "resources" :{ "limits" :{ "cpu": "1", "memory": "512Mi"}, "requests" :{ "cpu": "0.5", "memory": "256Mi"}}}]}}'

The above command updates the resource limits and requests for the container named “my-container” in “my-pod” pod.

You can use the below command to delete the specified namespace.

kubectl delete namespaces my-namespace

While Kubernetes namespaces provide many benefits for organizing and isolating resources within a cluster, there are also some limitations that you should be aware of.

Limited resource isolation

Namespaces help isolate resources from each other, but they may not provide complete isolation for all cases. For example, pods in different namespaces can still share a node, which can impact resource usage. Secondly, there is no ability to enforce the isolation other than stringent RBAC. Otherwise, any user in a Kubernetes cluster may access any resource in any namespace, provided he has access. Creating another Kubernetes cluster is the way to go if you need true isolation and separation.

Namespace collision

Namespace names must be unique within a cluster. Namespace collisions occur if multiple teams or applications use the same name. It can cause confusion and strange errors. Additionally, Kubernetes does not support a hierarchical namespace structure, making it challenging to organize resources in a complex cluster.

Absence of geographical distribution

If your application serves several countries, a Kubernetes cluster deployed locally in each country will serve the purpose better. Namespaces can achieve isolation but can't address latency issues.

Security risks

As you add more namespaces to your cluster, managing and configuring them becomes more complex, increasing the risk of errors and security issues. For example, network policies are scoped within a namespace, limiting their effectiveness for securing traffic across namespaces. In addition, when compliance requirements arise, namespaces are not the answer and do not provide the expected isolation level. A separate cluster is a suitable solution instead.

You can overcome some namespace limitations by following these best practices.

Monitoring Kubernetes at the namespace level is vital to ensure that resources within a namespace perform as expected and troubleshoot possible issues.

Key considerations

Here are some critical aspects of monitoring Kubernetes at the namespace level.

Metrics collection

Kubernetes provides rich metrics from different resources, including nodes, pods, and services. You can collect metrics using tools like Prometheus or Grafana and visualize them through dashboards for a real-time view of resource usage and performance.

Resource usage monitoring

By monitoring resource usage against quotas, you can identify potential performance bottlenecks or over-provisioning issues that may impact the performance of your applications.

Application Performance Monitoring (APM)

APM tools can help you monitor response time, error rates, and throughput metrics. As a result, you can identify and troubleshoot performance issues before they impact your users.

Alerting

You can set up alerts at the namespace level for critical metrics like CPU or memory usage. Then, Kubernetes will notify you automatically when issues arise so you can take action to resolve them.

Monitoring example

Below is an example of monitoring a namespace in Kubernetes using Prometheus.

kubectl create namespace monitoring
helm install prometheus stable/prometheus-operator --namespace monitoring

The above command will deploy the Prometheus Operator and a Prometheus server, Grafana, and other monitoring components into the monitoring namespace.

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: my-namespace-monitor
  namespace: my-namespace
spec:
  selector:
    matchLabels:
      app: my-app
  endpoints:
  - port: http
    path: /metrics
    interval: 30s

This “ServiceMonitor” will monitor pods with the app=my-app label in my-namespace. It will scrape metrics from the /metrics endpoint every 30 seconds. You can optionally use a Grafana dashboard to display CPU and memory usage metrics for pods in the my-namespace namespace.

You might want to migrate Kubernetes namespaces between clusters for several reasons.

1. Reorganizing resources to reflect changes in organizational structure.
2. Consolidating underutilized namespaces to improve resource utilization and simplify management.
3. Resolving namespace conflicts like same or similar resource names, labels, or annotations.
4. Migrating resources to a different namespace to improve security and ensure that sensitive resources are appropriately isolated from less sensitive ones.

Migration example

Here are some steps to consider when migrating a Kubernetes namespace across clusters.

1. Export resources from the source cluster: Use the kubectl command to export the resources from the source cluster to a YAML file. You can use the following command to export all resources in a namespace.

   kubectl get all --namespace=<source-namespace> -o yaml > resources.yaml

2. Modify the exported resources to ensure they are compatible with the new cluster, including updating resource names, labels, annotations, and other metadata to match the new cluster's configuration.
3. Import resources into the target cluster: Use the kubectl command to import the modified resources into the target cluster. You can use the following command to import all resources from a YAML file:

   kubectl apply -f resources.yaml

4. Once the migration is complete, test the migrated resources to ensure they work as expected. Testing includes connectivity between pods, verifying that services are reachable, and other application-specific functionality.
5. After testing, you can clean up the old resources by deleting them from the source cluster.

Key considerations

Migrating a namespace across clusters can be complex, especially if you have many resources to migrate. Planning and testing are essential to ensure the migration goes smoothly without unintended consequences. For example, you may need to configure networking and security policies to ensure the migrated resources can communicate with other resources in the target cluster. You may also need to update RBAC rules and other access controls to ensure the migrated resources have the appropriate permissions in the new cluster.

Along with RBAC, you can enhance the security of your namespace in Kubernetes by setting up the following.

Network policies

You can use network policies to control network traffic between pods and services within a namespace. They prevent unauthorized access and limit the scope of potential security breaches. For example, the below network policy allows all pods within the my-namespace namespace to communicate with each other.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-internal-traffic
  namespace: my-namespace
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector: {}

Secrets management

Namespaces provide a way to manage secrets (such as API keys and passwords) for specific applications or teams to ensure that sensitive information is only accessible to authorized users. Additionally, Kubernetes provides audit logging to track resource changes within a namespace. This can help you identify potential security issues and troubleshoot problems.

Pod security policies

Pod security policies(PSPs) are a Kubernetes feature that allows administrators to define security conditions that pods must meet. PSPs ensure your pods run with a minimum set of security permissions. As a result, they reduce the attack surface of the cluster and minimize the risk of potential security breaches.

PSPs can restrict various security features, including user and group IDs, file permissions, and network access. In the below example, pods are not allowed to run as root and must run with a non-root user. The PSP also sets restrictions on the fsGroup and volumes that pods can access, further limiting the attack surface.

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: my-psp
spec:
  privileged: false
  seLinux:
    rule: RunAsAny
  runAsUser:
    rule: MustRunAsNonRoot
  fsGroup:
    rule: MustRunAs
    ranges:
    - min: 1
      max: 65535
  volumes:
  - '*'

Kubernetes is a powerful tool for managing containerized workloads, but it can also be complex and expensive to operate at scale. One way to control costs is by leveraging Kubernetes namespaces. Here are some best practices for cost management with Kubernetes namespaces

Isolate workloads

By grouping related resources within a namespace, you can more easily track and allocate resources to specific teams or applications, helping to prevent over-provisioning and reducing wasteful spending on unused resources.

Implement resource quotas and limits

By setting quotas and limits on the resources a namespace can consume, you can prevent runaway workloads from consuming excessive resources and driving up costs. This is particularly important in multi-tenant environments where multiple teams share the same cluster.

Monitor resource usage

Regularly monitor resource usage within namespaces to identify workloads that consume excessive resources or are not being used. This can help optimize resource allocation and reduce costs.

Leverage cost management tools

Kubecost helps track resource usage and provides recommendations for optimizing costs. Kubecost allocates costs by namespace (teams) and finds out how much of the cluster resources the team used at the end of the month to provide visibility that is helpful for resource optimization and chargeback. Kubecost also helps users set a budget for their spending and send notifications when the costs exceed a preset budget.

A namespace in Kubernetes provides a powerful way to logically divide a cluster into smaller units and manage resources within those units. It isolates resources within a cluster to improve resource utilization. By creating separate namespaces for different applications or teams, you can ensure that they don't interfere with each other's resources and can manage and deploy them independently.

While namespaces provide many benefits, it's essential to consider their limitations when planning your Kubernetes deployment. For effective namespace use, it is essential to have a strategy around security, monitoring, resource, and cost management.