avatarJohn David Luther

Summary

The provided content outlines the process of exposing a microservices-based web application externally using Kubernetes Ingress on an Amazon EKS cluster, leveraging AWS Load Balancer Controller for Layer-7 Application Load Balancer (ALB) management.

Abstract

The web content delves into advanced Kubernetes networking by demonstrating how to expose a web application hosted on an Amazon EKS cluster to the public internet. It builds upon previous chapters, emphasizing the use of Ingress resources and the AWS Load Balancer Controller to manage an Application Load Balancer (ALB) for routing external traffic. The guide covers both single and multiple Ingress patterns, showcasing how to configure path-based routing to different services within the cluster. It provides detailed instructions, including command-line operations and annotations for Ingress resources, to enable real-life production system implementations of the Ingress model. The content also touches on the importance of understanding Kubernetes Services, Load Balancing, and Networking, and how AWS has tailored these concepts for the Amazon EKS platform.

Opinions

  • The author expresses pride in the comprehensiveness of the EKS Workshop modules, suggesting that the provided knowledge is substantial and valuable for learning Kubernetes.
  • The author believes that following the Ingress model, as opposed to simpler methods, is crucial for real-life Kubernetes-based production systems.
  • There is an emphasis on the practicality and importance of understanding cloud-specific implementations of Kubernetes networking, particularly with AWS services.
  • The use of a single ALB to handle multiple ingress rules through the IngressGroup feature is presented as an efficient and cost-effective approach for microservices-based applications.
  • The author encourages readers to follow along and engage with the content by suggesting that readers should expect to see certain outcomes at various stages of the hands-on session.
  • The content is structured to guide the reader through a learning journey, with each chapter building upon the previous one, culminating in the deployment of a sophisticated microservices architecture.

AWS Workshops DIY — EKS Workshop — 5. Exposing Web Application Externally w/ Kubernetes Ingress

Chapter 5— By using a Layer-7 Application Load Balancer (ALB) with Ingress (demonstrating single and multiple ingress patterns)

Having an Amazon EKS cluster up and a fairly sophisticated representative microservices application hosted in it, opens up all kinds of learning possibilities in the vast and complex world of Kubernetes, as should be evident by now if you’ve browsed through all the modules of this EKS Workshop. It’s quite prodigious if I may claim so!

https://www.eksworkshop.com/docs/fundamentals/exposing/ingress/

In Chapter 4–Exposing the Web Store Application Externally, we demonstrated a simple way, by leveraging the AWS Cloud Controller Manager’s capability to create a load balancer with the Service type: LoadBalancer directive, to expose our Web Store application to the outside world, accessible on the public internet.

In this chapter, we will mature our way to do the same but in a way real-life Kubernetes-based production systems are implemented, following the “Ingress model”, where the Application Load Balancer controls external traffic routing, operating in Application Layer 7, performing URL path-based routing to different services as defined in the ingress resource objects, and meeting other key networking and security needs.

https://kubernetes.io/docs/concepts/services-networking/ingress/

Theory Note and References

For conceptual understanding, the following links are helpful:

  1. This workshop’s Ingress chapter.
  2. Chapter 4’s Kubernetes Services, Load Balancing, Networking, and Cloud Controller Manager — A Refresher section where I have shared reference links.
  3. And since we’re dealing with AWS and Amazon EKS platform, bookmark AWS Load Balancer Controller Guide, the source of truth to learn how AWS has implemented the networking constructs in compliance with Kubernetes.io — Services, Load Balancing, and Networking guide.

Single Ingress Pattern

The tasks ahead for us, once the Amazon EKS cluster is up, is to create the microservices of the Web Store application as we did in the last two chapters, and then create the ingress resource pointing to the service. Because, by Kubernetes design, an ingress is just a configuration object containing the traffic routing rules, we do need an Ingress Controller (AWS Load Balancer Controller in our case) to actually forward the client requests to the target Kubernetes service.

