Consul
Service mesh proxy overview
This topic provides an overview of how Consul uses proxies in your service mesh. A proxy is a type of service that enables unmodified applications to connect to other services in the service mesh. Consul ships with a built-in L4 proxy and has first class support for Envoy. You can plug other proxies into your environment as well, and apply configurations in Consul to define proxy behavior.
Proxy use cases
You can configure proxies to perform several different types of functions in Consul.
Service mesh proxies
A service mesh proxy is any type of proxy service that you use for communication in a service mesh. Specialized proxy implementations, such as sidecar proxies and gateways, are subsets of service mesh proxies. Refer to Deploy service mesh proxy services for instructions on how to deploy a service mesh proxy.
Sidecars
Sidecar proxies are service mesh proxy implementations that transparently handles inbound and outbound service connections. Sidecars automatically wrap and verify TLS connections. In a non-containerized network, each service in your mesh should have its own sidecar proxy.
Refer to Deploy sidecar services for additional information.
Gateways
You can configure service mesh proxies to operate as gateway services, which allow service-to-service traffic across different network areas, including peered clusters, WAN-federated datacenters, and nodes outside the mesh. Consul ships with several types of gateway capabilities, but gateways deliver the underlying functionality.
Refer to Gateways overview for additional information.
Dynamic traffic control
You can configure proxies to dynamically redirect or split traffic to implement a failover strategy, test new features, and roll out new versions of your applications. You can apply a combination of configurations to enable complex scenarios, such as failing over to the geographically nearest service or to services in different network areas that you have designated as being functionally identical.
Refer to the following topics for additional information:
Supported proxies
Consul has first-class support for Envoy proxies, which is a highly configurable open source edge service proxy. Consul configures Envoy by optionally exposing a gRPC service on the local agent that serves Envoy's xDS configuration API. Refer to the following documentation for additional information:
You can use Consul's built-in proxy service that supports L4 network traffic, which is suitable for testing and development but not recommended for production environments. Refer to the built-in proxy reference for additional information.
Workflow
The following procedure describes how to implement proxies:
- Configure global proxy settings. You can configure global passthrough settings for all proxies deployed to your service mesh in the proxy defaults configuration entry. This step is not required, but it enables you to define common behaviors in a central configuration.
- Deploy your service mesh proxy. Configure proxy behavior in a service definition and register the proxy with Consul.
- Start the proxy service. Proxies appear in the list of services registered to Consul and must be started before they begin to route traffic in your service mesh.
Dynamic upstreams require native integration
Service mesh proxies do not support dynamic upstreams. If an application requires dynamic dependencies that are only available at runtime, you must natively integrate the application with Consul service mesh. After integration, the application can use the HTTP API or DNS interface to connect to other services in the mesh.
Proxies in Kubernetes-orchestrated networks
For Kubernetes-orchestrated environments, Consul deploys dataplanes by default to manage sidecar proxies. Consul dataplanes are light-weight processes that leverage existing Kubernetes sidecar orchestration capabilities. Refer to the dataplanes documentation for additional information.
Guidance
Refer to the following resources for help using service mesh proxies: