Ingress ALB Internal Load #19

 Ingress ALB Internal Load

 

Create Curl Pod

Cmd to test Ingress AWS Internal ALB using curl pod

Step-01: Introduction

• Create Internal Application Load Balancer using Ingress
• To test the Internal LB, use the curl-pod
• Deploy curl-pod
• Connect to curl-pod and test Internal LB from curl-pod

Step-02: Update Ingress Scheme annotation to Internal

• File Name: 04-ALB-Ingress-Internal-LB.yml

    # Creates Internal Application Load Balancer
    alb.ingress.kubernetes.io/scheme: internal 

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)

Step-04: How to test this Internal Load Balancer?

• We are going to deploy a curl-pod in EKS Cluster
• We connect to that curl-pod in EKS Cluster and test using curl commands for our sample applications load balanced using this Internal Application Load Balancer

Step-05: curl-pod Kubernetes Manifest

• File Name: kube-manifests-curl/01-curl-pod.yml

apiVersion: v1
kind: Pod
metadata:
  name: curl-pod
spec:
  containers:
  - name: curl
    image: curlimages/curl 
    command: [ "sleep", "600" ]

Step-06: Deploy curl-pod and Verify Internal LB

# Deploy curl-pod
kubectl apply -f kube-manifests-curl

# Will open up a terminal session into the container
kubectl exec -it curl-pod -- sh

# We can now curl external addresses or internal services:
curl http://google.com/
curl <INTERNAL-INGRESS-LB-DNS>

# Default Backend Curl Test
curl internal-ingress-internal-lb-1839544354.us-east-1.elb.amazonaws.com

# App1 Curl Test
curl internal-ingress-internal-lb-1839544354.us-east-1.elb.amazonaws.com/app1/index.html

# App2 Curl Test
curl internal-ingress-internal-lb-1839544354.us-east-1.elb.amazonaws.com/app2/index.html

# App3 Curl Test
curl internal-ingress-internal-lb-1839544354.us-east-1.elb.amazonaws.com

Step-07: Clean Up

# Delete Manifests
kubectl delete -f kube-manifests/
kubectl delete -f kube-manifests-curl/

ALB Ingress - Target Type - IP mode #18

 

Step-01: Introduction

• alb.ingress.kubernetes.io/target-type specifies how to route traffic to pods.
• You can choose between instance and ip
• Instance Mode: instance mode will route traffic to all ec2 instances within cluster on NodePort opened for your service.
• IP Mode: ip mode is required for sticky sessions to work with Application Load Balancers.

Step-02: Ingress Manifest - Add target-type

• File Name: 04-ALB-Ingress-target-type-ip.yml

    # Target Type: IP
    alb.ingress.kubernetes.io/target-type: ip   

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)
• PRIMARILY VERIFY - TARGET GROUPS which contain thePOD IPs instead of WORKER NODE IP with NODE PORTS

# List Pods and their IPs
kubectl get pods -o wide

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
  • target-type-ip-501.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 target-type-ip-501.stacksimplify.com 

Access Application using DNS domain

# Access App1
http://target-type-ip-501.stacksimplify.com /app1/index.html

# Access App2
http://target-type-ip-501.stacksimplify.com /app2/index.html

# Access Default App (App3)
http://target-type-ip-501.stacksimplify.com 

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
  - target-type-ip-501.stacksimplify.com 

why we define cluster IP service in Target IP mode?
No specific reason, so you can have it as nodeport or clusterip both are same,
Bcaz request coming to application load balancer will directly go to pod ip


why we define service itself in Target IP mode?
you need service have the ingress created target group and register the target inside that.
and target group register IP directly

Ingress Group #17

 

"Ingress" defines the routing rules for incoming traffic to services, 

while an "Ingress Class" is used to specify which Ingress controller should manage those routing rules.

 

Ingress Groups

So now here we have 3 application
each app have pod, deployment, svc

and for all 3 app we have single Ingress Resource: my-apps

and routing rule we define in a single file Ingress Resource

and for any change need to update you need to go to my-apps ingress resource

but you can group all 3 with ingress group concept and using annotation: so we can group them together with like myapps.web - so means i have annotation : ingress-group(myapp.web) in each ingress service file, and we can also define the priority for these ingress rules 

 

 

So now Creating a single AWS ALB by combining ingress services into Ingress group.

Step-01: Introduction

• IngressGroup feature enables you to group multiple Ingress resources together.
• The controller will automatically merge Ingress rules for all Ingresses within IngressGroup and support them with a single ALB.
• In addition, most annotations defined on a Ingress only applies to the paths defined by that Ingress.
• Demonstrate Ingress Groups concept with two Applications.

Step-02: Review App1 Ingress Manifest - Key Lines

• File Name: kube-manifests/app1/02-App1-Ingress.yml

    # Ingress Groups
    alb.ingress.kubernetes.io/group.name: myapps.web
    alb.ingress.kubernetes.io/group.order: '10'

Step-03: Review App2 Ingress Manifest - Key Lines

• File Name: kube-manifests/app2/02-App2-Ingress.yml

    # Ingress Groups
    alb.ingress.kubernetes.io/group.name: myapps.web
    alb.ingress.kubernetes.io/group.order: '20'

