status-im
/
consul
mirror of https://github.com/status-im/consul.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

doc: remove sentence that tproxy works cross-DC with config entries. (#10885) 

It can only work if there is a running service instance in the local DC,
so this is a bit misleading, since failover and redirects are typically
used when there is not an instance in the local DC.
This commit is contained in:
Nitya Dhanushkodi 2021-08-23 12:14:28 -07:00 committed by GitHub
parent 997547bd7f
commit 329ec62582
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 2 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
website/content/docs/connect/transparent-proxy.mdx
View File

@ -132,14 +132,12 @@ configure exceptions on a per-Pod basis. The following Pod annotations allow you
## Known Limitations ## Known Limitations
* Traffic can only be transparently proxied when the address dialed corresponds to the address of a service in the * Traffic can only be transparently proxied when the address dialed corresponds to the address of a service in the
transparent proxy's datacenter. Cross-datacenter transparent proxying is only possible using transparent proxy's datacenter. Services can also dial explicit upstreams in other datacenters without transparent proxy, for example, by adding an
[service-resolver configuration entries that resolve to remote datacenters](/docs/connect/config-entries/service-resolver#other-datacenters).
Services can also dial explicit upstreams in other datacenters without transparent proxy, for example, by adding an
[annotation](/docs/k8s/connect#consul-hashicorp-com-connect-service-upstreams) such as [annotation](/docs/k8s/connect#consul-hashicorp-com-connect-service-upstreams) such as
`"consul.hashicorp.com/connect-service-upstreams": "my-service:1234:dc2"` to reach an upstream service called `my-service` `"consul.hashicorp.com/connect-service-upstreams": "my-service:1234:dc2"` to reach an upstream service called `my-service`
in the datacenter `dc2`. in the datacenter `dc2`.
* In the deployment configuration where a [single Consul datacenter spans multiple Kubernetes clusters](https://www.consul.io/docs/k8s/installation/deployment-configurations/single-dc-multi-k8s), services in one Kubernetes cluster must explicitly dial a service in another Kubernetes cluster using the [consul.hashicorp.com/connect-service-upstreams](/docs/k8s/connect#consul-hashicorp-com-connect-service-upstreams) annotation. An example would be * In the deployment configuration where a [single Consul datacenter spans multiple Kubernetes clusters](https://www.consul.io/docs/k8s/installation/deployment-configurations/single-dc-multi-k8s), services in one Kubernetes cluster must explicitly dial a service in another Kubernetes cluster using the [consul.hashicorp.com/connect-service-upstreams](/docs/k8s/connect#consul-hashicorp-com-connect-service-upstreams) annotation. An example would be
`"consul.hashicorp.com/connect-service-upstreams": "my-service:1234"`, where `my-service` is the service that exists in another Kubernetes cluster and is exposed on port `1234`. Although Transparent Proxy is enabled, KubeDNS is not utilized when communicating between services existing on separate Kubernetes clusters. `"consul.hashicorp.com/connect-service-upstreams": "my-service:1234"`, where `my-service` is the service that exists in another Kubernetes cluster and is exposed on port `1234`. Although Transparent Proxy is enabled, KubeDNS is not utilized when communicating between services existing on separate Kubernetes clusters.
* When dialing headless services the request will be proxied using a plain TCP proxy with a 5s connection timeout. * When dialing headless services the request will be proxied using a plain TCP proxy with a 5s connection timeout.
Currently the upstream's protocol and connection timeout are not considered. Currently the upstream's protocol and connection timeout are not considered.