k8s docs edits

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

@@ -9,7 +9,7 @@ description: >-
 
 This reference topic describes the technical specifications associated with using cluster peering in your Kubernetes deployments. These specifications include [required Helm values](#helm-requirements) and [required custom resource definitions (CRDs)](#crd-requirements), as well as required Consul components and their configurations.
 
-For cluster peering requirements in other runtimes, refer to [cluster peering technical specifications](/consul/docs/connect/cluster-peering/tech-specs).
+For cluster peering requirements in non-Kubernetes deployments, refer to [cluster peering technical specifications](/consul/docs/connect/cluster-peering/tech-specs).
 
 ## Helm requirements
 
@@ -66,7 +66,7 @@ Refer to the following example CRDs:
 
   </CodeBlockConfig>
 
-   <CodeBlockConfig filename="dialer.yaml">
+  <CodeBlockConfig filename="dialer.yaml">
 
   ```yaml
     apiVersion: consul.hashicorp.com/v1alpha1
@@ -88,14 +88,13 @@ Refer to the following example CRDs:
 
 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.
+- Consul v1.14 or higher
+- Consul on Kubernetes v1.0.0 or higher
+- At least two Kubernetes clusters
 
 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)
 
@@ -164,20 +163,9 @@ Mesh gateways are required for cluster peering connections. Complete the followi
     $  kubectl --context $CLUSTER2_CONTEXT apply -f mesh.yaml 
     ```
 
-## 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/discovery/services).
-
-- 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.
-- 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).
+The `exported-services` CRD is required in order for services to communicate across partitions with cluster peering connections.
 
 Refer to the [`exported-services` configuration entry reference](/consul/docs/connect/config-entries/exported-services) for more information.
 

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

@@ -5,7 +5,7 @@ description: >-
   To establish a cluster peering connection on Kubernetes, generate a peering token to establish communication. Then export services and authorize requests with service intentions. 
 ---
 
-# Establish cluster peering connections
+# Establish cluster peering connections on Kubernetes
 
 This page details the process for establishing a cluster peering connection between services in a Consul on Kubernetes deployment.
 
@@ -26,7 +26,7 @@ You must meet the following requirements to use Consul's cluster peering feature
 - Consul on Kubernetes v1.0.0 or higher
 - At least two Kubernetes clusters
 
-In Consul on Kubernetes, peers identify each other using the `metadata.name` values you establish when creating the `PeeringAcceptor` and `PeeringDialer` CRDs. For additional information about the CRDs used for cluster peering, refer to [Cluster peering on Kubernetes technical specifications](/consul/docs/k8s/connect/cluster-peering/k8s-tech-specs).
+In Consul on Kubernetes, peers identify each other using the `metadata.name` values you establish when creating the `PeeringAcceptor` and `PeeringDialer` CRDs. For additional information about requirements for cluster peering on Kubernetes deployments, refer to [Cluster peering on Kubernetes technical specifications](/consul/docs/k8s/connect/cluster-peering/k8s-tech-specs).
 
 ### Assign cluster IDs to environmental variables
 
@@ -62,14 +62,6 @@ To use cluster peering with Consul on Kubernetes deployments, update the Helm ch
   $ helm install ${HELM_RELEASE_NAME} hashicorp/consul --create-namespace --namespace consul --version "1.0.1" --values values.yaml --set global.datacenter=dc2 --kube-context $CLUSTER2_CONTEXT
   ```
 
-## Mesh gateway requirements
-
-Mesh gateways are required for all cluster peering connections. Consider the following architectural requirements when creating mesh gateways:
-
-- A registered mesh gateway is required in order to export services to peers.
-- For Enterprise, the mesh gateway that exports services must 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.
-
 ### Configure the mesh gateway mode for traffic between services
 
 In Kubernetes deployments, you can configure mesh gateways to use `local` mode so that a service dialing a service in a remote peer dials the remote mesh gateway instead of the local mesh gateway. To configure the mesh gateway mode so that this traffic always leaves through the local mesh gateway, you can use the `ProxyDefaults` CRD.
@@ -143,7 +135,7 @@ Every time you generate a peering token, a single-use secret for establishing th
 
     ```shell-session
     $ kubectl --context $CLUSTER1_CONTEXT apply --filename acceptor.yaml
