Provision Cloud Service Mesh on a GKE Autopilot cluster

Set up your environment

You can set up your environment using the gcloud CLI or Terraform.

gcloud config set project PROJECT_ID
GOOGLE_CLOUD_PROJECT=$(gcloud config get-value project)
export GOOGLE_CLOUD_PROJECT

Create a GKE cluster

Create a GKE cluster in Autopilot mode.

resource "google_container_cluster" "cluster" {
  name                = "asm-cluster"
  location            = var.region
  deletion_protection = false # Warning: Do not set deletion_protection to false for production clusters

  enable_autopilot = true
  fleet {
    project = data.google_project.project.name
  }
}

data "google_project" "project" {}

Provision managed Cloud Service Mesh

You provision managed Cloud Service Mesh using the servicemesh feature on the fleet membership for your cluster.

resource "google_project_service" "mesh_api" {
  service = "mesh.googleapis.com"

  disable_dependent_services = true
}

resource "google_gke_hub_feature" "feature" {
  name     = "servicemesh"
  location = "global"

  depends_on = [
    google_project_service.mesh_api
  ]
}

resource "google_gke_hub_feature_membership" "feature_member" {
  location   = "global"
  feature    = google_gke_hub_feature.feature.name
  membership = google_container_cluster.cluster.fleet.0.membership
  membership_location = google_container_cluster.cluster.location
  mesh {
    management = "MANAGEMENT_AUTOMATIC"
  }
}

Verify the control plane is active

Wait until the controlPlaneManagement.state is ACTIVE. This might take up to 15 minutes.

watch -n 30 gcloud container fleet mesh describe

The output is similar to:

membershipSpecs:
  projects/746296320118/locations/us-central1/memberships/asm-cluster:
    mesh:
      management: MANAGEMENT_AUTOMATIC
membershipStates:
  projects/746296320118/locations/us-central1/memberships/asm-cluster:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        state: ACTIVE
      dataPlaneManagement:
        details:
        - code: PROVISIONING
          details: Service is provisioning.
        state: PROVISIONING
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'

The dataPlaneManagement section remains in the PROVISIONING state until you deploy the ingress gateway, because Autopilot clusters don't provision any nodes until you deploy a workload.

Deploy a mesh ingress gateway

In this section, you deploy a mesh ingress gateway to handle incoming traffic for the sample application. An ingress gateway is a load balancer operating at the edge of the mesh, receiving incoming or outgoing HTTP/TCP connections.

You deploy the gateway to a dedicated namespace and label the deployment to ensure that your gateway can be securely managed and automatically upgraded by the Cloud Service Mesh control plane.

1. Download credentials so that you can access the cluster:

   gcloud container clusters get-credentials asm-cluster --location=us-central1
   

2. Create a namespace for the gateway deployment:

   kubectl create namespace bank-gateways
   

3. Add a label to the namespace so that the Cloud Service Mesh control plane automatically injects the gateway configuration into the deployment.

   kubectl label namespace bank-gateways istio-injection=enabled
   

4. Deploy the ingress gateway to the namespace:

   Helm

   helm repo add istio https://istio-release.storage.googleapis.com/charts
   helm repo update
   helm install --wait --namespace bank-gateways \
       --set resources.requests.cpu=250m \
       --set resources.requests.memory=512Mi \
       --set resources.requests.ephemeral-storage=1Gi \
       --set resources.limits.cpu=250m \
       --set resources.limits.memory=512Mi \
       --set resources.limits.ephemeral-storage=1Gi \
       istio-ingressgateway istio/gateway
   

   kubectl

   kubectl apply -n bank-gateways \
       -k https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages/tree/main/samples/gateways/istio-ingressgateway
   kubectl -n bank-gateways wait "deployment/istio-ingressgateway"  \
       --for=condition=available --timeout=240s
   

   Ensure that you set adequate resource requests when you deploy to a production environment. GKE Autopilot only considers resource values set in requests and not limits. The Istio project publishes information on performance and scalability.

