How Kubernetes Gateway API plans to solve Ingress resource fragmentation
If you had to set up Ingress resources in Kubernetes to use an ingress controller, you’ve probably experienced first hand how easily they can get full of annotations inline into each Ingress resource. By specification, an Ingress resources route can only point to one service, which is also a significant limitation for more complex routing/load balancing scenarios. Over the last years, the ecosystem is getting more fragmented with the appearance of Custom Resources (CRDs) for this purpose, which makes using Ingress resource definitions harder to maintain in terms of implementation with different underlying cluster setups.
The SIG-NETWORK community is working on the Kubernetes Gateway API project, aiming towards to evolve Kubernetes service networking through expressive, extensible, and role-oriented interfaces that are implemented by many vendors and have broad industry support [1].
As of today, on a high level, this project provides the following new APIs to Kubernetes:
- GatewayClass — Represents a class of Gateways that can be instantiated. It is a cluster-scoped resource and allows to decouple this responsibility to the infrastructure provider.
- Gateway — An instance of GatewayClass, creating some load balancing configuration or infrastructure when applied, abstracting the way it is created. It allows to split this responsibility from the cluster operator and the infrastructure provider.
- HTTPRoute — Represents the routing behavior of HTTP requests from a Gateway listener to an API object (i.e. Service(s)). Defines specification for TLS certificate, hostname(s) and routing rules to be set in place, which may be path based or header based. This API is perfect for application developers to start adding their new microservices within the available gateways.
- TCPRoute, UDPRoute and TLSRoute — Another route representations for different protocols. Gateway API is designed to work with multiple protocols.
In a visual representation, Picture 1 depicts how these different resources interact with each other. You can see how this would allow decoupling responsibilities and effort between developers. Security-wise this is a good scenario since Gateway API uses Kubernetes RBAC, enabling you to delegate duties within your organization structure, solving the design limitations of Ingress resource in collaboration and shared tenancy.
This new API looks very exciting, and I believe it can gain traction over time, as a replacement for the Ingress resource, for more complex use-cases. If you want to start experimenting with it, this page of the documentation should help you get started. The implementation status is still in an alpha stage, with Contour, Ambassador, Gloo, GKE, Istio, Kong and Traefik working towards adding support for this initiative. Hopefully, soon, we should see more support from other vendors!
