We’re excited today to announce Ambassador 0.50 Early Access 1. This release consists of some major architectural changes to Ambassador:

Ambassador now uses Envoy’s v2 configuration, which allows us to support many commonly requested features such as SNI and gzip compression.

Ambassador has vastly improved connection draining semantics under load (> 1000 requests per second), as Ambassador 0.50 uses Envoy’s Aggregated Discovery Service API for configuration changes, instead of hot restart.

A new test suite (built on KAT) that is faster and more comprehensive than the old test suite

The early access release is not yet feature complete. We only support a subset of Ambassador’s functionality at the moment, and will be adding the rest of the functionality over the coming days.

Testing the Early Access release

This Early Access release is not intended for production use. We are releasing these changes as an early access release to enable broader community testing and feedback due to the scope of the changes.

To install the Early Access release, kubectl apply the following deployment.yaml :

If you’re testing the release, one suggested approach for testing this release is using Ambassador ID and shadowing. More information can be found on the early access release page.

Please post on our Slack a report of your Early Access experience (positive, negative). This information will be immensely valuable for us in resolving any issues prior to GA.

Early Access Limitations

Helm installation has not been tested.

The RateLimitService and TracingService resources are not currently supported.

and resources are not currently supported. statsd integration has not been tested.

integration has not been tested. WebSockets are not supported.

The logs are very cluttered.

Configuration directly from the filesystem isn’t supported.

The diagnostics service cannot correctly drill down by source file, though it can drill down by route or other resources.

AuthService does not have full support for configuring the request headers to hand off to the service. To send other headers not included by default, include them in allowed_headers (we will be adding a more fine-grained mechanism to control this in authentication directly in the future). This will also cause them to be forwarded from the external auth service to the upstream service on successful auth. The following headers are always sent:

Authorization

Cookie

Forwarded

From

Host

Proxy-Authenticate

Proxy-Authorization

Set-Cookie

User-Agent

X-Forwarded-For

X-Forwarded-Host

X-Forwarded

X-Gateway-Proto

WWW-Authenticate

Breaking changes

We are preserving backward compatibility for most Ambassador use cases. With 0.50, we are taking the opportunity to fully desupport a number of deprecated features.

You can no longer configure Ambassador with a ConfigMap .

. The authentication Module is no longer supported; use the AuthService resource instead (the documentation has been this way for a long time; most users probably won’t notice).

is no longer supported; use the resource instead (the documentation has been this way for a long time; most users probably won’t notice). External authentication with AuthService now uses the Envoy core ext_authz filter. This filter is based on the work we did with the custom filter used in Ambassador; we pushed this code into upstream Envoy.

now uses the Envoy core filter. This filter is based on the work we did with the custom filter used in Ambassador; we pushed this code into upstream Envoy. If you are using a custom external authentication service, ext_authz speaks the same HTTP protocol, and your service will continue to work. If your custom filter sent all HTTP headers to the external authentication service, ext_authz does not. You will need to configure the AuthService with the set of headers you wish to send to your external authentication service.

speaks the same HTTP protocol, and your service will continue to work. If your custom filter sent all HTTP headers to the external authentication service, does not. You will need to configure the with the set of headers you wish to send to your external authentication service. Circuit breakers and outlier detection are not supported (they will be reintroduced in a future release.)

Ambassador explicitly requires a TLS Module to enable TLS termination. Previous versions of Ambassador would automatically enable TLS termination if a Kubernetes secret named ambassador-certs was present. 0.50.0 will not. The following configuration will give you the same behavior:

---

kind: Module

name: tls

config:

server:

secret: ambassador-certs

Under the hood

Ambassador is a control plane for Envoy Proxy. Conceptually, all Ambassador does is convert Kubernetes configuration into Envoy Proxy configuration. In practice, however, Ambassador has to:

Be notified when configuration changes occur (via the Kubernetes API)

Parse and validate the configuration changes, and return useful error messages if there’s a problem

Integrate all the configuration changes from different manifests into one central configuration

Generate Envoy configuration

Ensure the Envoy configuration is valid, as Envoy is very particular about configuration forms

Pass the configuration to Envoy in a way that doesn’t impact existing connections (e.g., via hot restart or ADS)

As the Ambassador community has grown, we’ve found that the configurations that people are using have grown increasingly complex. For end users, this has resulted in hard-to-debug configuration, or revealing bugs in Ambassador due to the combinatorial explosion in possible configurations (and it’s hard to tell which!).

Over the past few months, we’ve been working on some architectural changes to Ambassador to address these issues. Coincidentally, these issues also tied with our desire to switch to the ADS and Envoy’s v2 configuration. So with Ambassador 0.50, we’ve:

Redesigned the Intermediate Representation (IR) used in Ambassador. The new IR is designed to be much more flexible in generating configuration, and it currently supports generating both v1 and v2 Envoy configuration. Should Envoy change its configuration format in the future, we’ll be in a much better place to support it. Moreover, the new IR also makes configuration validation and error reporting much easier.

Switched to passing the configuration information through the ADS, instead of hot restart. This means that configuration changes happen without a proxy restart, reducing the impact on existing connections. Hot restart is very reliable, but introduces a narrow window where existing clients get suboptimal performance when the proxy restarts.

We’ve also introduced a new test suite. The new test suite automatically generates multiple configuration permutations with a single test. Moreover, it runs much faster and more reliably than the old test suite, improving our “inner loop” development

We’re making extensive use of type hinting to reduce errors and assist comprehension.

For Python lovers, we’re starting to use multimethods for multiple dispatch, as discussed here: https://adambard.com/blog/implementing-multimethods-in-python/.

For Golang lovers, we’re using the Envoy Go control plane to send updates to Envoy ADS.

What’s next

Ambassador 0.50 Early Access 1 will be followed by several additional releases as we get to feature parity with Ambassador GA. We’d love to have you give it a test and report any bugs you might find!