Kubernetes Gateway API - Evolution of Service Networking

In this article, we are going to talk about Kubernetes Gateway API and how it is evolving Kubernetes Service Networking. We will briefly cover the design goals of Gateway API and how it aims to improve upon current Services Networking standards like Ingress.

Background

Service networking is the portion of Kubernetes that involves exposing or publishing your pods on a network so that they can be accessed by other clients. Service networking offers multiple abstractions to help expose pods by providing simple ways of doing that within the cluster or more complex ways that expose Kubernetes apps to clients running outside of the cluster or even on the public internet. Service networking resources like Service Load Balancer and Ingress are typically used to expose applications running inside Kubernetes on the network.

Ingress API is primarily used for targets exposing HTTP applications with a simple, declarative syntax and the Ingress controller configures the underlying load balancer and fulfills the ingress. Ingress API was designed for simple use cases and supports some basic HTTP routing semantics:

• HTTP host matching
• HTTP path matching
• TLS termination
• Routing to service backends

And in terms of flexibility, Ingress resource doesn't offer a lot of ways to evolve this API to support more advanced capabilities. So for advanced use cases and increasing demand for new load balancing features, individual vendors addressed these requests via the use of vendor-specific annotations. Though annotations did get the job done it caused inconsistencies between different implementations, bad user experience, and security concerns as annotations are free to form strings so there are no validations, and overall it becomes difficult to migrate from one vendor to the other.

Service resources are seeing almost similar problems as ingress resources and it too is getting a lot of custom annotations and becoming bloated with features that concern different areas of Kubernetes like load balancing etc.

These problems have existed for a while and are causing existing Service networking resources to become complicated enough, and making it a little difficult to manage and evolve. At KubeCon San Diego 2019, a group of folks got together to discuss these problems and an idea of a new API floated around that could be used to solve these problems. Kubernetes Gateway API is designed to provide solutions to these problems and evolve the service networking area of Kubernetes.

What is Kubernetes Gateway API?

Kubernetes Gateway API is an open-source project managed by the SIG-NETWORK community and is a specification or standard, which means that projects and companies that support it, must adhere to it. This promotes portability and reusability because many different implementations have the same user interfaces. As of today, there are many contributors like Google, RedHat, VMWare, Kong, Traefiklabs, etc, to Gateway API and the list continues to grow. These contributors and many others also provide implementations of the Gateway API called Gateway controllers. As of writing this article, there are 13 implementations of Gateway controllers listed on the official website and we believe many more exist which haven't yet made their way to the official website.

Gateway API has taken the lessons from ingress and also the service mesh community on up-leveling the Kubernetes-natives resources that we use to model service networking. The Gateway API adds support for:

• HTTP header-based matching
• HTTP header manipulation
• Weighted traffic splitting
• Traffic mirroring
• Role-oriented resource model
• and more

It also has extensibility and extension points built natively into the API for future enhancements and provides support for:

• Arbitrary backend CRD references (storage buckets, functions, etc)
• Layered API for different routing resources to existing, e.g. support for gRPC protocol and routing semantics
• Granular extension points for implementation-specific behaviors like load balancing algorithms, custom match types, etc

Just like the Ingress controller, which manages network infrastructure on behalf of Ingress resources, Gateway API has Gateway controllers which manage the underlying network infrastructure like load balancers, which could be anything from cloud-managed load balancers to in-cluster software proxies. Each Gateway controller supports one or more GatewayClass, where a GatewayClass is like a template that explicitly defines a set of Gateways that share a common configuration and behavior. Each GatewayClass will be handled by a single controller, although controllers MAY handle more than one GatewayClass.

Gateways are created from GatewayClass and they model the actual network infrastructure which processes the traffic, like your actual load balancer. A Gateway describes how traffic can be translated to Services within the cluster. That is, it defines a request for a way to translate traffic from somewhere that does not know about Kubernetes to somewhere that does. For example, traffic is sent to a Kubernetes Service by a cloud load balancer, an in-cluster proxy, or an external hardware load balancer. Gateways are designed to be abstract so that they can model many different kinds of data planes that perform routing.

And then you have Route Resources, which define protocol-specific rules for mapping requests from a Gateway to Kubernetes Services. As of v1alpha2, four Route resource types like HTTPRoute, TLSRoute, TCPRoute, and UDPRoute are included with the API. Custom Route types that are implementation-specific are encouraged for other protocols. New route types may be added to the API in the future.

As shown in the model diagram, we can see that together the Gateway and HTTP route resources do what the ingress resource does as a single resource. This separation allows different roles to deploy and own that resource.

Gateway API strikes a balance between distributed flexibility and centralized control via its role-oriented design for Kubernetes networking by providing flexibility to users of the infrastructure while maintaining control by owners of the infrastructure.

• Infrastructure provider (infra) is responsible for the overall environment that the cluster(s) are operating in. Examples include the cloud provider (AWS, Azure, GCP, ...) or the PaaS provider in a company.
• Cluster operator (ops) is responsible for the administration of entire clusters. They manage policies, network access, and application permissions.
• Application developer (dev) is responsible for defining their application configuration (e.g. timeouts, request matching/filter) and Service composition (e.g. path routing to backends).

This separation of roles allows many different teams to share the same Gateway resources even across namespace boundaries. This allows cluster operators to essentially control who has access to the Gateway and policies on that Gateway while delegating routing control in a distributed way to different teams.

Summary

We have briefly touched on the background, challenges, or complexities of current Kubernetes service networking resources has how Kubernetes Gateway API is providing new abstractions to overcome those challenges. We also learned that Kubernetes Gateway API is designed to be role oriented, expressive, extensible, and also generic so that it has the flexibility to be used by diverse organizations and implemented across a diverse set of Gateway controllers and retain its core portability for future use cases as well.

In the next article, we will explore Gateway API, and some more key concepts and provide a demonstration by using one of the Gateway controllers. So stay tuned.