Kubernetes shifts application architecture for microservices, as well as the development workflow for a full-cycle development. Ambassador Edge Stack is designed for the Kubernetes world with:
- Sophisticated traffic management capabilities (thanks to its use of Envoy Proxy), such as load balancing, circuit breakers, rate limits, and automatic retries.
- API management capabilities such as a developer portal and OpenID Connect integration for Single Sign-On.
- A declarative, self-service management model built on Kubernetes Custom Resource Definitions, enabling GitOps-style continuous delivery workflows.
Emissary-ingress is a CNCF Incubating project and provides the open-source core of Ambassador Edge Stack. Originally we called Emissary-ingress the "Ambassador API Gateway", but as the project evolved, we realized that the functionality we were building had extended far beyond an API Gateway. In particular, the Ambassador Edge Stack is intended to provide all the functionality you need at the edge -- hence, an "edge stack." This includes an API Gateway, ingress controller, load balancer, developer portal, and more.
The core Emissary-ingress is open source under the Apache Software License 2.0. The GitHub repository for the core is https://github.com/emissary-ingress/emissary. Some additional features of the Ambassador Edge Stack (e.g., Single Sign-On) are not open source and available under a proprietary license.
Yes! For more details please see the Ambassador Edge Stack Licenses page.
Ambassador Edge Stack uses Envoy Proxy as its core proxy. Envoy is an open-source, high-performance proxy originally written by Lyft. Envoy is now part of the Cloud Native Computing Foundation.
Yes. Thousands of organizations, large and small, run Ambassador Edge Stack in production. Public users include Chick-Fil-A, ADP, Microsoft, NVidia, and AppDirect, among others.
There are many dimensions to performance. We published a benchmark of Ambassador Edge Stack performance on Kubernetes. Our internal performance regressions cover many other scenarios; we expect to publish more data in the future.
Service meshes focus on routing internal traffic from service to service ("east-west"). Ambassador Edge Stack focuses on traffic into your cluster ("north-south"). While both a service mesh and Ambassador Edge Stack can route L7 traffic, the reality is that these use cases are quite different. Many users will integrate Ambassador Edge Stack with a service mesh. Production customers of Ambassador Edge Stack have integrated with Consul, Istio, and Linkerd2.
See the Controlling the Ambassador Edge Stack 404 Page how-to.
See the Protecting the Diagnostics Interface how-to.
We have an online Slack community with thousands of users. We try to help out as often as possible, although we can't promise a particular response time. If you need a guaranteed SLA, we also have commercial contracts. Contact sales for more information.
This error means that Ambassador Edge Stack could not connect to your backend service. Start by verifying that your backend service is actually available and responding by sending an HTTP response directly to the pod. Then, verify that Ambassador Edge Stack is routing by deploying a test service and seeing if the mapping works. Then, verify that your load balancer is properly routing requests to Ambassador Edge Stack. In general, verifying each network hop between your client and backend service is critical to finding the source of the problem.
There are two different CRD versions supported by Ambassador Edge Stack.
The first are the
getambassador.io/v3alpha1 CRDs which were introduced with
Ambassador Edge Stack 2.x. These are still supported and are not deprecated. As of Ambassador Edge Stack 3.10.1, the new
gateway.getambassador.io/v1alpha1 CRDs have also been introduced.
v1alpha1 CRDs have not only a new version, but also a new apigoup so that way they can
be installed alongside the older CRDs without causing any conflicts.
v1alpha1 CRDs are only available for the
WebApplicationFirewallPolicy resources, and are the next generation of the CRDs that Ambassador Edge Stack will support. We are introducing them now to allow users to try them out without needing to stop using the
v3alpha1 CRDs. You can use
v3alpha1 CRDs in the same cluster at the same time, but
FilterPolicies are not able to reference
Filters that do not match their CRD version.