How Traefik Labs is Pioneering the Kubernetes Gateway API Revolution

Since Kubernetes’ inception, the Ingress specification has been a reliable solution for managing inbound HTTP/S traffic, helping to expose services externally. As a leader in the Cloud-Native industry, Traefik was one of the first Ingress Controllers on the market and played a key role in the adoption of this API.

However, as organizations increasingly scale up their Kubernetes deployments and require more flexibility, the limitations of Ingress become apparent. Enter Kubernetes Gateway API, a new specification designed to address those limitations, introducing a more advanced and extensible model. It is no surprise that Traefik is playing a key role in this specification effort being one of the most complete Gateway API implementations on the market.

This article explores why the Gateway API is set to replace the traditional Ingress specification and how Traefik Labs drives this joint effort.

Exposing Workloads in Kubernetes: A Brief History

When Kubernetes was first introduced, it had different networking concepts: Services, Load Balancers and Ingress. Kubernetes Services allowed applications within a cluster to communicate, load balancers were used to provision cloud provider LBs, but when it came to exposing workloads externally, we used (and are still using) Ingress, a resource designed to handle HTTP/S routing to services. Ingress was a good foundation, but it soon became clear that it had limitations. It relied on provider-specific implementations with countless specific annotations, lacked flexibility, and offered only basic HTTP traffic management. Mastering the Ingress API covers only about 20% of the knowledge needed to address your needs, the next 80% is the “annotation hell”:

kind: Ingress
metadata:
  annotations:
    certmanager.k8s.io/cluster-issuer: letsencrypt-prod
    kubernetes.io/tls-acme: "true"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/use-regex: "true"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "120"
    nginx.ingress.kubernetes.io/from-to-www-redirect: "true"
    nginx.ingress.kubernetes.io/rewrite-target: https://example1.com/
    nginx.ingress.kubernetes.io/session-cookie-name: route
    nginx.ingress.kubernetes.io/too-many-annotations: "true"

This left many teams needing more advanced solutions to handle complex networking scenarios. That’s why we introduced the IngressRoute resource with Traefik v2.0 in 2019. The idea was to solve the annotation hell with a much more powerful structured CRD, but this was at the cost of vendor neutrality as it was only available for Traefik.

It was clear that Kubernetes needed a standardized way to manage inbound networking more elegantly.

Gateway API Comes to the Rescue

Kubernetes Gateway API is the next generation of Kubernetes Ingress, Load Balancing, and Service Mesh APIs. It has been incubating since 2019 and used to be called Service API at first. It introduces new concepts that simplify and standardize how Kubernetes clusters manage traffic, both internally and externally. Gateway API is designed to be vendor-neutral, layered and flexible at its core, and future-proof, addressing many of the shortcomings of Ingress resources.

Role-Based Resources

Gateway API introduces a set of resources that decouple networking responsibilities: GatewayClass resources which define the gateway controller and Gateway resources represent entry points into the cluster, can be managed by the operators of the cluster.

As for Developers, they will specifically use HTTPRoute or TLSRoute resources which define how traffic coming via the gateway maps to the services.

This separation of responsibilities makes it easier to define clear boundaries between different roles, allowing developers, network admins, and operations teams to work seamlessly together.

Layered Flexibility

Unlike the Ingress resource, which focused on HTTP/S traffic, Gateway API supports routing for multiple protocols like HTTP/S but also TCP, UDP and gRPC. This makes it an ideal choice to handle a diverse set of traffic types.

Another powerful concept is how policies can be applied at various layers—global, gateway-specific, or route-specific—allowing for a fine-grained control over how traffic is managed. Thanks to the Policy Attachment pattern, it is even possible to augment the behavior of an object that can't be described within the spec of that object.

Expressiveness & Vendor Neutrality

One of the key goals of Gateway API is to provide a consistent API across different environments. The core features set comes with header-based matching, traffic weighting, and many other capabilities that were only possible in Ingress through custom annotations. This allows developers to define routing rules and policies without being tied to a specific vendor’s implementation (through annotations). Whether you use Traefik, NGINX, or another provider, Gateway API aims to offer a powerful yet consistent experience.

Extensibility

Gateway API has been designed with extensibility in mind. Custom resources can be “augmented” at basically any layer of the API with Metaresources or ExtensionRef. This enables precise customization at the right levels within the API structure.

As you can see, Gateway API is much more powerful and flexible than Ingress. Most common exposing patterns can be tackled out of the box, and more complex needs can be addressed with extension mechanisms. This is a breath of fresh air for anyone who has been dealing with dozens or hundreds of Ingresses in production, familiar with the vendor-centric annotation hell.

Traefik Labs, Leader in the Gateway API Effort

Traefik Labs has always been a leader in the Kubernetes industry, being one of the very first Ingress Controllers back in 2016. Today is no different, Traefik is strongly involved in the Kubernetes Gateway API effort, playing a significant role in its development and adoption. Traefik was amongst the first controllers to adopt and support the Gateway API first alphas, recognizing its potential to simplify Kubernetes inbound traffic. Since then, Traefik Labs has been actively involved in the Kubernetes SIG-Network community, contributing to the development and refinement of the Gateway API specification. This involvement has allowed Traefik to influence the direction of the API, pushing for features that enhance user experience, security, and flexibility.

Traefik has been integrating Gateway API 1.0 since v3.0 and is continuously investing to provide the latest version available. Today, Traefik v3.2 brings support to fresh new Gateway API 1.2 adding GRPCRoute, TLSRoute, as well as more features on the HTTPRoute like h2c (HTTP/2 without TLS) and WebSocket support for backends, port matching in rules, response header modification, etc.Traefik Labs is committed in the long term to continually investing in the support and enhancement of Gateway API, ensuring that the community will always benefit from the latest progress in that space.

Conclusion

Gateway API is not just an improved Ingress resource. It’s basically a full replacement of Ingress, addressing all major flaws of this (too) basic specification and bringing advanced features to cover every need in cloud-native connectivity. By standardizing how inbound and east-west traffic is managed, Gateway API is making Kubernetes networking easier and more accessible for everyone. Its extensibility and flexibility will enable companies to tackle more complex workload exposure use cases, without sacrificing vendor neutrality.

As a pioneer of the Cloud-Native ecosystem, Traefik Labs has been at the forefront of designing the future of Ingress. This journey started back in 2019 and five years were needed to complete this giant step to the first GA of Gateway API. Today, as one of the most complete Gateway API implementations in the industry, we are extremely proud of the work accomplished. Seeing the impressive ongoing activity on the project, there is no doubt that Gateway API is only at the beginning of this joint effort.