Glossary

Adapters are plug-ins to Mixer, Istio’s policy and telemetry component, which enable it 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.

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.workload.name: example

Attributes are used by Istio’s policy and telemetry features.

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.

Micro-segmentation is a security technique that creates secure zones in cloud deployments and allows organizations to isolate workloads from one another and secure them individually.

The Istio component is 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 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 Pod is a group of one or more containers (such as Docker containers), with shared storage/network, and a specification for how to run the containers. A pod is the smallest deployable unit of computing in Kubernetes.

Provides a mapping between a service name and the workload instance principals that are authorized to run the workload instances 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 workload instances. 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 instance 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.

Istio maintains an internal service registry containing the set of services, and their corresponding service endpoints, running in a service mesh. Istio uses the service registry to generate Envoy configuration.

Istio does not provide service discovery, although most services are automatically added to the registry by Pilot adapters that reflect the discovered services of the underlying platform (Kubernetes, Consul, plain DNS). Additional services can also be registered manually using a ServiceEntry configuration.

Distinct variants of a service, typically backed by 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.

TLS origination occurs when an Istio proxy (sidecar or egress gateway) is configured to accept unencrypted internal HTTP connections, encrypt the requests, and then forward them to HTTPS servers that are secured using simple or mutual TLS. This is the opposite of TLS termination where an ingress proxy accepts incoming TLS connections, decrypts the TLS, and passes unencrypted requests on to internal mesh services.

A binary deployed by operators to deliver some function in Istio. Workloads have names, namespaces, and unique ids. These properties are available in policy and telemetry configuration using the following attributes:

• source.workload.name, source.workload.namespace, source.workload.uid
• destination.workload.name, destination.workload.namespace, destination.workload.uid

In Kubernetes, a workload typically corresponds to a Kubernetes deployment, while a workload instance corresponds to an individual pod managed by the deployment.

A single instantiation of a workload’s binary. A workload instance can expose zero or more service endpoints, and can consume zero or more services.

Workload instances have a number of properties:

• Name and namespace
• Unique ID
• IP Address
• Labels
• Principal

These properties are available in policy and telemetry configuration using the many source.* and destination.* attributes.

The verifiable authority under which a workload instance 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.

Workload instance principals are available in policy and telemetry configuration using the source.principal and destination.principal attributes.