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.
A cluster is set of compute nodes that run containerized applications. Typically, the compute nodes comprising a cluster can reach each other directly. Clusters limit external access through rules or policies.
- Control Plane
A control plane is a set of system services that configure the mesh or a subset of the mesh to manage the communication between the workload instances within. All instances of a control plane in a single mesh share the same configuration source.
Custom resource definitions (CRDs) are extensions of the default Kubernetes API. Istio uses the Kubernetes CRD API for configuration, even for non-Kubernetes Istio deployments.
- Data Plane
The data plane is the part of the mesh that directly controls communication between workload instances. Istio’s data plane uses intelligent Envoy proxies deployed as sidecars to mediate and control all traffic that your mesh services send and receive.
- Failure Domain
A failure domain is a physical or logical section of the computing environment that is negatively affected when a critical device or service experiences problems.
For an Istio deployment, failure domains could encompass multiple availability zones of your platform.
Identity is a fundamental security infrastructure concept. The Istio identity model is based on a first-class workload identity. At the beginning of service-to-service communication, the two parties exchange credentials with their identity information for mutual authentication purposes.
Clients check the server’s identity against their secure naming information to determine if the server is authorized to run the service.
Servers check the client’s identity to determine what information the client can access. Servers base that determination on the configured authorization policies.
Using identity, servers can audit the time information was accessed and what information was accessed by a specific client. They can also charge clients based on the services they use and reject any clients that failed to pay their bill from accessing the services.
The Istio identity model is flexible and granular enough to represent a human user, an individual service, or a group of services. On platforms without first-class service identity, Istio can use other identities that can group service instances, such as service names.
Istio supports the following service identities on different platforms:
Kubernetes: Kubernetes service account
GKE/GCE: GCP service account
GCP: GCP service account
AWS: AWS IAM user/role account
On-premises (non-Kubernetes): user account, custom service account, service name, Istio service account, or GCP service account. The custom service account refers to the existing service account just like the identities that the customer’s Identity Directory manages.
Typically, the trust domain specifies the mesh the identity belongs to.
The Istiod component is the consolidated monolithic control plane binary that encapsulates the functions of Pilot, Citadel, Mixer, and Galley.
- Managed Control Plane
A managed control plane is a control plane that cloud providers manage for their customers. Managed control planes reduce the complexity of user deployments and typically guarantee some level of performance and availability.
- Mesh Federation
Mesh federation is the act of exposing services between meshes and enabling communication across mesh boundaries. Each mesh may expose a subset of its services to enable one or more other meshes to consume the exposed services. You can use mesh federation to enable communication between meshes in a multi-mesh deployment.
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 set of request attributes and applying the operator-supplied configuration. Instances are delivered to individual handlers, on their way to infrastructure backends.
Multi-mesh is a deployment model that consists of two or more service meshes. Each mesh has independent administration for naming and identities but you can expose services between meshes through mesh federation. The resulting deployment is a multi-mesh deployment.
- Mutual TLS Authentication
Mutual TLS provides strong service-to-service authentication with built-in identity and credential management. Learn more about mutual TLS authentication.
Operators are a method of packaging, deploying and managing a Kubernetes application. For more information, see Operator pattern.
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 and network, and a specification for how to run the containers. Pods are the workload instances in a Kubernetes deployment of Istio.
- Routing Rules
Routing rules, which you configure in a virtual service, define the paths that requests follow within the service mesh. With routing rules, you can define conditions to route traffic addressed to the virtual service’s host to specific destination workloads. Routing rules let you control traffic for tasks like A/B testing, canary rollouts, and staged rollouts with percentage-based traffic splits.
- 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
A service mesh or simply mesh is an infrastructure layer that enables managed, observable and secure communication between workload instances.
Service names combined with a namespace are unique within a mesh. In a multicluster mesh, for example, the
barservice in the
cluster-1is considered the same service as the
barservice in the
- Service Name
A name that uniquely identifies a service within the service mesh. A service may not be renamed while maintaining its identity. 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
- 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.
- Trust Domain
Trust domain corresponds to the trust root of a system and is part of a workload identity
Istio uses a trust domain to create all identities within a mesh. Every mesh has an exclusive trust domain.
For example in
spiffe://mytrustdomain.com/ns/default/sa/mynamethe substring identifying the mesh is:
mytrustdomain.com. This substring is the trust domain of the mesh.
- Trust Domain Migration
The process of changing the trust domain of an Istio mesh.
A binary deployed by operators to deliver some function of a service mesh application. Workloads have names, namespaces, and unique ids. These properties are available in policy and telemetry configuration using the following attributes:
- 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