- The Mapping Resource
- Automatic Retries
- Canary Releases
- Circuit Breakers
- Cross-Origin Resource Sharing
- Method-based Routing
- Prefix Regex
- Traffic Shadowing
- Developer Portal
- The Ambassador Module
- Custom Error Responses
- Gzip Compression
- Host CRD, ACME Support, and External Load Balancer Configuration
- Ingress Controller
- Troubleshooting Ambassador
- Deploying to Kubernetes from GitHub
- Knative Serverless Framework
- Prometheus monitoring
- Frequently Asked Questions
Kubernetes shifts application architecture for microservices, as well as the development workflow for a full-cycle development. Ambassador 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.
The Ambassador API Gateway was the name of the original open-source project. 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 Ambassador Edge Stack is open source under the Apache Software License 2.0. The GitHub repository for the core is https://github.com/datawire/ambassador. Some additional features of the Ambassador Edge Stack (e.g., Single Sign-On) are not open source and available under a proprietary license.
Yes! The core functionality of the Ambassador Edge Stack is free and has no limits whatsoever. If you wish to use one of our additional, proprietary features such as Single Sign-On, you can get a free community license for up to 5 requests per second. Please contact sales if you need more than 5 RPS.
For more details on core unlimited features and premium features, see the editions page.
Ambassador 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 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 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 focuses on traffic into your cluster ("north-south"). While both a service mesh and Ambassador can route L7 traffic, the reality is that these use cases are quite different. Many users will integrate Ambassador with a service mesh. Production customers of Ambassador have integrated with Consul, Istio, and Linkerd2.
Established users will want to better control 404 behavior both for usability and
security. You can leverage the Mapping resource to implement this functionality to
your cluster. Ambassador Edge Stack users can use a 'catch-all' mapping using the '/'
prefix in a mapping configuration. The simplest mapping, described below, returns only 404 text.
To use a custom 404 landing page, simply insert your service and remove the rewrite value.
apiVersion: getambassador.io/v2kind: Mappingmetadata:name: "404-fallback"spec:prefix: "/"rewrite: "/404/" # This must not map to any existing prefix!service: localhost:8500
For more information on the Mapping resource, see Advanced Mapping Configuration.
In a production environment, public access to the console and admin endpoints is not an ideal situation. To solve this, we will be using an Ambassador Module to remove the default mappings and create a new, host-based mapping to expose the Admin endpoint more securely. The Ambassador module applies system-wide configuration settings for Ambassador to follow.
apiVersion: getambassador.io/v2kind: Modulemetadata:name: ambassadorspec:config:diagnostics:enabled: false
After applying this module, the admin endpoint is no longer accessible from the outside world.
We cannot, however, exclude actual administrators from this endpoint, so to create a more managed endpoint for them to use, create a mapping to expose the endpoint.
apiVersion: getambassador.io/v2kind: Mappingmetadata:name: admin-mappingspec:host: admin.example.comprefix: /edge_stack/rewrite: /edge_stack_ui/edge_stack/service: localhost:8500
Now, administrators can connect to the admin console via hostname. Additional Mapping and Filter settings can be appropriately configured to better control access to admin services. To learn more about Ambassador Module configurations, see Ambassador Module
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 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 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. In general, verifying each network hop between your client and backend service is critical to finding the source of the problem.