Kubernetes Gateway API — A successor to existing Kubernetes Ingress!
The Ingress resource created a diverse ecosystem of Ingress controllers which were used across hundreds of thousands of clusters in a standardised & consistent way that helped users to adopt Kubernetes.
However, with similar CRDs & overloaded annotations, there are signs of fragmentation which have led limiting the future of Kubernetes Ingress.
Initially Ingress was designed for more of a “self-service” oriented entity which was more due to that fact that at that time there were -
- Few tenants
- and dev owners were empowered for the whole deployment
So, Ingress had these personas mapping in mind during it’s inception -
However, a lot have evolved now which have led to -
- Multiple team/roles interactions
- and potentially multiple co-existing implementations
Now the personas landscape has evolved to something like -
These (& many others) have led to the evolution of the new Kubernetes Gateway API which proposes the following personas mapping -
With this in place, we have a clear definition of accountability with the right RBAC -
The Gateway API introduces a few new resource types:
- GatewayClass are cluster-scoped resources that act as templates to explicitly define the behavior for Gateways derived from them. This is similar in concept to StorageClasses, but for networking data-planes.
- Gateway are the deployed instances of GatewayClasses. They are the logical representation of the data-plane which performs routing, which may be in-cluster proxies, hardware LBs, or cloud LBs.
- Route are not a single resource, but represent many different protocol-specific Route resources. The HTTPRoute has matching, filtering, and routing rules that get applied to Gateways that can process HTTP and HTTPS traffic. Similarly, there are TCPRoutes, UDPRoutes, and TLSRoutes which also have protocol-specific semantics. This model also allows the Gateway API to incrementally expand its protocol support in the future.
Below are reference manifest definitions on how one declaratively defines each of the above constructs -
