Getting started with Anthos Service Mesh for GKE

Istio on Google Kubernetes Engine (GKE) was deprecated at the end of 2021 and by the end of September 2022, it was no longer supported on GKE. It has now been replaced by Anthos Service Mesh (ASM), which is Google’s fully supported flavor of Istio. ASM is compatible with (and uses) Istio APIs. With ASM, you also get the added bonus of integration with Google Cloud features like Logging, Tracing, Mesh CA, Identity-Aware Proxy (IAP) and many more! In this article, I am going to show you how to get started with ASM on GKE as a standalone service, which does not need a Anthos subscription.

Requirements

You will need to enable the following APIs:

• GKE Hub API
• Mesh Configuration API
• Anthos Service Mesh Certificate Authority API

You will also need to enable Workload Identity on your GKE cluster and register your cluster as a fleet as it is a managed service. Fleets are just Google’s way of logically organizing clusters.

gcloud container fleet mesh enable --project ${PROJECT_ID}

gcloud container fleet membership register ${GKE_CLUSTER_NAME}-membership 
  --gke-cluster=${GKE_LOCATION}/${GKE_CLUSTER_NAME} 
  --enable-workload-identity 
  --project ${PROJECT_ID}

gcloud container fleet mesh update 
  --management automatic 
  --memberships ${GKE_CLUSTER_NAME}-membership 
  --project ${PROJECT_ID}

After the last command, it will take ~5–10 min for the ASM to provision, so be patient. You can check the status with gcloud container fleet mesh describe –project ${PROJECT_ID} and you will know it is ready when you see an output resembling the following (make note of the revision name as you will need that later):

...
...
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed-rapid'
        state: ACTIVE
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: |-
        Revision(s) ready for use: asm-managed-rapid.
...
...

Deploying ingress gateway

Next is deploying an ingress gateway, which is just a load balancer but also an Envoy proxy. It is Envoy’s capabilities that we will be leveraging later on for fine-grained control over our traffic. Because the ingress gateway is also just an Envoy proxy, it needs to be deployed and so we will create a namespace to house it. I am going to call mine asm-gateway:

kubectl create namespace asm-gateway

Auto-injection

If you have used Istio in the past, the automatic side car injection is typically done via setting the istio-injection=enabled label on the namespace you wish the sidecar to be injected in. In this example, we will be doing something a little different: we will use a revision label instead. The revision label is the version of the ASM that Google manages for you. One of the benefits of this approach is that Google will manage the upgrades of the proxies and restarts your workload for you (either of which you can choose to opt out of). The ASM release version is tied with your GKE’s release channel. Here, you can see that I am using the rapid channel:

kubectl label namespace asm-gateway istio.io/rev=asm-managed-rapid

Deploy the ingress gateway in the asm-gateway namespace by applying the manifest below:

kubectl apply -f istio-ingressgateway.yaml -n asm-gateway

https://medium.com/media/5a64c43bce7a792caea98d23a4505b4e/href

NOTE: the original deployment manifests can be found here.

Sample application

We will be deploying the bookinfo app from Istio. I recommend starting with this to get your feet wet, but if you want to explore more of ASM’s features, I suggest deploying a sample app with more microservices, such as Google’s online boutique app. I chose the bookinfo application because it is a lightweight deployment (I can deploy on a single 2vCPU, 8GB memory node rather than requiring 3 nodes for the online boutique).

Steps to deploy the bookinfo app is identical to the deployment of the ingress gateway:

kubectl create namespace bookinfo
kubectl label namespace bookinfo istio.io/rev=asm-managed-rapid

kubectl apply -f https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/platform/kube/bookinfo.yaml -n bookinfo

Exposing the application

To expose our application, we will deploy a Gateway and VirtualService for our frontend:

https://medium.com/media/66c4444402633b45c0d75c85860a0063/href

Noteworthy Istio configurations

In this section, I will describe some of the more common Istio configurations that you will likely encounter and use.

VirtualService

VirtualService is very much like your tradition ingress resource where you perform traffic matching and direct the traffic to the appropriate service. You can do content-based matching based on the HTTP headers. If you wish to implement traffic splitting, this is also defined here in the VirtualService configuration (in conjunction with a DestinationRule subset). It can even perform rewrites!

One of the more interesting features is that VirtualService can allow you to add fault injection and network delay injection. This is very useful if you want to test the resiliency of your app and services against failures and network latency issues.

DestinationRule

DestinationRule are policies that apply to traffic after the routing has been determined. Here, you can tune your load balancer, connection pools, and configure circuit breakers.

ServiceEntry

Istio can only make service requests to destinations that are within the GKE cluster — that is to say it is unable to egress outside of the cluster. So what if your services need to access Google APIs, Facebook, or GitHub? To get around this, you need a ServiceEntry configuration. It is an egress allowlist of sorts.

AuthorizationPolicy

AuthorizationPolicy is what enables you to specify ingress access control rules. You can allow or deny traffic based on (but not limited to) service accounts, namespaces, actions (GET, POST, etc.), paths, CIDRs, etc.

PeerAuthentication

By default, mTLS operates in PERMISSIVE mode, which allows both plaintext and mTLS. You can change this behavior by creating a PeerAuthentication configuration to set the mode to STRICT, which allows only mTLS connections.

Summary

Anthos Service Mesh is a managed, fully supported flavor of Istio. It is compatible with Istio APIs and uses the same building blocks as open source Istio. Learning ASM on GKE will help you in understanding and navigating the world of service meshes as more and more enterprises move towards multi-cloud.

The example I described above can also be found in my Free Tier GKE GitHub repo along with other examples to help guide you in your Kubernetes journey.

Getting started with Anthos Service Mesh for GKE was originally published in Google Developer Experts on Medium, where people are continuing the conversation by highlighting and responding to this story.