Consul API Gateway 0.4 Is Now Generally Available

Consul API Gateway 0.4 introduces support for the new beta version of the Kubernetes Gateway API and HTTP path rewrites.

Today we’re pleased to announce the general availability of the Consul API Gateway version 0.4. With this release, we are the first to introduce support for the new beta release of the Kubernetes Gateway API and HTTP path rewrites. Consul API Gateway version 0.4 marks the growth of three key components within the API: GatewayClass, Gateway, and HTTPRoute. Alongside the maturity of these three APIs, URL Path Rewrites are also introduced as part of this release.

»The Kubernetes Gateway API Graduates to Beta

In the Kubernetes community, a specification must meet certain guidelines in order to move from an alpha to a beta classification. The first requirement is that the API must be widely implemented and actively used. HashiCorp has been one of 14 companies to offer an implementation of the Kubernetes Gateway API. The second requirement is to pass conformance tests to ensure basic coverage for all resources. Lastly, the Kubernetes special interest group (SIG) Network API reviewers must approve the graduation to beta. This SIG consists of individuals from multiple companies, including HashiCorp.

The beta upgrade is crucial within API GatewayClass, Gateway, and HTTPRoute as this means that these specific APIs can carry backwards compatibility for future releases. This helps reduce the chances of any failures such as outages. Please note that these are not new features to the Kubernetes Gateway API or newly supported in the Consul API Gateway but are being reintroduced solely as beta upgrades.


The Kubernetes Gateway API introduced a new way to handle ingress into a Kubernetes environment. One of the core resources that was created for this purpose was the Gateway service. Gateway services are Kubernetes resources that act as an entry point into the cluster. They can be deployed as either a LoadBalancer or NodePort resource and route traffic requests to services within a cluster. Gateway services support different listener protocols like HTTP/S, TCP, and TCP+TLS, providing clients with a broader array of connection types compared to Ingress Controllers.


The GatewayClass resource allows users to templatize how Gateway services are configured when one is deployed into a Kubernetes environment. GatewayClass configurations are stored in a Kubernetes controller (we call this the Consul API Gateway controller) and retrieved by newly provisioned Gateway services. A GatewayClass definition is required in order to provision a Gateway, so we provide default values upon installation, but users can configure different GatewayClasses depending on their needs.


Once a Gateway service has been created and is reachable to clients, users must attach HTTPRoutes to their gateway to facilitate where requests should be forwarded and what protocol should be used. HTTPRoutes are specifically designed for routing behavior of HTTP requests, including termination, but the Consul API Gateway also supports other route types such as TCPRoute. Using HTTPRoutes, users can configure the Gateway to look for request attributes like path prefixes, header values, and query parameters. In Consul API Gateway 0.4, we introduce another capability: path rewrites.

»HTTP Path Rewrites

In some cases, users may have a single hostname they want clients to send requests to, but the backend services are actually using a different hostname. With Consul API Gateway 0.4, HTTPRoutes now support the ability to detect the originating hostname and rewrite it before passing the request to the corresponding backend service. Here’s an example of what these filters look like:

kind: HTTPRoute
  name: http-filter-rewrite
    - rewrite.example
    - filters:
      - type: URLRewrite
          hostname: elsewhere.example
      - name: example-svc
        weight: 1
        port: 80

In this example, the client sends a request to rewrite.example, the gateway takes that request and re-writes the hostname to elsewhere.example before forwarding the request to the example-svc backend service. These rewrites can also be applied to path-prefixes offering even more granular controls over where requests are sent without requiring the client to send requests to multiple different hostnames. This feature is currently in the experimental phase and not considered part of the previously mentioned graduation to beta.

»Next Steps

Consul API Gateway 0.4 is now generally available to all users. To get started you will need to run Consul 1.12. For more information about Kubernetes Gateway API, please visit the Kubernetes Gateway API Graduates to Beta blog post. For more information on Consul API Gateway, please visit the documentation overview.

Sign up for the latest HashiCorp news

By submitting this form, you acknowledge and agree that HashiCorp will process your personal information in accordance with the Privacy Policy.