Ingress, Service Mesh & Gateway API
Ingress is the legacy API; Gateway API is its principled replacement. Reach for a service mesh only when you need mTLS, traffic shifting, or per-service policy.
Deep dive
Ingress vs Gateway API
Ingress mixes routing with controller-specific annotations — portability is fiction. Gateway API splits responsibilities: GatewayClass (infra), Gateway (network endpoint), HTTPRoute/GRPCRoute (routing). Cleaner RBAC, real type safety.
When you need a mesh
- mTLS everywhere without app changes.
- Traffic shifting for canaries based on headers/percentage.
- Per-service authZ at L7. Don't add Istio because a blog said so — it's a non-trivial operational burden (sidecar resource cost, control plane upgrades, debug complexity). Linkerd or Cilium with eBPF often cover 80% of needs with 20% of the pain.
Real-world example
From productionTeam adopted Istio for "future-proofing", spent 6 months learning operator quirks. Actual need was mTLS + simple canaries. Migrated to Linkerd in 3 weeks, same outcomes, no envoy sidecar tax.
Interview questions
1 senior-levelQ1Why move from Ingress to Gateway API?▾
Portability and cleaner separation of roles. Ingress requires controller-specific annotations for anything non-trivial. Gateway API standardizes routing, splits cluster-operator and app-team responsibilities, and is the long-term direction.
Common mistakes
Adopting a service mesh before having a use case for it.
Mixing multiple Ingress controllers without clear ownership.
Trade-offs
Service mesh adds latency (~1–2 ms) and operational complexity in exchange for L7 policy.