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.
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.
- External Control Plane
An external control plane is a control plane that externally manages mesh workloads running in their own clusters or other infrastructure. The control plane may, itself, be deployed in a cluster, although not in one of the clusters that is part of the mesh it’s controlling. Its purpose is to cleanly separate the control plane from the data plane of a mesh.
- 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.
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 an external 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.
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.
Istio uses a simplified definition of network based on general connectivity. Workload instances are on the same network if they are able to communicate directly, without a gateway.
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.
- Primary Cluster
A primary cluster is a cluster with a control plane. A single mesh can have more than one primary cluster for HA or to reduce latency. Primary clusters can act as the control plane for remote clusters.
- Remote Cluster
A remote cluster is a cluster that connects to a control plane residing outside of the cluster. A remote cluster can connect to a control plane running in a primary cluster or to an external control plane.
- 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
The Secure Production Identity Framework For Everyone (SPIFFE) Project defines a framework and a set of standards for identifying and securing communications between web-based services.
- 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. For example in
mytrustdomain.comspecifies that the workload is from a trust domain called
You can have one or more trust domains in a multicluster mesh, as long as the clusters share the same root of trust.
- 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