- Upgrading Ambassador
- Statistics and Monitoring
Ambassador configuration sequence
When you run Ambassador within Kubernetes:
- At startup, Ambassador will look for the
ConfigMap. If it exists, its contents will be used as the baseline Ambassador configuration.
- Ambassador will then scan Kubernetes
services in its namespace, looking for
getambassador.io/config. YAML from these
annotations will be merged into the baseline Ambassador configuration.
- Whenever any services change, Ambassador will update its
- The baseline configuration, if present, will never be updated after Ambassador starts. To effect a change in the baseline configuration, use Kubernetes to force a redeployment of Ambassador.
Note: We recommend using only
annotation-based configuration, so that Ambassador can respond to updates in its environment.
Modifying Ambassador's Underlying Envoy Configuration
Ambassador uses Envoy for the heavy lifting of proxying.
If you need to add additional configuration for Envoy clusters, you will need to use your own custom configuration template. To do this, create a templated
envoy.json file using the Jinja2 template language, and use this to to replace the default template. This method is not officially supported -- if you need to do this, please open a GitHub issue and contact us on Slack for more information if this seems necessary so that we can explore direct Ambassador support for your use case (or, better yet, submit a PR!).
Configuring Ambassador via a Custom Image
You can also run Ambassador by building a custom image that contains baked-in configuration:
- All the configuration data should be collected within a single directory on the filesystem.
At image startup, run
ambassador config $configdir $envoy_json_outwhere
$configdiris the path of the directory containing the configuration data, and
$envoy_json_outis the path to the
envoy.jsonto be written.
In this usage, Ambassador will not look for
annotation-based configuration, and will not update any configuration after startup.