Gateway API Reaches Stable: Production-Ready for Modern Kubernetes Networking

Updated on Dec 7, 2025 7 min read cloud-native gateway-api ingress kubernetes networking production

The Kubernetes Gateway API has reached a significant milestone, with multiple resource types now stable and production-ready for modern Kubernetes deployments. After years of development and community feedback, the Gateway API provides a more expressive, extensible, and role-oriented approach to service networking compared to the traditional Ingress API.

Gateway API Overview

The Gateway API is the evolution of Kubernetes ingress, designed to address the limitations of the original Ingress resource. It provides a more powerful, flexible, and standardized way to configure networking in Kubernetes clusters.

Core Principles

The Gateway API is built on several key principles:

Role-Oriented: Resources map to different personas in an organization
Expressive: Rich routing capabilities beyond basic path and host matching
Extensible: Standard extension points for vendor-specific features
Portable: Works across different implementations and cloud providers
Type-Safe: Better validation and error handling than the original Ingress

Stable Resource Types

Several Gateway API resource types have reached stable (v1) status, making them production-ready:

1. GatewayClass

GatewayClass defines a class of Gateways that can be instantiated, similar to StorageClass for storage.

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: nginx-gateway
spec:
  controllerName: gateway.nginx.org/gateway-controller
  description: NGINX Gateway Controller

2. Gateway

Gateway describes how traffic can be translated to Services within the cluster.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-gateway
  namespace: gateway-system
spec:
  gatewayClassName: nginx-gateway
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: All
  - name: https
    protocol: HTTPS
    port: 443
    allowedRoutes:
      namespaces:
        from: All
    tls:
      mode: Terminate
      certificateRefs:
      - name: production-cert

3. HTTPRoute

HTTPRoute defines routing rules for HTTP/HTTPS traffic, replacing and extending Ingress functionality.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: webapp-route
  namespace: production
spec:
  parentRefs:
  - name: production-gateway
    namespace: gateway-system
  hostnames:
  - example.com
  - www.example.com
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: api-service
      port: 8080
      weight: 100
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: web-service
      port: 80
      weight: 100

Key Advantages Over Ingress

1. Role-Based Configuration

The Gateway API separates concerns across different roles:

Infrastructure Providers: Create and manage GatewayClass resources
Cluster Operators: Provision and configure Gateway instances
Application Developers: Create HTTPRoute, TCPRoute, or UDPRoute resources

This separation enables better multi-tenancy and security boundaries.

2. Advanced Routing Capabilities

HTTPRoute provides significantly more routing options than Ingress:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: advanced-routing
spec:
  parentRefs:
  - name: production-gateway
  hostnames:
  - api.example.com
  rules:
  # Header-based routing
  - matches:
    - headers:
      - name: x-api-version
        value: v2
    backendRefs:
    - name: api-v2-service
      port: 8080
  
  # Query parameter routing
  - matches:
    - queryParams:
      - name: beta
        type: Exact
        value: enabled
    backendRefs:
    - name: beta-service
      port: 8080
  
  # Method-based routing
  - matches:
    - method: POST
      path:
        type: PathPrefix
        value: /upload
    backendRefs:
    - name: upload-service
      port: 8080
  
  # Request mirroring
  - matches:
    - path:
        type: PathPrefix
        value: /
    filters:
    - type: RequestMirror
      requestMirror:
        backendRef:
          name: logging-service
          port: 8080
    backendRefs:
    - name: main-service
      port: 80

3. Traffic Splitting and Canary Deployments

Built-in support for traffic splitting enables sophisticated deployment strategies:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: canary-deployment
spec:
  parentRefs:
  - name: production-gateway
  hostnames:
  - app.example.com
  rules:
  - backendRefs:
    - name: stable-service
      port: 80
      weight: 90
    - name: canary-service
      port: 80
      weight: 10

4. Cross-Namespace Routing

Gateway API supports routing across namespaces, enabling better organization and isolation:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: cross-namespace-route
  namespace: frontend
spec:
  parentRefs:
  - name: shared-gateway
    namespace: infrastructure
  hostnames:
  - app.example.com
  rules:
  - backendRefs:
    - name: backend-service
      namespace: backend
      port: 8080

Additional Resource Types

Beyond HTTPRoute, the Gateway API defines other route types:

TCPRoute

For TCP traffic routing:

apiVersion: gateway.networking.k8s.io/v1
kind: TCPRoute
metadata:
  name: database-route
spec:
  parentRefs:
  - name: production-gateway
  rules:
  - backendRefs:
    - name: postgres-service
      port: 5432

UDPRoute

For UDP traffic routing:

apiVersion: gateway.networking.k8s.io/v1
kind: UDPRoute
metadata:
  name: dns-route
spec:
  parentRefs:
  - name: production-gateway
  rules:
  - backendRefs:
    - name: dns-service
      port: 53

TLSRoute

For TLS passthrough:

apiVersion: gateway.networking.k8s.io/v1
kind: TLSRoute
metadata:
  name: tls-passthrough
spec:
  parentRefs:
  - name: production-gateway
  hostnames:
  - secure.example.com
  rules:
  - backendRefs:
    - name: secure-service
      port: 443

Implementation Ecosystem

