Ingress vs Gateway API

Ingress and Gateway API both provide HTTP routing in Kubernetes, but they serve different needs and have different capabilities. Understanding the differences helps you choose the right solution for your use case and plan migrations when needed.

Overview Comparison

graph TB subgraph ingress[Ingress] A[Single Resource] B[HTTP/HTTPS Only] C[Simple Routing] D[Widely Supported] E[Mature & Stable] end subgraph gatewayapi[Gateway API] F[Multiple Resources] G[HTTP, TCP, UDP, TLS] H[Advanced Routing] I[Growing Support] J[Modern & Evolving] end style ingress fill:#fff4e1 style gatewayapi fill:#e8f5e9

Key Differences

Architecture

Ingress:

Single resource (Ingress) for all configuration
Controller-specific annotations for advanced features
Tightly coupled to controller implementation

graph TB subgraph ingress[Ingress Architecture] A[Ingress Resource] --> B[Controller Reads] B --> C[Configures Load Balancer] end style A fill:#fff4e1

Gateway API:

Multiple resources (Gateway, HTTPRoute, etc.)
Standardized API with optional extensions
Clear separation between infrastructure and application

graph TB subgraph gatewayapi[Gateway API Architecture] D[Gateway Resource] --> E[Infrastructure Layer] F[HTTPRoute Resource] --> G[Application Layer] E --> H[Controller] G --> H H --> I[Configures Load Balancer] end style D fill:#e8f5e9 style F fill:#e8f5e9

Protocol Support

Ingress:

HTTP/HTTPS only
TCP/UDP requires controller-specific annotations (limited support)

Gateway API:

HTTP/HTTPS (HTTPRoute)
TCP (TCPRoute)
UDP (UDPRoute)
TLS (TLSRoute)
Standardized multi-protocol support

Routing Capabilities

Ingress:

Host-based routing
Path-based routing
Basic SSL/TLS termination
Advanced features via annotations (controller-specific)

Gateway API:

Host-based routing
Path-based routing (Prefix, Exact, RegularExpression)
Header matching
Query parameter matching
Method matching
Traffic splitting
Request/response modification
Standardized advanced features

Role Separation

Ingress:

Single resource managed by one team
No built-in role separation
RBAC provides some separation

Gateway API:

Infrastructure providers manage Gateway
Application developers manage HTTPRoute
Built-in role-based model
Better for multi-tenant scenarios

Feature Comparison

Feature	Ingress	Gateway API
Protocols	HTTP/HTTPS	HTTP, TCP, UDP, TLS
Path Matching	Prefix, Exact	Prefix, Exact, Regex
Header Matching	Via annotations	Native support
Traffic Splitting	Via annotations	Native support
Request Modification	Via annotations	Native filters
Role Separation	Manual (RBAC)	Built-in
Multi-protocol	Limited	Full support
Maturity	Very mature	Evolving
Adoption	Universal	Growing

When to Use Ingress

Use Ingress when:

✅ Simple HTTP routing - Basic host/path routing is sufficient
✅ Wide compatibility - Need universal controller support
✅ Mature solution - Want battle-tested, stable solution
✅ Quick setup - Need immediate solution with extensive documentation
✅ Standard use cases - Common web application routing needs
✅ Existing infrastructure - Already using Ingress successfully

Ingress is ideal for:

Standard web applications
Simple microservices routing
Teams new to Kubernetes
Environments requiring maximum compatibility

When to Use Gateway API

Use Gateway API when:

✅ Advanced routing - Need header matching, traffic splitting, etc.
✅ Multiple protocols - Need TCP, UDP, or TLS routing
✅ Role separation - Want infrastructure/app developer separation
✅ Future-proofing - Gateway API is the direction Kubernetes is heading
✅ Multi-tenant - Multiple teams sharing infrastructure
✅ Rich features - Need standardized advanced features

Gateway API is ideal for:

Complex routing requirements
Multi-protocol applications
Large organizations with role separation
Modern Kubernetes deployments
Future-looking projects

Migration Considerations

From Ingress to Gateway API

Migration involves:

Deploy Gateway API controller - Ensure controller supports Gateway API
Create Gateway resource - Replace Ingress with Gateway
Convert Ingress to HTTPRoute - Map Ingress rules to HTTPRoute
Update references - Update any code/config referencing Ingress
Test thoroughly - Verify routing works identically

Example Migration

Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

Gateway API equivalent:

# Gateway (infrastructure)
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: nginx
  listeners:
  - name: http
    protocol: HTTP
    port: 80

# HTTPRoute (application)
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-route
spec:
  parentRefs:
  - name: example-gateway
  hostnames:
  - example.com
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: api-service
      port: 80

Coexistence

Ingress and Gateway API can coexist:

Different controllers handle each
Use different ingressClassName and gatewayClassName
Route different traffic to each
Gradual migration possible

graph TB A[Traffic] --> B{Which Controller?} B -->|Ingress Class| C[Ingress Controller] B -->|Gateway Class| D[Gateway API Controller] C --> E[Services] D --> E style C fill:#fff4e1 style D fill:#e8f5e9

Controller Support

Ingress Controllers

Universal support - All major controllers support Ingress
Mature implementations - Well-tested and documented
Extensive features - Rich annotation ecosystems

Gateway API Controllers

Growing support - Major controllers adding Gateway API support
NGINX - Gateway API support available
Traefik - Gateway API support available
Istio - Native Gateway API support
Kong - Gateway API support available

Check controller documentation for current Gateway API support status.

Decision Matrix

Choose based on your priorities:

Choose Ingress if:

✅ Need immediate, universal compatibility
✅ Simple routing requirements
✅ Existing Ingress infrastructure
✅ Maximum stability and maturity

Choose Gateway API if:

✅ Need advanced routing features
✅ Multi-protocol requirements
✅ Role separation important
✅ Future-proofing is priority
✅ Controller supports Gateway API

Best Practices

For Ingress

Use standard annotations - Stick to well-documented annotations
Document controller-specific features - Note which controller you’re using
Test thoroughly - Verify routing works as expected
Keep it simple - Avoid overly complex configurations
Monitor controller - Ensure controller is healthy

For Gateway API

Check controller support - Verify your controller supports needed features
Use role separation - Leverage Gateway/Route separation
Start simple - Begin with basic routing, add complexity
Monitor evolution - Gateway API is evolving, stay updated
Test thoroughly - Gateway API is newer, test your use cases

Future Outlook

Ingress:

Will continue to be supported
Mature and stable
May see limited new features
Remains the safe, compatible choice

Gateway API:

Active development
Growing adoption
Future direction for Kubernetes networking
More features being added

Ingress vs Gateway API

Overview Comparison

Key Differences

Architecture

Protocol Support

Routing Capabilities

Role Separation

Feature Comparison

When to Use Ingress

When to Use Gateway API

Migration Considerations

From Ingress to Gateway API

Example Migration

Coexistence

Controller Support

Ingress Controllers

Gateway API Controllers

Decision Matrix

Best Practices

For Ingress

For Gateway API

Future Outlook

See Also