Announcing Ambassador 0.70: Application Modernization beyond Kubernetes
Ambassador is one of the most popular API Gateways for Kubernetes users. But what if you’re just starting to move to Kubernetes?
Today, we’re announcing general availability of Ambassador 0.70. Ambassador 0.70 enables organization to accelerate their application modernization efforts faster than ever before. 0.70:
- Simplifies management. Building on the declarative configuration model introduced in Ambassador 0.11, Ambassador 0.70 now supports defining mappings based on Kubernetes Custom Resource Definitions (CRDs), making it easier than ever to integrate into your existing workflow.
- Routes to applications anywhere in your data center. Your data center may include applications running on non-Kubernetes infrastructure. Ambassador 0.70 natively integrates with Consul to let you route to applications anywhere in the data center.
- Enables edge resilience. Microservices go down — but your users don’t have to know. Ambassador 0.70 supports advanced resilience strategies including timeouts, circuit breaking, and automatic retries.
- Supports advanced L7 load balancing. Ambassador now supports a wide variety of L7 load balancing strategies, including sticky sessions, session affinity, and round robin. Moreover, these strategies can be configured on a per-service basis.
Custom Resource Definitions
Ambassador was originally written after Third Party Resources were deprecated in Kubernetes, and before Custom Resource Definitions were ready. Instead, we created the Mapping resource and attached it to the Kubernetes service. This approach has proven popular over the past two years: conceptually, associating the route to a service with the service definition makes sense.
That said, Kubernetes has evolved, and a number of users have asked for Ambassador to natively support CRDs in Ambassador, just like we do in Ambassador Pro. For us, the most compelling reason to support CRDs is that, as of Kubernetes 1.14, CRDs support validation. While Kubernetes 1.14 adoption is a ways off, we plan on taking full advantage of these APIs to provide real-time feedback on your configuration. Note that we’re not deprecating our standard configuration format as part of this change — we’re simply adding the additional option of using CRDs.
CRDs in 0.70:
- Are available as one of seven different resource types:
AuthService,Mapping,Module,RateLimitService,TCPMapping,TLSContext, andTracingService - Are only permitted in the
getambassador.io/v1namespace. Note that the documentation may still useambassador/v1which will only work if you’re using the traditional annotation-on-service approach
Data Center Support
Kubernetes services may need to route to applications running outside of Kubernetes. Ambassador 0.70 includes a pluggable mechanism for service discovery, with out of the box support for Kubernetes and Consul. Ambassador synchronizes in real-time with either (or both!) service discovery mechanisms, and will route requests to the current network address of a given service supplied by Consul or Kubernetes.
Edge Resilience
Ambassador now supports multiple strategies for improving the resilience of your services. Supported strategies include timeouts, automatic retries, and circuit breakers. Together, these strategies can help your application “fail fast” and limit cascade failure. Finally, Ambassador supports a variety of L7 load balancing strategies which can be used to improve both performance and availability.
Advanced L7 Load Balancing
Today’s applications communicate with each other over L7 protocols: HTTP and WebSockets, and, more recently, gRPC and gRPC-Web. However, many load balancers today (including kube-proxy) are L4 load balancers, meaning they cannot efficient load balance L7 requests. For example, if one connection is handling 1M gRPC requests/second, and another is handling 1 gRPC request/second, an L4 load balancer would route one connection to one instance, and the other connection to another instance. An L7 load balancer would actually balance the requests evenly between all available instances.
Ambassador 0.70 supports true L7 load balancing using a variety of techniques, including round robin, ring hash, and Maglev. These approaches can be adjusted on a per-service basis, as different services may require different load balancing strategies.
More about 0.70
0.70 also includes the following additional changes:
- Rebase from Envoy 1.9.1 to Envoy 1.10.
wattnow waits until all bootstrap sources have synced before invoking the watch hook. Users may see a performance improvement in Ambassador detecting annotation changes.- Support for
remove_request_headers. Thanks to Vyshakh P.
Installing 0.70
0.70 is available with the Docker tag quay.io/datawire/ambassador:0.70.0. Update your existing deployment manifest with this tag and kubectl applyto install 0.70 into your cluster. Because 0.70 contains new CRDs, the Helm charts do not yet support 0.70 (they will shortly).
Upgrading to Ambassador 0.70
This release of Ambassador requires changes to both your RBAC configuration, as well as the creation of some additional CRDs. You can redeploy your configuration by running kubectl apply -f https://www.getambassador.io/yaml/ambassador/ambassador-rbac.yaml. If you have an existing deployment, we’d recommend you download this YAML, compare it to your existing deployment, and update your existing deployment appropriately.
Onward
If you run into any problems with the update, please open an issue or join our Slack for some help. If you need an out-of-the-box Ambassador setup that includes integrated authentication, rate limiting, and support, check out Ambassador Pro, our commercial product.
And, if Ambassador is working well for you, we’d love to hear about it. Drop us a line in the comments below, or @ambassadorlabs on Twitter.
