Skip to content

Commit

Permalink
fix link
Browse files Browse the repository at this point in the history
  • Loading branch information
Ferdudas97 committed Mar 21, 2022
1 parent f2d561f commit b0e0a4e
Show file tree
Hide file tree
Showing 3 changed files with 4 additions and 4 deletions.
4 changes: 2 additions & 2 deletions docs/ec_vs_other_software.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ this job, because of the JRE runtime. This means higher memory footprint and lat
Linkerd v2 was rewritten in Rust to get better performance. Unfortunately, just like Istio - it's Kubernetes only.

### Consul Connect
[Consul Connect](https://www.consul.io/docs/connect/index.html) is a simple way to deploy Envoy to current
[Consul Connect](https://www.consul.io/docs/connect) is a simple way to deploy Envoy to current
Consul based infrastructure.
The problem with Consul Connect is that versions prior to 1.6.0 had very limited traffic control capabilities.
We want to have a fallback to instances from other DCs, canary deployment and other features specific to our
Expand All @@ -35,4 +35,4 @@ Control Plane implementation on. They're not a sufficient Control Plane by thems
Discovery Service.

Envoy Control is based on Java Control Plane and integrates with Consul by default. It also adds features like
Cross DC Synchronization or Permission management.
Cross DC Synchronization or Permission management.
2 changes: 1 addition & 1 deletion docs/features/multi_dc_support.md
Original file line number Diff line number Diff line change
Expand Up @@ -47,7 +47,7 @@ The state is available in `LocalClusterStateChanges#latestServiceState`.

Then build a `RemoteServices` class providing:

* [AsyncControlPlaneClient](https://github.com/allegro/envoy-control/blob/master/envoy-control-runner/src/main/kotlin/pl/allegro/tech/servicemesh/envoycontrol/synchronization/AsyncRestTemplateControlPlaneClient.kt) - an HTTP client
* [AsyncControlPlaneClient](https://github.com/allegro/envoy-control/blob/master/envoy-control-runner/src/main/kotlin/pl/allegro/tech/servicemesh/envoycontrol/synchronization/RestTemplateControlPlaneClient.kt) - an HTTP client
* [ControlPlaneInstanceFetcher](https://github.com/allegro/envoy-control/blob/master/envoy-control-source-consul/src/main/kotlin/pl/allegro/tech/servicemesh/envoycontrol/consul/synchronization/SimpleConsulInstanceFetcher.kt) - the strategy of retrieving other Envoy Control from given cluster
* `remoteClusters` - list of remote clusters

Expand Down
2 changes: 1 addition & 1 deletion docs/integrations/consul.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ first-class integration with Consul.

Popular Service Mesh solutions provide integration with Consul by polling periodically the state of all services.
Assuming we polled the state each second in order to minimize change propagation latency, we would have to send a request
for a [list of services](https://www.consul.io/api/catalog.html#list-services) and then a
for a [list of services](https://www.consul.io/api/catalog#list-services) and then a
[request per each service](https://www.consul.io/api/catalog.html#list-nodes-for-service).
With 1,000 services, this would generate 1,000 rps per one instance of Control Plane.

Expand Down

0 comments on commit b0e0a4e

Please sign in to comment.