ICA key terms

A named, independently installable instance of the Istio control plane. Multiple revisions can coexist so you can canary a new version and migrate workloads by relabeling their namespaces before removing the old revision.

The Istio command-line utility used to install, upgrade, analyze, and debug a mesh. It can render manifests, run pre-upgrade checks, and inspect proxy configuration for a specific pod.

A custom resource that declares the desired shape of an Istio installation, including enabled components, resource settings, and mesh-wide options. The installer consumes it to generate the actual Kubernetes manifests.

The set of Istio components that configure the mesh rather than carry application traffic. It watches Kubernetes and Istio resources and pushes derived configuration to every sidecar and gateway.

The proxies that actually handle application traffic: sidecars injected into workload pods and standalone gateway deployments. They enforce routing, security, and telemetry policy received from the control plane.

The consolidated Istio control plane binary. It combines service discovery, configuration distribution, certificate authority duties, and sidecar injection webhook behavior in one deployment.

The mechanism that adds an Envoy proxy container to application pods, either automatically via a namespace label and admission webhook or manually by rewriting the pod spec before creation.

The container name and image running Envoy inside injected pods. It holds the proxy process itself plus helper processes that bootstrap configuration and manage certificates.

A named bundle of installation defaults, such as default, demo, or minimal, that toggles which components are enabled and how they are tuned. Profiles are a starting point you can override.

An upgrade strategy that installs a new control plane revision alongside the running one, moves a small set of workloads to it, validates behavior, then progressively migrates the rest before deleting the old revision.

A static checker that inspects live cluster configuration or files and reports likely misconfigurations, such as a VirtualService referencing a host that no Service defines, with severity levels and suggested fixes.

A routing resource that defines how requests for a host are matched and directed, including match conditions, destination subsets, timeouts, retries, and header or URI rewrites.

A resource that configures policy applied after routing decisions are made, covering load-balancing algorithm, connection pool limits, outlier detection, and the subsets that VirtualServices target.

A standalone Envoy deployment at the mesh edge that listens on specified ports and hosts. It accepts or rejects inbound traffic before any VirtualService routing rules are applied.

A Gateway deployment that terminates traffic entering the mesh from outside, typically fronted by a cloud or cluster load balancer. Routing onward to services is defined by bound VirtualServices.

A named group of pod endpoints within a single service, usually selected by labels such as version. Subsets let routing rules send traffic to a specific deployment variant.

Sending percentages of requests for one host to different weighted destinations, commonly used for canary releases. Weights are declared on routes and must sum to a meaningful total.

A DestinationRule health check that ejects endpoints returning consecutive errors from the load-balancing pool for a period, reducing traffic to unhealthy instances without Kubernetes readiness changes.

DestinationRule limits on concurrent connections, pending requests, and retries per endpoint. These settings cap resource use and shape how bursts are absorbed by upstream services.

A deliberate delay or abort applied to matched requests so teams can test timeout, retry, and resilience behavior without modifying application code.

Rules on a route that specify how many times and under what conditions a failed request is resent, including per-try timeout and which response codes or gRPC statuses qualify.

A per-route limit on how long the proxy waits for an upstream response before returning an error. It is distinct from retry attempts, which may each carry their own timeout.

A resource that registers external or otherwise unregistered hosts into the mesh's service registry, enabling routing, mTLS origination, and telemetry for traffic leaving the cluster.

A Gateway deployment through which selected outbound traffic is forced to exit the mesh, giving a single controlled point for auditing, policy, and static source IPs.

A namespaced resource that restricts which services and hosts a proxy is told about, reducing configuration size and memory. It scopes both inbound and outbound visibility for selected workloads.

A policy resource that controls whether traffic to workloads must use mutual TLS, may use it, or is exempt. It can be set mesh-wide, per namespace, or per workload selector.

Two-way certificate authentication where both client and server present and verify identities. In Istio it is automatic for meshed workloads and gives each proxy a cryptographic workload identity.

A resource that allows or denies requests based on source identity, namespace, method, path, or JWT claims. Policies combine with ALLOW, DENY, and CUSTOM actions and default to deny when any ALLOW exists.

A resource that declares how to validate end-user credentials, such as JWT issuers and JWKS locations. It verifies tokens but does not by itself restrict access; authorization rules must reference the claims.

A standardized URI-form identity embedded in workload certificates, such as spiffe://cluster.local/ns/foo/sa/bar. Authorization policies and telemetry use it to identify callers precisely.

Secret Discovery Service, the protocol by which a proxy fetches and rotates its certificates and keys from the control plane instead of reading static files from disk.

Authorization conditions that match on validated token claims, such as issuer, audience, groups, or scopes. They require a RequestAuthentication for the same issuer to have verified the token first.

The high-performance proxy that implements Istio's data plane. It receives listener, route, cluster, and endpoint configuration over the xDS APIs and applies it without restarting.

The family of discovery APIs, including LDS, RDS, CDS, and EDS, through which the control plane streams proxy configuration. Understanding them helps interpret config dump output during debugging.

The full JSON snapshot of a proxy's current listeners, routes, clusters, and endpoints, retrieved with istioctl proxy-config or the admin endpoint. It is the primary artifact for routing investigations.

An istioctl subcommand that lists every proxy with the sync state of each xDS type, showing whether configuration was accepted, rejected, or is stale relative to the control plane.

Per-request records emitted by the proxy containing response code, latency, upstream host, and identities. Enabling them is often the fastest way to see whether traffic reached the intended destination.

The metrics, traces, and logs Istio produces for mesh traffic. Default metrics such as request counts and durations are labeled by source and destination workload and can be scraped by Prometheus.