Guest post originally published on the ARMO blog by Leonid Sandler

Despite being a large open-source and complex project, Kubernetes keeps on evolving at an impressive pace. Being at the center of various platforms and solutions, the biggest challenge for the Kubernetes project is to remain vendor-neutral. This is the reason the community has come up with Kubernetes Gateway API.

Gateway API is a new project by the SIG-Network community designed to enhance service networking through consistent and extensible interfaces that multiple vendors can implement to offer broader choices to the development community.

In this article, we’ll look into Gateway API, how it is different from Ingress, and what we can do with it.

How Gateway API Differs from Ingress

Usually, after deploying a Kubernetes application, you need to expose it to the end users. This is typically done using Ingress Controller constructs for north-south traffic. The Ingress API object defines the routes and mapping of the external traffic to Kubernetes services; it also offers load balancing, SSL termination, and name-based virtual hosting.

Many off-the-shelf controllers such as NGINX Ingress controller and HAProxy implement the Ingress interface. These controllers have differentiated themselves from each other by providing more features such as advanced load balancing via proprietary extensions. The current Ingress API scope is very limited to ensure better portability in the ecosystem.

Gateway API is an evolution of Ingress that provides advanced features natively by extending the API definitions. Some of these features were provided by individual Ingress vendors as private extensions, but these implementations were not aligned with each other. Now, with Gateway API, many such capabilities will be implemented by multiple vendors according to a single specification so that users will have a choice of different implementations.

Important additions by Gateway API include HTTP and TCP routes, traffic splitting, and a role-oriented approach that allows cluster admins and developers to focus on the setting relevant to their responsibilities.

Kubernetes Gateway API Concepts

The SIG-Network community has come up with the following design goals for Gateway API to improve upon the Ingress resource:

Diagram showing Kubernetes Gateway API Concepts

Other notable capabilities of Kubernetes API Gateway are:

Now, the question is, what can you do with Gateway API?

Advanced Traffic Routing and Progressive Delivery

One of the most important features missing in Ingress is advanced traffic routing. Up until now, this was resolved by way of a service mesh, which made it complex and tightly coupled with the mesh implementation.

Below, we cover some of the advanced routing scenarios that Gateway API provides natively so you no longer need a mesh.

Simple Gateway

This is the simplest way to expose the service using the Gateway and Route, managed by the same owner. The load balancer is managed by the Gateway controller, which sends all arriving traffic coming to the service. This gives autonomy to the service owners and allows them to expose the service as they want, a model that is similar to Ingress:

Simple Gateway pattern where traffic flows via a load balancer
Figure 2: Simple Gateway pattern where traffic flows via a load balancer. (Source: Kubernetes Gateway API)

HTTP Routing

HTTPRoute allows you to route the traffic to multiple services based on filters. In the example below, there are two routes attached to the same gateway.

This model allows you to introduce a progressive delivery strategy:

HTTP routing with multiple paths and header-based routing
Figure 3: HTTP routing with multiple paths and header-based routing. (Source: Kubernetes Gateway API )

HTTP Traffic Splitting

In this model, you can have weighted traffic routing, which you can combine with A/B or canary strategies to achieve complex rollouts in a simple way. In the above diagram, the HTTPRoute is splitting the traffic 90/10 and sending it to the foo-v1 service and foo-v2 service, respectively.

Here, the weight is not in the percentage. Instead, the sum of all weights within the single route is the denominator of all the backends. This allows for a gradual rollout of the newer version:

 HTTP traffic splitting example
Figure 4: HTTP traffic splitting example (Source: Kubernetes Gateway API)

You can also achieve header-based routing by having the same weight but a filter on the header. A canary route with header traffic=test is sent to the new service foo-v2 for testing, thus allowing for safer releases without impacting v1 traffic:

Header-based routing
Figure 5: Header-based routing (Source: Kubernetes Gateway API)

Cross-Namespace Routing

In the cross-namespace routing, you can share the gateway(s) and have team-based control on their routes. For example, in a large setup, an infrastructure team may be responsible for managing the shared gateway, while individual teams manage their routes. This allows for clear separation of duties among the users:

Cross-namespace routing using a shared gateway model
Figure 6: Cross-namespace routing using a shared gateway model (Source: Kubernetes Gateway API)

In the table below, we can see the different roles and responsibilities of the owner for each resource type. For example, an infrastructure provider may have access to all the layers, but an application developer is limited to owning only routes to their service:

 GatewayClassGatewayRoute
Infrastructure ProviderYesYesYes
Cluster OperatorSometimesYesYes
Application AdminsNoIn specific namespacesIn specific namespaces
Application DevelopersNoNoIn specific namespaces

TLS

Gateway API supports TLS configuration at various points in the network path between the client and service—for upstream and downstream independently. Depending on the listener configuration, various TLS modes and route types are possible; support for cert-manager integration is also available:

TLS configuration for both upstream and downstream
Figure 7: TLS configuration for both upstream and downstream (Source: Kubernetes Gateway API)

The following table from the official documentation provides clarification as to when an object should be used and the TLS support provided by each:

ObjectOSI LayerRouting DiscriminatorTLS SupportPurpose
HTTPRouteLayer 7Anything in HTTP ProtocolTerminated onlyHTTP and HTTPS routing
TLSRouteBetween Layer 7 and Layer 4SNI or other TLS propertiesPassthrough or terminatedRouting of TLS protocols including HTTPS where inspection of the HTTP stream is not required
TCPRouteLayer 4Destination portPassthrough or terminatedAllows for forwarding of a TCP stream from the listener to the backends
UDPRouteLayer 4Destination portNoneAllows for forwarding of a UDP stream from the listener to the backends

TCP Routing

You can implement numerous protocols with Gateway API, including support for TCPRoute. The listeners under the gateway should have protocol: TCP in the configuration to enable TCP routing and allow you to manage TCP traffic.

Integration with Progressive Delivery Tools

Combined with the various advanced traffic routing options, API Gateway currently provides integration with Flagger—a progressive delivery tool for advanced deployment strategies such as A/B, blue-green, and canary. It works with all implementations of Gateway API.

Portability

The main idea of introducing Gateway API was to bring consistency across the Ingress capabilities offered by various solutions. This also makes it portable, so when you move the workload to a different provider or write a multi-cloud solution, it will work the same way without requiring a significant amount of change in the specifications.

Kubernetes Gateway API Demo

There are various vendors working to introduce Gateway API implementations such as Contour, Emissary-Ingress, GKE, and Traefik. You can get the list of implementations here. Just keep in mind that most of them are in beta and not really production-ready.

Conclusion

Kubernetes Gateway API has evolved to provide expressive, portable, and extensible API specs for implementers such as infrastructure providers, cluster operators, and application developers. Although not a complete replacement for Ingress as of now, you should aim to use Gateway API wherever possible, as it does provide more options for developers without introducing a lot of annotations or non-portable changes.

Furthermore, all the projects in the service mesh and Ingress controller space have implemented Gateway API along with tools like Flagger and cert-manager—and you should expect more to jump on board soon as it becomes more popular in the CNCF ecosystem. Most of the implementations discussed above are in beta but are expected to be GA soon. To learn more about Gateway API’s graduation to beta and plans for its GA release, check out this talk at KubeCon + CloudNativeCon Europe 2022.