Plan an installation

Note: This guide only supports Cloud Service Mesh with Istio APIs and does not support Google Cloud APIs. For more information see, Cloud Service Mesh overview.

This page provides information to help you plan a new installation of in-cluster Cloud Service Mesh for Kubernetes workloads off Google Cloud.

Note: If you need to install Cloud Service Mesh from a private or custom container registry, see Install Cloud Service Mesh from a custom container registry.

Customize the control plane

The features that Cloud Service Mesh supports differ between platforms. We recommend that you review the Supported features to learn which features are supported on your platform. Some features are enabled by default, and others you can optionally enable by creating an IstioOperator overlay file. When you run asmcli install, you can customize the control plane by specifying the --custom_overlay option with the overlay file. As a best practice, we recommend that you save the overlay files in your version control system.

The asmcli directory in GitHub contains many overlay files. These files contain common customizations to the default configuration. You can use these files as they are, or you can make additional changes to them as needed. Some of the files are required to enable optional Cloud Service Mesh features. The anthos-service-mesh package is downloaded when you run asmcli to validate your project and cluster.

When you install Cloud Service Mesh using asmcli install, you can specify one or more overlay files with the --option or --custom_overlay. If you don't need to make any changes to the files in the anthos-service-mesh repository, you can use --option, and the script fetches the file from GitHub for you. Otherwise, you can make changes to the overlay file, and then use the --custom_overlay option to pass it to the asmcli.

Choose a Certificate Authority

Depending on your use case and platform, you can choose one of the following as the certificate authority (CA) for issuing mutual TLS (mTLS) certificates:

• Cloud Service Mesh certificate authority
• Certificate Authority Service
• Istio CA

This section provides high-level information about each of these CA options and their use cases.

Mesh CA

Unless you require a custom CA, we recommend that you use Cloud Service Mesh certificate authority for the following reasons:

• Cloud Service Mesh certificate authority is a highly reliable and scalable service that is optimized for dynamically scaled workloads.
• With Cloud Service Mesh certificate authority, Google manages the security and availability of the CA backend.
• Cloud Service Mesh certificate authority lets you rely on a single root of trust across clusters.

Certificates from Cloud Service Mesh certificate authority include the following data about your application's services:

• The Google Cloud project ID
• The GKE namespace
• The GKE service account name

Important: The certificates issued by Cloud Service Mesh certificate authority should only be used to enable secure service-to-service communication within your service mesh, and not be used for any other purpose. These certificates are sent whenever services attempt to communicate with each other using mutual TLS. Make sure that you don't inadvertently expose confidential information by using these certificates when communicating outside your service mesh.

CA Service

Platform note: CA Service is only supported on the following platforms: GKE clusters on Google Cloud, Google Distributed Cloud (software only) for VMware, and Distributed Cloud. If you run asmcli install and specify --ca gcp_cas on other platforms, the installation appears successful, but your workloads will fail to start.

In addition to Cloud Service Mesh certificate authority, you can configure Cloud Service Mesh to use Certificate Authority Service. This guide provides you an opportunity to integrate with CA Service, which is recommended for the following use cases:

• If you need different certificate authorities to sign workload certificates on different clusters.
• If you need to back your signing keys in a managed HSM.
• If you are in a highly regulated industry and are subject to compliance.
• If you want to chain up your Cloud Service Mesh CA to a custom enterprise root certificate to sign workload certificates.

The cost of Cloud Service Mesh certificate authority is included in the Cloud Service Mesh pricing. The CA Service isn't included in the base Cloud Service Mesh price and is charged separately. Additionally, CA Service comes with an explicit SLA, but the Cloud Service Mesh certificate authority does not.

Istio CA

We recommend that you use Istio CA if you meet the following criteria:

• Your mesh already uses Istio CA and you do not require the benefits enabled by Cloud Service Mesh certificate authority or CA Service.
• You require a custom root CA.
• You have off-Google Cloud workloads where a Google Cloud-managed CA service is not acceptable.

Prepare gateway configuration

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.

asmcli doesn't install the istio-ingressgateway. We recommend that you deploy and manage the control plane and gateways separately. For more information, see Installing and upgrading gateways.

What's next?

• Install dependent tools and validate cluster