- Features and Benefits
- Using Ambassador Edge Stack in Your Organization
- Ambassador Edge Stack vs. Other Software
- Certified Builds
- Ambassador Edge Stack Architecture
- Ambassador Edge Stack Deployment Architecture
- Continuous Delivery, Declarative Config, and GitOps
- Microservices API Gateways
- Rate Limiting Concepts
- Self-Service Routing and Deployment Control
- Safely Testing in Production
- OAuth & OIDC Overview
- Why Ambassador Edge Stack Uses Envoy Proxy (External Link)
- Configuring Ambassador Edge Stack
- Mapping Services
- Canary Releases
- Circuit Breakers
- Cross Origin Resource Sharing
- Header-based routing
- Host Header
- Host CRD
- Prefix Regex
- Rate Limits
- Remove Request Headers
- Remove Response Headers
- Add Request Headers
- Add Response Headers
- Automatic Retries
- Routing TCP Connections
- Traffic Shadowing
- Developer Portal
- Filter Reference
- Statistics and Monitoring
Traditionally, API Gateways have focused on operators as the primary user. Ambassador Edge Stack considers both developers and operators to be first-class citizens.
The Ambassador Edge Stack model is a decentralized, declarative configuration model. What does this mean?
Decentralized. Ambassador Edge Stack is designed so that lots of developers can individually configure a specific aspect of its configuration (usually a route). Ambassador Edge Stack then aggregates these individual bits of configuration into a master configuration for the gateway.
Declarative. In Ambassador Edge Stack, the user declares the desired end state of the configuration. Ambassador Edge Stack then figures out how to achieve that desired end state. If the desired end state is already in effect, no change happens. This is a contrast from an imperative model (most frequently seen as a REST API configuration), which forces the user to understand how to configure the gateway.
In a typical Ambassador Edge Stack deployment, each service is owned by a developer or development team. This team writes the code, tests, and deploys the service. To deploy this service, a team must create a Kubernetes manifest that specifies the desired end state of the service. For example, the
my-service service could be defined as below:
kind: ServiceapiVersion: v1metadata:name: my-servicespec:selector:app: MyAppports:- protocol: TCPport: 80targetPort: 9376
Because a Kubernetes
service is the fundamental abstraction by which new services are exposed to other services and end-users, Ambassador Edge Stack extends the
service with a custom mapping. For example:
---apiVersion: getambassador.io/v2kind: Mappingmetadata:name: my-servicespec:prefix: /my-service/service: my-service---kind: ServiceapiVersion: v1metadata:name: my-servicespec:selector:app: MyAppports:- protocol: TCPport: 80targetPort: 9376
With this approach, there is no centralized Ambassador Edge Stack configuration file -- the routing configuration for Ambassador Edge Stack is associated with each service. This offers numerous benefits:
- Agility: Service owners can change their Ambassador Edge Stack configuration without worrying about other end-users or going through a central operations function.
- Organizational scalability: Configuring individual routes in Ambassador Edge Stack is the responsibility of service owners, instead of a centralized team.
- Maintainability: If a service is deleted, the route disappears with the service. All of the machinery used to manage Kubernetes manifests can be used with Ambassador Edge Stack without modification.
You can use Ambassador Edge Stack as an Ingress Controller.