Getting started with Amazon EKS Anywhere and Istio service mesh

How long does it take to getting started with Amazon EKS Anywhere, Istio, and Gloo Mesh?  Assuming you already have the Kubernetes clusters, it will take you 15 minutes to configure secure and seamless global failover of your services from EKS Anywhere (EKS-A) to traditional EKS in the AWS cloud.

Pre-requisites

1. An EKS-A cluster, which you can deploy using the eksctl anywhere CLI on your desktop machine or VMware vSphere environment.

eksctl anywhere create cluster -f eks-a-cluster1.yaml

2. EKS Clusters. You can deploy 2 EKS clusters using the eksctl CLI, for example:

eksctl create cluster --name gm-mgmt --region=us-east-1
eksctl create cluster --name cluster2 --region=us-east-1

3. Configure cluster context environment variables for these 3 clusters:

export MGMT=gm-mgmt
export CLUSTER1=cluster1
export CLUSTER2=cluster2

4. Export your GLOO_MESH_LICENSE_KEY. If you don’t have one, you can get a free trial license by contacting Solo.io.

export GLOO_MESH_LICENSE_KEY=$REPLACE_WITH_KEY_VALUE

You’ll deploy Istio, Gloo Mesh, and the famous “book info” app to our clusters on EKS Anywhere and EKS.  You’ll try a failover of reviews service seamlessly from EKS Anywhere in your corporate data center to EKS in AWS cloud as the diagram shows:

Let’s get started!

Install Istio

Download Istio:

export ISTIO_VERSION=1.10.3
curl -L https://istio.io/downloadIstio | sh -

Install Istio on cluster1 running on EKS Anywhere and on cluster2 running on EKS:

./istio-1.10.3/bin/istioctl --context ${CLUSTER1} install -f https://raw.githubusercontent.com/linsun/istio-yamls/main/gm-eks/cluster1.yaml
./istio-1.10.3/bin/istioctl --context ${CLUSTER2} install -f https://raw.githubusercontent.com/linsun/istio-yamls/main/gm-eks/cluster2.yaml

A couple of installation notes:

• In cluster1.yaml, you configured Istio ingress gateway to run on type: NodePort because we don’t have a load balancer deployed in our EKS Anywhere cluster. Change the service type to type: LoadBalancer if needed.
• In cluster2.yaml, you had the 15021 status port as the first port in the Istio ingress gateway service. This is on purpose because the AWS ELB by default performs health check on the first port.

Enable mutual TLS on both clusters to only allow mutual TLS traffic for services in the mesh:

kubectl --context ${CLUSTER1} apply -f https://raw.githubusercontent.com/linsun/istio-yamls/main/gm-eks/mtls.yaml
kubectl --context ${CLUSTER2} apply -f https://raw.githubusercontent.com/linsun/istio-yamls/main/gm-eks/mtls.yaml

Install Gloo Mesh Enterprise

First, install the meshctl CLI:

curl -sL https://run.solo.io/meshctl/install | GLOO_MESH_VERSION=v1.1.0 sh -
export PATH=$HOME/.gloo-mesh/bin:$PATH

Second, run the following commands to deploy Gloo Mesh Enterprise:

helm repo add gloo-mesh-enterprise https://storage.googleapis.com/gloo-mesh-enterprise/gloo-mesh-enterprise
helm repo update
kubectl --context ${MGMT} create ns gloo-mesh
helm install gloo-mesh-enterprise gloo-mesh-enterprise/gloo-mesh-enterprise \
--namespace gloo-mesh --kube-context ${MGMT} \
--version=1.1.1 \
--set licenseKey=${GLOO_MESH_LICENSE_KEY}
kubectl --context ${MGMT} -n gloo-mesh rollout status deploy/enterprise-networking

Third, you need to register the cluster1 and cluster2:

SVC=$(kubectl --context ${MGMT} -n gloo-mesh get svc enterprise-networking -o jsonpath='{.status.loadBalancer.ingress[0].*}')
meshctl cluster register --mgmt-context=${MGMT} --remote-context=${CLUSTER1} --relay-server-address=$SVC:9900 enterprise cluster1 --cluster-domain cluster.local
meshctl cluster register --mgmt-context=${MGMT} --remote-context=${CLUSTER2} --relay-server-address=$SVC:9900 enterprise cluster2 --cluster-domain cluster.local

