K8s Gateway API: What is it and What are your Options?

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:

Streamlined functionalities

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:

1. Portability - Objects are less prone to changes given different Gateway vendors
2. 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.

As you can see there is a lot of vendor specific definitions going on here with heavy usage of annotations, however, with the new Gateway API, the equivalent will be

As you can see, much less noise here, and the definitions are completely portable. Nice!

Cross-Namespace routing 

As part of the understanding that there are different roles operating different components in a Kubernetes cluster, there is a need to support cross namespace referencing as these different organization units usually operate in different namespace, while still using common infrastructure components, such as TLS certificates , hostnames, and more.

To enable the above, Gateway API supports establishing Gateway objects in one cluster, and creating Route objects in each application/organization unit namespace that reference it.

Here is an Illustration of such setup:

The infrastructure operators can also explicitly constraint who can register a Route object to Gateway, In our example, the Gateway is defined as follows:

The Gateway will only allow namespaces with shared-gateway-access: "true" label to use the shared-gateway, so in our example, the Namespace objects must be defined as follows:

Once those layers are deployed, the application developers can register their Route objects, referencing the shared gateway.

In our example, the store Route object will look like this:

Spoiler alert ! Here at Groundcover we rely heavily on API Gateway in production, and as a result in development as well, until we will implement Gateway objects, we’ve come up with our own Ingress-based cross-namespace API Gateway solution - a blog post about it will be up soon!

Final thoughts - the value in universal APIs for K8s

This blog relies heavily on Kubernetes SIG-Network they did an awesome job in documenting the new API, if you’re interested in trying Gateway API now, they list available implementations here (Warning! They are still work in progress).

The Kubernetes landscape is changing rapidly, and although adapting to those changes is hard and sometimes frustrating and needless to mention - requires monitoring, it's definitely worth it. 

As I see it, the community is doing amazing work in gathering case studies and unifying them in a responsible way. 

Enabling Kubernetes users to build expertise in universal apis instead of becoming vendor-specific experts will help build more mature products, focus on creating value and apply our skills more easily and in different environments.

Here at groundcover, we are hardcore Kubernetes fans (I mean, look at me, writing a blog about a new api that was announced beta only yesterday, just out of sheer excitement). If you feel like geeking out further on this topic, join our slack channel anytime.

‍

Noam Levy

,

Founding Engineer

7

minutes read, updated on:

February 14, 2024

Copy link

https://www.groundcover.com/blog/k8s-gateway-api