Glossary

    A

    Annotation

    Annotation refers to a attached to a resource, for example a pod. For a list of valid Istio-specific annotations, see Resource Annotations.

    Attribute

    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:

    Attributes are used by Istio’s features.

    Auto mTLS

    Auto mTLS is a feature of Istio to automatically configure client side proxies to send mutual TLS traffic on connections where both the client and server are able to handle Mutual TLS traffic. Istio downgrades to plaintext when either the client or server is not able to handle such traffic.

    C

    Cluster

    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.

    CRDs

    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.

    D

    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.

    Destination

    A remote that Envoy interacts with on behalf of a workload.

    E

    Envoy

    The high-performance proxy that Istio uses to mediate inbound and outbound traffic for all services in the . Learn more about Envoy.

    External Control Plane

    An external control plane is a 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.

    F

    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.

    G

    Gateway

    A gateway is a standalone Istio proxy deployed at the edge of the mesh. Gateways are used to route traffic or out of the mesh.

    An Istio CR is used to configure the exposed ports of a gateway deployment.

    I

    Identity

    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

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

    Injection

    Injection, or sidecar injection, refers to the use of mutating webhooks to modify pod specifications at creation time.

    See for more information.

    IO

    See Istio Operator Custom Resource

    IOP

    See

    Istio Operator Custom Resource

    The Istio Operator Custom Resource, often referred to using the short form IOP or IO, is the custom resource used to configure an Istio installation when installing using the istioctl install command or the in-cluster operator.

    Istiod

    The Istiod component is the consolidated control plane binary that encapsulates the functions of Pilot, Galley, Citadel, and the sidecar injector.

    Learn more about Istiod.

    M

    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 .

    Micro-Segmentation

    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

    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 . The resulting deployment is a multi-mesh deployment.

    Multicluster

    Multicluster is a deployment model that consists of a mesh with multiple .

    Mutual TLS Authentication

    Mutual TLS provides strong service-to-service authentication with built-in identity and credential management. Learn more about mutual TLS authentication.

    N

    Namespace Sameness

    Within a multicluster mesh, namespace sameness applies and all namespaces with a given name are considered to be the same namespace. If multiple clusters contain a Service with the same namespaced name, they will be recognized as a single combined service. By default, traffic is load-balanced across all clusters in the mesh for a given service.

    Network

    Istio uses a simplified definition of network based on general connectivity. are on the same network if they are able to communicate directly, without a gateway.

    O

    Operator

    Operators are a method of packaging, deploying and managing a Kubernetes application. For more information, see .

    P

    Pilot

    The Istio component that programs the proxies, responsible for service discovery, load balancing, and routing.

    Pod

    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 in a Kubernetes deployment of Istio.

    Primary Cluster

    A primary cluster is a with a control plane. A single can have more than one primary cluster for HA or to reduce latency. Primary clusters can act as the control plane for remote clusters.

    R

    Remote Cluster

    A remote cluster is a cluster that connects to a residing outside of the cluster. A remote cluster can connect to a control plane running in a primary cluster or to an .

    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.

    S

    Secure Naming

    Provides a mapping between a service name and the that are authorized to run the workload instances implementing a .

    Service

    Service Consumer

    The agent that is using a service.

    Service Endpoint

    The network-reachable manifestation of a . Workload instances expose service endpoints but not all services have service endpoints.

    Service Mesh

    A service mesh or simply mesh is an infrastructure layer that enables managed, observable and secure communication between .

    Service names combined with a namespace are unique within a mesh. In a multicluster mesh, for example, the bar service in the foo namespace in is considered the same service as the bar service in the foo namespace in cluster-2.

    Since are shared within the service mesh, workload instances can authenticate communication with any other within the same service mesh.

    Service Name

    A name that uniquely identifies a service within the . 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

    The agent that manages a within a service mesh by manipulating configuration state and monitoring the service’s health via a variety of dashboards.

    Service Producer

    The agent that creates a .

    Service Registry

    Istio maintains an internal service registry containing the set of services, and their corresponding , running in a service mesh. Istio uses the service registry to generate Envoy configuration.

    Istio does not provide , 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 configuration.

    Service Version

    Distinct variants of a service, typically backed by different versions of a binary. Common scenarios where multiple service versions may be used include A/B testing and canary rollouts.

    Source

    The downstream client of the Envoy proxy. Within the a source is typically a workload, but the source for ingress traffic may include other clients such as a browser or mobile app.

    SPIFFE

    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.

    .

    T

    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 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 within a mesh. For example in spiffe://mytrustdomain.com/ns/default/sa/myname the substring mytrustdomain.com specifies that the workload is from a trust domain called mytrustdomain.com.

    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.

    W

    Workload

    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 :

    • , source.workload.namespace, source.workload.uid
    • destination.workload.name, destination.workload.namespace, destination.workload.uid

    In Kubernetes, a workload typically corresponds to a Kubernetes deployment, while a workload instance corresponds to an individual managed by the deployment.

    Workload Instance

    A single instantiation of a workload’s binary. A workload instance can expose zero or more , and can consume zero or more services.

    Workload instances have a number of properties:

    • Name and namespace
    • Unique ID
    • IP Address
    • Labels

    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.