Check the status of the server with the meshctl check server command, you should be able to confirm that Gloo Mesh is installed successfully with agents from cluster1 and cluster2 connected to the management cluster.

Create a virtual mesh for cluster1 and cluster2

The Istio CA’s signing certificates are different in the cluster1 and cluster2. Creating a Virtual Mesh can help you easily reconfigure Istiod on both clusters with a common root identity so the services across clusters can communicate with each other securely using mTLS with the passthrough gateways. Run the following command to create the Virtual Mesh:

cat << EOF | kubectl --context ${MGMT} apply -f -
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
EOF

You can describe your virtualmesh resource and check its status, you should see a bunch of ACCEPTED status:

kubectl describe virtualmesh -n gloo-mesh

Global traffic failover from EKS Anywhere to EKS

Deploy productpage, details, reviews v1 & v2, ratings services and the productpage gateway resource on cluster1. Deploy reviews v3 and ratings services on cluster2:

kubectl --context ${CLUSTER1} label namespace default istio-injection=enabled
kubectl --context ${CLUSTER1} apply -f https://raw.githubusercontent.com/linsun/istio-yamls/main/gm-eks/bookinfo-cluster1.yaml
kubectl --context ${CLUSTER2} label namespace default istio-injection=enabled
kubectl --context ${CLUSTER2} apply -f https://raw.githubusercontent.com/linsun/istio-yamls/main/gm-eks/bookinfo-cluster2.yaml

Apply the virtual destination custom resource for the global review service on the management cluster:

cat << EOF | kubectl --context ${MGMT} apply -f -
apiVersion: networking.enterprise.mesh.gloo.solo.io/v1beta1
kind: VirtualDestination
metadata:
 name: reviews-global
 namespace: gloo-mesh
spec:
 hostname: reviews.global
 port:
   number: 9080
   protocol: http
 localized:
   outlierDetection:
     consecutiveErrors: 1
     maxEjectionPercent: 100
     interval: 5s
     baseEjectionTime: 120s
   destinationSelectors:
   - kubeServiceMatcher:
       labels:
         app: reviews
 virtualMesh:
   name: virtual-mesh
   namespace: gloo-mesh
EOF

Apply the traffic policy on the managemnt cluster to use the global review virtual destination you just created:

cat << EOF | kubectl --context ${MGMT} apply -f -
apiVersion: networking.mesh.gloo.solo.io/v1
kind: TrafficPolicy
metadata:
 name: reviews-shift-failover
 namespace: default
spec:
 sourceSelector:
 - kubeWorkloadMatcher:
     namespaces:
     - default
 destinationSelector:
 - kubeServiceRefs:
     services:
       - clusterName: cluster1
         name: reviews
         namespace: default
 policy:
   trafficShift:
     destinations:
       - virtualDestination:
           name: reviews-global
           namespace: gloo-mesh
EOF

Visit the bookinfo application via the Istio ingress gateway on cluster1 a few times to confirm that you will only see reviews v1 and v2. This is because you have programmed Gloo Mesh and Istio to use the reviews service in the local cluster when they are healthy.

kubectl --context ${CLUSTER1} port-forward deploy/istio-ingressgateway -n istio-system 8080
open http://localhost:8080/productpage

Scale down reviews v1 & v2 in cluster1 to simulate a failover scenario:

kubectl scale deploy reviews-v1 --replicas=0 --context $CLUSTER1
kubectl scale deploy reviews-v2 --replicas=0 --context $CLUSTER1

Visit the bookinfo application again to confirm you will see review v3 seamlessly:

When the reviews v1 and v2 service deployments fail in cluster1, the productpage service in cluster1 is automatically routed to the reviews v3 service in cluster2 automatically without any manual intervention.

Visit Gloo Mesh UI and navigate to Graph, you should be able to view the service communication graph among 2 clusters:

kubectl --context ${MGMT} port-forward -n gloo-mesh svc/dashboard 8090
open http://localhost:8090/graph/?virtual_mesh=gloo-mesh.virtual-mesh

Wrapping Up

We hope this gets you excited about how easy it is getting started with EKS Anywhere and Istio using Gloo Mesh! If you are looking to increase service resiliency of your services across different clusters and different clouds with zero trust security model, join us in our upcoming Istio or Gloo Mesh workshops to learn more about how Istio and Gloo Mesh can help you to easily increase resiliency or security or observability of your services regardless of where you are running your services in your hybrid cloud environment.