Learn more about Gloo Edge and how to use it to set up a high-availability, high-performance environment.
Join the DZone community and get the full member experience. Gloo Edge is our Kubernetes native API gateway based on Envoy. It provides Authentication (OAuth, JWT, API keys, JWT,…), Authorization (OPA, custom, …), Web Application Firewall (based on ModSecurity), function discovery (OpenAPI based, Lambda, …), advanced transformations, and much more. One of the first questions our customers are generally asking us is how many instances of Envoy (the gateway-proxy Pod in Gloo Edge) are needed for their use case. We generally answer that they need 2 instances to get High Availability, but that’s very rare that someone needs to deploy more instances for performance reasons. In this blog post series, I’m going to perform benchmarks to provide more accurate data. I’ll start in this Blog post by benchmarking Gloo Edge without any filter (basic HTTP requests). In the next post, I’ll show the impact of enabling different security features (HTTPS, JWT, API keys, WAF, …). Finally, I’ll write a blog post about benchmarking Web Assembly (WASM). To perform my tests, I decided to deploy KinD in a VirtualMachine on GCP. I know that the CPU should be a bottleneck, so I decided to use a `n1-highcpu-96` instance type. You can find more information about this instance type in the table below: I’ve deployed a Kubernetes cluster on this VM and Gloo Edge on this cluster. I decided to use only one Envoy instance and to scale it only if I wasn’t able to use all the CPUs. I did my first tests using the httpbin Docker image for the backend (Upstreams) and was getting some 5xx errors (between 0.
