Multi-project installation on GKE

This guide explains how to install Anthos Service Mesh for a mesh containing multiple Google Kubernetes Engine (GKE) clusters that are in different Google Cloud projects.

You can use this guide for the following onboarding use cases:

• New installations of Anthos Service Mesh 1.10.6.

• Upgrading from 1.9 or a 1.10 patch release to Anthos Service Mesh 1.10.6. Upgrades from earlier versions aren't supported.

• Migrating from open source Istio to Anthos Service Mesh 1.10.6. If you have an earlier version of Istio, you must upgrade first before migrating to Anthos Service Mesh. If you need to upgrade, go to the Upgrade Istio page in the applicable version of Istio. Note that Upgrading Istio across more than one minor version (for example, 1.6.x to 1.8.x) in one step is not officially tested or recommended. Be sure to review Preparing to migrate from Istio to plan your migration.

Not all features are available for a service mesh with clusters in different projects. In particular, the Anthos Service Mesh dashboards in the Google Cloud console currently aren't available. However, you can still view logs in Cloud Logging and metrics in Cloud Monitoring for each project.

Note:

For information about other Anthos Service Mesh onboarding use cases, see the following:

• For installation instructions for clusters that are in the same Google Cloud project, see the GKE single project guide.
• After you have installed Anthos Service Mesh, if you need to configure a multi-cluster service mesh, see Setting up a multi-cluster mesh.

Before you begin

This guide assumes that you already have:

• A Google Cloud project.
• A Cloud Billing account.
• A GKE cluster that meets the requirements.

If you are migrating from Istio, be sure to review Preparing to migrate from Istio.

Anthos and Anthos Service Mesh differences

Anthos Service Mesh is available with GKE Enterprise or as a standalone service. Google APIs are used to determine how you are billed. To use Anthos Service Mesh as a standalone service, don't enable the GKE Enterprise API in your project. For information about Anthos Service Mesh pricing, see Pricing.

• GKE Enterprise subscribers, be sure to enable the GKE Enterprise API.

  Enable the API

• If you aren't an GKE Enterprise subscriber, you can still install Anthos Service Mesh, but certain UI elements and features in Google Cloud console are only available to GKE Enterprise subscribers. For information about what is available to subscribers and non-subscribers, see GKE Enterprise and Anthos Service Mesh UI differences.

• If you enabled the GKE Enterprise API, but you want to use Anthos Service Mesh as a standalone service, disable the GKE Enterprise API.

Requirements

• Because your clusters are in different projects, they must be in a Shared Virtual Private Cloud (VPC). For information on configuring your clusters, see Setting up clusters with Shared VPC.

• Your GKE cluster must meet the following requirements:

  • The GKE cluster must be Standard, because Autopilot clusters have Webhooks limitations that don't allow the MutatingWebhookConfiguration for the istio-sidecar-injector.

  • A machine type that has at least four vCPUs, such as e2-standard-4. If the machine type for your cluster doesn't have at least four vCPUs, change the machine type as described in Migrating workloads to different machine types.

  • The minimum number of nodes depends on your machine type. Anthos Service Mesh requires at least eight vCPUs. If the machine type has four vCPUs, your cluster must have at least two nodes. If the machine type has eight vCPUs, the cluster only needs one node. If you need to add nodes, see Resizing a cluster.

  • To prepare your cluster before installing Anthos Service Mesh, you enable Workload Identity. Workload Identity is the recommended method of calling Google APIs. Enabling Workload Identity changes the way calls from your workloads to Google APIs are secured, as described in Workload Identity limitations.

  • Optionally, but recommended, enroll the cluster in a release channel. We recommend that you enroll in the Regular release channel because other channels might be based on a GKE version that isn't supported with Anthos Service Mesh 1.10.6. For more information, see Supported environments. Follow the instructions in Enrolling an existing cluster in a release channel if you have a static GKE version.

• 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 are installing Anthos Service Mesh on a private cluster, you must open port 15017 in the firewall to get the webhook used with automatic sidecar injection to work properly. For more information, see Opening a port on a private cluster.

• If you have created a service perimeter in your organization, you might need to add the Mesh CA service to the perimeter. See Adding Mesh CA to a service perimeter for more information.

• A Google Cloud project can only have one mesh associated with it.

• If you want to lower the default resource limits for the istio-proxy sidecar container, you new limits should allow enough memory to avoid out-of-memory (OOM) events.

Choosing a certificate authority

For both new installations and migrations from Istio, you can use Anthos Service Mesh certificate authority (Mesh CA) or Istio's Citadel as the certificate authority (CA) for issuing mutual TLS (mTLS) certificates.

Unless you require a custom CA, such as HashiCorp Vault, we recommend that you use Mesh CA for the following reasons:

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

If you're migrating from Istio, you can choose to migrate to Mesh CA or continue using Istio's Citadel CA. If you choose Citadel, there's little downtime because mTLS traffic isn't interrupted during the migration. If you choose Mesh CA, you need to schedule downtime for the migration because the root of trust changes from Citadel to Mesh CA. To complete the migration to the Mesh CA root of trust, you need to restart all Pods in all namespaces. During this process, the old Pods cannot establish mTLS connections with the new Pods.

Certificates from Mesh CA 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 Mesh CA 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.

Registering your cluster

Although not required currently, we recommend that you register your cluster in your project's fleet (formerly known as an environ). A fleet lets you organize clusters to make multi-cluster management easier. By registering your clusters in a fleet, you can group services and other infrastructure as needed to apply consistent policies. If you have clusters in different projects, you need to register the clusters with the fleet host project rather than the project that the cluster was created in. For details on how to register your cluster, see Registering clusters to the fleet.

The concept of a fleet host project is important when you set up your cluster to enable the options that Anthos Service Mesh requires. The service mesh for your cluster is identified with a value that is based on a project number. When you are setting up clusters from different projects, you need to use the project number for the fleet host project.

Next >