Today, we’re announcing native support in the Ambassador API Gateway for the Consul service mesh. With this support, engineers can use Ambassador’s declarative configuration to expose any Consul service to the internet. Together, Ambassador and Consul provide a complete solution for traffic management in today’s hybrid cloud, spanning Kubernetes, virtual machines (VMs), and bare metal infrastructure.
Organizations today are increasingly focused on modernizing their applications to take advantage of technology innovations such as machine learning and big data. In addition, application modernization initiatives—such as containerization, declarative configuration, and defining policy as code—decouple application and infrastructure, and provide organizations the ability to incrementally migrate to cloud platforms as needed.
The first step in application modernization is decoupling applications from the heterogeneous runtime infrastructure: VMs, bare metal, containers. By enabling applications to run anywhere—while remaining connected to both external and internal users—this decoupling sets the stage for an incremental application modernization effort. This decoupling requires two major technologies:
Together, Ambassador and Consul provide a powerful architecture for application modernization. With this architecture, application workloads deployed share a common set of security and routing policies. Applications can be moved anywhere in the data center, without impacting security or end users.
In this architecture, Consul is the source of truth for your entire data center, tracking available endpoints, service configuration, and keeping secrets for TLS encryption. Consul also routes service-to-service traffic, ensuring end-to-end traffic is fully secured with TLS.
Using Consul for service discovery, Ambassador is able to route to any Consul service using TLS.
Ambassador serves as a common point of ingress to your applications and services, providing common cross-cutting functionality such as user authentication, API management, and TLS termination.
We’ve worked closely with the HashiCorp team to create a simple configuration experience. Ambassador uses a declarative configuration format built on Kubernetes annotations. So to use Consul for service discovery, we first register Consul as a resolver:
---
apiVersion: ambassador/v1
kind: ConsulResolver
name: consul
address: consul:8500
datacenter: dc3
Now that we’ve registered Consul, we can tell Ambassador to route to any service using Ambassador’s standard declarative configuration format. All Ambassador features such as gRPC, timeouts, and configurable load balancing are fully supported. In the example below, we’re creating a mapping between /foo/
and the foo
service registered in Consul:
---
apiVersion: ambassador/v1
kind: Mapping
prefix: /foo/
service: foo
timeout_ms: 5000
resolver: consul
tls: consul-tls-cert
load_balancer:
policy: round_robin
As soon as this route is registered, Ambassador will start routing traffic to that service. Behind the scenes, Ambassador will:
foo
service from ConsulAmbassador pulls service and mapping data from Kubernetes. Ambassador also pulls endpoint data and security certificates (for TLS encryption) from Consul. Ambassador will typically detect any configuration changes in milliseconds. Using this data, Ambassador assembles a complete configuration snapshot of your environment: the routing table, available endpoints, and route configuration (e.g., protocol, timeouts, prefix rewrites, and such). To prevent a cascade of configuration changes from triggering configuration churn, Ambassador will coalesce all configuration changes that occur within a 250ms interval. Note that Ambassador’s architecture is stateless by design -- it relies on Consul and Kubernetes as the single source of truth, enabling simple horizontal scale-out of Ambassador instances.
Both Ambassador and Consul rely on Envoy Proxy for the data plane. In Ambassador’s case, the configuration snapshot is rendered into Envoy configuration, and passed to Envoy over Envoy’s Aggregated Discovery Services API. Incoming traffic is directly routed by the configured Envoy Proxy instance. Traffic from the Ambassador Envoy is routed to Connect-aware proxies over TLS.
Both Consul team at HashiCorp and the Ambassador team at Datawire are excited for this collaboration, and we look forward to continuing to deepen the integration between Ambassador and Consul as both products move forward. To learn more about the Ambassador and Consul integration, see the following:
The HashiCorp Consul ecosystem continues its growth with the addition of 13 new Consul integrations.
The new global management plane for Consul is now generally available. Try it out to gain full visibility for both self-managed and HCP Consul clusters.
Consul 1.15 simplifies user onboarding, enhances troubleshooting workflows, and reduces operational complexity.