Day 33: Working with Namespaces and Services in Kubernetes

Welcome back to our Kubernetes journey! In the last article, we explored how to deploy a Django application using Kubernetes. Today, we will take a step further and delve into the concepts of Namespaces and Services in Kubernetes. These essential features allow us to organize our resources efficiently and ensure smooth communication between different components within the cluster.

What are Namespaces?

In a Kubernetes cluster, namespaces are virtual clusters that help in partitioning resources and managing them separately. They enable multiple teams or projects to share the same cluster without interfering with each other. Namespaces act as a mechanism to create isolated environments within the same Kubernetes cluster.

When you deploy resources in a namespace, they are only accessible within that namespace, making it easier to manage and secure various components. For instance, if you have a development and production environment for your Django application, using namespaces will help you keep them separate, reducing the chances of conflicts.

When to use Namespace?

Some common use cases of Namespaces are:

• When you have a shared Kubernetes cluster where multiple applications coexist, namespaces can be used to provide isolation between different tenants.
• Namespaces can be used to separate different environments, such as development, staging, and production.
• Namespaces can be used to enforce resource quotas and limits on different teams or applications.
• RBAC (Role-Based Access Control) in Kubernetes can be applied at the namespace level. This allows you to define different roles and permissions for different teams or users within specific namespaces.
• Namespaces can be used to separate testing and CI/CD pipelines.

Creating a Namespace

To create a namespace, you can use the kubectl command-line tool:

kubectl create namespace <namespace_name>

Today’s task:
Task 1) Create a Namespace for your Deployment

Step 1) Use the command ‘kubectl create namespace <namespace-name>’ to create a Namespace

Step 2) Update the deployment.yml file to include the Namespace

apiVersion: apps/v1

kind: Deployment

metadata:

  name: todo-deployment
  namespace: day33-name-space

  labels:

    app: todo-app

spec:

  replicas: 3

  selector:

    matchLabels:

      app: todo-app

  template:

    metadata:

      labels:

        app: todo-app

    spec:

      containers:

      - name: todo-app

        image: trainwithshubham/django-todo:latest

        ports:

        - containerPort: 8000

Step 3) Apply the updated deployment using the command:

 kubectl apply -f deployment.yml -n <namespace-name>

Step 4) Verify that the Namespace has been created by checking the status of the Namespaces in your cluster.

We can check the pods created under the namespace.

kubectl get pods -n=<name_of_namespace>

Task 2): Explain what you know about Services, Load Balancing, and Networking in Kubernetes.

Services

In Kubernetes, a Service is a method for exposing a network application that is running as one or more Pods in your cluster.

An example from the official documentation of k8s, explains very easily what a service is:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

This is a YAML manifest file that describes a Kubernetes Service. This Service definition named “my-service” will route incoming TCP traffic on port 80 to the Pods with the label app.kubernetes.io/name: MyApp and forward it to their port 9376. This allows other components within the cluster to access the Pods of the "MyApp" application through the Service's stable DNS name and port 80, without needing to know the specific IP addresses or port numbers of the Pods.

Why do you need services?

• Services distribute incoming network traffic across multiple Pods that are part of the Service.
• Services have a stable DNS name and IP address that can be used by other components within the cluster to access the Pods.
• When scaling the number of Pods or performing rolling updates, the Service automatically adjusts the routing of traffic to the available Pods.
• Services can be used for internal communication between different components within the cluster.
• Services can be configured to expose applications externally, allowing access from outside the cluster.

Types of services in Kubernetes:

1. ClusterIP Service
2. NodePort Service
3. LoadBalancer Service

ClusterIP

This is the default service type in Kubernetes. It creates a virtual IP address within the cluster to access the pods that are part of the service.

ClusterIP services expose a set of pods in a K8s cluster to the other pods in the same cluster using a virtual IP address.

A common practical use case for ClusterIP service would be when a web application consists of a backend API service and a frontend service. The frontend service can access the backend API service which can be exposed as a ClusterIP service. The backend pods are not directly accessible from outside the Kubernetes cluster, but they can be accessed by the frontend pods that are running in the same cluster.

So, the ClusterIP will provide access to an application within a Kubernetes cluster but without access from the world, and will use an IP from the cluster’s IP pool and will be accessible via a DNS name in the cluster’s scope.

NodePort

A NodePort service is a type of Kubernetes service that allows access to a set of pods running on a cluster from outside the cluster. It exposes the pods to the outside world by opening a specific port on all the nodes of the cluster.

This type of service exposes the container to the outside world by mapping a static port on the worker node(s) to the pod. This is useful for testing or accessing a service from outside the cluster.

When a NodePort is created, K8s assigns a random port number (between 30000 and 32767 by default) on each node in the cluster. The service can then be accessed using the IP address of any node in the cluster and the assigned port number.

The NodePort type is: tied to a specific host like ЕС2, if the host isn’t available from the world — then such a Service will not provide external access to pods, will use an IP from a provider’s pool, for example, AWS VPC CIDR, and will provide access to pods only on the same Worker Node.

A practical example is, NodePort Service can be used to expose a web application to the internet.

LoadBalancer

A LoadBalancer service is a type of Kubernetes service that provides external network access to a set of pods running on a cluster. It creates a load balancer that distributes incoming traffic across multiple backend pods, providing scalability and high availability for the application.

When you create a LoadBalancer service, Kubernetes creates a cloud load balancer (if you are running on a cloud provider) or a software load balancer (if you are running on-premises) that distributes traffic across the pods in the service. The load balancer provides a stable IP address that external clients can use to connect to the service.

So, the LoadBalancer Service type will provide external access to pods, will provide a basic load-balancing to pods on different EC2, will give the ability to terminate SSL/TLS sessions, and doesn’t support level-7 routing.

It can be used to distribute traffic across a set of pods running a web application or a backend API service, for example.

Kubernetes Networking

Kubernetes networking is the process of enabling communication between the various components of a Kubernetes cluster. It involves configuring networking resources such as pods, services, and ingress to allow traffic to flow between them.

Kubernetes has fundamental requirements for networking implementations:

1. Pods should be able to communicate with other pods on other nodes also without NAT.
2. Agents on the node should be able to communicate with all the pods on that node.

In Kubernetes, each pod gets its own IP address, and services act as a stable endpoint for accessing a set of pods. This allows for load balancing and automatic scaling of application traffic.

In addition, Kubernetes provides network policies that allow for fine-grained control over traffic flow between pods.