- Kubernetes Integration (architecture overview)
- Adding Tracing
- Upgrading Ambassador
- Statistics and Monitoring
- Need Help?
Kubernetes Integration: Ambassador Architecture Overview
Ambassador is a control plane
Ambassador is a specialized control plane for Envoy Proxy. In this architecture, Ambassador translates configuration (in the form of Kubernetes annotations) to Envoy configuration. All actual traffic is directly handled by the high-performance Envoy Proxy.
When a user applies a Kubernetes manifest containing Ambassador annotations, the following steps occur:
- Ambassador is asynchronously notified by the Kubernetes API of the change.
- Ambassador translates the configuration into an abstract intermediate representation (IR).
- An Envoy configuration file is generated from the IR.
- The Envoy configuration file is validated by Ambassador (using Envoy in validation mode).
- Assuming the file is valid configuration, Ambassador uses Envoy's hot restart mechanism to deploy the new configuration and properly drain connections.
Scaling and availability
Ambassador relies on Kubernetes for scaling, high availability, and persistence. All Ambassador configuration is stored directly in Kubernetes; there is no database. Ambassador is packaged as a single container that contains both the control plane and an Envoy Proxy instance. By default, Ambassador is deployed as a Kubernetes
deployment and can be scaled and managed like any other Kubernetes deployment.
Ambassador closely tracks Envoy Proxy releases. A stable branch of Envoy Proxy is maintained that enables the team to cherry pick specific fixes into Ambassador.