Kubernetes Ingress

Project: Deploying a Web Application with Kubernetes Ingress

Kubernetes Ingress involves understanding key points mentioned below:

Basic Kubernetes Concepts
Understanding Services and Service Types

Let’s learn about Kubernetes Ingress in very easy words.

Kubernetes Ingress is like a traffic cop for web services in a Kubernetes neighborhood. Without it, services are like houses with no doors facing the street, only talking to each other. Ingress puts up signs and traffic rules, directing visitors (web traffic) to the right houses (services), making it easy for people outside the neighborhood to access the web applications

Provides a way to route HTTP and HTTPS traffic from outside the cluster to services running inside the cluster, based on rules you define

Here’s a breakdown of its key components and how it works:

Let’s go through each point with examples:

1. Ingress Resource: You create an Ingress resource that routes traffic for example.com to a specific service within your cluster, such as a web application service named web-service.

#This YAML defines an Ingress resource named example-ingress
#It specifies rules for routing HTTP traffic based on the requested paths

#Requests to example.com/api will be directed to the api-service on port 80

#Requests to example.com/app will be directed to the app-service on port 80.

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

2. Ingress Controller: You deploy the NGINX Ingress Controller as a pod within your Kubernetes cluster. This controller monitors the cluster for Ingress resources and configures the NGINX server accordingly.

#This command deploys the NGINX Ingress Controller into the Kubernetes cluster

#The Ingress Controller is responsible for managing and enforcing the rules defined in Ingress resources.

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/cloud/deploy.yaml

3. Rules : In your Ingress resource, you define a rule that routes traffic for example.com/api to a backend service named api-service and traffic for example.com/app to a backend service named app-service.

4. Load Balancing: You have multiple instances of a backend service running in your cluster, and the Ingress controller automatically distributes incoming traffic across these instances to ensure high availability and optimal resource utilization.

#As traffic is routed to backend services, 
#The Ingress Controller automatically balances the load among available instances of those services.

5. TLS Termination: You configure your Ingress resource to terminate SSL/TLS encryption for traffic coming to example.com, allowing the Ingress controller to handle the decryption and forward the decrypted traffic to the backend service.

#This section specifies TLS termination for the example.com hostname.

#It instructs the Ingress Controller to terminate SSL/TLS encryption for traffic directed to example.com, 
#Using the TLS certificate provided in the example-tls-secret. 

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  tls:
  - hosts:
    - example.com
    secretName: example-tls-secret
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

6. Rewrites and Redirections: You set up a rule in your Ingress resource to rewrite URL paths, such as redirecting requests from example.com/old-path to example.com/new-path, or redirecting HTTP traffic to HTTPS for improved security.

#This YAML defines an Ingress resource named example-ingress
#It specifies multiple rules for routing HTTP traffic based on the requested paths

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /old-path  #Requests to /old-path are directed to the old-service on port 80
        pathType: Prefix
        backend:
          service:
            name: old-service
            port:
              number: 80
      - path: /redirect-me   #Requests to /redirect-me are directed to the redirect-service on port 80
        pathType: Prefix
        backend:
          service:
            name: redirect-service
            port:
              number: 80
      - path: /new-path #Requests to /new-path are directed to the new-service on port 80
        pathType: Prefix
        backend:
          service:
            name: new-service
            port:
              number: 80
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: default-service
            port:
              number: 80
        # Redirect /old-path to /new-path  
        #Rule defines a redirection from /old-path to /new-path
      - path: /old-path
        pathType: Prefix
        redirect:
          path: /new-path
          targetPort: 80

#If a request matches /old-path, it will be redirected to /new-path
#All other requests are directed to the default-service on port 80 

7. Customization: You customize the settings of your Ingress controller to set timeouts for incoming requests, configure connection limits, or specify request size limits based on the requirements of your applications and infrastructure.

• Configurations like timeouts, connection limits, etc., are typically managed in the Ingress Controller’s configuration file or through annotations in the Ingress resource. Here’s an example annotation for setting a timeout:

#This YAML defines an Ingress resource named example-ingress
#It includes annotations to customize NGINX Ingress Controller settings.


#The annotations set proxy timeouts for connect, send, and 
#read operations to 5 seconds, 10 seconds, and 20 seconds respectively.

#The rules section defines routing rules for HTTP traffic, 
#with a single rule for the host example.com directing 
# all requests to the web-service on port 80.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "5s"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "10s"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "20s"
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

We shall Talk More about Kubernetes Ingress:

Ingress Controller Deployment

Monitoring and Troubleshooting

Security Best Practices

Ingress in a Multi-Cloud Environment

Overall, Kubernetes Ingress provides a powerful way to manage external access to services running within your cluster, offering flexibility, scalability, and security for your applications.

Prerequisites:

• Kubernetes cluster up and running (you can use Minikube or any cloud provider like GKE, AKS, EKS).
• kubectl CLI installed and configured to connect to your Kubernetes cluster.
• A domain name pointing to your Kubernetes cluster’s IP address (or use a local hostname if testing locally).

Steps:

1. Deploy a Sample Application:

For this project, let’s deploy a simple “Hello World” web application. Here’s a basic YAML manifest for deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sample-app
  template:
    metadata:
      labels:
        app: sample-app
    spec:
      containers:
      - name: sample-app
        image: nginx:latest
        ports:
        - containerPort: 80

Save this manifest to a file named sample-app-deployment.yaml, then apply it to your Kubernetes cluster:

kubectl apply -f sample-app-deployment.yaml

2. Expose the Deployment with a Service:

Expose the deployed application using a Kubernetes service. Here’s a basic YAML manifest for a service:

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

Save this manifest to a file named sample-app-service.yaml, then apply it:

kubectl apply -f sample-app-service.yaml

3. Set Up Ingress:

Create an Ingress resource to expose the service externally. Here’s an example Ingress manifest:

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

Replace yourdomain.com with your actual domain name. Save this manifest to a file named sample-app-ingress.yaml, then apply it:

kubectl apply -f sample-app-ingress.yaml

4. Update DNS:

Update the DNS records of your domain name to point to your Kubernetes cluster’s IP address.

5. Access the Application:

Once the DNS changes propagate, you should be able to access your application using your domain name (e.g., http://yourdomain.com). You should see the "Hello World" message served by the NGINX container.

That’s it! You’ve successfully deployed a web application using Kubernetes Ingress. You can further customize the Ingress configuration for features like SSL termination, load balancing, etc., depending on your requirements.

Enhanced Project Link Here 👆

If you found this guide helpful then do click on 👏 the button.

Follow for more Learning like this 😊

If there’s a specific topic you’re curious about, feel free to drop a personal note or comment. I’m here to help you explore whatever interests you!

Thanks for spending your valuable time learning to enhance your knowledge!