Ambassador API Gateway Announces Native Support for Consul Service Mesh

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.

»Why this matters

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:

• API Gateways decouple application composition and location from external consumers. An API gateway dynamically routes external requests to different applications, regardless of where it is deployed.
• Service meshes decouple applications from internal consumers. A service mesh dynamically routes internal requests to different applications, regardless of where it is deployed.

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.

»How it works

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:

• Obtain a list of available endpoints for the foo service from Consul
• Obtain the appropriate TLS certificate from Consul to originate encrypted TLS to the endpoints
• Apply any additional configuration to the route such as load balancing rules, protocol, timeouts, and so forth.

»Architecture

Ambassador 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.

»Learn more

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:

• Join our webinar to watch a live demo.
• Getting started with Ambassador and Consul. This is a quick start guide to installing Ambassador and configuring it to use Consul for service discovery and end-to-end TLS.
• Service discovery configuration. This reference guide for Ambassador discusses how to configure service discovery in Ambassador with Consul.
• Attending KubeCon Europe 2019? Daniel Bryant from Datawire and Nic Jackson from HashiCorp will be presenting on Securing Cloud Native Communications with Ambassador and Consul.