istio.io/_docs/reference/glossary.md

4.9 KiB
Raw Blame History

title overview order bodyclass layout type
Glossary A glossary of common Istio terms. 40 docs docs markdown

Glossary

  • Destination. The remote upstream service to which the proxy/sidecar is talking to, on behalf of the source service. There can be one or more service versions for a given service and the proxy 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 TBD.

  • Istio-Manager. Istio-Manager 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 users services that is independent of the underlying platform.

  • Microservice. A lightweight service.

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

  • 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 Versions. 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 or another service) calling the proxy/sidecar (typically to reach another service).