Use cases for Amazon EKS Anywhere (EKS-A) with Gloo Mesh, an enhanced Istio service mesh
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:
