Service mesh

Exam tasks: 2.1 (networking: service mesh)

The decision: does this requirement (encrypt all service-to-service traffic, retry failed calls, shift 5% of traffic to a new version, see per-call latency) need a service mesh, and if so, which data plane model?

What a mesh addsCopy Anchor Link

Kubernetes Services give you discovery and simple load balancing. A service mesh moves the rest of service-to-service concerns out of application code and into infrastructure:

• The mesh handles east-west traffic (service to service inside the cluster). North-south traffic still enters through a Gateway or Ingress, which the mesh can also secure.
• Apps don't change. The mesh intercepts traffic transparently.

Data plane and control planeCopy Anchor Link

• The data plane is the set of proxies that actually carry traffic.
• The control plane programs those proxies, issues workload certificates and watches the Kubernetes API for Services and endpoints. It is not in the request path.

Sidecar vs ambientCopy Anchor Link

• ztunnel handles mTLS, L4 authorization and TCP telemetry. A waypoint (an Envoy proxy, usually per namespace) adds HTTP routing, retries and L7 policy.
• Kubernetes also has native sidecar containers (init containers with restartPolicy: Always), which start before and stop after the app container. Meshes use them to fix startup and Job-completion ordering problems.

mTLS and workload identityCopy Anchor Link

• In plain TLS only the server proves who it is. In mutual TLS, both sides present certificates, so the server also knows which workload is calling.
• The mesh control plane acts as a certificate authority. It issues short-lived certificates to each workload, usually tied to the Pod's ServiceAccount, and rotates them automatically.
• Istio identities follow SPIFFE (spiffe://<trust-domain>/ns/<namespace>/sa/<serviceaccount>). SPIFFE and its reference implementation SPIRE are CNCF graduated.
• Authorization policies can then say "only the checkout ServiceAccount may call billing", which is stronger than IP-based rules because Pod IPs change.
• Linkerd turns on mTLS automatically for all meshed TCP traffic. Istio supports permissive mode (accept plain text and mTLS during migration) and strict mode (mTLS only).

Traffic managementCopy Anchor Link

• Retries and timeouts: the proxy retries failed calls and gives up after a deadline, so apps don't need their own retry logic.
• Circuit breaking: stop sending traffic to an instance that keeps failing (outlier detection), so one bad replica doesn't drag down callers.
• Weighted routing: send 90% to v1 and 10% to v2 for a canary, independent of replica counts.
• Traffic mirroring: copy live requests to a new version and discard its responses.
• Fault injection: add delays or errors on purpose to test resilience.

The projectsCopy Anchor Link

• Envoy (CNCF graduated) is a general-purpose L7 proxy. It's the data plane of Istio and of many Gateway API controllers. It's a proxy, not a mesh by itself.
• Cilium offers mesh features (mTLS, L7 policy) using eBPF and per-node Envoy, without sidecars.

Standards: from SMI to GAMMACopy Anchor Link

• GAMMA (Gateway API for Mesh Management and Administration) uses the same HTTPRoute you use for ingress, but attaches it to a Service instead of a Gateway. The route then applies to traffic going to that Service inside the mesh.
• Mesh support is part of the Gateway API standard channel since v1.1. Istio, Linkerd and Cilium implement it.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: recommender-canary
  namespace: shop
spec:
  parentRefs:
    - group: ""
      kind: Service
      name: recommender
      port: 8080
  rules:
    - backendRefs:
        - name: recommender-v1
          port: 8080
          weight: 90
        - name: recommender-v2
          port: 8080
          weight: 10

ScenariosCopy Anchor Link

Further readingCopy Anchor Link

• Istio: sidecar or ambient?
• Linkerd: automatic mTLS
• Gateway API for service mesh (GAMMA)
• Sidecar containers