Multiple Gateway API implementations are available and production-ready:

NGINX Gateway Fabric

NGINX’s implementation of the Gateway API:

# Install NGINX Gateway Fabric
kubectl apply -f https://raw.githubusercontent.com/nginxinc/nginx-gateway-fabric/main/deploy/manifests/install.yaml

Istio

Istio provides Gateway API support alongside its service mesh:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: istio-gateway
spec:
  gatewayClassName: istio
  listeners:
  - name: http
    protocol: HTTP
    port: 80

Kong Gateway

Kong provides a full-featured Gateway API implementation:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: kong
spec:
  controllerName: konghq.com/kic-gateway-controller

Envoy Gateway

A vendor-neutral Gateway API implementation using Envoy:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: envoy
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller

AWS Load Balancer Controller

AWS provides Gateway API support through their Load Balancer Controller:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: aws-lb
spec:
  controllerName: elbv2.k8s.aws/gateway-controller

Migration from Ingress

Key Differences

When migrating from Ingress to Gateway API, understand these key differences:

Ingress	Gateway API
Single resource type	Multiple resource types (Gateway, HTTPRoute, etc.)
Namespace-scoped only	Supports cross-namespace routing
Limited routing features	Advanced routing with headers, query params, etc.
Basic traffic splitting	Native weight-based splitting
Limited TLS support	Enhanced TLS configuration
Vendor-specific annotations	Standard extension points

Migration Steps

Assess Current Ingress Usage

# List all Ingress resources
kubectl get ingress --all-namespaces

# Export Ingress configurations
kubectl get ingress -n production -o yaml > ingress-configs.yaml

Install a Gateway API Implementation

Choose and install a Gateway API implementation that meets your needs.

Create Gateway Resources

Set up Gateway instances to replace Ingress controllers:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: migration-gateway
  namespace: gateway-system
spec:
  gatewayClassName: nginx-gateway
  listeners:
  - name: http
    protocol: HTTP
    port: 80
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      certificateRefs:
      - name: tls-cert

Convert Ingress to HTTPRoute

Translate Ingress rules to HTTPRoute resources:

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

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

Test and Validate

Gradually migrate services and validate functionality:

# Apply HTTPRoute
kubectl apply -f web-route.yaml

# Test routing
curl -H "Host: example.com" http://gateway-ip/

# Monitor Gateway status
kubectl get gateway -n gateway-system
kubectl describe gateway migration-gateway -n gateway-system

Gradual Rollout

Use traffic splitting to gradually migrate:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: gradual-migration
spec:
  parentRefs:
  - name: migration-gateway
  rules:
  - backendRefs:
    # Keep Ingress controller running initially
    - name: ingress-service
      port: 80
      weight: 10
    # Route most traffic to Gateway API
    - name: gateway-service
      port: 80
      weight: 90

Best Practices

1. Use GatewayClasses for Multi-tenancy

Define GatewayClasses for different teams or environments:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: team-a-gateway
spec:
  controllerName: gateway.nginx.org/gateway-controller
  parametersRef:
    group: gateway.nginx.org
    kind: GatewayClassConfig
    name: team-a-config

2. Implement Namespace Policies

Control which namespaces can use which Gateways:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shared-gateway
spec:
  gatewayClassName: nginx-gateway
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: Selector
        selector:
          matchLabels:
            gateway-access: allowed

3. Use Reference Grants for Cross-Namespace

Enable secure cross-namespace references:

apiVersion: gateway.networking.k8s.io/v1
kind: ReferenceGrant
metadata:
  name: allow-frontend-to-backend
  namespace: backend
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    namespace: frontend
  to:
  - group: ""
    kind: Service

4. Implement Proper TLS Management

Use proper certificate management:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: secure-gateway
spec:
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      certificateRefs:
      - name: tls-cert
        namespace: cert-manager

Performance and Scalability

Gateway API implementations typically offer:

Better Performance: More efficient routing decisions
Horizontal Scalability: Better support for scaling Gateway instances
Resource Efficiency: Lower resource overhead than traditional Ingress controllers
Connection Pooling: Better connection management

Future Developments

The Gateway API continues to evolve with new features:

GRPCRoute: Native support for gRPC routing
TCPRoute Enhancements: Advanced TCP routing features
Service Mesh Integration: Better integration with service mesh technologies
Enhanced Observability: Built-in metrics and tracing support

Conclusion

The Gateway API reaching stable status represents a significant milestone in Kubernetes networking. With its role-oriented design, advanced routing capabilities, and broad ecosystem support, it provides a compelling path forward for modern Kubernetes deployments.

Key takeaways:

Production Ready: Multiple stable resource types available
Enhanced Capabilities: Significantly more powerful than traditional Ingress
Ecosystem Support: Multiple implementations available
Migration Path: Clear migration strategies from Ingress
Future-Proof: Active development and community support

Organizations should evaluate Gateway API implementations and plan migrations from Ingress, especially as the ecosystem continues to mature and traditional Ingress controllers face deprecation timelines.

The Gateway API is not just an evolution of Ingress—it’s a fundamental improvement that enables better security, scalability, and operational practices for Kubernetes networking.

For more information about Gateway API, visit the official Gateway API documentation and the Kubernetes Gateway API repository.