Backport of Docs/cluster peering 1.15 updates into release/1.15.x (#1…

…6398) * backport of commit e878d2d * Docs/cluster peering 1.15 updates (#16291) * initial commit * initial commit * Overview updates * Overview page improvements * More Overview improvements * improvements * Small fixes/updates * Updates * Overview updates * Nav data * More nav updates * Fix * updates * Updates + tip test * Directory test * refining * Create restructure w/ k8s * Single usage page * Technical Specification * k8s pages * typo * L7 traffic management * Manage connections * k8s page fix * Create page tab corrections * link to k8s * intentions * corrections * Add-on intention descriptions * adjustments * Missing </CodeTabs> * Diagram improvements * Final diagram update * Apply suggestions from code review Co-authored-by: trujillo-adam <[email protected]> Co-authored-by: Tu Nguyen <[email protected]> Co-authored-by: David Yu <[email protected]> * diagram name fix * Fixes * Updates to index.mdx * Tech specs page corrections * Tech specs page rename * update link to tech specs * K8s - new pages + tech specs * k8s - manage peering connections * k8s L7 traffic management * Separated establish connection pages * Directory fixes * Usage clean up * k8s docs edits * Updated nav data * CodeBlock Component fix * filename * CodeBlockConfig removal * Redirects * Update k8s filenames * Reshuffle k8s tech specs for clarity, fmt yaml files * Update general cluster peering docs, reorder CLI > API > UI, cross link to kubernetes * Fix config rendering in k8s usage docs, cross link to general usage from k8s docs * fix legacy link * update k8s docs * fix nested list rendering * redirect fix * page error --------- Co-authored-by: trujillo-adam <[email protected]> Co-authored-by: Tu Nguyen <[email protected]> Co-authored-by: David Yu <[email protected]> Co-authored-by: Tu Nguyen <[email protected]> --------- Co-authored-by: boruszak <[email protected]> Co-authored-by: Jeff Boruszak <[email protected]> Co-authored-by: trujillo-adam <[email protected]> Co-authored-by: Tu Nguyen <[email protected]> Co-authored-by: David Yu <[email protected]> Co-authored-by: Tu Nguyen <[email protected]>
hashicorp · Feb 23, 2023 · 42913d6 · 42913d6
1 parent 983a1b8
commit 42913d6
Show file tree

Hide file tree

Showing 17 changed files with 1,654 additions and 1,176 deletions.
diff --git a/website/content/api-docs/operator/usage.mdx b/website/content/api-docs/operator/usage.mdx
@@ -48,6 +48,7 @@ $ curl \
 ### Sample Response
 
 <Tabs>
+
 <Tab heading="OSS">
 ```json
 {
@@ -75,6 +76,7 @@ $ curl \
 }
 ```
 </Tab>
+
 <Tab heading="Enterprise">
 ```json
 {

diff --git a/...eway/service-to-service-traffic-peers.mdx → ...connect/cluster-peering/configuration.mdx b/...eway/service-to-service-traffic-peers.mdx → ...connect/cluster-peering/configuration.mdx
@@ -1,27 +1,21 @@
 ---
 layout: docs
-page_title: Enabling Service-to-service Traffic Across Peered Clusters
+page_title: Cluster Peering Configuration
 description: >-
-  Mesh gateways are specialized proxies that route data between services that cannot communicate directly. Learn how to enable service-to-service traffic across clusters in different datacenters or admin partitions that have an established peering connection.
+  
 ---
 
 # Enabling Service-to-service Traffic Across Peered Clusters
 
-Mesh gateways are required for you to route service mesh traffic between peered Consul clusters. Clusters can reside in different clouds or runtime environments where general interconnectivity between all services in all clusters is not feasible.
-
-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.
+The topic provides an overview of the configuration options and process for cluster peering.
 
 ## Prerequisites
 
 To configure mesh gateways for cluster peering, make sure your Consul environment meets the following requirements:
 
 - Consul version 1.14.0 or newer.
 - 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.
+- Use [Envoy proxies](/docs/connect/proxies/envoy). Envoy is the only proxy with mesh gateway capabilities in Consul.
 
 ## Configuration
 
@@ -30,31 +24,33 @@ Configure the following settings to register and use the mesh gateway as a servi
 ### Gateway registration
 
 - 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](/consul/docs/connect/proxies/envoy#gateway-options) and [Escape-hatch Overrides](/consul/docs/connect/proxies/envoy#escape-hatch-overrides) documentation for additional configuration information.
+- 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.
 
-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](/consul/commands/connect/envoy#mesh-gateways).
+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).
 
 ### Sidecar registration
 
-- Configure the `proxy.upstreams` parameters to route traffic to the correct service, namespace, and peer. Refer to the [`upstreams` documentation](/consul/docs/connect/registration/service-registration#upstream-configuration-reference) for details.
+- Configure the `proxy.upstreams` parameters to route traffic to the correct service, namespace, and peer. 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_peer` 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.
 
 ### Service exports
 
-- Include the `exported-services` configuration entry to enable Consul to export services contained in a cluster to one or more additional clusters. For additional information, refer to the [Exported Services documentation](/consul/docs/connect/config-entries/exported-services).
+- Include the `exported-services` configuration entry to enable Consul to export services contained in a cluster to one or more additional clusters. For additional information, refer to the [Exported Services documentation](/docs/connect/config-entries/exported-services).
 
 ### 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 Enterprise admin partition or OSS datacenter to the gateway's service definition. 
+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 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.
 
 You must also grant `mesh:write` to mesh gateways routing peering traffic in the data plane.
+
 This permission allows a leaf certificate to be issued for mesh gateways to terminate TLS sessions for HTTP requests.
 
 ### Modes
 
 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](/consul/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters#remote).
+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).
-Original file line number
+Diff line change
@@ Expand Up / @@ -48,6 +48,7 @@ $ curl \ @@
     ### Sample Response
     <Tabs>
     <Tab heading="OSS">
     ```json
     {
@@ Expand Down Expand Up / @@ -75,6 +76,7 @@ $ curl \ @@
     }
     ```
     </Tab>
     <Tab heading="Enterprise">
     ```json
     {
@@ Expand Down @@