Ingress in Kubernetes Part2

Path-based routing is a fundamental concept in web application development. It determines how incoming requests are directed to the appropriate resources or pages.

This concept is crucial for creating a seamless user experience and ensuring that requests are handled correctly.

Scenario based Example

Scenario: Imagine a website with multiple pages, such as a home page, a courses page, and a blog page. Each page is deployed separately, meaning it has its own unique URL.

URL Structure

Home Page: https://mycourses.com
Courses Page: https://courses.com/courses
Blog Page: https://courses.com/blogs

Path Based Routing

Request Routing: When a user requests a specific page, the web server needs to determine which deployed page to serve. This is where path-based routing comes into play.

Concept: Each deployed page is associated with a dedicated service. When a request arrives, the server routes it to the corresponding service based on the URL path.

Key Principle: The path component of the URL (e.g., /courses, /blogs, /) is used to identify the appropriate resource or page.

Let’s understand this through this diagram

Host-Based Routing

Host-based routing is a feature in load balancers (such as AWS Application Load Balancers) or reverse proxies that allows routing of incoming HTTP or HTTPS requests to different backend services based on the Host header in the request. This is commonly used when hosting multiple domains or subdomains on the same infrastructure.

Definition: A method of directing traffic to different parts of a website based on the hostname (e.g., https://exams.mycourses.com).
Purpose: Allows for the creation of separate subdomains, each with its own unique content and functionality.

SSL Termination

Definition: The process of encrypting and decrypting traffic between a client and a server.
Purpose: Ensures secure communication and protects sensitive data.
Protocol: HTTPS (Hypertext Transfer Protocol Secure) is used for secure communication.
Implementation: SSL termination should be implemented for all subdomains to ensure secure communication across the entire website.

Previous Deployment Strategies

Previously, deploying websites on Kubernetes cluster through Deployment and Service.
Generally, we make deployment in which we put all configurations path and image of our website.
Then to expose it to other users, we make a NodePort Service which opens a port between 30000 to 32676 and we access our application on https://IP:port.

But suppose our client requirements comes in which they ask for a fully functional DNS routing with SSL certificates and all pages should be accessible. Now, let’s understand how we can achieve this.

Understanding Ingress - An API Object in Kubernetes

Ingress: A Kubernetes component that exposes HTTP and HTTPS routes from outside the cluster to services within the cluster.
It supports Path-Based and Host-Based Routing
Ingress Controller: A component that manages the Ingress resource and routes traffic to the appropriate services. The Ingress Controller acts as a traffic manager, making decisions based on the rules defined in the Ingress Resource file.
Ingress Resource: A Kubernetes object that defines how external traffic should be routed to services within the cluster. A YAML file that defines routing rules for incoming traffic to your Kubernetes cluster. Ingress Controller reads the Ingress Resource file and uses its routing rules to direct traffic to the appropriate services.
Ingress Benefits:
- Load Balancing: Distributes traffic across multiple instances of a service.
- Traffic Management: Allows for routing traffic based on various criteria, such as hostname, path, or headers.
- Security: Provides a layer of security by controlling access to services.

Workflow of Ingress

Client Request: A user initiates a request to https://mycourses.com.
Ingress Service: The request first reaches the Ingress service, which is responsible for handling incoming traffic.
Ingress Controller: The Ingress Controller, deployed as a service within the Kubernetes cluster, receives the request.
Ingress Resource File: The Ingress Controller reads the Ingress Resource file to determine the appropriate routing rules.
Routing Decision: Based on the routing rules and the incoming request, the Ingress Controller decides which service to forward the request to.
Target Service: The request is then forwarded to the designated service, such as the home page service in our example.
Service Deployment: The target service, which is deployed as a pod within the Kubernetes cluster, handles the request.
Response: The service processes the request and sends a response back to the client.

So, the flow looks like this

A: Client
B: Ingress Service
C: Ingress Controller
D: Ingress Resource File
E: Routing Rules
F: Target Service
G: Service Deployment
H: Response

The Ingress Resource file is a critical component in Kubernetes for managing incoming traffic and routing it to the appropriate services. The Ingress Controller, guided by the rules defined in the Ingress Resource file, acts as a traffic manager, ensuring that requests are directed to the correct services within the Kubernetes cluster. This architecture provides a flexible and scalable way to handle incoming traffic and manage the flow of requests within your Kubernetes environment.

Sample Ingress Resource file

apiVersion: networking.k8s.io/vl
kind: Ingress
metadata:
name: example-ingress
spec:
  rules:
  - host: "mycourses. com"
    http:
      paths:
      - pathType: Prefix
        path: /
        backend:
          service:
            name: home-service
            port:
              number: 8080
      - pathType: Prefix
        path: /courses
        backend:
          service:
            name: course-service
            port:
              number: 8184

Ingress Resource File Structure

API Version: Specifies the version of the Kubernetes API used for the Ingress resource.
Networking: Defines the networking configuration for the Ingress resource, including the Ingress controller used to handle traffic.
Kind: Specifies the type of Kubernetes object, which is "Ingress" in this case.
Metadata: Contains information about the Ingress resource, such as its name and labels.
Spec: Defines the rules for routing traffic to services within the cluster.
Rules: An array of rules that define how traffic is routed based on hostnames and paths.
Host: Specifies the hostname that the rule applies to.
HTTP: Defines the HTTP-specific rules for routing traffic.
Paths: An array of paths that define the specific URLs that the rule applies to.
Backend: Specifies the service that the traffic should be routed to.
Service Name: The name of the service that the traffic should be routed to.

Ingress in Kubernetes Part2 - CKA