Anthos Service Mesh 1.12 has reached end of life and is no longer supported. See Upgrading from earlier versions.

View the latest documentation or select another available version:

Available versions

1.20 (latest)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12
1.11
1.10
1.9
1.8
1.7
1.6
1.5
1.4

Glossary

This page provides brief definitions and links to more information of terms that are used in the Anthos Service Mesh documentation.

A

Anthos Workload Identity: a tuple of trust domain, namespace, and service account. It has a SPIFFE identity format of spiffe://<workload_identity_pool>/ns/<namespace>/sa/<serviceaccount> in Anthos workload x509 certificates. For other credential types (e.g., OIDC tokens), the format may vary.

C

canary cluster migration

Canary cluster migration is a common migration strategy used for migrating from Istio to Anthos Service Mesh where you enable Anthos Service Mesh on a new, separate cluster. Canary cluster migration strategy is explored in the tutorial, Migrate Istio 1.11 or above to managed Anthos Service Mesh. The canary cluster migration can also be used when migrating from in-cluster Anthos Service Mesh to managed Anthos Service Mesh. The other common migration strategy is canary control plane migration.

canary control plane migration

Canary control plane migration is a common migration strategy used for migrating from Istio to Anthos Service Mesh, where Anthos Service Mesh is enabled on the existing Istio-installed cluster. The migration consists of relabelling namespaces such that the data plane uses Anthos Service Mesh. The canary cluster migration can also be used when migrating from in-cluster Anthos Service Mesh to managed Anthos Service Mesh. The other common migration strategy is canary cluster migration.

canary upgrade

See revision-based upgrade.

Canonical Service

A label applied to workloads in Anthos Service Mesh that allows you to group one or more workloads as a logical service within the service mesh. A workload belongs to exactly one canonical service, whereas it can belong to multiple Kubernetes services. A canonical service is identified by a name and a namespace, and can be further divided into one or more canonical revisions.

control plane

A control plane is a set of system services that configure the mesh or a subset of the mesh to manage the communication between the workload instances within. Anthos Service Mesh 1.9 and later provides two control planes:

Google-managed control plane: This is a fully-managed Google Cloud service that you only need to configure, while Google handles its reliability, upgrades, scaling and security for you. Managed Anthos Service Mesh consists of the Google-managed control plane and the optional Google-managed data plane.
In-cluster control plane: This is a Google-supported distribution of istiod that you install on your cluster. When you install Anthos Service Mesh with istiod, you are responsible for upgrading and for configuring security and scaling.

Although the control plane distributes its configuration to the sidecar proxies, the control plane does not directly participate in handling traffic for workloads in the mesh.

D

data plane: The data plane is the part of the mesh that directly handles communication between workload instances. Anthos Service Mesh's data plane uses proxies deployed as sidecars to mediate and control all TCP traffic that your mesh services send and receive. Managed Anthos Service Mesh offers a Google-managed data plane.

E

egress gateway: An egress gateway is an Envoy proxy that lets you configure a dedicated exit node for the traffic leaving the mesh. You use the Gateway custom resource to configure the proxy. An egress gateway lets you limit which services can or should access external networks. See Install and upgrade gateways for more information.

F

fleet: A fleet (formerly known as an environ) lets you organize clusters to make multi-cluster management easier. Registering your clusters in a fleet simplifies the management of a multi-cluster mesh by introducing the concept of "sameness" for identity, namespaces and services. 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. To learn more about fleets, see Introducing fleets.

H

hydrated manifests: A manifest that is ready for deployment in the target. To hydrate a manifest, typically you use a tool such as Helm, Kustomize or kpt to set values for the variables in the manifest.

I

identity

Identity is a fundamental security infrastructure concept. The Anthos Service Mesh identity model is based on a first-class workload identity. At the beginning of service-to-service communication, the two parties exchange credentials with their identity information for mutual authentication purposes.

Clients check the server's identity against their secure naming information to determine if the server is authorized to run the service.

Servers check the client's identity to determine what information the client can access. Servers decide whether to allow the access based on the configured authorization policies.

Using identity, servers can audit the time information was accessed and what information was accessed by a specific client. They can also charge clients based on the services they use and reject any clients that failed to pay their bill from accessing the services.

The Anthos Service Mesh identity model is flexible and granular enough to represent a human user, an individual service, or a group of services. On platforms without first-class service identity, Anthos Service Mesh can use other identities that can group service instances, such as service names.

Anthos Service Mesh supports the following service identities on different platforms:

Kubernetes: Kubernetes service account
Google Kubernetes Engine: Google Cloud service account
Google Cloud: Google Cloud service account

ingress gateway

An ingress gateway is an Envoy proxy that functions as a load balancer to handle incoming traffic entering from outside the mesh. You use the Gateway custom resource to configure the load balancer and you create virtual services and authentication policies to control how incoming traffic is secured and routed to your workloads. See Install and upgrade gateways for more information.

injection

Injection, or auto-injection, refers to the use of mutating webhooks to modify Pod specifications at creation time. You use injection to add the Envoy proxy sidecar configuration for your mesh services or to configure the Envoy proxy of gateways.

in-place upgrade

An in-place upgrade replaces the existing control plane with a new revision. As a best practice, we recommend revision-based upgrades.

istiod

istiod (the "d" is for "daemon)" is the consolidated monolithic binary that provides control plane services. Before Anthos Service Mesh 1.5, the control plane services were provided by separate components called Pilot, Citadel, Mixer, and Galley.

IstioOperator

A custom resource that you use to configure the in-cluster control plane. For more information, see Enabling optional features.

M

Managed Instance Group (MIG)

Lets you operate applications on multiple identical VMs, starting with a minimum MIG size of one VM. You can make your workloads scalable and highly available by taking advantage of automated MIG services, including: autoscaling, autohealing, regional (multiple zone) deployment, and automatic updating. For more information, see managed instance groups (MIGs).

Manifest

A Kubernetes configuration object that is used to create, modify, and delete Kubernetes resources such as Pods, deployments, services, or ingresses. In the Anthos Service Mesh documentation, the manifest that you use to configure the control plane is referred to as an overlay file.

Manifests exist in one of two states: rendered (also referred to as hydrated) or unrendered. An unrendered manifest is not ready for deployment into a target. The rendering process, which includes populating specific values into the manifest, is often performed by tools like Helm, Kustomize, and kpt.

Mesh CA

The name of the Google-managed certificate authority that manages mTLS certificates. Mesh CA is enabled by default when you install Anthos Service Mesh on GKE clusters on Google Cloud, and you can optionally enable Mesh CA when you install Anthos Service Mesh 1.10 or higher on GKE on VMware or bare metal. For more information see Security overview.

mutual TLS

Anthos Service Mesh uses mutual TLS (mTLS) for authentication and encryption between services in the mesh. mTLS makes it possible for workloads to verify each other's identities and authenticate with each other. You might be familiar with simple TLS through its use in HTTPS to allow browsers to trust web servers and to encrypt the data that is exchanged. When simple TLS is used, the client establishes that the server can be trusted by validating its certificate. mTLS is an implementation of TLS in which both client and server present certificates to each other and verify each other's identities.

N

network: Anthos Service Mesh uses a simplified definition of network based on general connectivity. Workload instances are on the same network if they are able to communicate directly, without a gateway.

O

overlay file: A YAML file containing an IstioOperator custom resource (CR). You use overlay files to configure the in-cluster control plane. You can override the default control plane configuration and enable Supported optional features in a YAML file that you pass to asmcli install. You can layer on more overlays, and each overlay file overrides the configuration on the previous layers. See Enabling optional features for the YAML that you can use to enable features that aren't enabled by default.

P

primary cluster: A primary cluster is a cluster with a control plane. A single mesh can have more than one primary cluster for high availability or to reduce latency. In the Istio 1.7 documentation, a multi-primary deployment is referred to as a replicated control plane.

R

remote cluster: A remote cluster is a cluster that connects to a control plane residing outside of the cluster. A remote cluster can connect to a control plane running in a primary cluster or to an external control plane.
revision: A revision represents a snapshot-in-time of application code version and configuration. When you install or upgrade Anthos Service Mesh, a revision label is added to the control plane. To enable automatic sidecar injection, you add the revision label to your namespaces and restart your Pods. The revision label associates the Pods in a namespace with a particular control plane revision.
revision-based upgrade: Migrations from OSS Istio and upgrades follow the revision-based upgrade process (referred to as "canary upgrades" in the Istio documentation). With a revision-based upgrade, the new revision of the control plane is installed alongside the existing control plane. You then move some of your workloads to the new revision, which lets you monitor the effect of the upgrade with a small percentage of the workloads before migrating all of the traffic to the new revision.

S

secure naming: Server identities are encoded in certificates, but service names are retrieved through the discovery service or DNS. The secure naming information maps the server identities to the service names. A mapping of identity A to service name B means "A is authorized to run service B". The control plane watches the apiserver, generates the secure naming mappings, and distributes them securely to the sidecar proxies.
service mesh: A service mesh or simply mesh is an infrastructure layer that enables managed, observable and secure communication between workload instances.
sidecar: A pattern for running a utility or helper alongside a workload. If you are using Kubernetes, sidecars run alongside the workload container in a pod. When discussing service mesh, the word "sidecar" is often used to refer to the proxy.

T

trust domain

Trust domain corresponds to the root of trust of a system and is part of a workload identity.

Anthos Service Mesh uses a trust domain to create all identities within a mesh. For example, in the SPIFFE ID spiffe://mytrustdomain.com/ns/default/sa/myname, the substring mytrustdomain.com specifies that the workload is from a trust domain called mytrustdomain.com.

When using the Mesh CA, the trust domain is automatically generated by Anthos Service Mesh. It is based on the cluster's workload pool.

You can have one or more trust domains in a multi-cluster mesh, as long as the clusters share the same root of trust.

W

workload: A workload is a containerized application, service, or other program such as a batch job or daemon running on a platform. The platform could be a Kubernetes cluster, virtual machine, or another environment such as Google Distributed Cloud Virtual for Bare Metal. Workloads have names, namespaces, and unique ids. On Kubernetes, a workload typically corresponds to a Deployment, but there are other types of workloads, such as a StatefulSet.
WorkloadEntry: Allows you to describe non-Kubernetes-Pod endpoints that should be part of the mesh, and treat them the same as a Kubernetes Pod. In our case, each VM is registered as a WorkloadEntry in the mesh. For more information, see https://istio.io/latest/blog/2020/workload-entry/
WorkloadGroup: Describes a collection of workload instances. See WorkloadGroup.
Workload Identity pool: The trust boundary, also known as a trust domain of an Anthos Service Mesh.