Yesterday (July 13th, 2022), the Kubernetes SIG-Network announced version 0.5.0 of the much anticipated Gateway API.
What is so special about this release you ask? It’s that finally, major components of the api are graduating to beta (v1beta1) - which means we will soon start to see more projects using those primitives - and they might even be good enough for the early adopters among us to give them a try.
Let’s go over the basics of Gateway API, what it aims to solve, and get to know its benefits, so you’ll be prepared for that small talk over a cup of coffee when you hear a person saying “have you heard about Gateway API? I heard it’s the new Ingress”.
What is the K8s Gateway API?
The Gateway API is a collection of new and official Kubernetes resources which are defining a specification to be implemented by a vendor, similar to how Ingress have implementations by Google, Amazon, etc.
The new resources introduced by it are:
- Gateway ( Graduated to beta )
- GatewayClass ( Graduated to beta )
- HTTPRoute ( Graduated to beta )
- ReferenceGrant ( Still in alpha, replacing ReferencePolicy )
- TCPRoute ( Still in alpha )
- TLSRoute ( Still in alpha )
- UDPRoute ( Still in alpha )
The goals of the new Gateway API as stated by the SIG-Network are:
- Role-oriented - Gateway is composed of API resources which model organizational roles that use and configure Kubernetes service networking.
- Portable - This isn't an improvement but rather something that should stay the same. Just as Ingress is a universal specification with numerous implementations, Gateway API is designed to be a portable specification supported by many implementations.
- Expressive - Gateway API resources support core functionality for things like header-based matching, traffic weighting, and other capabilities that were only possible in Ingress through custom annotations.
- Extensible - Gateway API allows for custom resources to be linked at various layers of the API. This makes granular customization possible at the appropriate places within the API structure.
Gateway and GatewayClass are the infrastructure-level components, they are the underlying layer for the XRoute components ( which is what makes this release exciting, as it is the enabler for them ).
Lets see what this hierarchy actually looks like:
But what is the purpose of this separation and those new components anyway?
Role-oriented API: One Cluster, multiple users, different roles
The first immediate benefit of the Gateway API is that it enables a much better separation of concerns.
Ingress objects, which are great, are delicate objects where Devops and App engineers usually need to figure out the configuration together, the application developer is aware of the application routes, but usually is unaware of details such as TLS certificates, which are usually in the Devops domain, this and other configurations that takes place in the same Ingress object are preventing autonomy from both parties, and allows more room for miss-configuration.
In the new Gateway API, the Gateway API decouples those and other configurations to a Gateway and a Route object, allowing the application engineer and the Devops engineer/Cluster operator to act freely and securely, here is how it looks like:
Another key benefit of the new API, is that more functionalities are expressed in the Gateway API objects definitions, and are not left for vendors to define through custom annotations.
This enhancement provides several benefits:
- Portability - Objects are less prone to changes given different Gateway vendors
- Expertise - Focusing engineers on getting familiar with Kubernetes specifications rather than vendor-specific specifications.
Let’s do an example, here is how you define traffic splitting with an Ingress object, with AWS alb.