The ingress controller needs to be deployed independently as it is not provided as part of the Kube Controller Manager or Cloud Controller Manager. The deployment comes as part of the prepare-environment script, the first command in our hands-on session, and that’s where we begin.

# Ref: https://www.eksworkshop.com/docs/fundamentals/exposing/ingress/

# Pre-Req: Create Amazon EKS Cluster following Chapter-2
# https://readmedium.com/aws-workshops-diy-eks-workshop-2-lets-cluster-with-eksctl-e129a4a3be9b

# Prepare the environment for this chapter after creating the EKS cluster
# This installs the AWS Load Balancer Controller in the Amazon EKS cluster
prepare-environment exposing/ingress

# Check that there are no Ingress resources in the cluster yet!
kubectl get ingress -n ui

# There are also no Service resources of type LoadBalancer either
kubectl get svc -n ui

# We do have all the microservices, accessible internally, inside the cluster
kubectl get svc -l app.kubernetes.io/created-by=eks-workshop -A

# Let's create the ingress that will route traffic to the UI service
# Review the YAML manifest
cat ~/environment/eks-workshop/modules/exposing/ingress/creating-ingress/ingress.yaml

# Apply ingress manifest
kubectl apply -k ~/environment/eks-workshop/modules/exposing/ingress/creating-ingress

# Inspect the Ingress object created
# As it shows, the ALB creation is already in progress
kubectl get ingress ui -n ui

# Or
kubectl describe ingress -n ui

# Wait for the load balancer to finish provisioning
# And get the load balancer URL to access our application externally
wait-for-lb $(kubectl get ingress -n ui ui -o jsonpath="{.status.loadBalancer.ingress[*].hostname}{'\n'}")

# And the application is visible on a browser window with the URL from above

# We can examing the configuration of this ALB
# Scheme field suggets the ALB is accessible over the public internet
# Subnet IDs point to public subnets in the VPC
aws elbv2 describe-load-balancers --query 'LoadBalancers[?contains(LoadBalancerName, `k8s-ui-ui`) == `true`]'

# Inspect the targets in the target group of the ALB
# Expect to see only one IP as the target, the IP of the ui pod
ALB_ARN=$(aws elbv2 describe-load-balancers --query 'LoadBalancers[?contains(LoadBalancerName, `k8s-ui-ui`) == `true`].LoadBalancerArn' | jq -r '.[0]')
TARGET_GROUP_ARN=$(aws elbv2 describe-target-groups --load-balancer-arn $ALB_ARN | jq -r '.TargetGroups[0].TargetGroupArn')
aws elbv2 describe-target-health --target-group-arn $TARGET_GROUP_ARN

# Scale up the ui component to 3 replicas to create more pods
kubectl scale -n ui deployment/ui --replicas=3
kubectl wait --for=condition=Ready pod -n ui -l app.kubernetes.io/name=ui --timeout=60s

# Examine the targets of the load balancer after the scale out
# Expect to see 3 targets pointing to 3 scaled up pods
aws elbv2 describe-target-health --target-group-arn $TARGET_GROUP_ARN

# Same with the ingress object as well, it has 3 backend IPs
kubectl describe ingress -n ui

# Mission accomplished, Web Store is public with Ingress pattern

Multiple Ingress Pattern

As illustrated in the Ingress Model diagrams above, most microservices-based Kubernetes applications will have multiple ingress objects managing a multitude of services and deployments handled by a single load balancer (ALB). To avoid creating a separate ALB for each Ingress, the IngressGroup feature groups multiple ingress rules, and a single ALB handles all the routing. Implementation-wise, the alb.ingress.kubernetes.io/group.name annotation is where the group magic happens.

In our Web Store application, we’ll expose the catalog API out through the same ALB as the ui component, and leverage path-based routing to send requests to the appropriate deployment pod via the corresponding service.

# Ref: https://www.eksworkshop.com/docs/fundamentals/exposing/ingress/multiple-ingress

