Exposing Microservices Running in AWS EKS With a Microservices/API Gateway Like Solo Gloo

So you’ve decided to run your Kubernetes workloads in AWS. As we’ve seen before setting up AWS EKS requires a lot of patience and headache. You may be able to get it working.

For others, you should check out the eksctl tool from Weaveworks. Now that you’ve got a Kubernetes cluster, you want to start deploying your microservices to it and start exposing and integrating APIs and services to your clients and other parts of your organization. At Solo.io we’ve open-sourced a microservices gateway built on top of Envoy Proxy named Gloo.

Gloo is a platform agnostic control plane for Envoy purposefully built to understand “function” level calls (think combination of HTTP path/method/headers, gRPC calls, or Lambda functions) for the purposes of composing them and building richer APIs for both north-south AND east-west traffic. Gloo is highly complementary to service-mesh technology like Istio. Gloo’s functionality includes: Function routing (HTTP/1, HTTP/2, gRPC functions, Lambda/Cloud Functions)

Fine grained traffic shifting (function canary, function weighted routing, etc) Request/content transformations (implicit and explicit) In helping folks use Gloo in AWS EKS, we’ve had to navigate through the fairly complex choices of choosing and exposing services running in Kubernetes. These options will be the same for other Kuberentes-native ingress, API, or function gateways.

Since AWS EKS is Kubernetes, we could expose a microservices/API gateway like Gloo in the following ways: On Gloo, we are also working on native OpenShift support and should have it shortly.

Source: medium.com