-    ````
+    ```
 
 1. Save your peering token so that you can export it to the other cluster.
 

website/content/docs/k8s/connect/cluster-peering/usage/k8s-l7-traffic.mdx

@@ -7,23 +7,23 @@ description: >-
 
 # Manage L7 traffic with cluster peering on Kubernetes
 
-This usage topic describes how to configure the [`service-resolver` configuration entry](/docs/connect/config-entries/) to set up and manage L7 traffic between services that have an existing cluster peering connection in Consul on Kubernetes deployments.
+This usage topic describes how to configure the `service-resolver` custom resource definition (CRD) to set up and manage L7 traffic between services that have an existing cluster peering connection in Consul on Kubernetes deployments.
 
 ## Service resolvers for redirects and failover
 
 When you use cluster peering to connect datacenters through their admin partitions, you can use [dynamic traffic management](/consul/docs/connect/l7-traffic) to configure your service mesh so that services automatically forward traffic to services hosted on peer clusters.
 
-However, the `service-splitter` and `service-router` configuration entry kinds do not natively support directly targeting a service instance hosted on a peer. Before you can split or route traffic to a service on a peer, you must define the service hosted on the peer as an upstream service by configuring a failover in the `service-resolver` configuration entry. Then, you can set up a redirect in a second service resolver to interact with the peer service by name.
+However, the `service-splitter` and `service-router` CRDs do not natively support directly targeting a service instance hosted on a peer. Before you can split or route traffic to a service on a peer, you must define the service hosted on the peer as an upstream service by configuring a failover in a `service-resolver` CRD. Then, you can set up a redirect in a second service resolver to interact with the peer service by name.
 
 For more information about formatting, updating, and managing configuration entries in Consul, refer to [How to use configuration entries](/consul/docs/agent/config-entries).
 
 ## Configure dynamic traffic between peers
 
 To configure L7 traffic management behavior in deployments with cluster peering connections, complete the following steps in order:
 
-1. Define the peer cluster as a failover target in the service resolver configuration. Then apply the configuration.
+1. Define the peer cluster as a failover target in the service resolver configuration. 
 
-  The following example updates the [`service-resolver` configuration 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.
+  The following example updates the [`service-resolver` CRD](/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.
 
   <CodeBlockConfig title="failover-resolver.yaml">
 
@@ -44,9 +44,15 @@ To configure L7 traffic management behavior in deployments with cluster peering
 
   </CodeBlockConfig>
 
-1. Define the desired behavior in `service-splitter` or `service-router` configuration entry. Then apply the configuration.
+1. Apply the resource to the local cluster.
 
-  The following example splits traffic evenly between `frontend` and `frontend-peer` services by defining the desired behavior locally:
+    ```shell-session
+    $ kubectl apply --filename failover-resolver.yaml
+    ```
+
+1. Define the desired behavior in `service-splitter` or `service-router` CRD.
+
+  The following example splits traffic evenly between `frontend` and `frontend-peer`:
 
   <CodeBlockConfig title="splitter.yaml">
 
@@ -63,9 +69,15 @@ To configure L7 traffic management behavior in deployments with cluster peering
         service: frontend-peer
   ```
 
-  </CodeBlockCOnfig>
+  </CodeBlockConfig>
+
+1. Apply the resource to the local cluster.
 
-1. Create a second `service-resolver` configuration entry on the local cluster that resolves the name of the peer service you used when splitting or routing the traffic. Then apply the configuration.
+    ```shell-session
+    $ kubectl apply --filename splitter.yaml
+    ```
+
+1. Create a second `service-resolver` configuration entry on the local cluster that resolves the name of the peer service you used when splitting or routing the traffic.
 
   The following example uses the name `frontend-peer` to define a redirect targeting the `frontend` service on the peer `cluster-02`:
 
@@ -82,4 +94,10 @@ To configure L7 traffic management behavior in deployments with cluster peering
       service: 'frontend'
   ```
 
-</CodeBlockConfig>
+</CodeBlockConfig>
+
+1. Apply the resource to the local cluster.
+
+    ```shell-session
+    $ kubectl apply --filename peer-resolver.yaml
+    ```

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

@@ -36,11 +36,7 @@ To reset the cluster peering connection, you need to generate a new peering toke
 
     </CodeBlockConfig>
 
-1. After updating `PeeringAcceptor`, repeat the following steps to establish a new peering connection:
-      1. [Create a peering token](/consul/docs/k8s/connect/cluster-peering/usage/k8s-establish-peering#create-a-peering-token)
-      1. [Establish a peering connection between clusters](/consul/docs/k8s/connect/cluster-peering/usage/k8s-establish-peering#establish-a-peering-connection-between-clusters)
-      1. [Export services between clusters](/consul/docs/k8s/connect/cluster-peering/usage/k8s-establish-peering#export-services-between-clusters)
-      1. [Authorize services for peers](/consul/docs/k8s/connect/cluster-peering/usage/k8s-establish-peering#authorize-services-for-peers)
+1. After updating `PeeringAcceptor`, repeat all of the steps to [establish a new peering connection](/consul/docs/k8s/connect/cluster-peering/usage/k8s-establish-peering).
 
 ## List all peering connections