You are viewing documentation for Anthos Service Mesh 1.7. View the latest documentation or select another available version:

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.

I

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.

M

mutual TLS
Anthos Service Mesh uses mutual TLS (mTLS) for peer authentication and encryption. mTLS makes it possible for workloads to verify each other's identities and authenticate with each other.

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.

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

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.

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 Anthos on 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.