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