Overview of HAProxy Unified Gateway

HAProxy Unified Gateway enables Kubernetes-native traffic management conformant with the Kubernetes Gateway API specification. It’s built on HAProxy, the reverse proxy known for its legendary performance and reliability.

Gateway API is the recommended way to extend Kubernetes to add network traffic routing capabilities that Kubernetes doesn’t provide natively. Specifically, Gateway API solves the problem of how network traffic outside of your Kubernetes cluster can enter and get routed to the correct containerized application. The Kubernetes platform assumes that third-party providers will implement this part of the platform through reverse proxy software that can bridge the divide. Gateway API defines a standardized set of functions that these proxies must implement.

A new paradigm for traffic routing Jump to heading #

Gateway API replaces the Ingress API, which had served the same purpose in a different way. It has more layers of abstraction than Ingress API, allowing different teams within your organization to manage different aspects of the rollout. For instance:

• Your organization could have a platform team that decides that everyone will use HAProxy Unified Gateway in all cases or in combination with other proxy technologies, depending on the environment and use case. Each of these enabled proxies is called a GatewayClass. GatewayClasses are scoped to the cluster, so they can be used in any namespace. Think of these like options on a menu.

• Then, a DevOps team, when deciding how best to route network traffic to applications running in a certain namespace, could choose a GatewayClass from that approved list and deploy an instance of it. This is called a Gateway. Let’s say they name it example-gateway.

• With the Gateway deployed, an application team can define routes that hook up to it. For example, the team could add a route that directs all HTTP requests for URLs beginning with /cart to the pods running the shopping cart application. In that route definition, they’d indicate which Gateway to use, in this case choosing the example-gateway instance, which would handle proxying external traffic to the application.

This separation of concerns is central to the Gateway API ethos. The motivation is to give teams the flexibility to select the best proxy depending on the circumstances, while allowing different people to manage and control the proxy technologies enabled at the cluster and namespace levels, ensuring safe and efficient operation.

How it works Jump to heading #

You’ll install HAProxy Unified Gateway as a GatewayClass in your Kubernetes cluster. Once installed, HAProxy Unified Gateway runs in the background, constantly monitoring your cluster for Gateway instances. When it finds one that matches its type, it allocates a new proxy for it to handle any routes that get assigned to it. It will automatically discover the pods that serve an application, grouping them into a pool of backend servers, and then load balance incoming requests across them.

It continuously monitors for changes in your cluster and updates the proxy configuration accordingly. For example, as your application pods scale up or down, HAProxy Unified Gateway reacts to these changes and updates the server lines in the backend section of its internal configuration. It also handles TLS, path rewrites, redirects, health checks, and other load balancing logic.

How to use this guide Jump to heading #

This guide contains all you need to know to get started using HAProxy Unified Gateway.

• Head over to Installation for steps on getting started.
• See the Usage topic for examples of setting up routes and other features.
• From the Administration topic, learn how best to manage your deployment.