mirror of https://github.com/status-im/consul.git
Apply suggestions from code review
Co-authored-by: trujillo-adam <47586768+trujillo-adam@users.noreply.github.com>
This commit is contained in:
parent
a4c28d1aea
commit
5062e89651
|
@ -81,9 +81,9 @@ $ curl --request POST \
|
|||
}
|
||||
```
|
||||
|
||||
## Establish a Peering
|
||||
## Establish a Peering Connection
|
||||
|
||||
This endpoint establishes a peering with a given peering token.
|
||||
This endpoint establishes a peering connection with a given peering token.
|
||||
|
||||
| Method | Path | Produces |
|
||||
| ------- | -------------------- | ------------------ |
|
||||
|
@ -154,9 +154,9 @@ $ curl --request POST \
|
|||
{}
|
||||
```
|
||||
|
||||
## Read a Peering
|
||||
## Read a Peering Connection
|
||||
|
||||
This endpoint reads a peering with the given name.
|
||||
This endpoint returns information about a peering connection for the specified peer name.
|
||||
|
||||
| Method | Path | Produces |
|
||||
| ------ | ------------------ | ------------------ |
|
||||
|
@ -205,14 +205,11 @@ $ curl --header "X-Consul-Token: b23b3cad-5ea1-4413-919e-c76884b9ad60" \
|
|||
}
|
||||
```
|
||||
|
||||
## Delete a Peering
|
||||
## Delete a Peering Connection
|
||||
|
||||
This endpoint marks a peering for deletion. Once marked, Consul will
|
||||
delete all the data imported from the peer in the background. Only once
|
||||
all associated data has been deleted will the peering actually disappear.
|
||||
Until then, further reads can be performed on the peering and a `DeletedAt`
|
||||
field will be populated with the timestamp of when the peering was
|
||||
marked for deletion.
|
||||
Call this endpoint to delete a peering connection. Consul deletes all data imported from the peer in the background. The peering connection is removed after all associated data has been deleted.
|
||||
Operators can still read the peering connections while the data is being removed. A `DeletedAt`
|
||||
field will be populated with the timestamp of when the peering was marked for deletion.
|
||||
|
||||
| Method | Path | Produces |
|
||||
| -------- | ------------------ | -------- |
|
||||
|
|
|
@ -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 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
|
||||
|
@ -55,7 +55,7 @@ $ curl --request POST --data @peering_token.json http://127.0.0.1:8500/v1/peerin
|
|||
|
||||
In the peer parameter, specify a name for the first cluster. The `PeeringToken` parameter should include the entire peering token created in the first cluster.
|
||||
|
||||
When you connect server agents through cluster peering, they will peer their default partitions. To establish peerings for other partitions through server agents, you must specify the partitions you want to peer using the `Partition` field of the request body.
|
||||
When you connect server agents through cluster peering, they will peer their default partitions. To establish peering connections for other partitions through server agents, you must specify the partitions you want to peer using the `Partition` field of the request body.
|
||||
|
||||
## Connect service endpoints
|
||||
|
||||
|
@ -117,7 +117,7 @@ Sources = [
|
|||
|
||||
</CodeBlockConfig>
|
||||
|
||||
**Tip:** If the peer’s name is not specified in `Peer`, then Consul assumes that the service is in the local cluster.
|
||||
If the peer’s name is not specified in `Peer`, then Consul assumes that the service is in the local cluster.
|
||||
|
||||
Then, add the configuration entry to your cluster.
|
||||
|
||||
|
@ -138,7 +138,7 @@ A successful query will include service information in the output.
|
|||
|
||||
## Remove peering connections
|
||||
|
||||
After you create a peering connection between clusters in different datacenters, you can “unpeer” the connected clusters. Deleting a peering connection stops data replication to the peer and deletes imported data, including services and CA certificates.
|
||||
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.
|
||||
|
||||
|
|
|
@ -7,7 +7,7 @@ description: >-
|
|||
|
||||
# What is Cluster Peering?
|
||||
|
||||
->**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.
|
||||
~> **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.
|
||||
|
||||
|
@ -22,23 +22,23 @@ For detailed instructions on setting up cluster peering with the Consul CLI, ref
|
|||
|
||||
### Differences between WAN federation and cluster peering
|
||||
|
||||
WAN Federation and cluster peering are different ways to connect clusters. The most important distinction is that WAN Federation assumes clusters are owned by the same operators, so it maintains and replicates global states like ACLs and Configuration Entries. As a result, WAN Federation requires a “primary datacenter" to serve as an authority for replicated data.
|
||||
WAN federation and cluster peering are different ways to connect clusters. The most important distinction is that WAN federation assumes clusters are owned by the same operators, so it maintains and replicates global states such as ACLs and configuration entries. As a result, WAN federation requires a _primary datacenter_ to serve as an authority for replicated data.
|
||||
|
||||
Regardless of whether you connect your clusters through WAN Federation or cluster peering, human and machine users can use either method to discover services in other clusters or dial them through the service mesh.
|
||||
Regardless of whether you connect your clusters through WAN federation or cluster peering, human and machine users can use either method to discover services in other clusters or dial them through the service mesh.
|
||||
|
||||
| | WAN Federation | Cluster Peering |
|
||||
| :----------------------------------------------- | :------------: | :-------------: |
|
||||
| Connects clusters across datacenters | ✅ | ✅ |
|
||||
| Shares support queries and service endpoints | ✅ | ✅ |
|
||||
| Connects clusters owned by different operators | ❌ | ✅ |
|
||||
| Functions without declaring “primary datacenter” | ❌ | ✅ |
|
||||
| Functions without declaring primary datacenter | ❌ | ✅ |
|
||||
| Shares key/value stores | ✅ | ❌ |
|
||||
| Uses gossip protocol | ✅ | ❌ |
|
||||
|
||||
## Technical preview constraints
|
||||
Not all features and functionality are available in the technical preview release. In particular, consider the following technical constraints:
|
||||
|
||||
- Mesh gateways for _service to service traffic_ between clusters are available. However, mesh gateways for _server to server traffic_ are not available.
|
||||
- Mesh gateways for _server to server traffic_ are not available. However, mesh gateways for _service to service traffic_ between clusters are available.
|
||||
- Services exported to peered clusters must not be configured as HTTP.
|
||||
- Support for dynamic routing such as splits, custom routes, or redirects is not available.
|
||||
- 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).
|
||||
|
|
Loading…
Reference in New Issue