# Mission — Istio & the Service Mesh

## Why this course exists

**Course 4 of 7** in the deployment/infra track. Course 2 gave you Kubernetes **Services** (a
stable name in front of Pods); Course 3 showed you how Helm **generates** those objects. But a
plain Service only does basic L4 load-balancing — it can't do request routing, retries, mTLS,
or per-request telemetry. This repo layers **Istio**, a service mesh, on top for routing, edge
security, and observability. It's a big surface here: **~571 VirtualServices** across the env×org
cells, the `istio-ingressgateway`, DestinationRules, EnvoyFilters, and the `istio_requests_total`
metric that already drives the KEDA autoscaling you met in Course 2. One honest thing to know
up front: this mesh is used for **traffic routing + edge TLS + telemetry**, *not* in-mesh
mTLS/zero-trust (auto-mTLS is off; there are no backend PeerAuthentication/AuthorizationPolicy
objects). That's a real, defensible architecture — and a useful contrast to the textbook.

If Course 2 was "the objects" and Course 3 was "how they're generated," Course 4 is "how
traffic actually flows between and into them — routed, secured, and observed."

## Who the learner is

- Backend engineer on the **conversationmgmt / notification / spike** team — strong Go, gRPC,
  Kafka, Postgres, Airflow; now solid on containers, Kubernetes, and Helm (nine courses in).
- **Newer to service mesh.** Sidecars, Envoy, VirtualService/DestinationRule/Gateway, mTLS are
  new. Assume strong backend maturity, NOT mesh fluency.
- Directly relevant: their gRPC services sit in the mesh; `tom` has a hand-written
  DestinationRule; every service's `apiHttp`/`webHttp` values become VirtualServices.

## What "success" looks like

By the end, the learner can, from memory:

1. Explain what a service mesh is — the sidecar/Envoy data plane vs the istiod control plane —
   and why you add it *without changing app code*.
2. Explain sidecar injection and how Envoy transparently intercepts a Pod's traffic.
3. Name the three traffic-management resources — **Gateway, VirtualService, DestinationRule** —
   and what each governs.
4. Read a **VirtualService** (match / route / rewrite / timeout / retries) — including this
   repo's `apiHttp`/`webHttp` route tables — and a **DestinationRule** (subsets, trafficPolicy).
5. Explain the ingress **Gateway** (`istio-ingressgateway`, edge TLS termination) and the real
   request path — and why `gandalf` is a *test harness*, not the gateway.
6. Explain **mTLS/identity** (PeerAuthentication, SPIFFE, istiod as CA) and
   **AuthorizationPolicy** as Istio capabilities — and articulate why this repo *doesn't* use
   them (and what it does instead).
7. Explain mesh **observability** — `istio_requests_total` (from the Envoy sidecar) → Prometheus
   → KEDA — and **EnvoyFilter** as the escape hatch (the repo's Salesforce/Hasura Lua filters).

## Grounding

Every concept lands on real Istio config in `deployments/helm/` — the VirtualService/
DestinationRule templates, the ingress Gateway, EnvoyFilters, and `tom`'s DestinationRule —
mapped in [reference/repo-istio-map.md](./reference/repo-istio-map.md). External claims cite the
official Istio docs ([RESOURCES.md](./RESOURCES.md)) — never my memory.

## The seven-course plan (this track)

1. Containers & Local Dev ✅
2. Kubernetes ✅
3. Helm ✅
4. **Istio & Service Mesh** ← *you are here*
5. CI/CD & Delivery — how all this config reaches real clusters
6. Observability & Monitoring — Prometheus/Grafana/Jaeger/**Kiali** (the mesh's dashboards)
7. Infrastructure as Code — Terraform/GCP/GKE/Workload Identity