About on

Why Emissary?

Mon, 01 Jan 0001 00:00:00 +0000

Emissary gives platform engineers a comprehensive, self-service edge stack for managing the boundary between end-users and Kubernetes. Built on the Envoy Proxy and fully Kubernetes-native, Emissary is made to support multiple, independent teams that need to rapidly publish, monitor, and update services for end-users. A true edge stack, Emissary can also be used to handle the functions of an API Gateway, a Kubernetes ingress controller, and a layer 7 load balancer (for more, see this blog post).

Features and Benefits

Mon, 01 Jan 0001 00:00:00 +0000

In cloud-native organizations, developers frequently take on responsibility for the full development lifecycle of a service, from development to QA to operations. Emissary was specifically designed for these organizations where developers have operational responsibility for their service(s).

As such, the Emissary is designed to be used by both developers and operators.

Self-Service via Kubernetes Annotations

Emissary is built from the start to support self-service deployments – a developer working on a new service doesn’t have to go to Operations to get their service added to the mesh, they can do it themselves in a matter of seconds. Likewise, a developer can remove their service from the mesh, or merge services, or separate services, as needed, at their convenience. All of these operations are performed via Kubernetes resources or annotations, so they can easily integrate with your existing development workflow.

Frequently Asked Questions

Mon, 01 Jan 0001 00:00:00 +0000

General

Why Emissary?

Kubernetes shifts application architecture for microservices, as well as the development workflow for a full-cycle development. Emissary 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.
A declarative, self-service management model built on Kubernetes Custom Resource Definitions, enabling GitOps-style continuous delivery workflows.

We’ve written about the history of Emissary, Why Emissary In Depth, Features and Benefits and about the evolution of API Gateways.

Support

Mon, 01 Jan 0001 00:00:00 +0000

When running Emissary join our #emissary-ingress slack channel to talk with other users in the community and get your questions answered.

File a Github Issue

If you see a bug you want to fix please file an issue on github.

If you have an issue in our documentation to fix please file an issue on the documentation repository.

Alternatives

Mon, 01 Jan 0001 00:00:00 +0000

Alternatives to Emissary fall into three basic categories:

Hosted API gateways, such as the Amazon API gateway.
Traditional API gateways, such as Kong.
L7 proxies, such as Traefik, NGINX, HAProxy, or Envoy, or Ingress controllers built on these proxies.

Both hosted API gateways and traditional API gateways are:

Not self-service. The management interfaces on traditional API gateways are not designed for developer self-service, and provide limited safety and usability for developers.
Not Kubernetes-native. They’re typically configured using REST APIs, making it challenging to adopt cloud-native patterns such as GitOps and declarative configuration.
Designed for API management, rather than designed for microservices.

A Layer 7 proxy can be used as an API gateway, but typically requires additional bespoke development to support microservices use cases. In fact, many API gateways package the additional features needed for an API gateway on top of an L7 proxy. Emissary uses Envoy, while Kong uses NGINX. If you’re interested in deploying Envoy directly, we’ve written an introductory tutorial.

Known Issues

Mon, 01 Jan 0001 00:00:00 +0000

2.2.1

TLS certificates using elliptic curves were incorrectly flagged as invalid. This issue is corrected in Emissary 2.2.2.

Major Changes in Emissary 2.X

Mon, 01 Jan 0001 00:00:00 +0000

The 2.X family introduces a number of changes to allow Emissary to more gracefully handle larger installations, reduce global configuration to better handle multitenant or multiorganizational installations, reduce memory footprint, and improve performance. We welcome feedback!! Join us on Slack and let us know what you think.

While Emissary 2 is functionally compatible with Emissary 1.14, note that this is a major version change and there are important differences between Emissary 1.X and Emissary 2.0. For details, read on.

Major Changes in Emissary 3.X

Mon, 01 Jan 0001 00:00:00 +0000

The 3.X family introduces a number of changes to ensure Emissary keeps up with latest Envoy versions and to support new features such as HTTP/3. We welcome feedback! Join us on Slack and let us know what you think.

Emissary 3 is functionally compatible with Emissary 2.x, but with any major upgrade there are some changes to consider. Such as, Envoy removing support for V2 Transport Protocol features. Below we will outline some of these changes and things to consider when upgrading.