How to Create Namespace in Kubernetes with 'kubectl'

September 18th, 2024
How to Create Namespace in Kubernetes with 'kubectl'

Kubernetes comprises an endless number of components that have to be secured from many cyberattacks. Kubernetes security implementations come in different levels of protection. The simplest level of security in Kubernetes is isolating resources and components from each other. When Pod A is under a security breach Pod B will not be affected by the breach if they are isolated.

Kubernetes has an isolation mechanism called namespace. Namespaces are used to organize and segregate Kubernetes resources into partitions. In this article, you will learn what Kubernetes namespaces are in detail. In addition, you will learn how to create and manage namespaces using kubectl.

Prerequisites

Make sure you have a fully operational Kubernetes cluster and that kubectl is properly installed on your local machine.

What are Kubernetes namespaces?

Namespaces are used to divide a cluster into subclusters of resources. Namespaces are very useful for clusters that are used by many teams or individuals. Certain individuals will be given access to some namespaces and get denied access to crucial namespaces. Namespaces provide a way for resources to be grouped into subclusters and get organized using name scopes or prefixes to say. A production namespace will start with “prod-” followed by a logical group name. All Kubernetes resources can be organized using namespaces excluding nodes and volumes.

Since namespaces divide a cluster into sub clusters this improves the Kubernetes API search performance. The Kubernetes API only has to search the current namespace. The search latency becomes high when there are many resources in one namespace.

Kubernetes has three default namespaces that will be generated when you create a Kubernetes cluster:

  1. default: Every component that you create that is not assigned to a namespace will be assigned to the default namespace.
  2. kube-system: This namespace is reserved for components that are created by the Kubernetes systems.
  3. kube-public: This namespace can be accessed and read by all users including those not authenticated.

Build and scale your self-managed Kubernetes clusters effortlessly with powerful Dedicated Servers — ideal for containerized workloads.

How to create and delete namespace in Kubernetes

Namespaces are usually created using imperative commands. This approach is fast as the namespace doesn't need a lot of configuration to be specified in the YAML file.

Creating a namespace

Use the following command to create a namespace.

kubectl create namespace [namespace name]

After creating a namespace you have to switch to the namespace you just created to be able to view the details of the namespace or access any resource in that namespace. Before creating any namespace, the configuration will be set to the default namespace. If you try to access the newly created namespace without switching to the new namespace you will get an error that indicates that the namespace does not exist.

Namespaces are used by kubeconfig to define the context of the cluster. Kubeconfig is a file that is used by kubectl to interact and manage multiple Kubernetes clusters. This kubeconfig file stores details about the namespaces you create and enables you to switch namespaces. Below is the full command you can use to change namespaces.

kubectl config set-context --current --namespace=<namespace-name>

To switch namespaces in Kubernetes you have to access the kubeconfig file using the kubectl config command. The config subcommand is used to modify the kubeconfig. The set-context command updates the kubeconfig context settings of the kubeconfig and changes the current namespace to a different namespace.

If you changed namespace successfully you will get the following output:

Switch namespace

Describing a namespace

To get more details about the namespace you just created, use the kubectl describe command. It is important to know the details of the namespace such as resource limits. You can find out that the resource consumption errors stem from limit misconfigurations set in the namespaces. All resource limits assigned to the namespace apply to all Pods and containers in the namespace.

kubectl describe namespace [namespace name]

You will get the following output that shows that the namespace is active and has a list of resource limits set. But no resource quota is set. The resource limits shown below were added to the namespace using the resource limits and ranges shown in the previous section, “Setting resource quotas for a specific namespace”.

Namespace details

Listing namespaces

Use the following command to list all namespaces available in your cluster.

kubectl get namespace [namespace name]

You will get the following list of available namespaces:

Namespace list

Deleting a namespace

Use the following command to delete namespace that are no longer needed.

kubectl delete namespace [namespace name]

Why should you use namespaces?

In this section, you will learn how isolation created by namespaces improves cluster control and management. Below are the importances of using Kubernetes namespaces.

Minimizing attack surface using resource isolation

An attack surface illustrates all the resources and parts of a cluster that are affected during a cyberattack. The bigger the attack surface, the more impact and destruction will be caused by a security breach. Reducing the attack surface by isolating resources using namespaces will minimize the amount of damage that can be initiated by malicious users.

When two Pods are separated by different namespaces they don't share the same technical aspects such as network policies and secrets.

Organizing the cluster using namespaces

Namespaces divide components into different groups. For example, all resources used during the development stage will be kept in a namespace called development_environment. While resources used during production will be kept in a namespace called prodcution_environment. The latter namespace will host crucial resources that are used for deploying the containers. So not everyone will be allowed to access this namespace.

Namespaces are good at creating well organized clusters. Imagine how clumsy Kubernetes clusters would be if all resources were cramped up into one cluster partition. It would be hard to identify and locate resources for different environments. Namespaces help create partitions for resources to be easily identified and located.

Setting resource quotas for a specific namespace

Kubernetes resource limits and requests control how many resources a container can request and consume. These resource limits are configured and assigned to a namespace. All the resources in the namespace will use the resource limits assigned to the namespace. You don't have to assign memory and cpu limits to every pod. Below is an example of a resource limit range for a namespace called dev_environment.

apiVersion: "v1"
kind: "LimitRange"
metadata:
  name: "resource-limits"
spec:
  limits:
    - type: "Pod"
      max:
        cpu: "500m"
        memory: "750Mi"
      min:
        cpu: "10m"
        memory: "5Mi"
    - type: "Container"
      max:
        cpu: "500m"
        memory: "750Mi"
      min:
        cpu: "10m"
        memory: "5Mi"
      default:
        cpu: "100m"
        memory: "100Mi"
      defaultRequest:
        cpu: "20m"
        memory: "20Mi"
    - type: "PersistentVolumeClaim"
      min:
        storage: "1Gi"
      max:
        storage: "50Gi"

Also read: How to deploy Kubernetes on bare metal

Conclusion

In this guide, you have learned what namespaces are and how to create them. In addition, you have learned how to fetch the details of the namespaces and how to delete the namespace when it is no longer needed.

Since all resources in a namespace use the same resource limit ranges it is important to ensure that there is consistent supply of memory and CPU. You can implement a consistent supply of cloud computing storage using Cherry Servers. Cherry Servers offers flexible and expandable storage and cloud resources using elastic block storage.

Boemo is a software developer specializing in DevOps technical writing. He has more than 3 years of experience in DevOps technical writing. He has written detailed tutorials on DataOps, Kubernetes security tools, and Android video chat implementation using Agora. He is an expert in authoring Linux, Docker, Kubernetes and Android development tutorials. He currently works as a freelance technical writer and resides in Gaborone, Botswana. In his previous role as a freelance DevOps writer at Draft.dev he reviewed developer tools such as Cast.ai, Shipa, and Kubecost. After gaining abundant knowledge on how these tools work, he wrote articles that compare developer tools and show developers the best tools they should use for different DevOps cost analysis use cases.

Start Building Now

Deploy your new Cloud VPS server in 5 minutes starting from $5.83 / month.

We use cookies to ensure seamless user experience for our website. Required cookies - technical, functional and analytical - are set automatically. Please accept the use of targeted cookies to ensure the best marketing experience for your user journey. You may revoke your consent at any time through our Cookie Policy.
build: b0376f5bd.760