Apply suggestions from code review

Co-authored-by: trujillo-adam <47586768+trujillo-adam@users.noreply.github.com>

website/content/docs/connect/cluster-peering/create-manage-peering.mdx

@@ -73,10 +73,10 @@ Save this value to a file or clipboard to be used in the next step on `cluster-0
 <Tab heading="Consul UI" group="ui">
 
 1. In the Consul UI for the datacenter associated with `cluster-01`, click **Peers**.
-2. Click **Add peer connection**.
-3. In the **Generate token** tab, enter `cluster-02` in the **Name of peer** field.
-4. Click the **Generate token** button.
-5. Copy the token before you proceed. Be careful not to lose the token, as you cannot view the token again after leaving this screen. If you lose your token, you must generate a new one.
+1. Click **Add peer connection**.
+1. In the **Generate token** tab, enter `cluster-02` in the **Name of peer** field.
+1. Click the **Generate token** button.
+1. Copy the token before you proceed. You cannot view it again after leaving this screen. If you lose your token, you must generate a new one.
 
 </Tab>
 </Tabs>
@@ -376,7 +376,7 @@ Next to the name of the peer, click **More** (three horizontal dots) and then **
 </Tabs>
 
 ## L7 traffic management between peers
-
+The following sections describe how to enable L7 traffic management features between peered clusters.
 ### Service resolvers for redirects and failover
 
 As of Consul v1.14, you can use [dynamic traffic management](/consul/docs/connect/l7-traffic) to configure your service mesh so that services automatically failover and redirect between peers. The following examples update the [`service-resolver` config entry](/docs/connect/config-entries/) in `cluster-01` so that Consul redirects traffic intended for the `frontend` service to a backup instance in peer `cluster-02` when it detects multiple connection failures.
@@ -434,7 +434,7 @@ spec:
 
 ### Service splitters and custom routes
 
-The `service-splitter` and `service-router` config entry kinds do not support directly targeting a service instance hosted on a peer. To split or route traffic to a service on a peer, you must combine the definition with a `service-resolver` config entry that defines the service hosted on the peer as an upstream service. For example, to split traffic evenly between `frontend` services hosted on peers, first define the desired behavior locally:
+The `service-splitter` and `service-router` configuration entry kinds do not support directly targeting a service instance hosted on a peer. To split or route traffic to a service on a peer, you must combine the definition with a `service-resolver` configuration entry that defines the service hosted on the peer as an upstream service. For example, to split traffic evenly between `frontend` services hosted on peers, first define the desired behavior locally:
 
 <CodeTabs tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
 
@@ -444,7 +444,7 @@ Name = "frontend"
 Splits = [
   {
     Weight  = 50
-    ## defaults to service with same name as config entry ("frontend")
+    ## defaults to service with same name as configuration entry ("frontend")
   },
   {
     Weight  = 50
@@ -461,7 +461,7 @@ metadata:
 spec:
   splits:
     - weight: 50
-      ## defaults to service with same name as config entry ("web")
+      ## defaults to service with same name as configuration entry ("web")
     - weight: 50
       service: frontend-peer
 ```
@@ -484,7 +484,7 @@ spec:
 
 </CodeTabs>
 
-Then, create a local `service-resolver` config entry named `frontend-peer` and define a redirect targeting the peer and its service:
+Then, create a local `service-resolver` configuration entry named `frontend-peer` and define a redirect targeting the peer and its service:
 
 <CodeTabs tabs={[ "HCL", "Kubernetes YAML", "JSON" ]}>
 

website/content/docs/connect/cluster-peering/index.mdx

@@ -16,9 +16,9 @@ You can create peering connections between two or more independent clusters so t
 Cluster peering is a process that allows Consul clusters to communicate with each other. The cluster peering process consists of the following steps:
 
 1. Create a peering token in one cluster.
-2. Use the peering token to establish peering with a second cluster.
-3. Export services between clusters.
-4. Create intentions to authorize services for peers.
+1. Use the peering token to establish peering with a second cluster.
+1. Export services between clusters.
+1. Create intentions to authorize services for peers.
 
 For detailed instructions on establishing cluster peering connections, refer to [Create and Manage Peering Connections](/docs/connect/cluster-peering/create-manage-peering).
 
@@ -56,7 +56,7 @@ Not all features and functionality are available in the beta release. In particu
 
 - Mesh gateways for _server to server traffic_ are not available.
 - Services with node, instance, and check definitions totaling more than 4MB cannot be exported to a peer.
