Kubernetes Gateway API — Next-Generation Service Networking for K8s

Introduction

The Kubernetes Gateway API is a collection of CRDs that define a portable, expressive API for service networking. It was designed by the Kubernetes SIG-Network community to replace the limited Ingress resource with a richer model that separates infrastructure concerns from application routing and supports protocols beyond HTTP.

What Gateway API Does

• Defines GatewayClass, Gateway, and Route resources for layered networking control
• Supports HTTP, gRPC, TCP, TLS, and UDP routing through typed Route resources
• Enables role-based resource ownership separating infra admins from app developers
• Provides traffic splitting, header-based matching, and request mirroring
• Works across multiple implementations without vendor lock-in

Architecture Overview

Gateway API uses three layers: GatewayClass (defines the controller implementation), Gateway (represents an infrastructure load balancer or proxy instance), and Routes (HTTPRoute, GRPCRoute, TCPRoute, TLSRoute) that attach to Gateways and define routing rules. This separation lets cluster operators manage Gateways while developers manage their own Routes independently. Implementations like Envoy Gateway, Istio, Cilium, and Contour watch these CRDs and configure the data plane accordingly.

Self-Hosting & Configuration

• Install Gateway API CRDs via the official release YAML
• Deploy a conformant implementation (Envoy Gateway, Istio, Cilium, Contour, or others)
• Create a GatewayClass pointing to your chosen controller
• Define Gateway resources with listener configurations for ports and protocols
• Attach HTTPRoute or other Route resources to expose application services

Key Features

• Role-oriented design with clear separation between infra and app concerns
• Multi-protocol support beyond HTTP including gRPC, TCP, and TLS passthrough
• Traffic splitting for canary deployments and A/B testing at the route level
• Conformance testing suite ensures portable behavior across implementations
• Extensible via policy attachment for auth, rate limiting, and custom filters

Comparison with Similar Tools

• Ingress — simpler but limited to HTTP, no role separation, implementation-specific annotations
• Istio VirtualService — powerful but Istio-specific, not portable across service meshes
• Traefik IngressRoute — Traefik-specific CRD with similar expressiveness but vendor lock-in
• Contour HTTPProxy — Contour-specific CRD, now superseded by Gateway API support in Contour

FAQ

Q: Does Gateway API replace Ingress? A: Gateway API is the successor to Ingress. Ingress continues to work, but new features are being developed in Gateway API. Migration paths exist for most use cases.

Q: Which implementations support Gateway API? A: Over 20 implementations support Gateway API including Envoy Gateway, Istio, Cilium, Contour, Traefik, Kong, and NGINX Gateway Fabric.

Q: Can I use Gateway API for internal (east-west) traffic? A: Yes. Some implementations support using Gateway API for service mesh routing, and the GAMMA initiative extends the API for mesh use cases.

Q: Is Gateway API production-ready? A: HTTPRoute reached GA (v1) status. GRPCRoute, TLSRoute, and TCPRoute are at varying stages of maturity in the experimental channel.

Sources

• https://github.com/kubernetes-sigs/gateway-api
• https://gateway-api.sigs.k8s.io/