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.
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.
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.
- Mixer Handler
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.
- Mixer Instance
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 Authentication
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.
- Secure Naming
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.
- Service Consumer
The agent that is using a service.
- Service Endpoint
- 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 Operator
- Service Producer
The agent that creates a service.
- Service Registry
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
- Service Version
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.
- TLS Origination
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:
In Kubernetes, a workload typically corresponds to a Kubernetes deployment, while a workload instance corresponds to an individual pod managed by the deployment.
- Workload Instance
Workload instances have a number of properties:
- Name and namespace
- Unique ID
- IP Address
These properties are available in policy and telemetry configuration using the many
- Workload Instance Principal
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