docs: update tproxy docs (/docs/connect/transparent-proxy) (#10415)

* docs: update tproxy docs

* add examples

* links
This commit is contained in:
Nitya Dhanushkodi 2021-06-22 16:29:52 -07:00 committed by GitHub
parent 32179b9867
commit 7494b25c1e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 44 additions and 15 deletions

View File

@ -1,16 +1,16 @@
---
layout: docs
page_title: Connect - Transparent Proxy
sidebar_title: Transparent Proxy <sup>Beta</sup>
sidebar_title: Transparent Proxy
description: |-
Transparent proxy is used to direct inbound and outbound traffic to services via the Envoy proxy and configure
upstreams via intentions.
---
# Transparent Proxy <sup>Beta</sup>
# Transparent Proxy
Transparent proxy allows users to reach other services in the service mesh while ensuring that inbound and outbound
traffic for services in the mesh are directed through the sidecar proxy. This makes it more likely that traffic is secure
traffic for services in the mesh are directed through the sidecar proxy. Traffic is secured
and only reaches intended destinations since the proxy can enforce security and policy like TLS and Service Intentions.
Previously, service mesh users would need to explicitly define upstreams for a service as a local listener on the sidecar
@ -30,8 +30,7 @@ the traffic redirection command is automatically set up via an init container.
### Kubernetes
* To use transparent proxy on Kubernetes, Consul-helm >= `0.32.0` and Consul-k8s >= `0.26.0` are required in addition to
the Consul >= `1.10.0`.
* To use transparent proxy on Kubernetes, Consul-helm >= `0.32.0` and Consul-k8s >= `0.26.0` are required in addition to Consul >= `1.10.0`.
* If the default policy for ACLs is "deny", then Service Intentions should be set up to allow intended services to connect to each other.
Otherwise, all Connect services can talk to all other services.
@ -41,6 +40,7 @@ enabling traffic redirection.
## Configuration
### Enabling Transparent Proxy
Transparent proxy can be enabled in Kubernetes on the whole cluster via the Helm value:
```yaml
@ -49,8 +49,15 @@ connectInject:
defaultEnabled: true
```
It can also be enabled on a per namespace basis by setting the label `consul.hashicorp.com/transparent-proxy=true` on the
Kubernetes namespace. This will override the Helm value `connectInject.transparentProxy.defaultEnabled` and define the
default behaviour of Pods in the namespace. For example:
```bash
kubectl label namespaces my-app "consul.hashicorp.com/transparent-proxy=true"
```
It can also be enabled on a per service basis via the annotation `consul.hashicorp.com/transparent-proxy=true` on the
Pod for each service:
Pod for each service, which will override both the Helm value and the namespace label:
```yaml
apiVersion: v1
@ -100,12 +107,34 @@ spec:
serviceAccountName: static-server
```
## Known Beta Limitations
### Kubernetes HTTP Health Probes Configuration
Traffic redirection interferes with [Kubernetes HTTP health
probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) since the
probes expect that kubelet can directly reach the application container on the probe's endpoint, but that traffic will
be redirected through the sidecar proxy, causing errors because kubelet itself is not encrypting that traffic using a
mesh proxy. For this reason, Consul allows you to overwrite Kubernetes HTTP health probes to point to the proxy instead,
to pass that traffic through via the proxy using the Helm value `connectInject.transparentProxy.defaultOverwriteProbes`
or the Pod annotation `consul.hashicorp.com/transparent-proxy-overwrite-probes`.
### Traffic Redirection Configuration
Pods with transparent proxy enabled will have an init container injected that sets up traffic redirection for all
inbound and outbound traffic through the sidecar proxies. This will include all traffic by default, with the ability to
configure exceptions on a per-Pod basis. The following Pod annotations allow you to exclude certain traffic from redirection to the sidecar proxies:
- [`consul.hashicorp.com/transparent-proxy-exclude-inbound-ports`](/docs/k8s/connect#consul-hashicorp-com-transparent-proxy-exclude-inbound-ports)
- [`consul.hashicorp.com/transparent-proxy-exclude-outbound-ports`](/docs/k8s/connect#consul-hashicorp-com-transparent-proxy-exclude-outbound-ports)
- [`consul.hashicorp.com/transparent-proxy-exclude-outbound-cidrs`](/docs/k8s/connect#consul-hashicorp-com-transparent-proxy-exclude-outbound-cidrs)
- [`consul.hashicorp.com/transparent-proxy-exclude-uids`](/docs/k8s/connect#consul-hashicorp-com-transparent-proxy-exclude-uids)
## Known Limitations
* There is no first class support for transparent proxying on VMs.
* 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 service-resolver
configuration entries that resolve to remote datacenters.
transparent proxy's datacenter. Cross-datacenter transparent proxying is only possible using
[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
`"consul.hashicorp.com/connect-service-upstreams": "my-service:1234:dc2"` to reach an upstream service called `my-service`
in the datacenter `dc2`.
* 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.

View File

@ -236,7 +236,7 @@
"path": "connect/intentions-legacy"
},
{
"title": "Transparent Proxy <sup>Beta</sup>",
"title": "Transparent Proxy",
"path": "connect/transparent-proxy"
},
{