Ingress, Gateway, And Service Mesh
Traffic tools should be selected by ownership model and control needs. A small platform can start with ingress. A multi-team platform may need Gateway API. A service mesh should be justified by runtime traffic controls, not by fashion.
Decision table
| Need | Fit |
|---|---|
| Simple HTTP routing and TLS | Ingress controller |
| Multi-team route ownership | Gateway API |
| mTLS, retries, traffic splitting, service telemetry | Service mesh |
| L4 and L7 shared edge control | Gateway API plus controller-specific features |
Senior constraints
- Separate external edge from internal service-to-service policy.
- Keep TLS certificate lifecycle automated.
- Define route ownership. A central team should not hand-edit every application route.
- Treat mesh sidecars or ambient dataplanes as operational dependencies with upgrade plans.
Failure modes
- Ingress controller becomes overloaded by every tenant and every protocol.
- Teams create conflicting host and path routes.
- Mesh policy blocks traffic because identity labels changed.
- Retries amplify downstream failure.