By Nick Young, Daneyon Hansen and Alex Xu April 27, 2021

Project post by Nick Young, Daneyon Hansen and Alex Xu – Contour

What is Gateway API?

Gateway API is an open source project by the Kubernetes SIG-Network community, that aims to provide a dynamic, reconciled representation of the resources required for service networking in Kubernetes, inside a Kubernetes cluster. It uses a collection of resources ( GatewayClass, Gateway, HTTPPRoute, TCPRoute, Service, and others) to model many different types of service networking, so that implementers may write controllers that implement all or some part of the API.

One of the use cases the API is intended to support is traditional Kubernetes Ingress. For this use case, Gateway API is intended to resolve the gaps in the original Ingress spec that have been addressed in other ways by individual controllers, including Contour’s own HTTPProxy resource.

Both Gateway API and HTTPProxy are designed to cut annotation sprawl by bringing required configuration into full-fledged fields within the object, rather than passing everything through annotations. Gateway API is intended to be a cross-implementation standard for configuring the more advanced features that require annotations when using the Ingress object. (some examples here).

However, the scope of the API is broader than the traditional layer 7 Ingress model, the API is intended to be able to describe Layer 4 traffic, such as direct TCP or UDP forwarding. Since Contour is a Layer 7 controller, we are implementing the slice of the API that describes Layer 7 HTTP services, effectively just the objects that handle HTTP and TLS routes. By providing a consistent set of APIs for both L4 and L7, all key personas from the Infrastructure Admin managing the network, through the Kubernetes Admin provisioning resources for their clusters, to the Developer configuring their application routing, can all work on a unified substrate.  For the users who are not ready to deal with the complexities of service meshes, Gateway API also provides a reasonable level of customizability in prescribing this traffic flow in both East-West and North-South traffic.

For more information about Gateway APIs and their creation, see the Kubernetes.io blog explaining further.

Why is Contour implementing it?

The Contour team has been involved in the Gateway API project since its inception. We have a multitude of experience with the Ingress API and its limitations, and have made two of our own custom resources to address them (HTTPProxy, and the now-removed predecessor IngressRoute). When we noticed that SIG-Network was starting work to evolve Ingress and Service, we jumped on board, looking to apply our experience upstream.  

Contour has seen increasing adoption in production deployments of varying sizes as of late but it is not uncommon for large enterprises to employ different ingress solutions as well as gateway solutions across many silos.  Our goal with Gateway API is for these large enterprises to standardize on traffic routing, enable self service and API discovery, and facilitate developers with exposing their Cloud Native applications.  This will further enhance capabilities in areas of security, compliance, multi-tenancy and much more.  

We’ve contributed feedback, designs and engineering time, and continue to do so. Daneyon Hansen, our maintainer from Red Hat is currently also a maintainer of the Gateway API project.

We believe that having a full-featured upstream API for describing cluster ingress, in all its forms, is healthy for the Kubernetes networking ecosystem, and are excited to be a part of its creation.

What’s Contour’s long-term plan for API support?

Ingress v1 is here to stay. The API will not go away for the foreseeable future, and it will stay as a great option for simple Ingress requirements.

HTTPProxy and Gateway API’s Layer 7 slice are targeting similar, more complex use cases, including features like traffic splitting and weighted routing, rate limiting, and external authentication. Some of these are not currently part of Gateway API, but are definitely targeted for inclusion in the future.

As a general guideline, we believe in enriching the set of core APIs in the upstream to the fullest extent for uniformity and transparency and keeping the more advanced capabilities in our downstream when it makes sense to do so.   This allows Contour to broaden its coverage for Kubernetes deployments while remaining an opinionated control plane for Envoy.

In the meantime, we’ve also improved our support for ingress v1 in the latest v1.14 release before Gateway API is mature by enabling filtering ingress resources using the IngressClass resource, as a more robust alternative to the annotation.   As part of this, you can specify different path matching modes for HTTP requests according to the Ingress v1 Spec including Exact path matching that will match a request path exactly, and Prefix path matching that will match path prefixes (similar to what Contour does right now).

Gateway API resources to get you started

Upcoming Kubecon Session

Please tune in to our Kubecon Maintainer Track session to learn more about Project Contour’s recent releases, roadmap, and our vision for Gateway API.

Please also check out this Gateway API session that deepdives the APIs and its advanced use cases.

Join the Contour Community!

Nick Young, Contour Tech Lead and Staff Engineer, VMware

Daneyon Hansen, Contour Maintainer and Principal Software Engineer, Red Hat

Alex Xu, Contour Maintainer and Product Manager, VMware