Q: How do you evaluate and implement Istio Ambient Mode versus sidecar-based service mesh in your platform templates, and how does ambient mode solve sidecar tax, lifecycle coupling, and upgrade friction across hundreds of microservices?

Analyze operational friction: sidecar model requires pod restarts on proxy upgrades, inflates memory footprints by ~50-100MB per container, and complicates pod lifecycle hooks. Ambient mode runs an untrusted per-node L4 proxy (ztunnel) via eBPF/Geneve tunnels for mTLS and auth policies, delegating optional L7 traffic management (retries, rate limiting, header routing) to standalone waypoint Envoy instances managed via Gateway API.

# Namespace enablement for ambient mode
apiVersion: v1
kind: Namespace
metadata:
  name: checkout-service
  labels:
    istio.io/dataplane-mode: ambient

Expose service mesh capabilities to developers through standard Gateway API resources rather than raw VirtualServices. When a service requests L7 policies (e.g., canary deployments or JWT auth), the platform reconciler dynamically deploys a dedicated waypoint proxy without modifying developer workloads.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: checkout-waypoint
  namespace: checkout-service
  labels:
    istio.io/waypoint-for: service
spec:
  gatewayClassName: istio-waypoint
  listeners:
  - name: mesh
    port: 15008
    protocol: HBONE

Decouple control plane and proxy updates from tenant deployments. Upgrading ztunnel is performed as a rolling DaemonSet upgrade with in-flight socket handover, achieving zero pod restarts across thousands of tenant workloads.

helm upgrade istio-cni istio/cni -n istio-system
helm upgrade ztunnel istio/ztunnel -n istio-system --wait