Understanding Kubernetes Namespaces: Isolation, Connectivity, and Practical Use Cases

Introduction

Welcome back to the blog series on Certified Kubernetes Administrator (CKA) preparation. In today's post, we'll delve into the concept of namespaces in Kubernetes. We'll explore why namespaces are essential, how they provide isolation within a cluster, and perform hands-on tasks to demonstrate connectivity between services across different namespaces. Let's get started!

What are Namespaces and Why Are They Needed?

Namespaces in Kubernetes provide an additional layer of isolation within a cluster. They allow you to separate objects and resources, making management and organization easier. By default, if you don't specify a namespace, the resource is created in the default namespace. Kubernetes itself creates several namespaces, such as kube-system, which hosts control plane components, ensuring critical resources are isolated and protected from accidental modifications.

Practical Benefits of Using Namespaces

1. Isolation: By separating resources into different namespaces, you can avoid accidental deletions or modifications. For instance, if you intend to delete a pod in the test namespace, you won’t mistakenly delete a pod in the prod namespace.
2. Resource Management: Namespaces make it easier to manage resources, especially in large clusters with multiple teams and projects.
3. Access Control: You can assign different permissions and roles (RBAC) to each namespace, enhancing security and governance.

Hands-On Task: Connectivity Between Services Across Namespaces

Let's demonstrate how namespaces affect the connectivity between services.

Step 1: Check Existing Namespaces

Run the command to list existing namespaces:

kubectl get namespaces

You'll see namespaces like default, kube-system, kube-public, and kube-node-lease.

Step 2: Create a New Namespace

You can create a namespace using a YAML file or an imperative command. Here, we'll use a YAML file.

Create a file ns.yaml:

apiVersion: v1
kind: Namespace
metadata:
  name: demo

Apply the file:

kubectl apply -f ns.yaml

Alternatively, you can use the command:

kubectl create namespace demo

Step 3: Deploy Applications in Different Namespaces
Deploy an NGINX application in the demo namespace:

kubectl create deployment nginx-demo --image=nginx --namespace=demo

Deploy another NGINX application in the default namespace:

kubectl create deployment nginx-test --image=nginx

Step 4: Expose the Deployments as Services
Expose the deployments as services:

kubectl expose deployment nginx-demo --port=80 --namespace=demo --name=svc-demo
kubectl expose deployment nginx-test --port=80 --name=svc-test

Step 5: Verify Connectivity
To check connectivity, we’ll use the pod IP addresses and service names.
Get the Pod IPs:

kubectl get pods -o wide --namespace=demo
kubectl get pods -o wide

Check Connectivity via IP Address:

Exec into a pod in the demo namespace and curl the IP address of the pod in the default namespace:

kubectl exec -it <demo-pod-name> --namespace=demo -- sh
curl <default-pod-ip>

Similarly, check from the default namespace to the demo namespace.

Check Connectivity via Service Name:

Exec into a pod in the demo namespace and curl the service name in the default namespace:

kubectl exec -it <demo-pod-name> --namespace=demo -- sh
curl svc-test.default.svc.cluster.local

And vice versa:

kubectl exec -it <default-pod-name> -- sh
curl svc-demo.demo.svc.cluster.local

Conclusion

Namespaces in Kubernetes are crucial for resource isolation, management, and security. They allow different projects and teams to coexist within the same cluster without interfering with each other. Understanding and using namespaces effectively can significantly enhance your Kubernetes administration skills.

I hope you found this post helpful. Stay tuned for the next part of our series, where we will dive into multi-container pods and related concepts. Happy learning!

For further reference, check out the detailed YouTube video here: