Glossary

A

• Adapters

• Adapters are plug-ins to Mixer to enable Mixer to interface with an open-ended set of infrastructure backends that deliver core functionality, such as logging, monitoring, quotas, ACL checking, and more. The exact set of adapters used at runtime is determined through configuration and can easily be extended to target new or custom infrastructure backends.

  Learn more about adapters.

• Attribute

• Attributes control the runtime behavior of services running in the mesh. Attributes are named and typed pieces of metadata describing ingress and egress traffic and the environment this traffic occurs in. An Istio attribute carries a specific piece of information such as the error code of an API request, the latency of an API request, or the original IP address of a TCP connection. For example:

  request.path: xyz/abc
  request.size: 234
  request.time: 12:34:56.789 04/17/2017
  source.ip: 192.168.0.1
  destination.service: example
  

D

• Destination

• The remote upstream service Envoy is talking to on behalf of a source workload. There can be one or more service versions for a given service and Envoy chooses the version based on routing rules.

E

• Envoy

• The high-performance proxy that Istio uses to mediate inbound and outbound traffic for all services in the service mesh. Learn more about Envoy.

M

• Mixer

• The Istio component responsible for enforcing access control and usage policies across the service mesh and collecting telemetry data from Envoy and other services. Learn more about Mixer.

• Mixer Handler

• Handlers represent fully configured Mixer adapters. A single binary adapter can be used with different configurations, each such configuration is known as a handler. At runtime, Mixer routes instances to one or more handlers.

• Mixer Instance

• An instance represents a chunk of Mixer data that is produced by inspecting a a set of request attributes and applying the operator-supplied configuration. Instances are delivered to individual handlers, on their way to infrastructure backends.

• Mutual TLS Authentication

• Mutual TLS provides strong service-to-service authentication with built-in identity and credential management. Learn more about mutual TLS authentication.

P

• Pilot

• The Istio component that programs the Envoy proxies, responsible for service discovery, load balancing, and routing.

S

• Secure Naming

• Provides a mapping between a service name and the workload principals that are authorized to run the workloads implementing a service.

• Service

• A delineated group of related behaviors within a service mesh. Services are identified using a service name, and Istio policies such as load balancing and routing are applied using these names. A service is typically materialized by one or more service endpoints, and may consist of multiple service versions.

• Service Consumer

• The agent that is using a service.

• Service Endpoint

• The network-reachable manifestation of a service. Service endpoints are exposed by workloads. Not all services have service endpoints.

• Service Mesh

• A shared set of names and identities that allows for common policy enforcement and telemetry collection. Service names and workload principals are unique within a service mesh.

• Service Name

• A unique name for a service, identifying it within the service mesh. A service may not be renamed and maintain its identity, each service name is unique. A service may have multiple versions, but a service name is version-independent.

  • Service names are accessible in Istio configuration as the source.service and destination.service attributes.
• Service Operator

• The agent that manages a service within a service mesh by manipulating configuration state and monitoring the service’s health via a variety of dashboards.

• Service Producer

• The agent that creates a service.

• Service Version

• Distinct variants of a service, typically backed by a different versions of a workload binary. Common scenarios where multiple service versions may be used include A/B testing, canary rollouts, etc. Each service has a default version.

• Source

• The downstream client of the Envoy proxy. Within the service mesh a source is typically a workload, but the source for ingress traffic may include other clients such as a browser or mobile app.

W

• Workload

• A process/binary deployed by operators in Istio, typically represented by entities such as containers, pods, or VMs.

  • A workload can expose zero or more service endpoints.
  • A workload can consume zero or more services.
  • Each workload has a single canonical service name associated with it, but may also represent additional service names.
• Workload ID

• A unique identifier for an individual instance of a workload. Like workload name, the workload ID is not a strongly verified property and should not be used when enforcing ACLs. The workload IDs are accessible in Istio configuration as the source.uid and destination.uid attributes.

• Workload Name

• A unique name for a workload, identifying it within the service mesh. Unlike the service name and the [workload principal], the workload name is not a strongly verified property and should not be used when enforcing ACLs. The workload names is accessible in Istio configuration as the source.name and destination.name attributes.

• Workload Principal

• Identifies the verifiable authority under which a workload runs. Istio’s service-to-service authentication is used to produce the workload principal. By default workload principals are compliant with the SPIFFE ID format.

  • Multiple workloads may share the same workload principal, but each workload has a single canonical workload principal
  • Workload principals are accessible in Istio configuration as the source.user and destination.user attributes.