• Glossary
    • A
    • C
    • D
    • E
    • F
    • I
    • M
    • O
    • P
    • R
    • S
    • T
    • V
    • W

    Glossary

    A|C|D|E|F|I|M|O|P|R|S|T|V|W

    A

    • Adapters
    • Adapters are plug-ins to Mixer, Istio’s policy and telemetry component, which enable it to interfacewith 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 beextended to target new or custom infrastructure backends.

    Learn more about adapters.

    • Annotation

    • Annotation refers to aKubernetes annotationattached to a resource, for example a pod. For a list of valid Istio-specific annotations, seeResource 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 theenvironment this traffic occurs in. An Istio attribute carries a specific pieceof information such as the error code of an API request, the latency of an API request, or theoriginal IP address of a TCP connection. For example:
    1. request.path: xyz/abc
    2. request.size: 234
    3. request.time: 12:34:56.789 04/17/2017
    4. source.ip: 192.168.0.1
    5. destination.workload.name: example

    Attributes are used by Istio’s policy and telemetry features.

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

    • CRDs

    • Custom resource definitions (CRDs)are extensions of the default Kubernetes API. Istio uses the Kubernetes CRD API forconfiguration, 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 alltraffic that your mesh services send and receive.

    • Destination

    • A remote service that Envoy interacts with on behalf of a sourceworkload.

    E

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

    F

    • Failure Domain
    • A failure domain is a physical or logical section of the computing environmentthat is negatively affected when a critical device or service experiencesproblems.

    For an Istio deployment, failure domains could encompass multiple availabilityzones of your platform.

    I

    • Identity
    • Identity is a fundamental security infrastructure concept. The Istio identitymodel is based on a first-class workload identity. At the beginning ofservice-to-service communication, the two parties exchange credentials withtheir identity information for mutual authentication purposes.

    Clients check the server’s identity against their secure naming information todetermine if the server is authorized to run the service.

    Servers check the client’s identity to determine what information the client canaccess. Servers base that determination on the configured authorizationpolicies.

    Using identity, servers can audit the time information was accessed and whatinformation was accessed by a specific client. They can also charge clientsbased on the services they use and reject any clients that failed to pay theirbill from accessing the services.

    The Istio identity model is flexible and granular enough to represent a humanuser, an individual service, or a group of services. On platforms withoutfirst-class service identity, Istio can use other identities that can groupservice 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, servicename, Istio service account, or GCP service account. The custom serviceaccount refers to the existing service account just like the identities thatthe customer’s Identity Directory manages.

    Typically, the trust domain specifiesthe mesh the identity belongs to.

    M

    • Managed Control Plane

    • A managed control plane is a control planethat cloud providers manage for their customers.Managed control planes reduce the complexity of user deploymentsand typically guarantee some level of performance and availability.

    • Mesh Federation

    • Mesh federation is the act of exposing services between meshes and enablingcommunication across mesh boundaries. Each mesh may expose a subset of itsservices to enable one or more other meshes to consume the exposed services. Youcan use mesh federation to enable communication between meshes in amulti-mesh deployment.

    • Micro-Segmentation

    • Micro-segmentation is a security technique that creates secure zones in cloud deployments and allows organizations toisolate workloads from one another and secure them individually.

    • Mixer

    • The Istio component is responsible for enforcing access control and usage policies across the service mesh and collecting telemetry datafrom Envoy and other services.Learn more about Mixer.

    • Mixer Handler

    • Handlers represent fully configured Mixer adapters. A single binary adapter can be usedwith different configurations, each such configuration is known as a handler. Atruntime, 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 toinfrastructure backends.

    • 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 canexpose services between meshes through mesh federation.The resulting deployment is a multi-mesh deployment.

    • Multicluster

    • Multicluster is a deployment model that consists of amesh with multipleclusters.

    • Mutual TLS Authentication

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

    O

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

    P

    • Pilot

    • The Istio component that programs the Envoy 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 workload instances in aKubernetes deployment of Istio.

    R

    • Routing Rules
    • Routing rules, which you configure in a virtual service, define the paths thatrequests follow within the service mesh. With routing rules, you can defineconditions to route traffic addressed to the virtual service’s host to specificdestination workloads. Routing rules let you set up complextraffic routingscenarios.

    S

    • Secure Naming

    • Provides a mapping between a service name and the workload instance principals that are authorized torun the workload instances implementing a service.

    • Service

    • A delineated group of related behaviors within a service mesh. Services are identified using aservice 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 multipleservice versions.

    • Service Consumer

    • The agent that is using a service.

    • Service Endpoint

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

    • Service Mesh

    • A service mesh or simply mesh is an infrastructure layer that enablesmanaged, observable and secure communication betweenworkload instances.

    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 cluster-1 is considered the sameservice as the bar service in the foo namespace in cluster-2.

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

    • 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

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

    • 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 Pilotadapters that reflect the discovered services of the underlying platform (Kubernetes, Consul, plain DNS).Additional services can also be registered manually using aServiceEntry configuration.

    • Service Version

    • Distinct variants of a service, typically backed by different versions of a workload 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 service mesh a source is typically aworkload, but the source for ingress traffic may include other clients such as abrowser or mobile app.

    T

    • TLS Origination

    • TLS origination occurs when an Istio proxy (sidecar or egress gateway) is configured to accept unencryptedinternal HTTP connections, encrypt the requests, and then forward them to HTTPS servers that are securedusing simple or mutual TLS. This is the opposite of TLS terminationwhere an ingress proxy accepts incoming TLS connections, decrypts the TLS, and passes unencryptedrequests 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 allidentities within a mesh. Every mesh hasan exclusive trust domain.

    For example in spiffe://mytrustdomain.com/ns/default/sa/myname the substringidentifying the mesh is: mytrustdomain.com. This substring is the trustdomain of the mesh.

    • Trust Domain Migration
    • The process of changing the trust domain of an Istio mesh.

    V

    • Virtual Service
    • A virtual service is a resource you can use to configure how Envoy proxies routerequests to a service within an Istio service mesh. The routing rules that youdefine in a virtual service let you set up complextraffic routingscenarios.

    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 configurationusing the following attributes:

      • source.workload.name, source.workload.namespace, source.workload.uid
      • destination.workload.name, destination.workload.namespace, destination.workload.uidIn Kubernetes, a workload typically corresponds to a Kubernetes deployment,while a workload instance corresponds to an individual pod managedby the deployment.

    • Workload Instance

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

    Workload instances have a number of properties:

    • Name and namespace
    • Unique ID
    • IP Address
    • Labels
    • PrincipalThese properties are available in policy and telemetry configurationusing the many source. and destination. attributes.
    • 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 configurationusing the source.principal and destination.principal attributes.