Here is a glossary of common Istio words and phrases.
Destination. The remote upstream service to which Envoy is talking to, on behalf of a source service. There can be one or more service versions for a given service and Envoy would choose the version based on routing rules.
Envoy. Envoy is the high-performance proxy that Istio uses to mediate all inbound and outbound traffic for all services in the service mesh. Learn more about Envoy here.
Istio-Auth. Istio-Auth provides strong service-to-service and end-user authentication using mutual TLS, with built-in identity and credential management. Learn more about Istio-Auth here.
Mixer. Mixer is an Istio component responsible for enforcing access control and usage policies across the service mesh and collecting telemetry data from the Envoy proxy and other services. Learn more about Mixer here.
Pilot. Pilot serves as an interface between the user and Istio, collecting and validating configuration and propagating it to the various Istio components. It abstracts environment-specific implementation details from Mixer and Envoy, providing them with an abstract representation of the user’s services that is independent of the underlying platform.
Service. A unit of an application with a unique name that other services use to refer to the functionality being called. Service instances are pods/VMs/containers that implement the service.
Service Consumer. The agent that is using a service.
Service Mesh. A collection of services interconnected through Istio’s fleet of proxies.
Service Operator. The agent that deploys and manages a service by manipulating configuration state and monitoring health via a variety of dashboards.
Service Producer. The agent that creates a service by writing source code.
Service Version. In a continuous deployment scenario, for a given service, there can be multiple sets of instances running potentially different variants of the application binary or config. These variants are not necessarily different API versions. They could be iterative changes to the same service, deployed in different environments (prod, staging, dev, etc.). Common scenarios where this occurs include A/B testing, canary rollouts, etc. The choice of a particular version can be decided based on various criterion (headers, url, etc.) and/or by weights assigned to each version. Each service has a default version consisting of all its instances.
Source. Downstream client (browser, mobile app, or another service) calling Envoy (typically to reach another service).