Consul API Gateway 0.3 Introduces HA Logical Gateways
The latest release of the HashiCorp Consul API Gateway allows users to generate multiple instances of a logical gateway — avoiding single points of failure.
Today at HashiConf Europe, we announced the availability of version 0.3 of the HashiCorp Consul API Gateway. This release allows the deployment of multiple instances of a logical gateway — also known as highly available (HA) gateway instances — in a Kubernetes cluster, giving users greater control, consistency, and resilience. Previously, users could deploy multiple distinct logical gateways within a single cluster, but not multiple instances of the same gateway sharing the same configuration.
The new feature assures users that access to their environments will be consistent even in the event of a pod outage, while also enabling them to react to sudden spikes in external client traffic. This blog post explores how this feature works and what the architecture looks like.
»HA Logical Gateways: How They Work
When users deploy the Consul API Gateway there are two core components: the gateway controller and the logical gateway. The controller is responsible for distributing user-defined configurations to the logical gateways and gathering relevant credentials and certificates from Consul. The controller is installed with Consul and has a built-in failure tolerance; should the controller pod fail, it will redeploy within the cluster.
Logical gateways receive class and route configurations from the controller and are the endpoints that handle the traffic routing of client requests. If these pods become unreachable, then client requests will likely be mishandled until a new instance of the logical gateway is redeployed. To prevent this, Consul API Gateway 0.3 allows users to scale up the number of logical gateway instances deployed, all sharing the same configuration and route information, similar to how ReplicaSets are used to deploy redundant applications. We call this feature highly available logical gateways.
To deploy multiple instances of a Consul API Gateway on the installation, users can set the default number of instances per logical gateway and set min/max guardrails in their GatewayClassConfig. Here’s an example of a block within the GatewayClassConfig that will default to two instances of the logical gateway upon creation, with a minimum of one gateway instance and a maximum of eight:
spec:
consul:
ports:
grpc: 8502
http: 8501
scheme: https
deployment:
defaultInstances: 2
maxInstances: 8
minInstances: 1
Once the logical gateway has been deployed, users can scale the number of instances up or down using kubectl scale. The number of scalable instances is bound by the minimum and maximum set in the GatewayClassConfig. Currently, the maximum number of instances that we allow is eight.
»Resilience Through Multiple Instances
Having multiple instances of a logical gateway provides resilience in the case of pod outages as well as enhancing the Consul API Gateway’s ability to handle scale. Users can leverage a perimeter security solution, such as an application load balancer, for client requests coming from the public internet and then load balance those requests through the different gateway instances. This ensures that the Consul API Gateway does not become a single point of failure in the face of abnormally high traffic.
When users detect increased client traffic, this feature allows them to scale up the number of logical gateway instances to support the new requests without having to reconfigure their existing deployment. Users can increase the total number of logical gateway instances to meet the increased demand, then scale them back down to conserve resources through a simple kubectl command.
»What About the API Gateway Controller?
Note that this enhancement is designed for only the logical gateways, not the gateway controller. That’s why we call the feature “highly available logical gateways” instead of just “high availability”. While we may explore additional options for deploying additional replicas of the gateway controller when running on Kubernetes, we feel that the current architecture is sufficient for production scale for several reasons.
First, the gateway controller is responsible only for distributing gateway configurations to newly created logical gateways and attaching any routes created. Since it is not receiving client requests directly, there is less likelihood that the controller will be overwhelmed by spikes in traffic. Additionally, the gateway controller is configured to automatically restart in the event of a pod outage, and existing logical gateways will still function even if the controller is down.
»Next Steps
The Consul API Gateway 0.3 is generally available starting today. To get started, you will need to run Consul 1.11.2 or greater and use version 0.45 of the Consul Helm chart. For more information, please visit the Consul API Gateway documentation.
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.