Consul Connect has first class support for using Envoy as a proxy. Consul configures Envoy by optionally exposing a gRPC service on the local agent that serves Envoy's xDS configuration API.
Consul can configure Envoy sidecars to proxy http/1.1, http2, or gRPC traffic at L7 or any other tcp-based protocol at L4. Prior to Consul 1.5.0 Envoy proxies could only proxy tcp at L4.
Configuration of some L7 features is possible via configuration entries. If you wish to use an Envoy feature not currently exposed through these config entries as an interim solution, you can add custom Envoy configuration in the proxy service definition allowing you to use the more powerful features of Envoy.
Why I opened this issue
I need to have a way to connect internal services that allow observability.
Consul Discovery + Connect Services
One of the main goals of service discovery is to provide a catalog of available services. To that end, the agent provides a simple service definition format to declare the availability of a service and to potentially associate it with a health check. A health check is considered to be application level if it is associated with a service. A service is defined in a configuration file or added at runtime over the HTTP interface.
Connect proxies are typically deployed as "sidecars" that run on the same node as the single service instance that they handle traffic for. They might be on the same VM or running as a separate container in the same network namespace.
Layer 7 traffic management allows operators to divide L7 traffic between different subsets of service instances when using Connect.
There are many ways you may wish to carve up a single datacenter's pool of services beyond simply returning all healthy instances for load balancing. Canary testing, A/B tests, blue/green deploys, and soft multi-tenancy (prod/qa/staging sharing compute resources) all require some mechanism of carving out portions of the Consul catalog smaller than the level of a single service and configuring when that subset should receive traffic.
Envoy Integration
Consul Connect has first class support for using Envoy as a proxy. Consul configures Envoy by optionally exposing a gRPC service on the local agent that serves Envoy's xDS configuration API.
Consul can configure Envoy sidecars to proxy http/1.1, http2, or gRPC traffic at L7 or any other tcp-based protocol at L4. Prior to Consul 1.5.0 Envoy proxies could only proxy tcp at L4.
Configuration of some L7 features is possible via configuration entries. If you wish to use an Envoy feature not currently exposed through these config entries as an interim solution, you can add custom Envoy configuration in the proxy service definition allowing you to use the more powerful features of Envoy.
Why I opened this issue
I need to have a way to connect internal services that allow observability.
Consul Discovery + Connect Services
One of the main goals of service discovery is to provide a catalog of available services. To that end, the agent provides a simple service definition format to declare the availability of a service and to potentially associate it with a health check. A health check is considered to be application level if it is associated with a service. A service is defined in a configuration file or added at runtime over the HTTP interface.
Sidecar Service Registration
Connect proxies are typically deployed as "sidecars" that run on the same node as the single service instance that they handle traffic for. They might be on the same VM or running as a separate container in the same network namespace.
Envoy
L7
Layer 7 traffic management allows operators to divide L7 traffic between different subsets of service instances when using Connect.
There are many ways you may wish to carve up a single datacenter's pool of services beyond simply returning all healthy instances for load balancing. Canary testing, A/B tests, blue/green deploys, and soft multi-tenancy (prod/qa/staging sharing compute resources) all require some mechanism of carving out portions of the Consul catalog smaller than the level of a single service and configuring when that subset should receive traffic.