Cloud Service Mesh and Traffic Director are now Cloud Service Mesh. For more information, see the Cloud Service Mesh overview.

In-cluster Cloud Service Mesh prerequisites

This page describes the prerequisites and the requirements for installing in-cluster Cloud Service Mesh for Kubernetes workloads off Google Cloud, such as GKE Enterprise licensing, cluster requirements, fleet requirements, and general requirements.

Cloud project

Before you begin:

Select or create a Google Cloud project.
Verify that billing is enabled for your project.

GKE Enterprise licensing

To install Cloud Service Mesh on-premises, on GKE on AWS, on Amazon EKS, on GKE on Azure, or on Microsoft AKS, you have to be an GKE Enterprise customer. GKE Enterprise customers are not billed separately for Cloud Service Mesh because it is already included in the GKE Enterprise pricing. For more information, see the GKE Enterprise Pricing guide.

General requirements

To be included in the service mesh, service ports must be named, and the name must include the port's protocol in the following syntax: name: protocol[-suffix] where the square brackets indicate an optional suffix that must start with a dash. For more information, see Naming service ports.
If you have created a service perimeter in your organization, you might need to add the Cloud Service Mesh certificate authority service to the perimeter. See Adding Cloud Service Mesh certificate authority to a service perimeter for more information.
If you want to change the default resource limits for the istio-proxy sidecar container, the new values must be greater than the default values to avoid out-of-memory (OOM) events.
A Google Cloud project can only have one mesh associated with it.

Cluster requirements

Ensure that the user cluster that you install Cloud Service Mesh on has at least 4 vCPUs, 15 GB memory, and 4 nodes.
Verify that your cluster version is listed in Supported platforms.
Ensure that the client machine that you install Cloud Service Mesh from has network connectivity to the API server.
If you are deploying sidecars in application pods where direct connectivity to CA services (such as meshca.googleapis.com and privateca.googleapis.com) is not available, you must configure an explicit CONNECT-based HTTPS proxy.
For public clusters with egress firewall rules set that are blocking implied rules, ensure you have configured HTTP/HTTPS and DNS rules to reach public Google APIs.

Fleet requirements

All clusters must be registered to a fleet, and fleet workload identity must be enabled. You can either setup up the clusters yourself, or you can let asmcli register the clusters as long as they meet the following requirements:

GKE clusters outside Google Cloud: (applies to in-cluster Cloud Service Mesh) Google Distributed Cloud (software only) for VMware, Google Distributed Cloud (software only) for bare metal, GKE on AWS, and GKE on Azure are automatically registered to your project fleet at cluster creation time. As of GKE Enterprise 1.8, all these cluster types automatically enable fleet Workload Identity when registered. Existing registered clusters are updated to use fleet Workload Identity when they are upgraded to GKE Enterprise 1.8.
Amazon EKS clusters: (applies to in-cluster Cloud Service Mesh) The cluster must have a public IAM OIDC Identity Provider. Follow the instructions in Create an IAM OIDC provider for your cluster to check if a provider exists, and create a provider if necessary.

When you run asmcli install, you specify the project ID of the fleet host project. asmcli registers the cluster if it isn't already registered.