Kubernetes Gateway API vs Ingress: A Practical Production Model for Platform Teams
Kubernetes Gateway API vs Ingress: A Practical Production Model for Platform Teams
Ingress still works, but new routing requirements in shared clusters are better served by Gateway API. This guide explains what changes operationally, what to migrate first, and how to validate support safely.
TL;DR
Ingress is not removed from Kubernetes, but its API is frozen and Kubernetes recommends Gateway API for future evolution. The practical win for platform teams is governance: GatewayClass and Gateway can be owned by infrastructure teams, while HTTPRoute and related route objects can be owned by application teams. Migration should be incremental, with Ingress and Gateway resources coexisting while behavior is validated against your specific implementation. Production success depends on conformance checks, supported feature verification, and explicit cross-namespace attachment policy rather than direct YAML translation.
Gateway API Is Not Just a Syntax Upgrade from Ingress
Most teams evaluate Gateway API by comparing YAML fields. That is useful, but it misses the operational reason this migration matters. Ingress can still route production traffic effectively, but its API is frozen, and new routing governance requirements in shared clusters are better handled by Gateway API’s resource boundaries.
Kubernetes explicitly states that Ingress remains available while recommending Gateway for ongoing evolution. For platform teams, the pragmatic takeaway is simple: keep existing Ingress stable, but design new routing governance around Gateway API.
1. Treat Ownership Separation as the Primary Design Goal
Ingress often accumulates controller-specific annotations and mixed concerns. Gateway API gives you structured ownership layers:
GatewayClass: platform-level controller intentGateway: listener and attachment policyHTTPRouteand other routes: application routing intent
This supports a cleaner policy model in multi-team clusters.
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: shared-edge
namespace: edge-platform
spec:
gatewayClassName: standard-edge
listeners:
- name: https
protocol: HTTPS
port: 443
allowedRoutes:
namespaces:
from: Selector
selector:
matchLabels:
edge-attach: "enabled"apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: tenant-a-api
namespace: tenant-a
spec:
parentRefs:
- name: shared-edge
namespace: edge-platform
rules:
- matches:
- path:
type: PathPrefix
value: /api
backendRefs:
- name: api-v1
port: 8080
weight: 90
- name: api-v2
port: 8080
weight: 102. Use Gateway API Features Deliberately, Not All at Once
Gateway API supports richer behavior such as weighted traffic splitting and advanced matching, but feature depth varies by implementation and version. Production design should start with a narrow supported subset and expand only after validation.
A safe first scope:
- route attachment policy with
allowedRoutes - basic
HTTPRoutehost/path matching - controlled weighted backend rollout for one service
Then expand into broader traffic policy only after implementation checks pass in staging and production-like load.
3. Validate Conformance Before Large-Scale Migration
Gateway API documentation distinguishes Core, Extended, and implementation-specific capabilities. Teams should assume feature variance until validated.
At minimum, validate:
- which route kinds your controller supports in your exact version
- behavior for weighted traffic and header/method matching
- cross-namespace attachment policy enforcement
- coexistence behavior with existing ingress resources
For AWS Load Balancer Controller specifically, follow its Gateway support documentation rather than assuming upstream examples map 1:1 to your deployment.
4. Migrate in Parallel, Not by Big-Bang Cutover
Parallel migration avoids avoidable outage risk.
Recommended sequence:
- Keep current Ingress in service.
- Deploy Gateway objects for one low-risk route.
- Validate route policy, metrics, and failure behavior.
- Shift traffic gradually with weighted backend references.
- Repeat by service class.
This sequence creates rollback points per service instead of per cluster.
5. Why This Model Holds Up Better Than Ingress-Only Governance
| Control Area | Ingress-Only Pattern | Gateway-Based Pattern | Production Benefit |
|---|---|---|---|
| Ownership boundaries | Platform and app concerns often mixed in single objects | Platform manages GatewayClass/Gateway, app teams manage Routes | Clearer policy control and review ownership |
| Cross-namespace governance | Often implemented through conventions | Attachment policy is explicit in listener configuration | Fewer accidental route attachments |
| Traffic rollout behavior | Controller-specific patterns vary | Weighted backend refs modeled at route level | More consistent progressive delivery patterns |
| Migration safety | Replace-and-hope tendency | Parallel Ingress and Gateway operation | Lower blast radius and clearer rollback |
| Feature validation | Implicit trust in docs | Conformance plus implementation verification | Fewer production surprises |
What To Do Next
- Catalog current ingress objects by complexity and business criticality.
- Define ownership boundaries for GatewayClass, Gateway, and Route resources.
- Build a migration pilot for one non-critical route with weighted rollout.
- Add conformance and implementation checks to release readiness criteria.
Frequently Asked Questions
Q: Should we stop using Ingress immediately? No. Keep stable ingress traffic paths while introducing Gateway API incrementally.
Q: Is Gateway API guaranteed to behave identically across controllers? No. Validate behavior against your controller’s documented support and observed runtime behavior.
Q: Can Gateway API improve team autonomy? Yes, when ownership boundaries and attachment policy are enforced through resource design instead of informal conventions.
Comments
Post a Comment