Day 10/40 Days of K8s: Kubernetes Namespaces !!☸️

🤔 What is Namespace?

Logically Organizing your resources within your cluster. It is nothing but virtual cluster inside the cluster.

Example: when multiple teams are involved and each working in different micro service app, then we have a dedicated namespace for each team to avoid conflicts.

❓Default Namespaces?

When we create a cluster, there are some default namespaces that were created out of the box.

1. Default: All resources are created here by default if we don’t specify any NS, create other NS from here.

2. Kube-system: where control plane processes running . Don’t create or modify anything in this namespace.

3. Kube-node-lease : Gets information about the heart beats of the nodes, each node is associated lease object in NS . Determines the node availability.

4. Kube-public: Contains publicly access data, A configmap which contains the cluster information access even without the authentication.

    kubectl describe configmap cluster-info -n kube-public
   

💁 Why we need Namespace?

The main reasons for the need of Namespace are:

1️⃣ Logically grouping resources
2️⃣ Isolate team resources - Avoid conflicts
3️⃣ Share resources between diff env
4️⃣ In case of Blue/Green deployment
5️⃣ Limit permissions and compute resources for teams

• Logically grouping resources: What if everything is in one NS like default?
  Let's say if you have a complex app like many objects are created like deploy,svc,rps,cm,secrets. There will not be a clear overview.

  Solution: group up resources in NS like DB NS, Monitoring NS, Elastic stack NS, Nginx-ingress NS. This provides clear isolation of resources and overview.

• Isolate team resources: What if many teams are working on same application?
  Let's say If we have 3 teams, uses same cluster, team 1 created my-app deployment with config, another team deploy with same name but different config, it will create accidental overwrites and conflicts.

  Solution: Have a dedicated NS per team to avoid conflicts.

• Share resources between diff env: What if we host both env in one cluster, like staging and dev in their dedicated namespaces, elastic stack and nginx-ingress-controller deploy in cluster used for Both the NS, no need to deploy resources again and again.

• Blue/green deployment: If there are two versions of application one which is live and another which is next ready one in their respecitve namespaces. NS uses same resources like nginx and elastic stack.

• Access and resource limits :
  case-1: If Team 1 and Team 2 are working in their own dedicated namespaces, how can we ensure that each team has restricted access to their own secure and isolated environment?
  solution: Assign restricted access to each namespace so that teams only have access to their own namespace, creating a secure and isolated environment.

  Case-2: What happens if Team 1 consumes more resources than allocated, potentially causing Team 2 to run out of resources? can we limit resources such as CPU, RAM, and storage per namespace within the cluster?
  solution: Use ResourceQuotas to set limits on how much CPU, RAM, and storage each namespace can consume. This ensures fair resource distribution and prevents any one team from over-consuming resources, which could impact other teams.

✅ Create and Manage Namespace:

kubectl client will interact with master for Namespace management.

These are the following commands which are used for creating NS and resources in the specified NS as shown below.

kubectl create ns my-namespace
kubectl delete ns my-namespace 
kubectl get ns

✅ Creating Resources using Imperative and Declarative way:

✅ Imperative:

This deployment is created in default namespace as we didn't specify any ns explicitly.

✅ Declarative way:

Created deployment yaml where namespace is included in manifest file.

Here is Deploy.yaml file:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
  namespace: my-namespace
  labels:
    tier: backend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: v1
  template:
    metadata:
      labels:
        app: v1
    spec:
      containers:
      - name: nginx
        image: nginx:1.23.0
        ports:
        - containerPort: 80

✅ Pod-to-Pod Communication in Kubernetes

Case 1: Within the Same Namespace

1. Communication between Pods using Services:

   • Scenario: Pod from svc1 wants to communicate with a pod from svc2 within the same namespace.

   • Service Discovery: The pod in svc1 can use the service name of svc2 to communicate. InKubernetes CoreDNS handles the service discovery and routing.

   • Command: If both svc1 and svc2 are in the namespace mynamespace, the pod from svc1 can reach svc2 using its service name:

       curl http://svc2name
     

Case 2: Across Different Namespaces

Communication between Pods using Services:

• Scenario: Pod from svc1 in namespace ns1 wants to communicate with a pod from svc1 in namespace ns2.

• Service Discovery: The pod in ns1 can use the fully qualified domain name (FQDN) of the service in ns2 for communication.

• Command: If svc1 is the service in ns2, the pod from ns1 can reach svc1 in ns2 using:

    curl http://svc1.ns2.svc.cluster.local
  

📝 TASK: Our nginx-pod from default NS has to access nginx-deploy pod from my-namespace.

• Get the list of pods from default namespace:

• Get the list of pods from my-namespace:

• Expose the deployment named "nginx-deploy" from my-namespace Namespace.

• Now, Exec into the nginx pod of default NS, and try to access nginx-deploy svc of my-namespace.

vivekmanne@Viveks-MacBook-Pro Day10 % k get pods
NAME                     READY   STATUS    RESTARTS   AGE
nginx-759cd5f4c4-g5mmp   1/1     Running   0          7h28m
nginx-759cd5f4c4-ql7xf   1/1     Running   0          7h28m
nginx-759cd5f4c4-wrwxg   1/1     Running   0          7h28m
vivekmanne@Viveks-MacBook-Pro Day10 % k get pods -o wide
NAME                     READY   STATUS    RESTARTS   AGE     IP           NODE                     NOMINATED NODE   READINESS GATES
nginx-759cd5f4c4-g5mmp   1/1     Running   0          7h28m   10.244.2.3   kind-cluster-1-worker2   <none>           <none>
nginx-759cd5f4c4-ql7xf   1/1     Running   0          7h28m   10.244.1.2   kind-cluster-1-worker    <none>           <none>
nginx-759cd5f4c4-wrwxg   1/1     Running   0          7h28m   10.244.2.2   kind-cluster-1-worker2   <none>           <none>
vivekmanne@Viveks-MacBook-Pro Day10 % k get svc
NAME               TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
cluster-service    ClusterIP      10.96.180.221   <none>        80/TCP         7h28m
kubernetes         ClusterIP      10.96.0.1       <none>        443/TCP        7h32m
lb-service         LoadBalancer   10.96.2.31      <pending>     80:32748/TCP   7h21m
nodeport-service   NodePort       10.96.197.147   <none>        80:31051/TCP   7h27m
vivekmanne@Viveks-MacBook-Pro Day10 % k exec -it nginx-759cd5f4c4-g5mmp sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
# curl 10.244.2.4
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
#
#
# curl http://nginx-deploy.my-namespace.svc.cluster.local
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

📊 Results:

1. Direct pod-to-pod communication (using pod IP)
2. Pod-to-service communication (using FQDN: http://nginx-deploy.my-namespace.svc.cluster.local)

✅ Cluster wide vs Namespaced Resources

1. Cluster-wide resources: components that can’t be created within Namespaces, these are accessible cluster-wide. Low level resources like volumes, nodes,CRD's, PV,SC,CR,CRD....etc

2. Namespaced resources: Resources like pod, service etc..Access service in another namespace.

To find out if the resources are namespaced or not used the command:

Kubectl api-resources —namespaced=false
Kubectl api-resources —namespaced=true

✅ Change active namespace:

we can change the active namespace without providing -n flag to every command in two ways:

1. Define NS for current context

2. Kubens tool - switch Namespace

• Define NS for current context: we can define the namespace for the current cluster context like

# This will set the namespace to the current context
kubectl config set-context --current -n my-namespace

• Kubens: Install kubens tool locally, use to switch namespaces

# This will list out all namespaces and active one
kubens 

# This will switch to my-namespace Namespace.
kubens my-namespace

Namespaces in Kubernetes play a important role in organizing and managing resources within a cluster. They enable logical grouping of resources, ensuring isolation and avoiding conflicts between different teams and their projects. By using namespaces, teams can also share resources between different environments, implement blue/green deployments effectively, and set limits on permissions and compute resources, enhancing both security and efficiency. Overall, namespaces are important for maintaining a well-structured and manageable Kubernetes environment.

#Kubernetes #Namespace #40DaysofKubernetes #CKASeries #Containerization