Service Mesh Uncharted: Google Cloud Service Mesh( aka ASM) — Part 2

This article is part 2 of Google Cloud Service Mesh (aka ASM) where I have covered Managed Service Mesh deployment along with the explanation and in this one the coverage is on Self-Managed Service Mesh deployment or In-Cluster Control Plane for GKE with Istio APIs.

All the theories, architectural explanations,s, and major pointers are already mentioned in Part 1 hence those are re-written here. I suggest reading Part 1 if you are new to Service Mesh.

Read all the articles of the Service Mesh Uncharted series.

Rahul Kumar Singh

Service Mesh Uncharted Series

View list

2 stories

Use Case Scenario is the same as Part 1, using GCP’s famous Online Boutique sample application.

In-Cluster Control Plane for GKE with Istio APIs — Self-Managed Service Mesh

What’s the Deal?

You’re in control of both the control plane and the data plane.

Why You’ll Love It?

Full control over configuration and customization. Ideal for those with specific needs and a knack for DIY

In-cluster Cloud Service Mesh deployment

When working with in-cluster cloud service mesh deployment we need to take care of the following factors:

1. Choose a Certificate Authority: Based on the use case, you can choose any of the three available options: Cloud Service Mesh CA, CA Service, and Istio CA. This is a mandatory and straightforward step — visit this link.
2. Manage Gateway Configurations: As this is an In-Cluster deployment we would be using asmclito deploy most of the components in the cluster and asmclidoesn’t install the istio gateway. Hence Google recommends deploying and managing the control plane and gateway separately.

ASM Architecture with In-Cluster Gateway Deployment. Credit Google Cloud YouTube

As this is a self-managed deployment this can be deployed on non-GCP clusters like EKS. Keep in mind the non-GCP cluster should be part of the GKE cluster Fleet as no integrated service mesh option in the non-GCP cluster will give you this feature.

Implementations

Beginning with downloading asmcli , making it executable, validating it with the kubeconfig file for your fleet. Once we have the asmcli installed and fleet validated we will install Gateway on the cluster. Once all the gateway and asmcli are in place we will have to inject the namespace with labels for the gateway to understand all the apps that should be part of the cluster.

Download asmcli

$ curl https://storage.googleapis.com/csm-artifacts/asm/asmcli_1.20 > asmcli
$ chmod +x asmcli

Validate the Project and Cluster using the asmclito make sure they are set up as required by Cloud Service Mesh.

$ ./asmcli validate \
 --kubeconfig KUBECONFIG_FILE \
 --fleet_id fleet_id \
 --output_dir DIR_PATH \
 --platform multicloud

Install Anthos Service Mesh manually:

$ ./asmcli install \
 --fleet_id rohan-orbit \
 --kubeconfig KUBECONFIG_FILE \
 --output_dir DIR_PATH \
 --platform multicloud \
 --enable_all \
 --ca mesh_ca

You will have to install some default features and CA service. Please use the link here to do so.

Install Gateway

Cloud Service Mesh gives you the option to deploy and manage gateways as part of your service mesh. A gateway describes a load balancer operating at the edge of the mesh receiving incoming or outgoing HTTP/TCP connections. Gateways are Envoy proxies that provide you with fine-grained control over traffic entering and leaving the mesh.

# Create the Gateway namespace
$ kubectl create namespace GATEWAY_NAMESPACE

# Default Injection labels. You can ignore the "istio.io/rev" not found in the output as that just means its the first you are creating the label in that namespace
$ kubectl label namespace GATEWAY_NAMESPACE istio-injection=enabled istio.io/rev-

# Apply the gateway, you can get the gateway.yaml from (https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages/tree/release-1.20/samples/gateways/istio-ingressgateway)
$ kubectl apply -n GATEWAY_NAMESPACE \
-f CONFIG_PATH/istio-ingressgateway

Note: Make sure your cluster(s) has enough resources to support the Gateway Installation. Based on my experience I would recommend having maximum of 4GB of memory and 2vCPUs as part of your cluster resource calculations for smoth functioning of Gateway in your cluster.

Application Deployment

You are all set now. Let’s deploy or redeploy the application:

# Enable auto-injection for labels in the application namespace
$ kubectl label namespace NAMESPACE istio-injection=enabled istio.io/rev-

# Perform a rollout of application deployments
$ kubectl rollout restart deployment -n NAMESPACE

Once you are done all of your services will be visible in the topology view in the GCP console.

Topology View

That's how it's being done!!!

Enable optional features on an in-cluster control plane

In-cluster control plan-supported features

Plan an upgrade

Migrate from Istio 1.11 or later to Cloud Service Mesh

Cloud Service Mesh security overview

Might subscribe to my medium to get updates.

Read Part 1 of Google Cloud Service Mesh

Service Mesh Uncharted: Google Cloud Service Mesh( aka ASM) — Part 1

Read all the articles of the Service Mesh Uncharted series

Rahul Kumar Singh

Service Mesh Uncharted Series

View list

2 stories

Read my other technical blogs

Rahul Kumar Singh - Medium