Kubernetes Gateway API — A successor to existing Kubernetes Ingress!

Sanjit Mohanty
3 min readApr 9, 2022

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 -

Reference - Kubecon/cncf
Reference — Kubecon/cncf

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 -

Reference - Kubecon/cncf
Reference — Kubecon/cncf

These (& many others) have led to the evolution of the new Kubernetes Gateway API which proposes the following personas mapping -

Reference - Kubecon/cncf
Reference — Kubecon/cncf

With this in place, we have a clear definition of accountability with the right RBAC -

Reference - Kubecon/cncf
Reference — Kubecon/cncf

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.
Reference - Kubecon/cncf
Reference — Kubecon/cncf

Below are reference manifest definitions on how one declaratively defines each of the above constructs -

Reference — Kong
Reference — Kong

--

--

Sanjit Mohanty

Engineering Manager, Broadcom | Views expressed on my blogs are solely mine; not that of present/past employers. Support my work https://ko-fi.com/sanjitmohanty