Kubernetes Gateway API v1alpha1: Ingress Evolution Begins

Introduction

On July 20, 2021, the Kubernetes SIG Network released Gateway API v1alpha1, the first stable alpha version of the modern ingress standard. After years of limitations with the original Ingress API, Gateway API introduced a role-oriented, extensible design that separated infrastructure concerns from application routing.

The original Ingress API served Kubernetes well, but it had limitations: no cross-namespace support, limited routing expressiveness, and unclear ownership boundaries. Gateway API v1alpha1 addressed these by introducing role-oriented resources (Gateway, HTTPRoute) that separated infrastructure providers from application developers, enabling more sophisticated routing patterns.

Why Gateway API?

• Role-Oriented Design: Separates infrastructure (Gateway) from application routing (HTTPRoute).
• Cross-Namespace Support: Routes can span namespaces, enabling multi-tenant scenarios.
• Extensible: Supports custom implementations and extensions for specific use cases.
• Portable: Works across different Kubernetes distributions and cloud providers.

Core Resources

Gateway

Defines network endpoints and capabilities for handling traffic:

apiVersion: gateway.networking.k8s.io/v1alpha1
kind: Gateway
metadata:
  name: my-gateway
spec:
  gatewayClassName: istio
  listeners:
  - name: web
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: All

HTTPRoute

Defines routing rules for HTTP and HTTPS traffic:

apiVersion: gateway.networking.k8s.io/v1alpha1
kind: HTTPRoute
metadata:
  name: my-route
spec:
  parentRefs:
  - name: my-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: api-service
      port: 80

Key Features (v1alpha1)

1. Role Separation: Infrastructure teams manage Gateways; application teams manage HTTPRoutes.
2. Cross-Namespace Routing: HTTPRoutes can reference services in different namespaces.
3. Advanced Matching: Path, header, and query parameter matching for sophisticated routing.
4. Backend Selection: Flexible service and endpoint selection with port and weight support.
5. TLS Configuration: Per-listener TLS termination with certificate management.

Comparison with Ingress

Getting Started

Install Gateway API CRDs:

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v0.4.0/standard-install.yaml

Create a Gateway:

apiVersion: gateway.networking.k8s.io/v1alpha1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: acme-lb
  listeners:
  - name: http
    protocol: HTTP
    port: 80

Create an HTTPRoute:

apiVersion: gateway.networking.k8s.io/v1alpha1
kind: HTTPRoute
metadata:
  name: example-route
spec:
  parentRefs:
  - name: example-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: example-service
      port: 80

Use Cases

• Multi-Tenant Clusters: Teams manage their own HTTPRoutes while infrastructure manages Gateways.
• Advanced Routing: Header-based routing, weighted traffic splitting, and canary deployments.
• Cross-Namespace Services: Route to services in different namespaces for microservices architectures.
• Cloud Portability: Same Gateway API configuration works across different cloud providers.

Implementation Status (v1alpha1)

Early implementations included:

• Istio: Full Gateway API support with Envoy data plane.
• Contour: Envoy-based implementation with HTTPRoute support.
• Traefik: Gateway API support in Traefik 2.6+.
• Kong: Gateway API implementation for Kong Ingress Controller.

Operational Considerations

• Alpha Stability: v1alpha1 is alpha; expect API changes in future releases.
• Implementation Gaps: Not all implementations support all features; check compatibility.
• Migration Path: Plan migration from Ingress to Gateway API gradually.
• Learning Curve: Teams need to understand Gateway API concepts and resources.

Common Patterns

• Namespace Isolation: Use Gateway namespace restrictions for multi-tenant security.
• Traffic Splitting: Use weighted backendRefs for canary deployments.
• Header Routing: Route traffic based on headers for A/B testing or feature flags.
• TLS Termination: Configure TLS at the Gateway level for centralized certificate management.

Limitations (v1alpha1)

• Alpha API: v1alpha1 is subject to change; not recommended for production without careful planning.
• Implementation Coverage: Not all Gateway API features are supported by all implementations.
• Migration Complexity: Migrating from Ingress requires understanding both APIs.
• Documentation: Early documentation may be incomplete; rely on examples and community.

Looking Ahead

Gateway API v1alpha1 set the foundation for:

• v1beta1: Beta stability with improved API design and broader implementation support.
• GA Release: General availability with stable APIs and production-ready implementations.
• Extended Features: Support for TCP, UDP, and other protocols beyond HTTP.
• Ecosystem Growth: More implementations and tooling around Gateway API.

Summary

Gateway API v1alpha1 marked the beginning of a new era for Kubernetes ingress. By introducing role-oriented resources and cross-namespace support, it provided a foundation for more sophisticated edge routing that would evolve into the production-ready standard used today.