Peering Mesh Gateway Updates for GA (#15344)
* docs(peering): remove beta references Co-authored-by: hc-github-team-consul-core <github-team-consul-core@hashicorp.com> Co-authored-by: Eric Haberkorn <erichaberkorn@gmail.com> Co-authored-by: Derek Menteer <105233703+hashi-derek@users.noreply.github.com>
This commit is contained in:
Dan Stough
GitHub
parent
62c0390707
commit
8a2d3c6cc6
|
|
@ -635,7 +635,7 @@ service definition keys for compatibility with the config file format.
|
|||
- `Kind` `(string: "")` - The kind of service. Defaults to "" which is a
|
||||
typical Consul service. This value may also be "connect-proxy" for
|
||||
[Connect](/docs/connect) proxies representing another service,
|
||||
"mesh-gateway" for instances of a [mesh gateway](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters),
|
||||
"mesh-gateway" for instances of a [mesh gateway](/docs/connect/gateways/mesh-gateway#connect-proxy-configuration),
|
||||
"terminating-gateway" for instances of a [terminating gateway](/docs/connect/gateways/terminating-gateway),
|
||||
or "ingress-gateway" for instances of a [ingress gateway](/docs/connect/gateways/ingress-gateway).
|
||||
|
||||
|
|
|
|||
|
|
@ -93,7 +93,7 @@ The table below shows this endpoint's support for
|
|||
parameter.
|
||||
|
||||
- `OverrideMeshGateway` `(MeshGatewayConfig: <optional>)` - Overrides the final
|
||||
[mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration)
|
||||
[mesh gateway configuration](/docs/connect/gateways/mesh-gateway#connect-proxy-configuration)
|
||||
for this any service resolved in the compiled chain.
|
||||
|
||||
This value comes from either the [proxy
|
||||
|
|
|
|||
|
|
@ -344,7 +344,7 @@ spec:
|
|||
name: 'MeshGateway',
|
||||
type: 'MeshGatewayConfig: <optional>',
|
||||
description: `Controls the default
|
||||
[mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration)
|
||||
[mesh gateway configuration](/docs/connect/gateways/mesh-gateway#connect-proxy-configuration)
|
||||
for all proxies. Added in v1.6.0.`,
|
||||
children: [
|
||||
{
|
||||
|
|
|
|||
|
|
@ -444,7 +444,7 @@ represents a location outside the Consul cluster. They can be dialed directly wh
|
|||
name: 'MeshGateway',
|
||||
type: 'MeshGatewayConfig: <optional>',
|
||||
description: `Controls the default
|
||||
[mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration)
|
||||
[mesh gateway configuration](/docs/connect/gateways/mesh-gateway#connect-proxy-configuration)
|
||||
for this upstream.`,
|
||||
children: [
|
||||
{
|
||||
|
|
@ -595,7 +595,7 @@ represents a location outside the Consul cluster. They can be dialed directly wh
|
|||
name: 'MeshGateway',
|
||||
type: 'MeshGatewayConfig: <optional>',
|
||||
description: `Controls the default
|
||||
[mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration)
|
||||
[mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters#connect-proxy-configuration)
|
||||
for this upstream.`,
|
||||
children: [
|
||||
{
|
||||
|
|
@ -753,7 +753,7 @@ represents a location outside the Consul cluster. They can be dialed directly wh
|
|||
name: 'MeshGateway',
|
||||
type: 'MeshGatewayConfig: <optional>',
|
||||
description: `Controls the default
|
||||
[mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration)
|
||||
[mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters#connect-proxy-configuration)
|
||||
for this service. Added in v1.6.0.`,
|
||||
children: [
|
||||
{
|
||||
|
|
|
|||
|
|
@ -19,13 +19,15 @@ in different clouds or runtime environments where general interconnectivity betw
|
|||
isn't feasible. One scenario where this is useful is when connecting networks with overlapping IP address space.
|
||||
|
||||
These gateways operate by sniffing the SNI header out of the mTLS connection and then routing the connection to the
|
||||
appropriate destination based on the server name requested. The data within the mTLS session is not decrypted by
|
||||
the Gateway.
|
||||
appropriate destination based on the server name requested.
|
||||
|
||||
As of Consul 1.8.0, mesh gateways can also forward gossip and RPC traffic between Consul servers.
|
||||
This is enabled by [WAN federation via mesh gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways).
|
||||
|
||||
For more information about mesh gateways, review the [complete documentation](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters)
|
||||
As of Consul 1.14.0, mesh gateways can route both data-plane (service-to-service) and control-plane (consul-to-consul) traffic for peered clusters.
|
||||
See [Mesh Gateways for Peering Control Plane Traffic](/docs/connect/gateways/mesh-gateway/peering-via-mesh-gateways)
|
||||
|
||||
For more information about mesh gateways, review the [complete documentation](/docs/connect/gateways/mesh-gateway)
|
||||
and the [mesh gateway tutorial](https://learn.hashicorp.com/tutorials/consul/service-mesh-gateways).
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -23,13 +23,15 @@ Mesh gateways enable service mesh traffic to be routed between different Consul
|
|||
in different clouds or runtime environments where general interconnectivity between all services in all datacenters
|
||||
isn't feasible.
|
||||
|
||||
They 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.
|
||||
They 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.
|
||||
|
||||
Mesh gateways enable the following scenarios:
|
||||
|
||||
* **Federate multiple datacenters across a WAN**. Since Consul 1.8.0, mesh gateways can forward gossip and RPC traffic between Consul servers. See [WAN federation via mesh gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways) for additional information.
|
||||
- **Service-to-service communication across datacenters**. Refer to [Enabling Service-to-service Traffic Across Datacenters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) for additional information.
|
||||
- **Service-to-service communication across WAN-federated datacenters**. Refer to [Enabling Service-to-service Traffic Across Datacenters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters) for additional information.
|
||||
- **Service-to-service communication across admin partitions**. Since Consul 1.11.0, you can create administrative boundaries for single Consul deployments called "admin partitions". You can use mesh gateways to facilitate cross-partition communication. Refer to [Enabling Service-to-service Traffic Across Admin Partitions](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions) for additional information.
|
||||
- **Bridge multiple datacenters using Cluster Peering**. Since Consul 1.14.0, mesh gateways can be used to route peering control-plane traffic between peered Consul Servers. See [Mesh Gateways for Peering Control Plane Traffic](/docs/connect/gateways/mesh-gateway/peering-via-mesh-gateways) for more information.
|
||||
- **Service-to-service communication across peered datacenters**. Refer to [Mesh Gateways between Peered Clusters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-peers) for more information.
|
||||
|
||||
-> **Mesh gateway tutorial**: Follow the [mesh gateway tutorial](https://learn.hashicorp.com/tutorials/consul/service-mesh-gateways) to learn concepts associated with mesh gateways.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,256 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Mesh Gateways
|
||||
description: >-
|
||||
Mesh gateways are specialized proxies that route data between services that cannot communicate directly. Learn how mesh gateways are used in different Consul configurations.
|
||||
---
|
||||
|
||||
# Mesh Gateways
|
||||
|
||||
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.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Mesh gateways can be used with any of the following Consul configrations for managing separate datacenters or partitions.
|
||||
|
||||
1. WAN Federation
|
||||
* [Mesh gateways can be used to route service-to-service traffic between datacenters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters)
|
||||
* [Mesh gateways can be used to route all WAN traffic, including from Consul servers](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways)
|
||||
2. Cluster Peering
|
||||
* [Mesh gateways can be used to route service-to-service traffic between datacenters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-peers)
|
||||
* [Mesh gateways can be used to route control-plane traffic from Consul servers](/docs/connect/gateways/mesh-gateway/peering-via-mesh-gateways)
|
||||
3. Admin Partitions
|
||||
* [Mesh gateways can be used to route service-to-service traffic between admin partitions in the same Consul datacenter](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions)
|
||||
|
||||
### Consul
|
||||
|
||||
Review the [specific guide](#prerequisites) for your use case to determined the required version of Consul.
|
||||
|
||||
### 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.
|
||||
|
||||
## 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 datacenter. 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.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 [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` - No gateway is used and a service mesh connect proxy makes its outbound connections directly
|
||||
to the destination services. This is the default for WAN federation. This setting is invalid for peered clusters
|
||||
and will be treated as remote instead.
|
||||
|
||||
* `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.
|
||||
|
||||
* `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. This is the default for peered clusters.
|
||||
|
||||
### 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 the service instance in the `remote` mode.
|
||||
|
||||
<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 = "remote"
|
||||
}
|
||||
upstreams = [
|
||||
{
|
||||
destination_name = "api"
|
||||
datacenter = "secondary"
|
||||
local_bind_port = 10000
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
|
||||
# Or alternatively inline with the service definition:
|
||||
|
||||
service {
|
||||
name = "web"
|
||||
port = 8181
|
||||
connect {
|
||||
sidecar_service {
|
||||
proxy {
|
||||
mesh_gateway {
|
||||
mode = "remote"
|
||||
}
|
||||
upstreams = [
|
||||
{
|
||||
destination_name = "api"
|
||||
datacenter = "secondary"
|
||||
local_bind_port = 10000
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
```yaml
|
||||
service:
|
||||
- kind: connect-proxy
|
||||
name: web-sidecar-proxy
|
||||
port: 8181
|
||||
proxy:
|
||||
- destination_service_name: web
|
||||
mesh_gateway:
|
||||
- mode: remote
|
||||
upstreams:
|
||||
- datacenter: secondary
|
||||
destination_name: api
|
||||
local_bind_port: 100
|
||||
```
|
||||
|
||||
</CodeTabs>
|
||||
|
||||
### 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.
|
||||
|
||||
<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"
|
||||
local_bind_port = 10000
|
||||
mesh_gateway {
|
||||
mode = "remote"
|
||||
}
|
||||
},
|
||||
{
|
||||
destination_name = "db"
|
||||
local_bind_port = 10001
|
||||
mesh_gateway {
|
||||
mode = "local"
|
||||
}
|
||||
},
|
||||
{
|
||||
destination_name = "logging"
|
||||
local_bind_port = 10002
|
||||
mesh_gateway {
|
||||
mode = "none"
|
||||
}
|
||||
},
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
```yaml
|
||||
service:
|
||||
- kind: connect-proxy
|
||||
name: web-sidecar-proxy
|
||||
port: 8181
|
||||
proxy:
|
||||
- destination_service_name: web
|
||||
upstreams:
|
||||
- destination_name: api
|
||||
local_bind_port: 10000
|
||||
mesh_gateway:
|
||||
- mode: remote
|
||||
- destination_name: db
|
||||
local_bind_port: 10001
|
||||
mesh_gateway:
|
||||
- mode: local
|
||||
- destination_name: logging
|
||||
local_bind_port: 10002
|
||||
mesh_gateway:
|
||||
- mode: none
|
||||
```
|
||||
</CodeTabs>
|
||||
|
|
@ -0,0 +1,70 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Mesh Gateways for Peering Control Plane Traffic
|
||||
description: >-
|
||||
Mesh gateways are specialized proxies that route data between services that cannot communicate directly. Learn how to enable traffic across clusters in different datacenters or admin partitions that have an established peering connection.
|
||||
---
|
||||
|
||||
# Mesh Gateways for Peering Control Plane Traffic
|
||||
|
||||
In addition to [service-to-service traffic routing](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-peers), mesh gateways can optionally be used to route control-plane traffic between peers.
|
||||
This includes the initial secret handshake and the bi-directional stream replicating peering data.
|
||||
This data is not decrypted by the mesh gateway(s).
|
||||
Instead, it is transmitted end-to-end using the accepting cluster’s auto-generated TLS certificate on the gRPC TLS port.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
To configure mesh gateways for cluster peering control plane traffic, make sure your Consul environment meets the following requirements:
|
||||
|
||||
- Consul version 1.14.0 or newer.
|
||||
- A local Consul agent in both clusters is required to manage mesh gateway configuration.
|
||||
- Use [Envoy proxies](/docs/connect/proxies/envoy). Envoy is the only proxy with mesh gateway capabilities in Consul.
|
||||
|
||||
## Configuration
|
||||
|
||||
Configure the following settings to register and use the mesh gateway as a service in Consul.
|
||||
|
||||
### Gateway registration
|
||||
|
||||
Register a mesh gateway in each of cluster that will be peered.
|
||||
|
||||
- Specify `mesh-gateway` in the `kind` field to register the gateway with Consul.
|
||||
- Define the `Proxy.Config` settings using opaque parameters compatible with your proxy. 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.
|
||||
- Apply a [Mesh config entry](/docs/connect/config-entries/mesh#peer-through-mesh-gateways) with `PeerThroughMeshGateways = true`. See [modes](#modes) for a discussion of when to apply this.
|
||||
|
||||
Alternatively, you can also use the CLI to spin up and register a gateway in Consul. For additional information, refer to the [`consul connect envoy` command](/commands/connect/envoy#mesh-gateways).
|
||||
|
||||
For Consul Enterprise clusters, mesh gateways must be registered in the "default" partition because this is implicitly where Consul servers are assigned.
|
||||
|
||||
### ACL configuration
|
||||
|
||||
- If ACLs are enabled, you must add a token granting `service:write` for the gateway's service name and `service:read` for all services in the "default" Enterprise admin partition or OSS datacenter to the gateway's service definition.
|
||||
These permissions authorize the token to route communications for other Consul service mesh services.
|
||||
|
||||
### Modes
|
||||
|
||||
Connect proxy configuration [Modes](/docs/connect/gateways/mesh-gateway#connect-proxy-configuration#modes) are not applicable to peering control plane traffic.
|
||||
The flow of control plane traffic through the gateway is implied by the presence of a [Mesh config entry](/docs/connect/config-entries/mesh#peer-through-mesh-gateways) with `PeerThroughMeshGateways = true`.
|
||||
|
||||
<CodeTabs heading="Example: Enabling Peering Control Plane Traffic for Mesh Gateways">
|
||||
|
||||
```hcl
|
||||
Kind = "mesh"
|
||||
Peering {
|
||||
PeerThroughMeshGateways = true
|
||||
}
|
||||
```
|
||||
|
||||
```yaml
|
||||
Kind: mesh
|
||||
Peeering:
|
||||
PeerThroughMeshGateways: true
|
||||
```
|
||||
</CodeTabs>
|
||||
|
||||
By setting this mesh config on a cluster before [creating a peering token](/docs/connect/cluster-peering/create-manage-peering#create-a-peering-token), inbound control plane traffic will be sent through the mesh gateway registered this cluster, also known the accepting cluster.
|
||||
As mesh gateway instances register and leave the accepting cluster, their addresses will be exposed to the dialing cluster over the bi-directional peering stream.
|
||||
|
||||
Setting this mesh config on a cluster before [establishing a connection](/docs/connect/cluster-peering/create-manage-peering#establish-a-connection-between-clusters) will cause the outbound control plane traffic to flow through the mesh gateway.
|
||||
|
||||
To route all peering control plane traffic though mesh gateways, both the accepting and dialing cluster must have the mesh config entry applied.
|
||||
|
|
@ -25,7 +25,7 @@ Ensure that your Consul environment meets the following requirements.
|
|||
* 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/config/config-files#connect) for details.
|
||||
* Each partition must have a unique name. Refer to the [admin partitions documentation](/docs/enterprise/admin-partitions) for details.
|
||||
* If you want to [enable gateways globally](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#enabling-gateways-globally) you must enable [centralized configuration](/docs/agent/config/config-files#enable_central_service_config).
|
||||
* If you want to [enable gateways globally](/docs/connect/gateways/mesh-gateway#enabling-gateways-globally) you must enable [centralized configuration](/docs/agent/config/config-files#enable_central_service_config).
|
||||
|
||||
### Proxy
|
||||
|
||||
|
|
|
|||
|
|
@ -9,16 +9,18 @@ description: >-
|
|||
|
||||
Mesh gateways are required for you to route service mesh traffic between different Consul clusters. Clusters can reside in different clouds or runtime environments where general interconnectivity between all services in all clusters is not feasible.
|
||||
|
||||
Unlike mesh gateways for datacenters and partitions, mesh gateways between peers terminate mTLS sessions to decrypt data to HTTP services and then re-encrypt traffic to send to services. Data must be decrypted in order to evaluate and apply dynamic routing rules at the destination cluster, which reduces coupling between peers.
|
||||
At a minimum, a peered cluster exporting a service must have a mesh gateway registered.
|
||||
For Enterprise, this mesh gateway must also be registered in the same partition as the exported service(s).
|
||||
To use the `local` mesh gateway mode, there must also be a mesh gateway regsitered in the importing cluster.
|
||||
|
||||
Unlike mesh gateways for WAN-federated datacenters and partitions, mesh gateways between peers terminate mTLS sessions to decrypt data to HTTP services and then re-encrypt traffic to send to services. Data must be decrypted in order to evaluate and apply dynamic routing rules at the destination cluster, which reduces coupling between peers.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
To configure mesh gateways for cluster peering, make sure your Consul environment meets the following requirements:
|
||||
|
||||
- Consul version 1.13.0 or newer.
|
||||
- Consul version 1.14.0 or newer.
|
||||
- A local Consul agent is required to manage mesh gateway configuration.
|
||||
- [Enable Consul service mesh](/docs/agent/config/config-files#connect-parameters) in all clusters.
|
||||
- [Enable `peering`](/docs/agent/config/config-files) on all Consul servers.
|
||||
- Use [Envoy proxies](/docs/connect/proxies/envoy). Envoy is the only proxy with mesh gateway capabilities in Consul.
|
||||
|
||||
## Configuration
|
||||
|
|
@ -49,4 +51,6 @@ Alternatively, you can also use the CLI to spin up and register a gateway in Con
|
|||
|
||||
### Modes
|
||||
|
||||
Modes are not configurable for mesh gateways that connect peered clusters. By default, all proxies connecting to peered clusters use mesh gateways in [remote mode](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#remote).
|
||||
Modes are configurable as either `remote` or `local` for mesh gateways that connect peered clusters.
|
||||
The `none` setting is invalid for mesh gateways in peered clusters and will be ignored by the gateway.
|
||||
By default, all proxies connecting to peered clusters use mesh gateways in [remote mode](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters#remote).
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Mesh Gateways between Datacenters
|
||||
page_title: Mesh Gateways between WAN-Federated Datacenters
|
||||
description: >-
|
||||
Mesh gateways are specialized proxies that route data between services that cannot communicate directly. Learn how to enable service-to-service traffic across datacenters and review example configuration entries.
|
||||
Mesh gateways are specialized proxies that route data between services that cannot communicate directly. Learn how to enable service-to-service traffic across wan-federated datacenters and review example configuration entries.
|
||||
---
|
||||
|
||||
# Mesh Gateways between Datacenters
|
||||
# Mesh Gateways between WAN-Federated Datacenters
|
||||
|
||||
-> **1.6.0+:** This feature is available in Consul versions 1.6.0 and newer.
|
||||
|
||||
|
|
@ -34,7 +34,7 @@ Ensure that your Consul environment meets the following requirements.
|
|||
* Each datacenters must be [WAN joined](https://learn.hashicorp.com/consul/security-networking/datacenters).
|
||||
* The [primary datacenter](/docs/agent/config/config-files#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.
|
||||
* [gRPC](/docs/agent/config/config-files#grpc_port) must be enabled.
|
||||
* If you want to [enable gateways globally](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#enabling-gateways-globally) you must enable [centralized configuration](/docs/agent/config/config-files#enable_central_service_config).
|
||||
* If you want to [enable gateways globally](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters#enabling-gateways-globally) you must enable [centralized configuration](/docs/agent/config/config-files#enable_central_service_config).
|
||||
|
||||
### Network
|
||||
|
||||
|
|
@ -9,7 +9,7 @@ description: >-
|
|||
|
||||
-> **1.8.0+:** This feature is available in Consul versions 1.8.0 and higher
|
||||
|
||||
~> This topic requires familiarity with [mesh gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters).
|
||||
~> This topic requires familiarity with [mesh gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters).
|
||||
|
||||
WAN federation via mesh gateways allows for Consul servers in different datacenters
|
||||
to be federated exclusively through mesh gateways.
|
||||
|
|
@ -38,7 +38,7 @@ Sometimes this prerequisite is difficult or undesirable to meet:
|
|||
|
||||
Operators looking to simplify their WAN deployment and minimize the exposed
|
||||
security surface area can elect to join these datacenters together using [mesh
|
||||
gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) to do so.
|
||||
gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters) to do so.
|
||||
|
||||
[](/img/wan-federation-connectivity-mesh-gateways.png)
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ for filtering by instance.
|
|||
|
||||
~> We recommend that terminating gateways are not exposed to the WAN or open internet. This is because terminating gateways
|
||||
hold certificates to decrypt Consul Connect traffic directed at them and may be configured with credentials to connect
|
||||
to linked services. Connections over the WAN or open internet should flow through [mesh gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters)
|
||||
to linked services. Connections over the WAN or open internet should flow through [mesh gateways](/docs/connect/gateways/mesh-gateway)
|
||||
whenever possible since they are not capable of decrypting traffic or connecting directly to services.
|
||||
|
||||
By specifying a path to a [CA file](/docs/connect/config-entries/terminating-gateway#cafile) connections
|
||||
|
|
|
|||
|
|
@ -228,7 +228,7 @@ A single node in the compiled discovery chain.
|
|||
be considered healthy.
|
||||
|
||||
- `MeshGateway` `(MeshGatewayConfig)` - The [mesh gateway
|
||||
configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration)
|
||||
configuration](/docs/connect/gateways/mesh-gateway#connect-proxy-configuration)
|
||||
to use when connecting to this target's service instances.
|
||||
|
||||
- `Mode` `(string: "")` - One of `none`, `local`, or `remote`.
|
||||
|
|
|
|||
|
|
@ -264,7 +264,7 @@ The following roles are supported for service entries:
|
|||
|
||||
- `connect-proxy`: Defines the configuration for a connect proxy
|
||||
- `ingress-gateway`: Defines the configuration for an [ingress gateway](/docs/connect/config-entries/ingress-gateway)
|
||||
- `mesh-gateway`: Defines the configuration for a [mesh gateway](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#mesh-gateway-configuration)
|
||||
- `mesh-gateway`: Defines the configuration for a [mesh gateway](/docs/connect/gateways/mesh-gateway)
|
||||
- `terminating-gateway`: Defines the configuration for a [terminating gateway](/docs/connect/config-entries/terminating-gateway#terminating-gateway)
|
||||
|
||||
In the service definition example described above, the service is registered as a proxy because the `kind` property is set to `connect-proxy`.
|
||||
|
|
|
|||
|
|
@ -138,7 +138,7 @@ in their [`network_configuration`](https://registry.terraform.io/providers/hashi
|
|||
Add the `gateway-task` to your Terraform configuration if you want to deploy a mesh gateway. Mesh gateways enable service to service communication across the WAN, as well as federate service mesh traffic across Consul admin partitions and Consul datacenters over the WAN. Refer to the following documentation to learn more about mesh gateways:
|
||||
|
||||
* [WAN Federation via Mesh Gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways)
|
||||
* [Service-to-service Traffic Across Datacenters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters).
|
||||
* [Service-to-service Traffic Across Datacenters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters).
|
||||
|
||||
You must add and configure a `gateway-task` for each Consul datacenter in your network. You must also enable TLS and gossip encryption on all server and client agents in all data centers per the [Requirements](#requirements). 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.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ description: >-
|
|||
|
||||
-> **1.8.0+:** This feature is available in Consul versions 1.8.0 and higher
|
||||
|
||||
~> This topic requires familiarity with [Mesh Gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) and [WAN Federation Via Mesh Gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways).
|
||||
~> This topic requires familiarity with [Mesh Gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters) and [WAN Federation Via Mesh Gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways).
|
||||
|
||||
-> Looking for a step-by-step guide? Complete the [Secure and Route Service Mesh Communication Across Kubernetes](https://learn.hashicorp.com/tutorials/consul/kubernetes-mesh-gateways?utm_source=docs) tutorial to learn more.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ description: >-
|
|||
|
||||
-> **1.8.0+:** This feature is available in Consul versions 1.8.0 and higher
|
||||
|
||||
~> This topic requires familiarity with [Mesh Gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) and [WAN Federation Via Mesh Gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways).
|
||||
~> This topic requires familiarity with [Mesh Gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters) and [WAN Federation Via Mesh Gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways).
|
||||
|
||||
Consul datacenters running on non-kubernetes platforms like VMs or bare metal can
|
||||
be federated with Kubernetes datacenters. Just like with Kubernetes, one datacenter
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ description: >-
|
|||
|
||||
# Federation Between Kubernetes Clusters with Vault as Secrets Backend
|
||||
|
||||
~> **Note**: This topic requires familiarity with [Mesh Gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters), [WAN Federation Via Mesh Gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways).
|
||||
~> **Note**: This topic requires familiarity with [Mesh Gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters), [WAN Federation Via Mesh Gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways).
|
||||
|
||||
This page describes how you can federate multiple Kubernetes clusters using Vault as the secrets backend. See the [Multi-Cluster Overview](/docs/k8s/deployment-configurations/multi-cluster) for more information on use cases and how it works.
|
||||
|
||||
|
|
|
|||
|
|
@ -31,6 +31,6 @@ You can also add the `consul-lambda-extension` plugin as a layer in your Lambda
|
|||
|
||||
Refer to [Invoke Services from Lambda Functions](/docs/lambda/invoke-from-lambda) for additional information about registering Lambda functions into Consul.
|
||||
|
||||
Consul mesh gateways are required to send requests from Lambda functions to mesh services. Refer to [Mesh Gateways between Datacenters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) for additional information.
|
||||
Consul mesh gateways are required to send requests from Lambda functions to mesh services. Refer to [Mesh Gateways](/docs/connect/gateways/mesh-gateway) for additional information.
|
||||
|
||||
Note that L7 traffic management features are not supported. As a result, requests from Lambda functions ignore service routes and splitters.
|
||||
Note that L7 traffic management features are not supported. As a result, requests from Lambda functions ignore service routes and splitters.
|
||||
|
|
|
|||
|
|
@ -86,7 +86,7 @@ spec:
|
|||
|
||||
The mesh gateway must be running and registered to the Lambda function’s Consul datacenter. Refer to the following documentation and tutorials for instructions:
|
||||
|
||||
- [Mesh Gateways between Datacenters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters)
|
||||
- [Mesh Gateways between WAN-Federated Datacenters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters)
|
||||
- [Mesh Gateways between Admin Partitions](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions)
|
||||
- [Mesh Gateways between Peered Clusters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-peers)
|
||||
- [Connect Services Across Datacenters with Mesh Gateways](https://developer.hashicorp.com/consul/tutorials/developer-mesh/service-mesh-gateways)
|
||||
|
|
|
|||
|
|
@ -466,18 +466,26 @@
|
|||
{
|
||||
"title": "Mesh Gateways",
|
||||
"routes": [
|
||||
{
|
||||
"title": "Overview",
|
||||
"path": "connect/gateways/mesh-gateway"
|
||||
},
|
||||
{
|
||||
"title": "WAN Federation",
|
||||
"path": "connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways"
|
||||
},
|
||||
{
|
||||
"title": "Enabling Service-to-service Traffic Across Datacenters",
|
||||
"path": "connect/gateways/mesh-gateway/service-to-service-traffic-datacenters"
|
||||
"title": "Enabling Service-to-service Traffic Across WAN Federated Datacenters",
|
||||
"path": "connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters"
|
||||
},
|
||||
{
|
||||
"title": "Enabling Service-to-service Traffic Across Admin Partitions",
|
||||
"path": "connect/gateways/mesh-gateway/service-to-service-traffic-partitions"
|
||||
},
|
||||
{
|
||||
"title": "Cluster Peering",
|
||||
"path": "connect/gateways/mesh-gateway/peering-via-mesh-gateways"
|
||||
},
|
||||
{
|
||||
"title": "Enabling Service-to-service Traffic Across Peered Clusters",
|
||||
"path": "connect/gateways/mesh-gateway/service-to-service-traffic-peers"
|
||||
|
|
|
|||
Loading…
Reference in New Issue