Tech Giant: ALB Ingress - Name based Virtual Host #15

The concept of "Name based Virtual Host" or "Host Header Routing" is related to how the ALB Ingress Controller routes incoming traffic based on the Host header of the HTTP request. Here's a breakdown of these terms:

Name based Virtual Host / Host Header Routing: In the context of web servers and load balancers, the Host header is an HTTP header that indicates the domain name of the server being accessed. Name based virtual hosting allows a single IP address to serve multiple domain names, and the web server or load balancer uses the Host header to determine which website or service to route the request to.
ALB Ingress Controller: The ALB Ingress Controller is a Kubernetes resource controller that manages ALBs to route traffic to different services in an EKS cluster based on Ingress resources configured in Kubernetes. An Ingress resource defines how to route external HTTP and HTTPS traffic to services within the cluster. The ALB Ingress Controller translates Ingress resources into ALB configurations.
what is the difference in b/w ContextPath-Based-Routing and VirtualHost-Routing?
1. ContextPath-Based Routing:
  In ContextPath-Based Routing, incoming requests are routed to different applications or services based on the path portion of the URL. The "context path" is the part of the URL that comes after the domain name and before any query parameters. This approach is often used when hosting multiple applications under the same domain.
  Example:
  - https://example.com/app1 routes to Application 1.
  - https://example.com/app2 routes to Application 2.
  Key Points:
  - Applications are differentiated by the path component of the URL.
  - Typically achieved using a reverse proxy or load balancer that examines the URL path.
2. VirtualHost (Host Header) Routing:
  In VirtualHost Routing, incoming requests are routed to different applications or services based on the domain name (Host header) provided in the HTTP request. This approach is used when hosting multiple websites or services on the same IP address.
  Example:
  - https://app1.example.com routes to Application 1.
  - https://app2.example.com routes to Application 2.
  Key Points:
  - Applications are differentiated by the domain name (Host header) in the HTTP request.
  - Often implemented using web server configurations (e.g., Apache, Nginx) or load balancers that support host-based routing.
Step-01: Introduction

Implement Host Header routing using Ingress
We can also call it has name based virtual host routing

Step-02: Review Ingress Manifests for Host Header Routing

File Name: 04-ALB-Ingress-HostHeader-Routing.yml

# Annotations Reference: https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/annotations/
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-namedbasedvhost-demo
  annotations:
    # Load Balancer Name
    alb.ingress.kubernetes.io/load-balancer-name: namedbasedvhost-ingress
    # Ingress Core Settings
    #kubernetes.io/ingress.class: "alb" (OLD INGRESS CLASS NOTATION - STILL WORKS BUT RECOMMENDED TO USE IngressClass Resource)
    alb.ingress.kubernetes.io/scheme: internet-facing
    # Health Check Settings
    alb.ingress.kubernetes.io/healthcheck-protocol: HTTP 
    alb.ingress.kubernetes.io/healthcheck-port: traffic-port
    #Important Note:  Need to add health check path annotations in service level if we are planning to use multiple targets in a load balancer    
    alb.ingress.kubernetes.io/healthcheck-interval-seconds: '15'
    alb.ingress.kubernetes.io/healthcheck-timeout-seconds: '5'
    alb.ingress.kubernetes.io/success-codes: '200'
    alb.ingress.kubernetes.io/healthy-threshold-count: '2'
    alb.ingress.kubernetes.io/unhealthy-threshold-count: '2'   
    ## SSL Settings
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-east-1:180789647333:certificate/632a3ff6-3f6d-464c-9121-b9d97481a76b
    #alb.ingress.kubernetes.io/ssl-policy: ELBSecurityPolicy-TLS-1-1-2017-01 #Optional (Picks default if not used)    
    # SSL Redirect Setting
    alb.ingress.kubernetes.io/ssl-redirect: '443'
    # External DNS - For creating a Record Set in Route53
    external-dns.alpha.kubernetes.io/hostname: default101.stacksimplify.com 
spec:
  ingressClassName: my-aws-ingress-class   # Ingress Class                  
  defaultBackend:
    service:
      name: app3-nginx-nodeport-service
      port:
        number: 80     
  rules:
    - host: app101.stacksimplify.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app1-nginx-nodeport-service
                port: 
                  number: 80
    - host: app201.stacksimplify.com
      http:
        paths:                  
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app2-nginx-nodeport-service
                port: 
                  number: 80

# Important Note-1: In path based routing order is very important, if we are going to use  "/*", try to use it at the end of all rules.                                        
                        
# 1. If  "spec.ingressClassName: my-aws-ingress-class" not specified, will reference default ingress class on this kubernetes cluster
# 2. Default Ingress class is nothing but for which ingress class we have the annotation `ingressclass.kubernetes.io/is-default-class: "true"`

Step-03: Deploy all Application Kubernetes Manifests and Verify

# Deploy kube-manifests
kubectl apply -f kube-manifests/

# Verify Ingress Resource
kubectl get ingress

# Verify Apps
kubectl get deploy
kubectl get pods

# Verify NodePort Services
kubectl get svc

Verify Load Balancer & Target Groups

Load Balancer - Listeneres (Verify both 80 & 443)
Load Balancer - Rules (Verify both 80 & 443 listeners)
Target Groups - Group Details (Verify Health check path)
Target Groups - Targets (Verify all 3 targets are healthy)

Verify External DNS Log

# Verify External DNS logs
kubectl logs -f $(kubectl get po | egrep -o 'external-dns[A-Za-z0-9-]+')

Verify Route53

Go to Services -> Route53
You should see Record Sets added for
- default101.stacksimplify.com
- app101.stacksimplify.com
- app201.stacksimplify.com

Step-04: Access Application using newly registered DNS Name

Perform nslookup tests before accessing Application

Test if our new DNS entries registered and resolving to an IP Address

# nslookup commands
nslookup default101.stacksimplify.com
nslookup app101.stacksimplify.com
nslookup app201.stacksimplify.com

Positive Case: Access Application using DNS domain

# Access App1
http://app101.stacksimplify.com/app1/index.html

# Access App2
http://app201.stacksimplify.com/app2/index.html

# Access Default App (App3)
http://default101.stacksimplify.com

Negative Case: Access Application using DNS domain

# Access App2 using App1 DNS Domain
http://app101.stacksimplify.com/app2/index.html  -- SHOULD FAIL

# Access App1 using App2 DNS Domain
http://app201.stacksimplify.com/app1/index.html  -- SHOULD FAIL

# Access App1 and App2 using Default Domain
http://default101.stacksimplify.com/app1/index.html -- SHOULD FAIL
http://default101.stacksimplify.com/app2/index.html -- SHOULD FAIL

Step-05: Clean Up

# Delete Manifests
kubectl delete -f kube-manifests/

## Verify Route53 Record Set to ensure our DNS records got deleted
- Go to Route53 -> Hosted Zones -> Records 
- The below records should be deleted automatically
  - default101.stacksimplify.com
  - app101.stacksimplify.com
  - app201.stacksimplify.com

Tech Giant

Tuesday, August 8, 2023

ALB Ingress - Name based Virtual Host #15

what is the difference in b/w ContextPath-Based-Routing and VirtualHost-Routing?

Step-01: Introduction