Common Istio words and phrases. Please let us know if you came here looking for a definition and didn’t find it.
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.
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
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.
The high-performance proxy that Istio uses to mediate inbound and outbound traffic for all services in the service mesh. Learn more about Envoy.
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.
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.
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 provides strong service-to-service authentication with built-in identity and credential management. Learn more about mutual TLS authentication.
The Istio component that programs the Envoy proxies, responsible for service discovery, load balancing, and routing.
Provides a mapping between a service name and the workload principals that are authorized to run the workloads implementing a 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.
The agent that is using a service.
The network-reachable manifestation of a service. Service endpoints are exposed by workloads. Not all services have service endpoints.
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.
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.
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.
The agent that creates a service.
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.
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.
A process/binary deployed by operators in Istio, typically represented by entities such as containers, pods, or VMs.
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
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
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.