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.
»Gateway
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.
»GatewayClass
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.
»HTTPRoute
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:
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
name: http-filter-rewrite
spec:
hostnames:
- rewrite.example
rules:
- filters:
- type: URLRewrite
urlRewrite:
hostname: elsewhere.example
backendRefs:
- 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
More blog posts like this one
HashiCorp at AWS re:Invent: Your blueprint to cloud success
If you’re attending AWS re:Invent in Las Vegas, Dec. 2 - Dec. 6th, visit us for breakout sessions, expert talks, and product demos to learn how to take a unified approach to Infrastructure and Security Lifecycle Management.
Consul 1.20 improves multi-tenancy, metrics, and OpenShift deployment
HashiCorp Consul 1.20 is a significant upgrade for the Kubernetes operator and developer experience, including better multi-tenant service discovery, catalog registration metrics, and secure OpenShift integration.
New SLM offerings for Vault, Boundary, and Consul at HashiConf 2024 make security easier
The latest Security Lifecycle Management (SLM) features from HashiCorp Vault, Boundary, and Consul help organizations offer a smoother path to better security practices for developers.