Working with Namespaces and Services in Kubernetes

What are Namespaces and Services in k8s

In Kubernetes (K8s), namespaces and services are fundamental concepts that help manage and organize applications and resources within a cluster. Here's a brief overview of each:

1. Namespaces: Namespaces provide a way to partition resources within a Kubernetes cluster. They act as virtual clusters within a physical cluster, allowing multiple teams or applications to coexist while providing isolation and resource allocation. Some key points about namespaces:

• Namespaces are a way to group and separate objects within a cluster, such as pods, services, deployments, and more.

• They help avoid naming conflicts and provide a scope for resource names.

• By default, Kubernetes provides the "default" namespace, but you can create and manage your own namespaces.

• Namespaces do not provide strict isolation but help with organizing and resource allocation.

1. Services: Services enable communication and discovery between different parts of an application or between applications in a Kubernetes cluster. They provide an abstraction layer over individual pods and allow for stable network endpoints. Key aspects of services include:

• Services define a logical set of pods and a policy to access them, providing a consistent endpoint for clients.

• They can be used to expose an application internally within the cluster or make it accessible externally.

• Services use labels and selectors to determine which pods they represent and to direct traffic to them.

• Different types of services are available, such as ClusterIP (accessible only within the cluster), NodePort (exposes the service on a specific port on each node), and LoadBalancer (exposes the service using a cloud provider's load balancer).

Task

1. Create a Namespace for your Deployment

   • Use the command kubectl create namespace <namespace-name> to create a Namespace

        kubectl create namespace todo
     

     

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

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: todo-app
      labels:
        app: todo
      namespace: todo
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: todo
      template:
        metadata:
          labels:
            app: todo
        spec:
          containers:
          - name: todo
            image: dwarika9167/todo-app:app1
            ports:
            - containerPort: 3000
   

3. Apply the updated deployment using the command: Apply the updated deployment using the command: kubectl apply -f deployment.yml -n <namespace-name>

    kubectl apply -f deployment.yml -n todo
   

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

    kubectl get namespaces
   

   

Load balancing

Load balancing in Kubernetes is achieved through the use of Services. Kubernetes provides different types of Services that allow for load-balancing traffic to the pods within a cluster. Here are the common load-balancing mechanisms in Kubernetes:

1. ClusterIP: This is the default type of Service. It exposes the Service on a cluster-internal IP address, and the Service is only accessible from within the cluster. It performs internal load balancing across the pods that belong to the Service.

2. NodePort: This type of Service exposes the Service on a static port on each node in the cluster. It allows the Service to be accessible from outside the cluster by forwarding the traffic to the appropriate pod. NodePort services also perform internal load balancing across the pods.

3. LoadBalancer: This type of Service is specifically used in cloud environments where a cloud provider's load balancer is used to distribute traffic to the Service. The cloud provider provisions a load balancer that automatically routes external traffic to the Service.

4. Ingress: Ingress is an API object that manages external access to Services within a cluster. It provides a way to define rules for routing external traffic to different Services based on path, domain, or other rules. Ingress typically uses an Ingress Controller that handles the actual load balancing and routing of the traffic.

The appropriate type of Service to use depends on the specific requirements of your application and the infrastructure you are running on. ClusterIP is commonly used for internal communication between services, NodePort for external access during development or testing, and LoadBalancer or Ingress for production deployments.

Networking in Kubernetes

Networking in Kubernetes plays a crucial role in connecting and enabling communication between various components, such as pods, services, and external resources. Here are some key aspects of networking in Kubernetes:

1. Cluster Networking:

   • Every Kubernetes cluster has an underlying network infrastructure that enables the communication between nodes and pods.

   • Pods within the same cluster can communicate with each other using their IP addresses.

   • Kubernetes assigns each pod a unique IP address from the cluster's address range.

2. Pod Networking:

   • Pods are assigned IP addresses from a specified range within the cluster's network.

   • By default, pods can communicate with each other using these IP addresses, regardless of which node they are running on.

   • Pod-to-pod communication happens within the same network namespace.

3. Services:

   • Kubernetes Services provide a stable network endpoint for accessing a set of pods.

   • Services can be accessed internally within the cluster or exposed externally.

   • Services abstract away the individual pod IP addresses and provide a consistent endpoint for client applications.

   • Load balancing is handled by the Service, distributing incoming traffic to the pods that match the Service's selector.

4. Ingress:

   • Ingress is an API object that manages external access to services in a cluster.

   • It allows inbound traffic to reach Services based on specific rules and routes.

   • Ingress controllers, such as Nginx or Traefik, implement the Ingress rules and handle the traffic routing.

5. Network Policies:

   • Network Policies define rules to control inbound and outbound traffic to pods.

   • They enable fine-grained network isolation and access control within the cluster.

   • Network Policies specify which pods can communicate with each other based on labels and selectors.

6. Container Network Interface (CNI):

   • CNI is a standard that defines how network interfaces are configured in containers or pods.

   • CNI plugins handle the creation and management of networking interfaces in Kubernetes.

   • Plugins such as Calico, Flannel, Weave, and Cilium provide networking solutions and implement the CNI standard.

7. DNS Resolution:

   • Kubernetes provides a built-in DNS service for name resolution within the cluster.

   • Each Service is assigned a DNS name that other pods can use to communicate with it.

   • Pods can resolve the DNS names of other Services or pods by simply using their names.

These are some of the fundamental aspects of networking in Kubernetes. Understanding and configuring networking properly is essential for ensuring the seamless communication and connectivity of applications within a Kubernetes cluster.

Thankyou........