Install and Manage Anthos Service Mesh on GKE (2026)

Anthos Service Mesh is Google Cloud’s managed Istio offering, designed to simplify the deployment and operation of a service mesh on Google Kubernetes Engine (GKE). It provides a robust platform for traffic management, security, and observability across your microservices.

Let’s see Anthos Service Mesh in action. Imagine you have a microservices application deployed on GKE. Without a service mesh, managing communication, enforcing policies, and observing behavior between these services can become a complex undertaking.

Here’s a simplified view of a GKE cluster with Anthos Service Mesh installed:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: my-gateway
spec:
  selector:
    istio: ingressgateway # use istio-ingressgateway pods
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-service-vs
spec:
  hosts:
  - my-service.default.svc.cluster.local
  gateways:
  - my-gateway
  http:
  - match:
    - uri:
        prefix: /api
    route:
    - destination:
        host: my-service.default.svc.cluster.local
        subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-service-dr
spec:
  host: my-service.default.svc.cluster.local
  subsets:
  - name: v1
    labels:
      version: v1

In this example:

The Gateway resource defines the entry point for traffic into the mesh, in this case, listening on port 80.
The VirtualService routes incoming HTTP requests with a /api prefix to a specific version (v1) of my-service.
The DestinationRule defines how traffic is routed to different versions of a service, allowing for fine-grained control and canary deployments.

The Problem Anthos Service Mesh Solves:

As your microservice architecture grows, you face challenges like:

Complex Network Configuration: Manually configuring load balancers, service discovery, and inter-service communication becomes unwieldy.
Inconsistent Security: Enforcing TLS, authorization policies, and identity across services is difficult to maintain uniformly.
Lack of Observability: Understanding request flows, latency, and error rates across distributed services requires dedicated tooling.
Deployment Complexity: Rolling out new versions with zero downtime, performing A/B testing, or implementing fault injection for testing is hard.

Anthos Service Mesh addresses these by introducing a "service mesh" – a dedicated infrastructure layer for handling service-to-service communication. It works by injecting a proxy (Envoy) alongside each of your application’s microservices. These proxies intercept all network traffic, allowing the control plane to manage, secure, and observe it.

How it Works Internally:

Data Plane: The data plane consists of the Envoy proxies. When you install Anthos Service Mesh, it automatically injects these proxies as sidecars into your application pods. All inbound and outbound traffic for your microservice is then routed through its corresponding Envoy proxy.
Control Plane: The control plane (managed by Google Cloud in Anthos Service Mesh) configures and coordinates the Envoy proxies. It pushes down routing rules, security policies, and collects telemetry data. Key components include:
- Istiod: The central control plane component that manages configuration, certificate issuance, and service discovery.
- Ingress Gateway: An Envoy proxy deployed as a Kubernetes Deployment and Service that acts as the entry point for external traffic into the mesh.
- Egress Gateway (Optional): Similar to the ingress gateway, but for controlling and observing outbound traffic from the mesh.

Key Levers for Control:

Traffic Management: You define VirtualService and DestinationRule resources to control how traffic is routed. This includes weighted routing for canary deployments, request routing based on headers, and fault injection.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: productpage-vs
spec:
  hosts:
  - productpage.default.svc.cluster.local
  http:
  - route:
    - destination:
        host: productpage.default.svc.cluster.local
        subset: v1
      weight: 90
    - destination:
        host: productpage.default.svc.cluster.local
        subset: v2
      weight: 10

This configuration sends 90% of traffic to v1 and 10% to v2 of the productpage service.

Security: You use AuthorizationPolicy resources to define access control rules. Anthos Service Mesh automatically handles mTLS encryption between services within the mesh, and you can enforce policies based on service identity.
```
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  action: DENY
  rules:
  - {}
```
This policy, if applied to a namespace, would deny all traffic by default. You would then create explicit ALLOW policies for services that need to communicate.
Observability: Anthos Service Mesh integrates with Google Cloud’s operations suite (formerly Stackdriver) to provide metrics, logs, and traces for all traffic flowing through the mesh. You can visualize service dependencies, latency, and error rates in the Google Cloud Console.

When you enable automatic sidecar injection for a namespace, Anthos Service Mesh will automatically detect new pods being created and inject the Envoy proxy container into them. This happens via a mutating webhook that intercepts pod creation requests and modifies the pod spec to include the sidecar.

The most surprising true thing about managing Anthos Service Mesh is that the core of its power lies not in complex custom Kubernetes resources, but in the sophisticated configuration and automation of the Envoy proxies. You’re essentially orchestrating a fleet of highly capable network proxies, and the Istio CRDs are just the user-friendly interface to that orchestration. This means that understanding Envoy’s capabilities can unlock deeper insights and more advanced mesh configurations, even if you’re primarily using Istio’s abstractions.

The next step in mastering Anthos Service Mesh is exploring advanced traffic routing patterns like fault injection and circuit breaking.