Deep Dive into Kubernetes Gateway API
9 hours ago
- #Gateway API
- #Networking
- #Kubernetes
- Kubernetes Gateway API is positioned as the successor to the deprecated Ingress API, with NGINX Ingress Controller scheduled for deprecation in March 2026.
- The Ingress API evolved from early Kubernetes Service types (ClusterIP, NodePort, LoadBalancer, ExternalName) to address limitations in exposing applications, but it faced issues like limited features, reliance on custom annotations, lack of policy enforcement, and insecure cross-namespace references.
- Gateway API addresses Ingress API limitations by being more expressive, separating concerns with resources like GatewayClass, Gateway, and Routes (e.g., HTTPRoute, GRPCRoute), supporting cross-namespace references with ReferenceGrant, and enabling extensions via Policies.
- Gateway API implementations vary, with options including Envoy Gateway (feature-rich and extensible), Istio (service mesh-focused), kgateway (conformant with custom transformations), Traefik (user-friendly but may have performance concerns), NGINX Gateway Fabric (NGINX-based with some enterprise features), Cilium Service Mesh (Cilium-integrated), and Kong (OSS image availability concerns).
- Migration from Ingress to Gateway API involves installing CRDs, setting up Gateway resources, converting Ingress to Routes using tools like ingress2gateway, and planning a gradual traffic switch, while considering compliance risks and CVEs associated with outdated Ingress Controllers.