Kubernetes Namespaces & Kubens

  • As you start deploying Pods, Deployments, Services etc. on the kubernetes cluster, these objects will grow exponentially and maintaining them becomes a challenge.
  • For example, different teams cannot create services or deployments with the same name or listing of all the pods will take time as the number of pods grow.
  • Namespace is a kubernetes object that helps to group and structure kubernetes objects like Pods, Deployments , Services and partition them logically in a Kubernetes cluster.
  • It allows you to organize or isolate your Kubernetes resources in a box-like form according to their purpose across multiple users and projects in a cluster.
  • Benefits of using Kubernetes Namespaces:
    • Allows to split-up resources into different groups.
    • Organizations that use a single cluster for development, testing, and production can use namespaces to sandbox dev and test environments.
    • Namespaces enable the use of Kubernetes RBAC, so teams can define roles that group lists of permissions or abilities under a single name. This can ensure that only authorized users have access to resources in a given namespace. 
    • Policy-driven resource limits can be set on namespaces by defining resource quotas for CPU or memory utilization. 
    • If a cluster is separated into multiple namespaces for different projects, the Kubernetes API will have fewer items to search when performing operations. This improves performances and reduces latency
  • There are three pre-configured namespaces created by Kubernetes when a cluster is set up, which are:
    • default: Every namespaced Kubernetes object that is created without specifying a namespace goes to this space.
    • kube-system : Used for Kubernetes components like etcd, kube-scheduler, etc.
    • kube-public : This namespace houses publicly accessible data, including a ConfigMap which stores cluster information like the cluster’s public certificate for communicating with the Kubernetes API.
  • To list all the namespaces the command is kubectl get namespaces
  • Creating a Namespace can be done with a single command. If you wanted to create a Namespace called ‘demo-pace’ you would run:
    • kubectl create namespace demo-space
  • Or you can create a YAML file
kind: Namespace
apiVersion: v1
  name: demo-space
    name: demo-space
  • And apply it – kubectl apply -f demo-space.yaml
  • To create a resource in this namespace, you can create the POD specification files and give the command – kubectl apply -f pod.yaml --namespace=demo-space
  • You can also specify a namespace in the YAML declaration in the POD specification file
  • All commands are run against the currently active Namespace. To find your Pod, in a particular namespace you need to use the “namespace” flag . kubectl get pods --namespace =demo-space
  • Out of the box, your active namespace is the “default” namespace. Unless you specify a Namespace in the YAML, all Kubernetes commands will use the active Namespace.
  • Managing and switching between namespaces can be annoying with kubectl. kubens is a great productive tool which makes it easy to work with namespaces
  • kubens command will highlight the default namespace, which is not available in the kubectl
  • To switch to a different namespace you can just type kubens <<namespace>>
  • Namespaces are deleted with the command: kubectl delete namespaces. Everything in the namespace including all services, running pods, and artifacts will be deleted.
  • Even if your resources or team are organized in Namespaces, there’s no built-in security mechanism. Pods can still talk to other Pods even if they are in different Namespaces.
  • Services in Kubernetes expose their endpoint using a common DNS pattern. It looks like this: <Service Aame>.<Namespace Name>.svc.cluster.local

Namespaces are useful for grouping resources logically and using kubens helps to work with nsamespaces in an easy way.

Thanks and share you comments / feedback

5 thoughts on “Kubernetes Namespaces & Kubens

Leave a Reply to rajeshsgrCancel reply