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
metadata:
  name: demo-space
  labels:
    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