Use cases for Amazon EKS Anywhere (EKS-A) with Gloo Mesh, an enhanced Istio service mesh

Ram Vennam
| September 8, 2021

This blog will cover popular use cases and describe how to set up Amazon EKS Anywhere (EKS-A) and an Istio service mesh with Solo.io’s Gloo Mesh.

Hybrid cloud refers to the unification of public cloud and on-premises infrastructure. Leveraging compute environments across both environments allows you take advantage of the cost-effective scalability of public cloud as well as the dedicated and regulatory compliance benefits of private cloud. The true benefits of a hybrid cloud environment can be leveraged when your developers are able to consistently deploy and run their applications. The physical or virtual location, and other specifics of the underlying infrastructure should be abstracted from the developers and applications. 

Amazon Elastic Kubernetes Service (EKS) lets you quickly create Kubernetes clusters across the AWS datacenter. The new EKS Anywhere offering extends this same experience to your datacenter and by allowing you to create and operate Kubernetes clusters on-premises, including on your own VMs and bare metal servers. Together, EKS and EKS-A take care of providing the environment for your developers to seamlessly and consistently deploy their applications anywhere.

The next piece of the puzzle is a service mesh – controlling, securing and observing the traffic flow between your microservices, regardless of where they are running. Gloo Mesh is enterprise Istio with multi-cluster and multi-mesh management capabilities across multiple clusters and VMs. Gloo Mesh can discover services, coordinate service meshes, configure and observe behavior, federate policies, and enforce security consistently.

 

Gloo Mesh uses a dedicated management plane and agents running on the mesh clusters to simplify service mesh adoption and add powerful networking capabilities. Gloo Mesh can discover meshes/workloads, establish federated identity, enable global traffic routing and load balancing, access control policy, centralized observability and more.

 In this example, we’re going to use Gloo Mesh’s VirtualMesh resource to group the two Istio meshes across the public and private data centers into a single virtual mesh. 

apiVersion: networking.mesh.gloo.solo.io/v1
kind: VirtualMesh
metadata:
  name: virtual-mesh
  namespace: gloo-mesh
spec:
  mtlsConfig:
    autoRestartPods: true
    shared:
      rootCertificateAuthority:
        generated: {}
  federation:
    selectors:
    - {}
  meshes:
  - name: istiod-istio-system-cluster1
    namespace: gloo-mesh
  - name: istiod-istio-system-cluster2
    namespace: gloo-mesh

Gloo Mesh handles all the complexities of managing identities, certificates, federation and generation of Istio ServiceEntry, DestinationRule and VirtualService resources that are needed for cross-cluster communication. Having your applications be able to run anywhere and securely talk to one another opens up a world of new use cases. Let’s take a look at a few popular ones.

Migrating to cloud with EKS-A and Istio service mesh

Incrementally migrate a workload to a different cluster without downtime. In this example, if we wanted to migrate Hello World from cluster1 (on-premises) to cluster2 (public cloud), you can deploy them both in parallel, and then use Gloo Mesh traffic shift policies to specify both as your destination from your existing gateway.

apiVersion: networking.enterprise.mesh.gloo.solo.io/v1beta1
kind: VirtualHost
metadata:
 name: hw-virtualhost
 namespace: gloo-mesh
spec:
 domains:
 - 'myapp.com'
 routes:
 - matchers:
   - uri:
       exact: /helloworld
   name: helloworld
   routeAction:
     destinations:
     - kubeService:
         name: helloworld
         namespace: ns1
         clusterName: cluster1
         weight: 90
     - kubeService:
         name: helloworld
         namespace: ns2
         clusterName: cluster2
         weight: 10

This will generate an Istio VirtualService that does a 90-10 traffic shift on requests coming from ingress gateway on cluster1 to helloworld services on both clusters. If everything is working OK, you can point your domain to the ingress gateway in cluster2 instead of cluster1 and complete your migration.

Canary traffic shifting with EKS-A and Istio service mesh

In the previous example, we covered a north-south traffic flow. East-West traffic (between microservices) can also be controlled similarly using a Traffic Policy.

This allows you to deploy new versions of any microservice in a different cluster and perform tests by sending a subset of the traffic to the canary version.  

apiVersion: networking.mesh.gloo.solo.io/v1
kind: TrafficPolicy
metadata:
 namespace: gloo-mesh
 name: reviews-tp
spec:
 destinationSelector:
 - kubeServiceRefs:
     services:
       - clusterName: cluster1
         name: reviews
         namespace: default
 httpRequestMatchers:
   - headers:
       - name: end-user
         value: '.*@acme.com'
         regex: true
 policy:
   trafficShift:
     destinations:
       - kubeService:
           clusterName: cluster2
           name: reviews
           namespace: default
           subset:
             version: v3

This traffic policy inspects the requests going to reviews in cluster1. If the request header has end-user that matches the email *@acme.com, it sends the request to reviews in cluster2 instead. This lets you test new functionality without deploying any applications to your production cluster or impacting your normal users.

Locality-based load balancing and failover with EKS-A and Istio service mesh

In a production environment, it’s common practice to add high availability and performance to the system by having multiple instances of an application running across clusters, zones, and regions. Traffic should be routed to the closest available destination, or be routed to a failover destination if issues occur.

Gloo Mesh’s VirtualDestination API lets you group microservices together into a single “global” endpoint. The composing services can be configured with outlier detection and the ability of the system to detect unresponsive services. Traffic will automatically be sorted into priority levels by proximity to the orginiating service, and failover when priorities become unhealthy.

apiVersion: networking.enterprise.mesh.gloo.solo.io/v1beta1
kind: VirtualDestination
metadata:
 name: reviews-vd
 namespace: gloo-mesh
spec:
 hostname: reviews.global
 port:
   number: 9080
   protocol: http
 localized:
   outlierDetection:
     consecutiveErrors: 1
     maxEjectionPercent: 100
     interval: 5s
     baseEjectionTime: 30s
   destinationSelectors:
   - kubeServiceMatcher:
       labels:
         app: reviews
 virtualMesh:
   name: virtual-mesh
   namespace: gloo-mesh
---
apiVersion: networking.mesh.gloo.solo.io/v1
kind: TrafficPolicy
metadata:
 name: reviews-shift-failover
 namespace: gloo-mesh
spec:
 destinationSelector:
 - kubeServiceRefs:
     services:
     - clusterName: cluster1
       name: reviews
       namespace: default
 policy:
   trafficShift:
     destinations:
     - virtualDestination:
         name: reviews-vd
         namespace: gloo-mesh

In this example, the VirtualDestination is grouping the reviews service in all clusters under the single hostname “reviews.global”. The TrafficPolicy then redirects the local reviews traffic to the global hostname. Now, when productpage on cluster1 tries to talk to reviews, it will be routed to reviews on cluster1 as expected. If that reviews service fails the health check, it will be ejected from the routing list, and new requests will start flowing to reviews in cluster2. 

You can set up your own EKS-A and Istio service mesh solution with Gloo Mesh and tackle the service-to-service communication challenges of microservices in a hybrid environment. The use cases covered in this post are just the basics. 

Try Gloo Mesh, Gloo Mesh Gateway, and Gloo Portal today! 

You can request a free trial of Gloo Mesh today here.

Join the #gloo-mesh and #gloo-portal channels in the Solo.io Slack.

See a comparison of Gloo Mesh editions and open source Istio.

Read our other blogs about how Solo works with Amazon EKS Anywhere:

Back to Blog