From b0e0a4e7e7fc05768d8d82a4a3b3651bf3f88551 Mon Sep 17 00:00:00 2001 From: "radoslaw.chrzanowski" Date: Mon, 21 Mar 2022 08:02:42 +0100 Subject: [PATCH] fix link --- docs/ec_vs_other_software.md | 4 ++-- docs/features/multi_dc_support.md | 2 +- docs/integrations/consul.md | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/ec_vs_other_software.md b/docs/ec_vs_other_software.md index cd05186cc..f33608ee8 100644 --- a/docs/ec_vs_other_software.md +++ b/docs/ec_vs_other_software.md @@ -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 @@ -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. \ No newline at end of file +Cross DC Synchronization or Permission management. diff --git a/docs/features/multi_dc_support.md b/docs/features/multi_dc_support.md index 54f5439ca..2d9e05e43 100644 --- a/docs/features/multi_dc_support.md +++ b/docs/features/multi_dc_support.md @@ -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 diff --git a/docs/integrations/consul.md b/docs/integrations/consul.md index bb648fbf0..4352293fe 100644 --- a/docs/integrations/consul.md +++ b/docs/integrations/consul.md @@ -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.