Service Mesh Uncharted: Google Cloud Service Mesh( aka ASM) — Part 1
This blog is the second iteration of the series “Service Mesh Uncharted”. Read the first blog of this series “Service Mesh Uncharted: HashiCorp Consul”.
The tool of the second edition is — Google Cloud Service Mesh aka Anthos Service Mesh or ASM. ASM is a relatively old tool that is refurbished with new names but still tastes like a smooth old whiskey used to with some additional flavors. Google Cloud Service Mesh is a premium managed service mesh offering under GKE Enterprise of GKE Enterprise and could be utilized for GKE Clusters, multi-cloud k8s clusters, and cloud & on-prem clusters.
This solution blog is a collaboration of Rahul Kumar Singh (Staff Cloud Infrastructure Engineer) and Rohan Singh (Senior Cloud Infrastructure Engineer and Google Cloud Champion Innovator) at SADA Systems — An Insight Company.
Google Cloud Service Mesh has three major deployment methods. This is part 1 of Google Cloud Service Mesh deployment methods. We will be following up with other methods in the upcoming blogs.
Use-Case Scenario
Applications scattered over multiple clusters part of the same fleet.
For this blog, we have used GCP’s famous Online Boutique sample application. Online Boutique Sample Application has a total of 11 microservices that have deployed or scattered b/w 2 GKE clusters registered within the same fleet. Each microservices is deployed in separate namespaces.
Six microservices are in cluster 1 where whereas the rest are in cluster 2. The reason being (assumption) cluster 1 apps belong to the data team and cluster 2 apps belong to the delivery team but all 11 microservices work together to make an application.
Why You Need a Managed Service Mesh???
Before we jump into the nitty-gritty, let’s talk about why you might want a service mesh in your GKEe setup —
- Effortless Setup and Management: No more wrestling with complex configurations. A managed service mesh takes care of installation, updates, and maintenance, freeing you to focus on building awesome features.
- Instant Observability: Get X-ray vision into your service communication. See exactly what’s happening, where the bottlenecks are, and how to optimize performance.
- Security Made Easy: Lock down your microservices with encryption, authentication, and authorization — all without cluttering your application code.
- Traffic Control: Easily route traffic, balance loads, and even run experiments like canary deployments and A/B testing.
- Resilience Built-In: Your microservices become superheroes themselves, able to handle failures with grace thanks to features like circuit breaking and retries.
Explanation
Control Plane: Manages and configures the proxies (sidecars) to route traffic. It is responsible for policy management, certificate distribution, and other administrative functions.
Data Plane: Consists of the proxies that handle the actual network traffic between services. These proxies enforce policies and collect telemetry data.
One more explanation
As the Managed Service Mesh is a GKEe feature it is enabled at FLEET-LEVEL (not on cluster level) which means no matter how many clusters your applications all of them would be under the same umbrella, and the topology view constructed by GKEe would be for overall fleet (not per cluster).
Referring to the hypothetical aforementioned use-case — when all the microservices act as a single entity to form an app (meaning, they are communicating with each other), GKEe Managed Service Mesh is smart enough to connect dots and present one single topology view.
In the case of different teams (data and delivery team in our case), applications have no communication b/w them or they are absolutely isolated, or two separate non-connected applications are deployed on the fleet but still want to leverage the same managed service mesh, GKEe Service Mesh is smart enough to identify this. We deploy Online Boutique Sample Application and Online Bookstore for this and we can see the non-connected topology.
Types of Cloud Service Mesh Deployment in GKE Enterprise
- Managed Service Mesh (Recommended)
- In-Cluster Control Plane for GKE with Istio APIs — Self-Managed Service Mesh
- Hybrid Service Mesh
This blog covers only 1 deployment method, for 2nd and 3rd there will be dedicated blogs.
Let’s Get Our Hands Dirty: Setting Up Your Service Mesh
Prerequisites
- GCP account with billing enabled.
- Google Cloud SDK installed and configured.
- A GKE cluster or a fleet of clusters ready to roll.
- Obtained the required permissions to provision Cloud Service Mesh
- Enabled Workload Identity on your clusters.
Managed Service Mesh Deployment
Enable the required APIs:
# Enable API's
gcloud services enable mesh.googleapis.com --project=${FLEET_PROJECT_ID}
# This command enables
meshconfig.googleapis.com
meshca.googleapis.com
container.googleapis.com
gkehub.googleapis.com
monitoring.googleapis.com
stackdriver.googleapis.com
opsconfigmonitoring.googleapis.com
connectgateway.googleapis.com
trafficdirector.googleapis.com
networkservices.googleapis.com
networksecurity.googleapis.comImportant Note: This setup is based on the assumption that your network and clusters are hosted in the same project as the Fleet. But this is not the case in general production scenarios so please follow this link to perform additional steps required to make things work.
Enable Service Mesh in GKEe via gcloud command. This can be done via Google UI Console also from Kubernetes Engine → Features Manager → Managed Service Mesh → Enable.
# Enable service mesh on the gke fleet
$ gcloud container fleet mesh enable --project=PROJECT_ID# Following command enables automatic management
$ gcloud container fleet mesh update --management automatic --memberships membership_name --project=PROJECT_IDOnce we have the fleet updated give it a few minutes for the updates to take effect and then run the below command
gcloud container fleet mesh describe --project FLEET_PROJECT_IDto check the status of control plane deployment and it should be ACTIVE.
The above would give output similar to the below
servicemesh:
conditions:
- code: VPCSC_GA_SUPPORTED
details: This control plane supports VPC-SC GA.
documentationLink: http://cloud.google.com/service-mesh/docs/managed/vpc-sc
severity: INFO
controlPlaneManagement:
details:
- code: REVISION_READY
details: 'Ready: asm-managed'
implementation: ISTIOD
state: ACTIVE
dataPlaneManagement:
details:
- code: OK
details: Service is running.
state: ACTIVE
state:
code: OK
description: |-
Revision ready for use: asm-managed.
All Canonical Services have been reconciled successfully.
updateTime: '2024-06-10T20:33:24.762357773Z'
...Now that the Control Plane is in an ACTIVE state let's move on to managed Data Plane. GCP takes care of the responsibility of activating and configuring the Data Plane per se after Control Plane enablement.
Once you start working with managed Cloud Service Mesh the headache of proxy upgrade becomes Google's responsibility unless you disable it at the namespace, workload, or revision level.
With the managed data plane, the sidecar proxies and injected gateways are automatically updated in conjunction with the managed control plane by restarting workloads to re-inject new versions of the proxy. This is normally completed in 1–2 weeks after the managed control plane is upgraded. If you want you can disable the Data Plane management as well at the namespace, workload, or revision level using the commands here.
We are done with the Managed Service Mesh Deployment method.
Application Deployment
Before deployment, enabling automatic sidecar injection is mandatory. Cloud Service Mesh automatically injects a sidecar proxy into workload Pods when it detects a specific namespace label. This proxy acts as an intermediary, intercepting and managing all incoming and outgoing traffic for the workloads, facilitating communication with the broader Cloud Service Mesh infrastructure.
Run to apply the default injection labels to the namespace —
# Enable auto-injection for labels in the application namespace
kubectl label namespace ${NAMESPACE} istio-injection=enabled istio.io/rev- \
--overwriteAfter labeling the namespace(s), you can deploy deployments, services, and serviceEntries.
Why Use ServiceEntries?
In Istio, by default, all traffic is assumed to be internal to the mesh. To enable controlled access to external services, you need to define them using ServiceEntries explicitly. This gives fine-grained control over which external services applications can talk to, how they can do so, and also centralizes management.
Here is the ServiceEntry that we have deployed for allowing egress traffic to Google APIs and the metadata server in your Kubernetes cluster.
If applications already exist in the namespace and you inject sidecar labels in the namespace, in such cases, restarting the deployments is required only. Run to do so —
# Perform a rollout for application deployments
kubectl rollout restart deployment -n ${NAMESPACE}The below screenshot presents the topology view of the Online Boutique Sample Application after deployment in two different GKE Clusters.
Clicking on icons in the topology view provides more information about the services in the service mesh like connections, traffic directions, Req/Sec, errors, latency, etc. Navigate to the service dashboard from the list view to get detailed information.
Below is the distribution of the Online Boutique Sample Applications on 2 different clusters.
That’s it for part 1. Parts 2 and 3 will be arriving soon. Read the first edition of “Service Mesh Uncharted: HashiCorp Consul”.
Might subscribe to my medium to get updates.
Read my other tech blogs
Read Rohan’s tech blogs
Connect with us on LinkedIn: Rahul Kumar Singh and Rohan Singh
