# Glossary — Istio & the Service Mesh

The canonical vocabulary for this course. Opinionated and repo-flavoured. Once a term is
defined here, every lesson uses it this way. Terms marked *(Part N)* are taught in that part.

---

### Service mesh
A dedicated infrastructure layer that handles service-to-service communication — routing,
security, and observability — via proxies alongside your services, *without changing app code*.
*Repo: Istio, layered over the Kubernetes Services from Course 2.*

### Istio
The service mesh used here. Split into a **data plane** (Envoy sidecars) and a **control plane**
(istiod). Installed via Helm (`platforms/istio`, Course 3).

### Data plane *(Lesson 1)*
The set of **Envoy** proxies that actually carry traffic — one sidecar per Pod. They mediate all
inbound/outbound traffic and emit telemetry.

### Control plane / istiod *(Lesson 1)*
**istiod** — the single control-plane binary. It does service discovery, converts high-level
rules (VirtualService, etc.) into Envoy config and pushes them to the sidecars, and acts as the
**Certificate Authority** issuing mTLS identities.

### Envoy *(Lesson 1–2)*
The high-performance C++ proxy Istio deploys as the sidecar. All of a Pod's traffic flows
through its Envoy; that's where routing, mTLS, retries, and metrics happen.

### Sidecar *(Lesson 2)*
The Envoy container added to your Pod (alongside your app container). Your app talks to
localhost; Envoy transparently intercepts and handles the network.

### Sidecar injection *(Lesson 2)*
How the Envoy sidecar gets added. **Automatic** injection happens when a namespace is labelled
`istio-injection=enabled` (or `istio.io/rev=…`) and a mutating webhook rewrites new Pods to
include Envoy. A pod annotation `sidecar.istio.io/inject` can override per-Pod.

### Gateway *(Lesson 3, 5)*
An Istio resource that configures a standalone Envoy at the **edge** of the mesh (the ingress
gateway) — which hosts, ports, and TLS to accept. It only opens the door; a VirtualService
routes what comes through.

### VirtualService *(Lesson 3, 4)*
Traffic **routing rules** for a host: match requests (by URI/header/…) and route them to a
destination (service, subset, weight), with rewrites, timeouts, and retries. *Repo: generated
from each service's `apiHttp`/`webHttp` route-table values — ~571 across cells.*

### DestinationRule *(Lesson 3, 6)*
Policies applied to traffic **after** routing: load-balancing algorithm, connection-pool limits,
outlier detection, mTLS mode, and the **subsets** a VirtualService can target. *Repo: `tom` has a
hand-written one.*

### Subset *(Lesson 6)*
A named subgroup of a service's Pods (by label, e.g. `version: v2`), declared in a DestinationRule
and targeted by a VirtualService route — the basis of canary/version routing.

### ServiceEntry *(Lesson 3)*
Adds an **external** service to the mesh's registry so sidecars can route to it with mesh
policies (retries, mTLS origination).

### Sidecar (resource) *(Lesson 12)*
A resource (confusingly same name) that limits a workload's proxy config — e.g. restrict egress
to only the services it actually needs, shrinking Envoy's memory.

### mTLS (mutual TLS) *(Lesson 9)*
Both ends of a connection present certificates and encrypt traffic. Istio *can* do it
transparently between sidecars — no app code — enforced by a PeerAuthentication policy.
*Repo: NOT used — `enableAutoMtls: false`, no PeerAuthentication. In-cluster traffic is
plaintext; TLS is terminated only at the ingress edge.*

### PeerAuthentication *(Lesson 9)*
The policy that sets mTLS mode for incoming connections: **STRICT** (require mTLS),
**PERMISSIVE** (accept both), or **DISABLE**. Can be mesh-wide, per-namespace, or per-workload.
*Repo: none exist — a deliberate opt-out of in-mesh mTLS.*

### SPIFFE identity *(Lesson 9)*
The workload identity format Istio uses for certs:
`spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>` — built from the Pod's Kubernetes
**ServiceAccount** (Course 2 L12). istiod (the CA) issues it.

### AuthorizationPolicy *(Lesson 10)*
Access control: *who* (which identity/namespace/principal) may call *what* (paths/methods).
mTLS proves identity; AuthorizationPolicy decides what that identity is allowed to do. *Repo:
none for backend services — auth is done in-app (token → gRPC metadata). Only platform
monitoring/Atlantis use it (with JWT RequestAuthentication).*

### RequestAuthentication *(Lesson 10)*
Validates end-user credentials (JWTs) on a request — origin authentication, distinct from the
peer (workload) authentication of mTLS.

### EnvoyFilter *(Lesson 12)*
The low-level **escape hatch**: patch the raw Envoy config directly when the high-level CRDs
can't express what you need (header manipulation, custom filters, rate limiting). Powerful,
version-fragile, use sparingly. *Repo: uses some.*

### `istio_requests_total` *(Lesson 11)*
The standard Istio **request-count** metric (a counter), emitted by every Envoy and scraped by
Prometheus. *Repo: the KEDA request-rate ScaledObject scales on a `rate(istio_requests_total…)`
query (Course 2 L9) — Istio is the source of that metric.*

### Golden signals *(Lesson 11)*
Latency, traffic, errors, saturation — the core service health metrics. Istio's standard metrics
(requests, duration, sizes) cover most of them out of the box, per-service, with no app changes.

### Kiali / Jaeger *(Lesson 11, Course 6)*
Mesh dashboards: **Kiali** visualises the service graph + config; **Jaeger** shows distributed
traces. Fed by Istio telemetry. (Detailed in Course 6, Observability.)

### istioctl *(Lessons 2, 12)*
Istio's CLI: `istioctl analyze` (validate config), `proxy-config`/`proxy-status` (inspect a
sidecar's live Envoy config), `kube-inject` (manual injection).