Step-04: Review App3 Ingress Manifest - Key Lines

    # Ingress Groups
    alb.ingress.kubernetes.io/group.name: myapps.web
    alb.ingress.kubernetes.io/group.order: '30'

Step-05: Deploy Apps with two Ingress Resources

# Deploy both Apps
kubectl apply -R -f kube-manifests

# Verify Pods
kubectl get pods

# Verify Ingress
kubectl  get ingress
Observation:
1. Three Ingress resources will be created with same ADDRESS value
2. Three Ingress Resources are merged to a single Application Load Balancer as those belong to same Ingress group "myapps.web"

Step-06: Verify on AWS Mgmt Console

• Go to Services -> EC2 -> Load Balancers
• Verify Routing Rules for /app1 and /app2 and default backend

Step-07: Verify by accessing in browser

# Web URLs
http://ingress-groups-demo601.stacksimplify.com/app1/index.html
http://ingress-groups-demo601.stacksimplify.com/app2/index.html
http://ingress-groups-demo601.stacksimplify.com

Step-08: Clean-Up

# Delete Apps from k8s cluster
kubectl delete -R -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
  - ingress-groups-demo601.stacksimplify.com

ALB Ingress SSL Discovery Host and TLS #16

ALB Ingress SSL Discovery Host and TLS

Automatically discovering and managing SSL/TLS certificates for secure communication within a Kubernetes cluster using Ingress objects. In this context, SSL/TLS certificates are used to encrypt and secure the communication between clients and services.

 

 

Ingress-SSL-Discovery-host

Step-01: Introduction

• Automatically disover SSL Certificate from AWS Certificate Manager Service using spec.rules.host
• In this approach, with the specified domain name if we have the SSL Certificate created in AWS Certificate Manager, that certificate will be automatically detected and associated to Application Load Balancer.
• We don't need to get the SSL Certificate ARN and update it in Kubernetes Ingress Manifest
• Discovers via Ingress rule host and attaches a cert for app102.stacksimplify.com or *.stacksimplify.com to the ALB

Step-02: Discover via Ingress "spec.rules.host"

# 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-certdiscoveryhost-demo
  annotations:
    # Load Balancer Name
    alb.ingress.kubernetes.io/load-balancer-name: certdiscoveryhost-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: default102.stacksimplify.com 
spec:
  ingressClassName: my-aws-ingress-class   # Ingress Class                  
  defaultBackend:
    service:
      name: app3-nginx-nodeport-service
      port:
        number: 80     
  rules:
    - host: app102.stacksimplify.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app1-nginx-nodeport-service
                port: 
                  number: 80
    - host: app202.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)
• PRIMARILY VERIFY - CERTIFICATE ASSOCIATED TO APPLICATION LOAD BALANCER

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
  • default102.stacksimplify.com
  • app102.stacksimplify.com
  • app202.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 default102.stacksimplify.com
nslookup app102.stacksimplify.com
nslookup app202.stacksimplify.com

Positive Case: Access Application using DNS domain

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

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

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

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
  - default102.stacksimplify.com
  - app102.stacksimplify.com
  - app202.stacksimplify.com

Ingress-SSL-Discovery-tls

Step-01: Introduction

• Automatically disover SSL Certificate from AWS Certificate Manager Service using spec.tls.host
• In this approach, with the specified domain name if we have the SSL Certificate created in AWS Certificate Manager, that certificate will be automatically detected and associated to Application Load Balancer.
• We don't need to get the SSL Certificate ARN and update it in Kubernetes Ingress Manifest
• Discovers via Ingress rule host and attaches a cert for app102.stacksimplify.com or *.stacksimplify.com to the ALB

Step-02: Discover via Ingress "spec.tls.hosts"

# 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-certdiscoverytls-demo
  annotations:
    # Load Balancer Name
    alb.ingress.kubernetes.io/load-balancer-name: certdiscoverytls-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: certdiscovery-tls-101.stacksimplify.com 
spec:
  ingressClassName: my-aws-ingress-class   # Ingress Class                  
  defaultBackend:
    service:
      name: app3-nginx-nodeport-service
      port:
        number: 80     
  tls:
  - hosts:
    - "*.stacksimplify.com"
  rules:
    - http:
        paths:
          - path: /app1
            pathType: Prefix
            backend:
              service:
                name: app1-nginx-nodeport-service
                port: 
                  number: 80
    - http:
        paths:                  
          - path: /app2
            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)
• PRIMARILY VERIFY - CERTIFICATE ASSOCIATED TO APPLICATION LOAD BALANCER

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
  • certdiscovery-tls-901.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 certdiscovery-tls-101.stacksimplify.com 

Access Application using DNS domain

# Access App1
http://certdiscovery-tls-101.stacksimplify.com/app1/index.html

# Access App2
http://certdiscovery-tls-101.stacksimplify.com/app2/index.html

# Access Default App (App3)
http://certdiscovery-tls-101.stacksimplify.com

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
  - certdiscovery-tls-101.stacksimplify.com 

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:

1. 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.

2. 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

1.