The Role of Envoy Gateway When an SPA Calls Backend APIs in Kubernetes

The Browser to Pod Journey

Congratulations! You have a single-page app (SPA) in a browser and want it to be useful, not just pretty, so you want to retrieve, write, or analyze data by calling a service running in a Kubernetes cluster. 

This article talks about the journey of a request from the browser to a backend service running in Kubernetes and the role of Envoy Gateway in handling the requests.

So, if the beginning of the arrow is in your browser, and the end is in a pod in Kubernetes, what are all the things in between? And what role does the Envoy Gateway component play at the edge of the Kubernetes cluster?

Traffic Path Summary from SPA to a Kubernetes Pod

To understand the role the Envoy Gateway plays in a SPA calling APIs, we must first look at the practical components the network call goes through when it comes from the browser:

• DNS Resolution—Since you don’t want your pretty web app to call an IP address, you registered a domain name to resolve to an IP address. For example, awesome.example.com is just a pretty name for an IP. What’s cool about DNS is that we can have it resolved to many IPs or change it later, so if we one day decide to migrate it all to a different place and get new IPs, the app code doesn’t have to change.
• External LoadBalancer—You must have wondered where you would get that IP address for the DNS Registration in the first place, which awesome.example.com would point to. Assuming you are using a cloud provider like GCP, AWS, or Azure, you are likely using one of the external load balancers that the cloud providers offer. If you are using AWS, let’s assume you use a low-cost option like an NLB. See this article for how to use NLB with Envoy Gateway in AWS: How to Use Envoy Gateway with AWS NLB for Maximum Throughput with Minimum Resources 
• Kubernetes Gateway—The biggest reason you picked a low-feature, low-cost option like an AWS NLB is that you picked a cloud provider-agnostic, feature-rich Kubernetes Gateway. In this example, you picked Envoy Gateway. You did this because you want to have all the complicated routing and security logic configured cloud-natively in Kubernetes rather than using a vendor-locked Cloud Provider Load Balancer to handle that logic. (See this link for how to get started with Envoy Gateway using the Tetrate Enterprise Gateway installation charts: Get Started with the TEG Demo Installation)
• Kubernetes Service—The Gateway receives the traffic and checks where it is supposed to go based on a header, a path, or the hostname like awesome.example.com to send it to the correct Kubernetes Service. You may be doing a release of a new build version of the service and want to send 10% of traffic to the latest version. The Gateway now tells Kubernetes which service to send the request to, and then Kubernetes leverages its internal service routing capabilities to get it to a ready Pod.
• Kubernetes Pod—The request arrives at the Pod, where the containerized application processes it, and the smart business logic happens. Then, a response is generated and travels back to the browser. Services abstract our access to Pods because a service might have a small number of idle pods ready to serve traffic, but when there is a high traffic load, the Kubernetes system will start spinning up more pods to handle more concurrent requests.

Component Summary

## What Does Envoy Gateway Do?

When considering the incoming traffic at the edge of the Kubernetes cluster, Envoy Gateway can handle several important jobs. These include traffic management, traffic control, access control, and observability, all of which are crucial for efficient and secure traffic handling.

Here is a summary of some common jobs Envoy Gateway can do for you:

• Traffic Management
  • Routing logic
  • Load balancing
  • Canary releases and traffic splitting
• Traffic Control
  • Rate limiting and throttling
  • Circuit breaking and retry policies
  • WAF integration
• Access Control
  • JSON Web Token (JWT) validation
  • Basic Auth
  • mTLS
• Observability
  • Integration with monitoring and visualization tooling like Prometheus and Grafana
  • Extensive logging