Deploy the sample application

1. Create a Kubernetes namespace for the deployment:

   kubectl create namespace bank-sample
   

2. Add a label to the namespace so that Cloud Service Mesh automatically injects sidecar proxies into the sample Pods:

   kubectl label namespace bank-sample istio-injection=enabled
   

3. Deploy the sample application:

   git clone https://github.com/GoogleCloudPlatform/bank-of-anthos.git
   kubectl apply -n bank-sample -f bank-of-anthos/extras/jwt/jwt-secret.yaml
   kubectl apply -n bank-sample -f bank-of-anthos/kubernetes-manifests/
   

4. Wait for the application to be ready. It will take several minutes.

   watch kubectl -n bank-sample get pods
   

   When the application is ready, the output is similar to the following:

   NAME                                 READY   STATUS    RESTARTS   AGE
   accounts-db-0                        2/2     Running   0          2m16s
   balancereader-5c695f78f5-x4wlz       2/2     Running   0          3m8s
   contacts-557fc79c5-5d7fg             2/2     Running   0          3m7s
   frontend-7dd589c5d7-b4cgq            2/2     Running   0          3m7s
   ledger-db-0                          2/2     Running   0          3m6s
   ledgerwriter-6497f5cf9b-25c6x        2/2     Running   0          3m5s
   loadgenerator-57f6896fd6-lx5df       2/2     Running   0          3m5s
   transactionhistory-6c498965f-tl2sk   2/2     Running   0          3m4s
   userservice-95f44b65b-mlk2p          2/2     Running   0          3m4s
   

5. Create Istio Gateway and VirtualService resources to expose the application behind the ingress gateway:

   kubectl apply -n bank-sample -f bank-of-anthos/extras/istio/frontend-ingress.yaml
   

6. Get a link to the sample application:

   INGRESS_HOST=$(kubectl -n bank-gateways get service istio-ingressgateway \
       -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
   echo "http://$INGRESS_HOST"
   

7. In a browser, follow the link to open the sample application. Login with the default username and password to view the application.

Enforce mutual TLS

Make sure that STRICT mutual TLS (mTLS) mode is enabled. Apply a default PeerAuthentication policy for the mesh in the istio-system namespace.

1. Save the following manifest as mesh-peer-authn.yaml:

   apiVersion: "security.istio.io/v1beta1"
   kind: "PeerAuthentication"
   metadata:
     name: "default"
     namespace: "istio-system"
   spec:
     mtls:
       mode: STRICT
   

2. Apply the manifest to the cluster:

   kubectl apply -f mesh-peer-authn.yaml
   

You can override this configuration by creating PeerAuthentication resources in specific namespaces.

Explore the Cloud Service Mesh dashboards

1. In Google Cloud console, go to Cloud Service Mesh to view the dashboards for your mesh:

   Go to Cloud Service Mesh

2. Select the project from the drop-down list on the menu bar.

   You see an overview table with all of the microservices in your mesh and a graphical visualization of the connections between the microservices. For each microservice, the table shows three of the SRE "golden signals":

   • Traffic - requests per second
   • Error rate - a percentage
   • Latency - milliseconds

   These metrics are based on the actual traffic being handled by the microservices. Constant test traffic is automatically sent to the frontend service by a loadgenerator client deployed as part of the sample application. Cloud Service Mesh automatically sends metrics, logs, and (optionally) traces to Google Cloud Observability.

3. Click the frontend service in the table to see an overview dashboard for the service. You see additional metrics for the service and a visualization of inbound and outbound connections. You can also create a Service Level Object (SLO) for monitoring and alerting on the service.

Verify that mTLS is enabled

Click the security link in the panel to see a security overview for the frontend service. The table and the visualization show a green lock icon for each of the inbound and outbound connections between microservices. This icon indicates that the connection is using mTLS for authentication and encryption.