diff --git a/website/content/docs/connect/cluster-peering/create-manage-peering.mdx b/website/content/docs/connect/cluster-peering/create-manage-peering.mdx index 263fe81247..7fde8293b6 100644 --- a/website/content/docs/connect/cluster-peering/create-manage-peering.mdx +++ b/website/content/docs/connect/cluster-peering/create-manage-peering.mdx @@ -47,7 +47,7 @@ Create a JSON file that contains the first cluster's name and the peering token. ## Establish a connection between clusters -Next, use the peering token to establish a secure connection between the clusters. In the client agents of “cluster-02,” establish the peering connection using the HTTP API. This endpoint does not generate an output unless there is an error. +Next, use the peering token to establish a secure connection between the clusters. In the client agents of "cluster-02," establish the peering connection using the HTTP API. This endpoint does not generate an output unless there is an error. ```shell-session $ curl --request POST --data @peering_token.json http://127.0.0.1:8500/v1/peering/establish @@ -61,9 +61,9 @@ When you connect server agents through cluster peering, they will peer their def After you establish a connection between the clusters, you need to create a configuration entry that defines the services that are available for other clusters. Consul uses this configuration entry to advertise service information and support service mesh connections across clusters. -First, create a configuration entry and specify the `Kind` as `“exported-services”`. +First, create a configuration entry and specify the `Kind` as `"exported-services"`. - + ```hcl Kind = "exported-services" @@ -98,9 +98,9 @@ Before you proceed, wait for the clusters to sync and make services available to Before you can call services from peered clusters, you must set service intentions that authorize those clusters to use specific services. Consul prevents services from being exported to unauthorized clusters. -First, create a configuration entry and specify the `Kind` as `“service-intentions”`. Declare the service on "cluster-02" that can access the service in "cluster-01." The following example sets service intentions so that "frontend-service" can access "backend-service." +First, create a configuration entry and specify the `Kind` as `"service-intentions"`. Declare the service on "cluster-02" that can access the service in "cluster-01." The following example sets service intentions so that "frontend-service" can access "backend-service." - + ```hcl Kind = "service-intentions" @@ -140,7 +140,7 @@ A successful query will include service information in the output. After you create a peering connection between clusters in different datacenters, you can disconnect the peered clusters. Deleting a peering connection stops data replication to the peer and deletes imported data, including services and CA certificates. -In “cluster-01,” request the deletion via the HTTP API. +In "cluster-01," request the deletion via the HTTP API. ```shell-session $ curl --request DELETE http://127.0.0.1:8500/v1/peering/cluster-02 diff --git a/website/content/docs/connect/cluster-peering/index.mdx b/website/content/docs/connect/cluster-peering/index.mdx index 1d23666325..4601e19470 100644 --- a/website/content/docs/connect/cluster-peering/index.mdx +++ b/website/content/docs/connect/cluster-peering/index.mdx @@ -9,7 +9,7 @@ description: >- ~> **Cluster peering is currently in technical preview**: Functionality associated with cluster peering is subject to change. You should never use the technical preview release in secure environments or production scenarios. Features in technical preview may have performance issues, scaling issues, and limited support. -You can create peering connections between two or more independent clusters so that services deployed to different partitions or datacenters can to communicate. +You can create peering connections between two or more independent clusters so that services deployed to different partitions or datacenters can communicate. ## Overview diff --git a/website/content/docs/connect/cluster-peering/k8s.mdx b/website/content/docs/connect/cluster-peering/k8s.mdx index 770cd365fe..e120a7216f 100644 --- a/website/content/docs/connect/cluster-peering/k8s.mdx +++ b/website/content/docs/connect/cluster-peering/k8s.mdx @@ -98,7 +98,7 @@ To peer Kubernetes clusters running Consul, you need to create a peering token a $ kubectl apply --filename peering-token.yml ``` -1. In “cluster-02,” create the `PeeringDialer` custom resource. +1. In "cluster-02," create the `PeeringDialer` custom resource. @@ -125,7 +125,7 @@ To peer Kubernetes clusters running Consul, you need to create a peering token a ## Deploy and export cluster services -1. For the service in “cluster-02” that you want to export, add the following [annotations](/docs/k8s/annotations-and-labels#consul-hashicorp-com-connect-service-upstreams) to your service's pods. This service is referred to as "backend-service" in the following steps. +1. For the service in "cluster-02" that you want to export, add the following [annotations](/docs/k8s/annotations-and-labels#consul-hashicorp-com-connect-service-upstreams) to your service's pods. This service is referred to as "backend-service" in the following steps. @@ -139,7 +139,7 @@ To peer Kubernetes clusters running Consul, you need to create a peering token a -1. In “cluster-02,” create an `ExportedServices` custom resource. +1. In "cluster-02," create an `ExportedServices` custom resource. @@ -184,13 +184,13 @@ To peer Kubernetes clusters running Consul, you need to create a peering token a $ kubectl apply --filename backend-service.yml --filename exportedsvc.yml --filename intention.yml ``` -1. To confirm that you peered your clusters, in “cluster-01,” query the `/health` HTTP endpoint. +1. To confirm that you peered your clusters, in "cluster-01," query the `/health` HTTP endpoint. ```shell-session $ curl "localhost:8500/v1/health/connect/backend?peer=cluster-02" ``` -1. For the services in “cluster-01” that you want to access the “backend-service,” add the following annotations to the service file. +1. For the services in "cluster-01" that you want to access the "backend-service," add the following annotations to the service file. @@ -216,10 +216,10 @@ To peer Kubernetes clusters running Consul, you need to create a peering token a ```shell-session $ curl localhost:1234 { - “name”: “backend-service”, + "name": "backend-service", ##… - “body”: “Response from backend”, - “code”: 200 + "body": "Response from backend", + "code": 200 } ``` @@ -227,7 +227,7 @@ To peer Kubernetes clusters running Consul, you need to create a peering token a To end a peering connection, delete both the `PeeringAcceptor` and `PeeringDialer` resources. -To confirm that you deleted your peering connection, in “cluster-01,” query the `/health` HTTP endpoint. The peered services should no longer appear. +To confirm that you deleted your peering connection, in "cluster-01," query the `/health` HTTP endpoint. The peered services should no longer appear. ```shell-session $ curl "localhost:8500/v1/health/connect/backend?peer=cluster-02"