c0780ef3e9
* converted main services page to services overview page * set up services usage dirs * added Define Services usage page * converted health checks everything page to Define Health Checks usage page * added Register Services and Nodes usage page * converted Query with DNS to Discover Services and Nodes Overview page * added Configure DNS Behavior usage page * added Enable Static DNS Lookups usage page * added the Enable Dynamic Queries DNS Queries usage page * added the Configuration dir and overview page - may not need the overview, tho * fixed the nav from previous commit * added the Services Configuration Reference page * added Health Checks Configuration Reference page * updated service defaults configuraiton entry to new configuration ref format * fixed some bad links found by checker * more bad links found by checker * another bad link found by checker * converted main services page to services overview page * set up services usage dirs * added Define Services usage page * converted health checks everything page to Define Health Checks usage page * added Register Services and Nodes usage page * converted Query with DNS to Discover Services and Nodes Overview page * added Configure DNS Behavior usage page * added Enable Static DNS Lookups usage page * added the Enable Dynamic Queries DNS Queries usage page * added the Configuration dir and overview page - may not need the overview, tho * fixed the nav from previous commit * added the Services Configuration Reference page * added Health Checks Configuration Reference page * updated service defaults configuraiton entry to new configuration ref format * fixed some bad links found by checker * more bad links found by checker * another bad link found by checker * fixed cross-links between new topics * updated links to the new services pages * fixed bad links in scale file * tweaks to titles and phrasing * fixed typo in checks.mdx * started updating the conf ref to latest template * update SD conf ref to match latest CT standard * Apply suggestions from code review Co-authored-by: Eddie Rowe <74205376+eddie-rowe@users.noreply.github.com> * remove previous version of the checks page * fixed cross-links * Apply suggestions from code review Co-authored-by: Eddie Rowe <74205376+eddie-rowe@users.noreply.github.com> --------- Co-authored-by: Eddie Rowe <74205376+eddie-rowe@users.noreply.github.com>
69 lines
4.4 KiB
Plaintext
69 lines
4.4 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: Cluster Peering Technical Specifications
|
|
description: >-
|
|
Cluster peering connections in Consul interact with mesh gateways, sidecar proxies, exported services, and ACLs. Learn about the configuration requirements for these components.
|
|
---
|
|
|
|
# Cluster peering technical specifications
|
|
|
|
This reference topic describes the technical specifications associated with using cluster peering in your deployments. These specifications include required Consul components and their configurations.
|
|
|
|
## Requirements
|
|
|
|
To use cluster peering features, make sure your Consul environment meets the following prerequisites:
|
|
|
|
- Consul v1.14 or higher.
|
|
- A local Consul agent is required to manage mesh gateway configuration.
|
|
- Use [Envoy proxies](/consul/docs/connect/proxies/envoy). Envoy is the only proxy with mesh gateway capabilities in Consul.
|
|
|
|
In addition, the following service mesh components are required in order to establish cluster peering connections:
|
|
|
|
- [Mesh gateways](#mesh-gateway-requirements)
|
|
- [Sidecar proxies](#sidecar-proxy-requirements)
|
|
- [Exported services](#exported-service-requirements)
|
|
- [ACLs](#acl-requirements)
|
|
|
|
### Mesh gateway requirements
|
|
|
|
Mesh gateways are required for routing service mesh traffic between partitions with cluster peering connections. Consider the following general requirements for mesh gateways when using cluster peering:
|
|
|
|
- A cluster requires a registered mesh gateway in order to export services to peers.
|
|
- For Enterprise, this mesh gateway must also be registered in the same partition as the exported services and their `exported-services` configuration entry.
|
|
- To use the `local` mesh gateway mode, you must register a mesh gateway in the importing cluster.
|
|
|
|
In addition, you must define the `Proxy.Config` settings using opaque parameters compatible with your proxy. Refer to the [Gateway options](/consul/docs/connect/proxies/envoy#gateway-options) and [Escape-hatch Overrides](/consul/docs/connect/proxies/envoy#escape-hatch-overrides) documentation for additional Envoy proxy configuration information.
|
|
|
|
#### Mesh gateway modes
|
|
|
|
By default, all cluster peering connections use mesh gateways in [remote mode](/consul/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters#remote). Be aware of these additional requirements when changing a mesh gateway's mode.
|
|
|
|
- For mesh gateways that connect peered clusters, you can set the `mode` as either `remote` or `local`.
|
|
- The `none` mode is invalid for mesh gateways with cluster peering connections.
|
|
|
|
Refer to [mesh gateway modes](/consul/docs/connect/gateways/mesh-gateway#modes) for more information.
|
|
|
|
## Sidecar proxy requirements
|
|
|
|
The Envoy proxies that function as sidecars in your service mesh require configuration in order to properly route traffic to peers. Sidecar proxies are defined in the [service definition](/consul/docs/services/usage/defin-services).
|
|
|
|
- Configure the `proxy.upstreams` parameters to route traffic to the correct service, namespace, and peer. Refer to the [`upstreams`](/consul/docs/connect/registration/service-registration#upstream-configuration-reference) documentation for details.
|
|
- The `proxy.upstreams.destination_name` parameter is always required.
|
|
- The `proxy.upstreams.destination_peer` parameter must be configured to enable cross-cluster traffic.
|
|
- The `proxy.upstream/destination_namespace` configuration is only necessary if the destination service is in a non-default namespace.
|
|
|
|
## Exported service requirements
|
|
|
|
The `exported-services` configuration entry is required in order for services to communicate across partitions with cluster peering connections.
|
|
|
|
Basic guidance on using the `exported-services` configuration entry is included in [Establish cluster peering connections](/consul/docs/connect/cluster-peering/usage/create-cluster-peering).
|
|
|
|
Refer to the [`exported-services` configuration entry](/consul/docs/connect/config-entries/exported-services) reference for more information.
|
|
|
|
## ACL requirements
|
|
|
|
If ACLs are enabled, you must add tokens to grant the following permissions:
|
|
|
|
- Grant `service:write` permissions to services that define mesh gateways in their server definition.
|
|
- Grant `service:read` permissions for all services on the partition.
|
|
- Grant `mesh:write` permissions to the mesh gateways that participate in cluster peering connections. This permission allows a leaf certificate to be issued for mesh gateways to terminate TLS sessions for HTTP requests. |