Service-to-service Traffic Across Datacenters

    Mesh gateways enable service mesh traffic to be routed between different Consul datacenters. Datacenters can reside in different clouds or runtime environments where general interconnectivity between all services in all datacenters 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.

    The following diagram describes the architecture for using mesh gateways for cross-datacenter communication:

    Mesh Gateway Tutorial: Follow the mesh gateway tutorial to learn important concepts associated with using mesh gateways for connecting services across datacenters.

    Ensure that your Consul environment meets the following requirements.

    • Consul version 1.6.0 or newer.
    • A local Consul agent is required to manage its configuration.
    • Consul must be enabled in both datacenters.
    • Each datacenter must have a unique name.
    • Each datacenters must be .
    • The primary datacenter must be set to the same value in both datacenters. This specifies which datacenter is the authority for Connect certificates and is required for services in all datacenters to establish mutual TLS with each other.
    • must be enabled.
    • If you want to enable gateways globally you must enable .

    Network

    • General network connectivity to all services within its local Consul datacenter.
    • General network connectivity to all mesh gateways within remote Consul datacenters.

    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.

    Configure the following settings to register the mesh gateway as a service in Consul.

    • Specify in the kind field to register the gateway with Consul.
    • Configure the proxy.upstreams parameters to route traffic to the correct service, namespace, and datacenter. Refer to the upstreams documentation for details. The service proxy.upstreams.destination_name is always required. The proxy.upstreams.datacenter must be configured to enable cross-datacenter traffic. The proxy.upstreams.destination_namespace configuration is only necessary if the destination service is in a different namespace.
    • Define the Proxy.Config settings using opaque parameters compatible with your proxy (i.e., Envoy). For Envoy, refer to the and 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.

    • - (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. That gateway is responsible for ensuring that the data is forwarded to gateways in the destination datacenter. Refer to the flow labeled local in the .

    • remote - The service mesh proxy makes an outbound connection to a gateway running in the destination datacenter. The gateway forwards the data to the final destination service. Refer to the flow labeled remote in the .

    Connect Proxy Configuration

    Set the proxy to the preferred 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

    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.

    Example: Enabling gateways globally.

    Example: Enabling gateways globally.

    HCL

    Enabling Service-to-service Traffic Across Datacenters - 图2

    • HCL
    • YAML
    1. Kind = "proxy-defaults"
    2. Name = "global"
    3. MeshGateway {
    4.    Mode = "local"
    5. }
    1. Kind: proxy-defaults
    2. MeshGateway:
    3. - Mode: local
    4. Name: global
    1. Kind: proxy-defaults
    2. MeshGateway:
    3. - Mode: local
    4. Name: global

    The following service-defaults configuration will enable gateways for all Connect services with the name web.

    Example: Enabling gateways per service.

    HCL

    • HCL
    • YAML
    1. Kind = "service-defaults"
    2. Name = "web"
    3. MeshGateway {
    4.    Mode = "local"
    5. }
    1. Kind: service-defaults
    2. MeshGateway:
    3. - Mode: local
    4. Name: web
    1. Kind: service-defaults
    2. MeshGateway:
    3. - Mode: local
    4. Name: web

    Enabling Gateways for a Service Instance

    The following Proxy Service Registration definition will enable gateways for the service instance in the remote mode.

    Example: Enabling gateways for a service instance.

    Example: Enabling gateways for a service instance.

    HCL

    Enabling Service-to-service Traffic Across Datacenters - 图4

    • HCL
    • YAML
    1. service {
    2.    name = "web-sidecar-proxy"
    3.    kind = "connect-proxy"
    4.    port = 8181
    5.    proxy {
    6.       destination_service_name = "web"
    7.       mesh_gateway {
    8.          mode = "remote"
    9.       }
    10.       upstreams = [
    11.          {
    12.             destination_name = "api"
    13.             datacenter = "secondary"
    14.             local_bind_port = 10000
    15.          }
    16.    }
    17. }
    19. # Or alternatively inline with the service definition:
    21. service {
    22.   name = "web"
    23.   port = 8181
    24.   connect {
    25.     sidecar_service {
    26.       proxy {
    27.         mesh_gateway {
    28.          mode = "remote"
    30.         upstreams = [
    31.           {
    32.             destination_name = "api"
    33.             datacenter = "secondary"
    34.             local_bind_port = 10000
    35.           }
    36.         ]
    37.       }
    38.     }
    39.   }
    40. }
    1. service {
    2.    name = "web-sidecar-proxy"
    3.    kind = "connect-proxy"
    4.    port = 8181
    5.    proxy {
    6.       destination_service_name = "web"
    7.       mesh_gateway {
    8.          mode = "remote"
    9.       }
    10.       upstreams = [
    11.          {
    12.             destination_name = "api"
    13.             datacenter = "secondary"
    14.             local_bind_port = 10000
    15.          }
    16.       ]
    17.    }
    18. }
    20. # Or alternatively inline with the service definition:
    22. service {
    23.   name = "web"
    24.   port = 8181
    25.   connect {
    26.     sidecar_service {
    27.       proxy {
    28.         mesh_gateway {
    29.          mode = "remote"
    30.         }
    31.         upstreams = [
    32.           {
    33.             destination_name = "api"
    34.             datacenter = "secondary"
    35.             local_bind_port = 10000
    36.           }
    37.         ]
    38.       }
    39.     }
    40.   }
    41. }
    1. service:
    2. - kind: connect-proxy
    3.   name: web-sidecar-proxy
    4.   port: 8181
    5.   proxy:
    6.   - destination_service_name: web
    7.     mesh_gateway:
    8.     - mode: remote
    9.     upstreams:
    10.     - datacenter: secondary
    11.       destination_name: api
    12.       local_bind_port: 100

    Enabling Gateways for a Proxy Upstream

    The following service definition will enable gateways in the local mode for one upstream, the remote mode for a second upstream and will disable gateways for a third upstream.

    Example: Enabling gateways for a proxy upstream.

    Example: Enabling gateways for a proxy upstream.

    • HCL
    • YAML
    1.    name = "web-sidecar-proxy"
    2.    kind = "connect-proxy"
    3.    port = 8181
    4.    proxy {
    5.       destination_service_name = "web"
    7.          {
    8.             destination_name = "api"
    9.             local_bind_port = 10000
    10.             mesh_gateway {
    11.                mode = "remote"
    12.             }
    13.          },
    14.          {
    15.             destination_name = "db"
    16.             local_bind_port = 10001
    17.             mesh_gateway {
    18.                mode = "local"
    19.             }
    20.          },
    21.          {
    22.             destination_name = "logging"
    23.             local_bind_port = 10002
    24.             mesh_gateway {
    25.                mode = "none"
    26.             }
    27.          },
    28.       ]
    29.    }
    30. }
    1. service {
    2.    name = "web-sidecar-proxy"
    3.    kind = "connect-proxy"
    4.    port = 8181
    5.    proxy {
    6.       destination_service_name = "web"
    7.       upstreams = [
    8.          {
    9.             destination_name = "api"
    10.             local_bind_port = 10000
    11.             mesh_gateway {
    12.                mode = "remote"
    13.             }
    14.          },
    15.          {
    16.             destination_name = "db"
    17.             local_bind_port = 10001
    18.             mesh_gateway {
    19.                mode = "local"
    20.             }
    21.          },
    22.          {
    23.             destination_name = "logging"
    24.             local_bind_port = 10002
    25.             mesh_gateway {
    26.                mode = "none"
    27.             }
    28.          },
    29.       ]
    30.    }
    31. }
    1. service:
    2. - kind: connect-proxy
    3.   name: web-sidecar-proxy
    4.   port: 8181
    5.   proxy:
    6.   - destination_service_name: web
    7.     upstreams:
    8.     - destination_name: api
    9.       local_bind_port: 10000
    10.       mesh_gateway:
    11.       - mode: remote
    12.     - destination_name: db
    13.       local_bind_port: 10001
    14.       mesh_gateway:
    15.       - mode: local
    16.     - destination_name: logging
    17.       local_bind_port: 10002
    19.       - mode: none