Glossary

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

C

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 (Preview): 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.
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.

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.

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

istiod

Istiod 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 control plane. For more information, see IstioOperator in the Istio docs.

M

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.

overlay file: A YAML file containing an IstioOperator custom resource (CR). You use overlay files to configure the control plane. You can override the default control plane configuration and enable Supported optional features in a YAML file that you pass to istioctl install or to the install_asm script. 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 istiod to identify the version. To enable automatic sidecar injection, you add the revision label to your namespaces and restart your Pods. You use the revision label to associate the pods in a namespace with a particular istiod revision, so that you can safely upgrade to a new control plane and rollback to the original revision in case of issues.

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, in the form of project-id.svc.id.goog or project-id.hub.id.goog.

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.