# Pre-Req: Create Amazon EKS Cluster following Chapter-2
# https://readmedium.com/aws-workshops-diy-eks-workshop-2-lets-cluster-with-eksctl-e129a4a3be9b

# To begin with, confirm that the catalog API is not accessible via the ALB
# Expect to see 404 response
ADDRESS=$(kubectl get ingress -n ui ui -o jsonpath="{.status.loadBalancer.ingress[*].hostname}{'\n'}")
curl $ADDRESS/catalogue

# Modify the UI Ingress
# By adding the annotation alb.ingress.kubernetes.io/group.name
cat ~/environment/eks-workshop/modules/exposing/ingress/multiple-ingress/ingress-ui.yaml

# Create the Catalog Ingress with the same group.name used above
# And with rules to route /catalogue requests to the catalog service
cat ~/environment/eks-workshop/modules/exposing/ingress/multiple-ingress/ingress-catalog.yaml

# Create the ingress objects
kubectl apply -k ~/environment/eks-workshop/modules/exposing/ingress/multiple-ingress

# Confirm two separate ingress objects exist in the cluster
# Expect to see both pointing to the same URL address
# Meaning the IngressGroup is doing its job of merging multiple ingress rules
kubectl get ingress -l app.kubernetes.io/created-by=eks-workshop -A

# Issue the usual wait command until the load balancer is done provisioning 
wait-for-lb $(kubectl get ingress -n ui ui -o jsonpath="{.status.loadBalancer.ingress[*].hostname}{'\n'}")

# Examing the ALB listener under the hood
# Observe:
# (1) Requests with path prefix /catalogue are routed to catalog service
# (2) Everything are routed to a target group for the ui service
# (3) A default 404 response if any requests fall through the cracks
ALB_ARN=$(aws elbv2 describe-load-balancers --query 'LoadBalancers[?contains(LoadBalancerName, `k8s-retailappgroup`) == `true`].LoadBalancerArn' | jq -r '.[0]')
LISTENER_ARN=$(aws elbv2 describe-listeners --load-balancer-arn $ALB_ARN | jq -r '.Listeners[0].ListenerArn')
aws elbv2 describe-rules --listener-arn $LISTENER_ARN

# The new Ingress URL in a browser should pull the application successfully!
kubectl get ingress -n ui ui -o jsonpath="{.status.loadBalancer.ingress[*].hostname}{'\n'}"

# To test catalog service, append the prefix /catalogue at the end of the URL
# Expect to receive back a JSON payload from the catalog service
ADDRESS=$(kubectl get ingress -n ui ui -o jsonpath="{.status.loadBalancer.ingress[*].hostname}{'\n'}")
curl $ADDRESS/catalogue | jq .

# Mission accomplished once again!
# (1) The Web Store is public with Multiple Ingress pattern
# (2) Multiple Kubernetes services are responding via the same ALB as
#    shown by the /catalogue response.

Next Steps

At this point, with the help of Chapters 3, 4, and 5, we’ve wrapped up the implementation of the most important part of the workshop, the deployment of a microservices architecture-based publicly visible web application, the Retail Web Store.

Having an Amazon EKS cluster up and a fairly sophisticated representative microservices application hosted in it, opens up all kinds of learning possibilities in the vast and complex world of Kubernetes, as should be evident by now if you’ve browsed through all the modules of this EKS Workshop. It’s quite prodigious if I may claim so!

The next two chapters will focus on Kubernetes Storage, covering two key AWS Storage pillars — EBS and EFS — starting with Chapter 6 below.

See you there!

If you benefited from reading the post, please 👏 a few times before parting, and help others by sharing it; I highly appreciate that!

Please follow to stay in touch, track, and be the first to get notified of all future writings on AWS Cloud, Containers, Kubernetes, and Machine Learning. Also, check all my stories on The AWS Way publication.

AWS
Kubernetes
DevOps
Automation
Cloud Computing
Recommended from ReadMedium