Ambassador 0.60: Consul, service mesh, timeouts, and more

Today, we’re announcing Ambassador 0.60. With this release, Ambassador can serve as your centralized API Gateway or ingress for your entire data center, and not just Kubernetes. Specifically, Ambassador 0.60 includes:

• Native Consul support. Ambassador can now route to any Consul service based on endpoint information supplied by Consul.
• Direct L7 load balancing. Ambassador can bypass the L4 kube-proxy load balancing, and route directly to Consul endpoints or Kubernetes pods using the round robin, ring hash, or Maglev load balancing algorithms.
• Many smaller enhancements and bug fixes (full list below).

Beyond Kubernetes

As much as we love Kubernetes, we know that few organizations run their infrastructure entirely on Kubernetes. Typically, organizations are running applications on virtual machines (e.g., EC2, VMware) and bare metal, and incrementally adopting containers and Kubernetes.

With Ambassador 0.60, all traffic to a data center can be routed through Ambassador. This is true no matter where your application is running. And you can still get all the benefits of Ambassador: declarative configuration, sophisticated L7 routing powered by Envoy Proxy, security, rate limiting, and more.

Ambassador + Consul

For this use case, Ambassador now has a core integration with Consul. Consul is a hugely popular distributed service mesh and service discovery solution from HashiCorp. In the data center, Consul tracks all available services and their corresponding endpoints. Ambassador uses Consul as the source of truth for services, and can route to any Consul service over TLS-encrypted connections. Using Consul from Ambassador is as simple as registering Consul as a resolver:

---
apiVersion: v1
kind: Service
metadata:
  name: ambassador
  annotations:
    getambassador.io/config: |
      ---
      apiVersion: ambassador/v1
      kind: ConsulResolver
      name: consul-dc1
      address: consul-server:8500
      datacenter: dc1
spec:
  type: LoadBalancer
  selector:
    service: ambassador
  ports:
  - name: http
    port: 80

Then, create a Mapping resource to route to any service registered in Consul, e.g.,

---
apiVersion: v1
kind: Service
metadata:
  name: consul-sd
  annotations:
    getambassador.io/config: |
      ---
      apiVersion: ambassador/v1
      kind: Mapping
      name: consul_qotm_mapping
      prefix: /qotm-consul/
      service: qotm-consul
      resolver: consul-dc1
      load_balancer: 
        policy: round_robin
spec:
  ports:
  - name: http
    port: 80

Behind the scenes, Ambassador obtains real-time endpoint information from Consul and real-time configuration data (i.e., the Mapping configuration) from Kubernetes. Within milliseconds of a configuration change, Ambassador computes an updated snapshot of your environment, and sends it to Envoy, which then routes the traffic.

For more information on using Consul and Ambassador, see the following:

• 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.
• Secure Routing and Traffic Management webinar with Nic Jackson (HashiCorp) and Daniel Bryant (Datawire) on Thursday, May 16th.
• KubeCon EU presentation on Ambassador and Consul on May 22 in Barcelona.

But wait, there’s more!

While we’re really excited about the Consul integration, Ambassador 0.60 includes a number of additional changes and enhancements:

• By default, Ambassador now runs as non-root on ports 8080 and 8443. This is a breaking change (details on how to upgrade are below).
• Support for round robin, ring hash, and Maglev load balancing algorithms.
• Additional timeout configuration options that are particularly useful for long-lived connections. Thanks to Aaron Triplett and Pétur Erlingsson. For more details, see the Timeouts documentation.
• Ambassador will now properly reload renewed certificates (#1416). Thanks to Matthew Ceroni for his work in debugging this issue.
• Ambassador will now properly redirect from HTTP to HTTPS based on x-forwarded-proto (#1233).
• The case_sensitive field now works when host_redirect is set to true (#699). Thanks to Peter Choi and Christopher Coté.

Installing 0.60

0.60 is available with the Docker tag quay.io/datawire/ambassador:0.60.0. Update your existing deployment manifest with this tag and kubectl applyto install 0.60 into your cluster.

You can also install via Helm:

helm install stable/ambassador

Upgrading

If you’re an existing Ambassador user, you’ll need to update your Ambassador Kubernetes service to point to port 8080 (plain-text) or 8443 (https) by setting targetPort:

---
apiVersion: v1
kind: Service
metadata:
  name: ambassador
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  ports:
   - port: 80
     targetPort: 8080
  selector:
    service: ambassador

This will tell the Ambassador service to listen on port 80 externally, while passing traffic to Ambassador on port 8080.

You should also update your Ambassador deployment to run as non-root:

containers:     
- name: ambassador
  image: quay.io/datawire/ambassador:0.60.0
  securityContext:
    runAsUser: 8888

For more information see running Ambassador as non-root.

Onward

If you run into any problems with the update, please open an issue or join our Slack for some help.

And, if Ambassador is working well for you, we’d love to hear about it. Drop us a line in the comments below, or @getambassadorio on Twitter.