Glossary

Here is a glossary of common Istio words and phrases.

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

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

  • Istio mutual TLS Authentication. Provides strong service-to-service authentication using mutual TLS, with built-in identity and credential management. Learn more about Istio mutual TLS authentication.

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

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

  • 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 named using a Service Name, and Istio policies such as load balancing and routing are applied using Service Names. A Service is typically materialized by one or more Service Endpoints, and may consistent 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 by manipulating configuration state and monitoring Service health via a variety of dashboards.

  • Service Producer. The agent that creates a Service and manages which Service Consumers may use it.

  • Service Version. Distinct variants of a Service, typically backed by a different version 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 Service Version.

  • Source. The downstream client of Envoy. 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.

  • 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, Workload ID is not a strongly verified property and should not be used when enforcing ACLs.
    • 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 Service Name and Workload Principal, Workload Name is not a strongly verified property and should not be used when enforcing ACLs.
    • Workload Names are accessible in Istio configuration as the source.name and destination.name attributes.
  • Workload Principal. Identifies the verifiable authority under which a Workload runs. Istio 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.