245 lines
9.3 KiB
Plaintext
245 lines
9.3 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: Service-to-service Traffic Across Partitions
|
|
description: >-
|
|
This topic describes how to configure mesh gateways to route a service's data to upstreams
|
|
in other partitions. It describes how to use Envoy and how you can integrate with your preferred gateway.
|
|
---
|
|
|
|
# Service-to-service Traffic Across Partitions
|
|
|
|
-> **Consul Enterprise 1.11.0+:** Admin partitions are supported in Consul Enterprise versions 1.11.0 and newer.
|
|
|
|
Mesh gateways enable you to route service mesh traffic between different Consul [admin partitions](/docs/enterprise/admin-partitions).
|
|
Partitions can reside in different clouds or runtime environments where general interconnectivity between all services
|
|
in all partitions isn't feasible.
|
|
|
|
Mesh gateways operate by sniffing and extracting the server name indication (SNI) header from the service mesh session and routing the connection to the appropriate destination based on the server name requested. The gateway does not decrypt the data within the mTLS session.
|
|
|
|
## Prerequisites
|
|
|
|
Ensure that your Consul environment meets the following requirements.
|
|
|
|
### Consul
|
|
|
|
* Consul Enterprise version 1.11.0 or newer.
|
|
* A local Consul agent is required to manage its configuration.
|
|
* Consul service mesh must be enabled in all partitions. Refer to the [`connect` documentation](/docs/agent/options#connect) for details.
|
|
* Each partition must have a unique name. Refer to the [admin partitions documentation](/docs/enteprise/admin-partitions) for details.
|
|
* If you want to [enable gateways globally](/docs/connect/mesh-gateway#enabling-gateways-globally) you must enable [centralized configuration](/docs/agent/options#enable_central_service_config).
|
|
|
|
### Proxy
|
|
|
|
Envoy is the only proxy with mesh gateway capabilities in Consul.
|
|
|
|
Mesh gateway proxies receive their configuration through Consul, which automatically generates it based on the proxy's registration.
|
|
Consul can only translate mesh gateway registration information into Envoy configuration.
|
|
|
|
Sidecar proxies that send traffic to an upstream service through a gateway need to know the location of that gateway. They discover the gateway based on their sidecar proxy registrations. Consul can only translate the gateway registration information into Envoy configuration.
|
|
|
|
Sidecar proxies that do not send upstream traffic through a gateway are not affected when you deploy gateways. If you are using Consul's built-in proxy as a Connect sidecar it will continue to work for intra-datacenter traffic and will receive incoming traffic even if that traffic has passed through a gateway.
|
|
|
|
## Configuration
|
|
|
|
Configure the following settings to register the mesh gateway as a service in Consul.
|
|
|
|
* Specify `mesh-gateway` in the `kind` field to register the gateway with Consul.
|
|
* Configure the `proxy.upstreams` parameters to route traffic to the correct service, namespace, and partition. Refer to the [`upstreams` documentation](/docs/connect/registration/service-registration#upstream-configuration-reference) for details. The service `proxy.upstreams.destination_name` is always required. The `proxy.upstreams.destination_partition` must be configured to enable cross-partition traffic. The `proxy.upstreams.destination_namespace` configuration is only necessary if the destination service is in a different namespace.
|
|
* Configure the `exported-services` configuration entry to enable Consul to export services contained in an admin partition to one or more additional partitions. Refer to the [Exported Services documentation](/docs/connect/config-entries/exported-services) for details.
|
|
* Define the `Proxy.Config` settings using opaque parameters compatible with your proxy, i.e., Envoy. For Envoy, refer to the [Gateway Options](/docs/connect/proxies/envoy#gateway-options) and [Escape-hatch Overrides](/docs/connect/proxies/envoy#escape-hatch-overrides) documentation for additional configuration information.
|
|
* If ACLs are enabled, a token granting `service:write` for the gateway's service name and `service:read` for all services in the datacenter or partition must be added to the gateway's service definition. These permissions authorize the token to route communications for other Consul service mesh services, but does not allow decrypting any of their communications.
|
|
|
|
### Modes
|
|
|
|
Each upstream associated with a service mesh proxy can be configured so that it is routed through a mesh gateway.
|
|
Depending on your network, the proxy's connection to the gateway can operate in one of the following modes:
|
|
|
|
* `none` - (Default) No gateway is used and a service mesh connect proxy makes its outbound connections directly
|
|
to the destination services.
|
|
|
|
* `local` - The service mesh connect proxy makes an outbound connection to a gateway running in the same datacenter. The gateway at the outbound connection is responsible for ensuring that the data is forwarded to gateways in the destination partition.
|
|
|
|
* `remote` - The service mesh connect proxy makes an outbound connection to a gateway running in the destination datacenter.
|
|
The gateway forwards the data to the final destination service.
|
|
|
|
### Connect Proxy Configuration
|
|
|
|
Set the proxy to the preferred [mode](#modes) to configure the service mesh proxy. You can specify the mode globally or within child configurations to control proxy behaviors at a lower level. Consul recognizes the following order of precedence if the gateway mode is configured in multiple locations the order of precedence:
|
|
|
|
1. Upstream definition (highest priority)
|
|
2. Service instance definition
|
|
3. Centralized `service-defaults` configuration entry
|
|
4. Centralized `proxy-defaults` configuration entry
|
|
|
|
## Example Configurations
|
|
|
|
Use the following example configurations to help you understand some of the common scenarios.
|
|
|
|
### Enabling Gateways Globally
|
|
|
|
The following `proxy-defaults` configuration will enable gateways for all Connect services in the `local` mode.
|
|
|
|
<CodeTabs heading="Example: Enabling gateways globally.">
|
|
|
|
```hcl
|
|
Kind = "proxy-defaults"
|
|
Name = "global"
|
|
MeshGateway {
|
|
Mode = "local"
|
|
}
|
|
```
|
|
|
|
```yaml
|
|
Kind: proxy-defaults
|
|
MeshGateway:
|
|
- Mode: local
|
|
Name: global
|
|
```
|
|
|
|
</CodeTabs>
|
|
|
|
### Enabling Gateways Per Service
|
|
|
|
The following `service-defaults` configuration will enable gateways for all Connect services with the name `web`.
|
|
|
|
<CodeTabs heading="Example: Enabling gateways per service.">
|
|
|
|
```hcl
|
|
Kind = "service-defaults"
|
|
Name = "web"
|
|
MeshGateway {
|
|
Mode = "local"
|
|
}
|
|
```
|
|
|
|
```yaml
|
|
Kind: service-defaults
|
|
MeshGateway:
|
|
- Mode: local
|
|
Name: web
|
|
```
|
|
</CodeTabs>
|
|
|
|
### Enabling Gateways for a Service Instance
|
|
|
|
The following [Proxy Service Registration](/docs/connect/registration/service-registration)
|
|
definition will enable gateways for `web` service instances in the `finance` partition.
|
|
|
|
<CodeTabs heading="Example: Enabling gateways for a service instance.">
|
|
|
|
```hcl
|
|
service {
|
|
name = "web-sidecar-proxy"
|
|
kind = "connect-proxy"
|
|
port = 8181
|
|
proxy {
|
|
destination_service_name = "web"
|
|
mesh_gateway {
|
|
mode = "local"
|
|
}
|
|
upstreams = [
|
|
{
|
|
destination_partition = "finance"
|
|
destination_namespace = "default"
|
|
destination_type = "service"
|
|
destination_name = "billing"
|
|
local_bind_port = 9090
|
|
}
|
|
]
|
|
}
|
|
}
|
|
```
|
|
|
|
```yaml
|
|
service:
|
|
- kind: connect-proxy
|
|
name: web-sidecar-proxy
|
|
port: 8181
|
|
proxy:
|
|
- destination_service_name: web
|
|
mesh_gateway:
|
|
- mode: local
|
|
upstreams:
|
|
- destination_name: billing
|
|
destination_namespace: default
|
|
destination_partition: finance
|
|
destination_type: service
|
|
local_bind_port: 9090
|
|
```
|
|
</CodeTabs>
|
|
|
|
### Enabling Gateways for a Proxy Upstream
|
|
|
|
The following service definition will enable gateways in `local` mode for three different partitions. Note that each service exists in the same namespace, but are separated by admin partition.
|
|
|
|
<CodeTabs heading="Example: Enabling gateways for a proxy upstream.">
|
|
|
|
```hcl
|
|
service {
|
|
name = "web-sidecar-proxy"
|
|
kind = "connect-proxy"
|
|
port = 8181
|
|
proxy {
|
|
destination_service_name = "web"
|
|
upstreams = [
|
|
{
|
|
destination_name = "api"
|
|
destination_namespace = "dev"
|
|
destination_partition = "api"
|
|
local_bind_port = 10000
|
|
mesh_gateway {
|
|
mode = "local"
|
|
}
|
|
},
|
|
{
|
|
destination_name = "db"
|
|
destination_namespace = "dev"
|
|
destination_partition = "db"
|
|
local_bind_port = 10001
|
|
mesh_gateway {
|
|
mode = "local"
|
|
}
|
|
},
|
|
{
|
|
destination_name = "logging"
|
|
destination_namespace = "dev"
|
|
destination_partition = "logging"
|
|
local_bind_port = 10002
|
|
mesh_gateway {
|
|
mode = "local"
|
|
}
|
|
},
|
|
]
|
|
}
|
|
}
|
|
```
|
|
|
|
```yaml
|
|
service:
|
|
- kind: connect-proxy
|
|
name: web-sidecar-proxy
|
|
port: 8181
|
|
proxy:
|
|
- destination_service_name: web
|
|
upstreams:
|
|
- destination_name: api
|
|
destination_namespace: dev
|
|
destination_partition: api
|
|
local_bind_port: 10000
|
|
mesh_gateway:
|
|
- mode: local
|
|
- destination_name: db
|
|
destination_namespace: dev
|
|
destination_partition: db
|
|
local_bind_port: 10001
|
|
mesh_gateway:
|
|
- mode: local
|
|
- destination_name: logging
|
|
destination_namespace: dev
|
|
destination_partition: logging
|
|
local_bind_port: 10002
|
|
mesh_gateway:
|
|
- mode: local
|
|
```
|
|
</CodeTabs>
|