Kubernetes Services enable communication between various components within and outside of the application. Kubernetes Services helps us connect applications with other applications or users.

For example, our application has groups of PODs running various sections, such as a group for serving front-end load to users, another group running back-end processes, and a third group connecting to an external data source. It is Services that enable connectivity between these groups of PODs. Services enable the front-end application to be made available to users, help communication between back-end and front-end PODs, and help in establishing connectivity to an external data source. Thus services enable loose coupling between microservices in our application.

Why do we need services?

• If one pod goes down replica set creates a new pod but the IP address will change, whenever the new pod comes up it comes up with a new IP Address. so how does the user or customer know about this new IP address?

• If your application requires multiple replicas of a pod to serve multi concurrent users, each replica of a pod has a unique IP address but customers or users would need one common IP address or DNS. Just like we all access google.com(DNS) or 8.8.8.8(IP Address) to access Google.

How is this implemented in Kubernetes?

To solve this issue, Kubernetes uses an object called a “service”.

Services Types

Cluster IP Mode

Your pods or your service will get a cluster IP so if you try to access your service so you will be only able to access the service using the cluster IP which is only available or accessible within the Kubernetes cluster.

Advantage: It provide service discovery.

Disadvantage: Application only accessible inside Kubernetes cluster.

Node port

When a service is created with a NodePort type, The kube-proxy updates the IPTables with the Node IP address and port that is chosen in the service configuration to access the pods.

It will allow your application to be accessed inside your organization.

Anybody within our network technically might not have access to Kubernetes clusters but they have access to the worker Node IP address.

Whoever has access to the Node IP address only they can access the application if the service is created in Note-Port mode.

Load Balancer

If you create a Service as type LoadBalancer, the cloud control manager creates an external load balancer IP using the underlying cloud provider logic in the C-CM. Users can access services using the external IP

EKS---service--->Load Balancer----get---->Elastic Load Balancer IP address for my service. This is a public IP address so anyone in the world can access it.

What Is Kubernetes Ingress?

Ingress is a powerful Kubernetes resource that allows you to expose HTTP and HTTPS routes from outside the cluster to services within the cluster. We'll dive into what Ingress is, how it works, and how to use it effectively.

What is Ingress?

Ingress is a Kubernetes resource that provides a way to manage external access to services in a Kubernetes cluster. In other words, Ingress allows you to route traffic from outside the cluster to services running inside the cluster. Ingress is an alternative to creating a LoadBalancer service or a NodePort service, which can be less flexible and more difficult to manage.

At a high level, Ingress consists of two parts: an Ingress controller and Ingress rules. The Ingress controller is responsible for monitoring changes to the Ingress resources and updating the configuration of the underlying load balancer. Ingress rules define how traffic should be routed to services based on the URL path and host.

How Ingress Works

To understand how Ingress works, let's take a closer look at the two main components: the Ingress controller and Ingress rules.

Ingress Controller

The Ingress controller is responsible for managing the underlying load balancer and routing traffic to the appropriate service based on the Ingress rules. The Ingress controller is typically a software component that runs inside the Kubernetes cluster and communicates with the Kubernetes API server to watch for changes to the Ingress resources.

When a new Ingress resource is created, the Ingress controller reads the Ingress rules and creates or updates the configuration of the underlying load balancer. The Ingress controller can work with a variety of load balancers, including Nginx, Traefik, and HAProxy.

Ingress Rules

Ingress rules define how traffic should be routed to services based on the URL path and host. Ingress rules consist of a set of rules that map incoming requests to services based on the request's host and path.

Here's an example of an Ingress rule that routes traffic based on the host:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: example-service
            port:
              name: http

This Ingress rule specifies that requests to example.com should be routed to the example-service service, which is listening on port 80.

In addition to host-based routing, Ingress rules can also route based on the URL path. Here's an example of an Ingress rule that routes traffic based on the URL path:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /app1
        pathType: Prefix
        backend:
          service:
            name: app1-service
            port:
              name: http
      - path: /app2
        pathType: Prefix
        backend:
          service:
            name: app2-service
            port:
              name: http

This Ingress rule specifies that requests to example.com/app1 should be routed to the app1-service service, and requests to example.com/app2 should be routed to the app2-service service.

How to Use Ingress

To use Ingress, you'll first need to set up an Ingress controller. There are several Ingress controllers available, including Nginx, Traefik, and HAProxy. You can choose the Ingress controller that best fits your needs based on features, performance, and ease of use.

Once you've set up your Ingress controller, you can create Ingress rules that define how traffic should be routed to your services. Ingress rules are defined using YAML files and consist of a set of rules that map incoming requests to services based on the request's host and path.

Here's an example of an Ingress rule that routes traffic based on the host:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: example-service
            port:
              name: http

In this example, requests to example.com are routed to the example-service service.

You can also route traffic based on the URL path using Ingress rules. Here's an example of an Ingress rule that routes traffic based on the URL path:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /app1
        pathType: Prefix
        backend:
          service:
            name: app1-service
            port:
              name: http
      - path: /app2
        pathType: Prefix
        backend:
          service:
            name: app2-service
            port:
              name: http

In this example, requests to example.com/app1 are routed to the `app1'

Network Policies

Network Policies provide a way to control traffic flow at the pod level. Network Policies can be used to control ingress and egress traffic, restrict traffic to specific pods, and restrict traffic based on the source or destination IP address. Network Policies are important for securing the network infrastructure of Kubernetes clusters.

DNS

DNS (Domain Name System) is a system for translating domain names into IP addresses. In Kubernetes, DNS is used to provide a consistent way to access services within the cluster. Kubernetes has an integrated DNS server that can be used to provide DNS resolution for services within the cluster. DNS is important for managing the network infrastructure of Kubernetes clusters.

CNI Plugins

CNI (Container Network Interface) plugins provide a way to configure network interfaces for containers. CNI plugins are responsible for configuring networking between containers and the host. Kubernetes supports a variety of CNI plugins such as Calico, Flannel, and Weave. CNI plugins are important for configuring the network infrastructure of Kubernetes clusters.

Now Let's see an example of a hands-on exercise you can try on an Amazon EC2 instance:

Deploying a Web Application with Kubernetes Networking

Prerequisite:

1. Create an Amazon EC2 instance and install Kubernetes using a tool like kubeadm.

2. Deploy a simple web application, such as nginx, using a Kubernetes deployment. Use a replica count of 2 to ensure high availability.

Steps:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.16
        ports:
        - containerPort: 80

1. Create a Kubernetes Service to expose the nginx deployment. Use the type: LoadBalancer to create an Amazon Elastic Load Balancer (ELB) to handle external traffic.

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: LoadBalancer

1. Use kubectl get services to retrieve the IP address of the ELB, and use a web browser to visit that IP address. You should see the nginx default welcome page.

2. Create an Ingress resource to route traffic to the nginx service based on the requested URL path. Use annotations to specify the ingress class and the SSL certificate to use.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/ssl-certificate: "my-tls-cert"
spec:
  rules:
  - http:
      paths:
      - path: /nginx
        pathType: Prefix
        backend:
          service:
            name: nginx-service
            port:
              name: http

1. Install and configure the nginx ingress controller using Helm. Use the stable/nginx-ingress chart, and enable TLS by creating a secret with your SSL certificate.

helm repo add stable https://charts.helm.sh/stable
helm install my-nginx stable/nginx-ingress \
    --set controller.publishService.enabled=true \
    --set controller.service.type=LoadBalancer \
    --set controller.service.externalTrafficPolicy=Local \
    --set controller.service.annotations."service\.beta\.kubernetes\.io/aws-load-balancer-ssl-cert"="my-tls-cert" \
    --set controller.scope.enabled=true \
    --set rbac.create=true \
    --set controller.stats.enabled=true

1. Use kubectl get ingress to retrieve the DNS name of the ingress controller, and use a web browser to visit that DNS name with the /nginx path. You should see the nginx default welcome page again.

2. Create a Network Policy to restrict traffic to the nginx service based on the source IP address. Use a namespaceSelector to select the namespace containing the nginx deployment, and a podSelector to select the nginx pods. Use an ingress rule to allow traffic only from a specific IP address range.

     apiVersion: networking.k8s.io/v1
     kind: NetworkPolicy
     metadata:
       name: nginx-policy
     spec:
       podSelector:
         matchLabels:
           app: nginx
       policyTypes:
       - Ingress
       ingress:
       - from:
         - ipBlock:
             cidr: 10.0.0.0/16
   

3. Use kubectl describe networkpolicy nginx-policy to verify that the policy was created and is enforcing the desired traffic restrictions.

   This Network Policy restricts all ingress traffic to the nginx pods to only the IP address range of 10.0.0.0/16. By using Kubernetes networking features like Network Policies, you can add an extra layer of security to your cluster, helping to ensure that your applications are protected from unauthorized access.

In conclusion, Kubernetes networking provides a powerful set of tools for managing the network infrastructure for containerized applications. Services, Ingress, Network Policies, DNS, and CNI plugins are important components of Kubernetes networking that provide a stable IP address and DNS name for accessing the application, control traffic flow at the pod level, translate domain names into IP addresses, and configure network interfaces for containers. Understanding these components is essential for managing the network infrastructure of Kubernetes clusters.

Resources:

https://www.digitalocean.com/community/tutorials/an-introduction-to-the-kubernetes-dns-service#what-does-the-kubernetes-dns-service-provide

https://kodekloud.com/blog/kubernetes-ingress/

https://www.kloia.com/blog/why-do-we-use-cni-plugins-on-kubernetes

Thank You! Stay Connected☁️👩‍💻

The above information is up to my understanding. Suggestions are always welcome.

Jatin Arora

#Kubernetes #Devops #Trainwithshubham #Kubeweek #kubeweekchallenge

Mentored by- Shubham Londhe

• Manual Orchestration

• Lack of Portability

• Inconsistent Deployment

• Limited Resource Management

Kubernetes addressed these problems by providing a robust, flexible, and portable platform for managing containerized applications. It abstracts away the complexity of managing containers and provides a consistent interface for deploying and managing applications across different environments. It also provides features for resource management, automatic scaling, and self-healing, which make it easier to operate and manage containerized applications at scale.

This blog will discuss the architecture and components of Kubernetes and Kubernetes Installation and Configuration.

Kubernetes Architecture

Kubernetes has a master-worker architecture. The master node manages the cluster and coordinates the tasks assigned to worker nodes. The worker nodes are responsible for running the applications and services.

Master components

• The API server, which exposes an API that you can use to interact with your cluster.

• The etcd database, which stores the configuration data for your cluster.

• The controller manager, which watches the state of your cluster and makes changes as necessary.

• The kube scheduler, which decides where to place your containers based on resource constraints and other factors.

Worker components

• The kubelet, runs on each node and communicates with the master node to get instructions on what containers to run.

• The kube-proxy, handles network traffic between your containers.

• The container runtime, which actually runs your containers (like Docker).

• The pod is the smallest and simplest unit in the deployment model. It is a logical host for one or more containers that share the same network namespace and storage volumes.

• Add-ons: Add-ons are optional components that extend the functionality of Kubernetes. Examples of add-ons include the Kubernetes Dashboard, DNS, and monitoring tools.

Installing and Configuring Kubernetes

• Launch 2 instances master and worker(node), in this installation guide we will be installing kubeadm so we need at least t2.medium for master node and worker node can be t2.micro.

STEP 1: On Master Node Only:

• Kindly execute the below commands to Configure Docker Daemon:

    sudo su –
    sudo wget https://raw.githubusercontent.com/lerndevops/labs/master/kubernetes/0-install/daemon.json -P /etc/docker
    sudo systemctl restart docker.service
    sudo service docker status
  

  • Initialize kubernetes Master Node by running the following command:

      sudo kubeadm init
    

    • To fix the problem of "The connection to the server localhost:8080 was refused - did you specify the right host or port?", please run the below-mentioned commands:

        sudo mkdir -p $HOME/.kube
        sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
        sudo chown (id -g) $HOME/.kube/config
      

      • Install networking driver -- Weave/flannel/canal/calico etc. by executing the following command:

          sudo kubectl apply -f
          https://raw.githubusercontent.com/projectcalico/calico/v3.24.1/manifests/calico.yaml
        

        • Validate using the command "kubectl get nodes"

Step 2: ON ALL Worker Nodes

• Configure Docker Daemon on all worker nodes by executing the below commands:

    sudo su -
    hostname WORKER1
    sudo su -sudo wget https://raw.githubusercontent.com/lerndevops/labs/master/kubernetes/0-install/daemon.json -P /etc/docker
    sudo systemctl restart docker.service
    sudo service docker status
  

• Run Below on Master Node to get join token and copy the kubeadm join token from master & run it on all nodes with the command "sudo kubeadm join <master-node-ip>:6443 --token mks3y2.v03tyyru0gy12mbt --discovery-token-ca-cert-hash sha256:3de23d42c7002be0893339fbe558ee75e14399e11f22e3f0b34351077b7c4b56"

• Validate on master node using the commands "kubectl get nodes" and "kubectl get nodes -o wide"

• If nodes are with status as NotReady, then delete the node and join it again in the cluster by executing the below steps:

  On Master Node:

  kubectl delete node nodename

  kubectl get nodes

  On the same Worker node that we have to delete:

  kubeadm reset --force

  On master Node: generate the token again, execute the below command:

  sudo kubeadm token create --print-join-command

  Copy the token

  On Worker Node: Copy the token, the node will join the master node

  On Master Node: kubectl get nodes

To install and configure Kubernetes, you can use many of the following methods:

1. Kubernetes the Hard Way: This method involves manually configuring each component of the Kubernetes architecture. It is a good option if you want to learn how Kubernetes works under the hood.

2. Minikube: Minikube is a tool that enables you to run a single-node Kubernetes cluster on your local machine. It is an easy way to get started with Kubernetes without having to set up a full cluster.

3. Kubernetes on a Cloud Provider: Most cloud providers offer managed Kubernetes services that enable you to deploy and manage Kubernetes clusters without having to worry about the underlying infrastructure.

Once you have installed Kubernetes, you can configure it to meet your specific needs. Some common configuration tasks include:

• Creating namespaces to isolate applications.

• Configuring networking to enable communication between pods and services.

• Defining resource quotas to limit resource usage by namespaces or applications.

Thanks and please follow for more blogs Jatin Arora