-- The `service-splitter` and `service-router` config entry kinds cannot directly target a peer. To split or route traffic to a service instance on a peer, you must supplement your desired dynamic routing definition with a `service-resolver` config entry on the dialing cluster. Refer to [L7 traffic management between peers](/docs/connect/cluster-peering/create-manage-peering#L7-traffic) for more information.
+- The `service-splitter` and `service-router` configuration entry kinds cannot directly target a peer. To split or route traffic to a service instance on a peer, you must supplement your desired dynamic routing definition with a `service-resolver` config entry on the dialing cluster. Refer to [L7 traffic management between peers](/docs/connect/cluster-peering/create-manage-peering#L7-traffic) for more information.
 - The `consul intention` CLI command is not supported. To manage intentions that specify services in peered clusters, use [configuration entries](/docs/connect/config-entries/service-intentions).
 - Accessing key/value stores across peers is not supported.
 - Because non-Enterprise Consul instances are restricted to the `default` namespace, Consul Enterprise instances cannot export services from outside of the `default` namespace to non-Enterprise peers.

website/content/docs/connect/cluster-peering/k8s.mdx

@@ -32,7 +32,9 @@ You must implement the following requirements to create and use cluster peering
 
 ### Prepare for installation
 
-1. After you provision a Kubernetes cluster and set up your kubeconfig file to manage access to multiple Kubernetes clusters, use the `kubectl` command to export the Kubernetes context names and then set them to variables for future use. For more information on how to use kubeconfig and contexts, refer to the [Kubernetes docs on configuring access to multiple clusters](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
+Complete the following procedure after you have provisioned a Kubernetes cluster and set up your kubeconfig file to manage access to multiple Kubernetes clusters. 
+
+1. Use the `kubectl` command to export the Kubernetes context names and then set them to variables for future use. For more information on how to use kubeconfig and contexts, refer to the [Kubernetes docs on configuring access to multiple clusters](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
 
     You can use the following methods to get the context names for your clusters:
   
@@ -101,9 +103,11 @@ Install Consul on Kubernetes by using the CLI to apply `values.yaml` to each clu
 
 ## Create a peering connection for Consul on Kubernetes
 
+To peer Kubernetes clusters running Consul, you need to create a peering token and share it with the other cluster. Complete the following steps to create the peer connection.
+
 ### Create a peering token
 
-To peer Kubernetes clusters running Consul, you need to create a peering token and share it with the other cluster. Peers identify each other using the `metadata.name` values you establish when creating the `PeeringAcceptor` and `PeeringDialer` CRDs.
+Peers identify each other using the `metadata.name` values you establish when creating the `PeeringAcceptor` and `PeeringDialer` CRDs.
 
 1. In `cluster-01`, create the `PeeringAcceptor` custom resource.
 
@@ -171,7 +175,7 @@ To peer Kubernetes clusters running Consul, you need to create a peering token a
 
 ### Export services between clusters
 
-~> **Tip**: The examples in this section demonstrate how to export a service named `backend`. You should change instances of `backend` in the example code to the name of the service you want to export.
+The examples described in this section demonstrate how to export a service named `backend`. You should change instances of `backend` in the example code to the name of the service you want to export.
 
 1. For the service in `cluster-02` that you want to export, add the following [annotations](/docs/k8s/annotations-and-labels) to your service's pods. 
 
@@ -433,7 +437,13 @@ To recreate or reset the peering connection, you need to generate a new peering
 
     </CodeBlockConfig>
 
-2. After you update `PeeringAcceptor`, repeat the steps to create a peering connection, including saving a new peering token and exporting it to the other cluster. Your peering connection is re-established with the updated token.
+2. After updating `PeeringAcceptor`, repeat the following steps to create a peering connection:
+      1.  [Create a peering token](#create-a-peering-token)
+      1.  [Establish a peering connection between clusters](#establish-a-peering-connection-between-clusters)
+      1. [Export services between clusters](#export-services-between-clusters)
+      1. [Authorize services for peers](#authorize-services-for-peers)
+      
+      Your peering connection is re-established with the updated token.
 
 ~> **Note:** The only way to create or set a new peering token is to manually adjust the value of the annotation `consul.hashicorp.com/peering-version`. Creating a new token causes the previous token to expire.