docs(tproxy): restructure and expand transparent proxy documentation #2064
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Transparent proxy docs are now consolidated under Using Kuma / Service Discovery & Networking / Transparent Proxy. The former "Kuma in Production" content is now "Introduction" in this group, and "Using Kuma / Transparent Proxying" is now "Technical Overview". Reachable Services, Reachable Backends, installation, and configuration are split into separate pages. Added a Transparent Proxy Configuration Reference. Signed-off-by: Bart Smykla <bartek@smykla.com>
Signed-off-by: Bart Smykla <bartek@smykla.com>
Signed-off-by: Bart Smykla <bartek@smykla.com>
Signed-off-by: Bart Smykla <bartek@smykla.com>
Signed-off-by: Bart Smykla <bartek@smykla.com>
✅ Deploy Preview for kuma ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Signed-off-by: Bart Smykla <bartek@smykla.com>
Signed-off-by: Bart Smykla <bartek@smykla.com>
Automaat
reviewed
Nov 5, 2024
Automaat
reviewed
Nov 5, 2024
Automaat
reviewed
Nov 5, 2024
Signed-off-by: Bart Smykla <bartek@smykla.com>
Automaat
reviewed
Nov 5, 2024
Automaat
reviewed
Nov 5, 2024
Automaat
reviewed
Nov 5, 2024
Signed-off-by: Bart Smykla <bartek@smykla.com>
Signed-off-by: Bart Smykla <bartek@smykla.com>
Signed-off-by: Bart Smykla <bartek@smykla.com>
Signed-off-by: Bart Smykla <bartek@smykla.com>
Automaat
reviewed
Nov 5, 2024
app/_src/networking/transparent-proxy/configuration-on-kubernetes.md
Outdated
Show resolved
Hide resolved
Automaat
reviewed
Nov 5, 2024
app/_src/networking/transparent-proxy/configuration-on-kubernetes.md
Outdated
Show resolved
Hide resolved
Signed-off-by: Bart Smykla <bartek@smykla.com>
Automaat
reviewed
Nov 5, 2024
app/_src/networking/transparent-proxy/configuration-on-kubernetes.md
Outdated
Show resolved
Hide resolved
Signed-off-by: Bart Smykla <bartek@smykla.com>
Signed-off-by: Bart Smykla <bartek@smykla.com>
Signed-off-by: Bart Smykla <bartek@smykla.com>
Automaat
reviewed
Nov 6, 2024
Automaat
reviewed
Nov 6, 2024
Automaat
reviewed
Nov 6, 2024
Automaat
reviewed
Nov 6, 2024
Automaat
reviewed
Nov 6, 2024
Signed-off-by: Bart Smykla <bartek@smykla.com>
Signed-off-by: Bart Smykla <bartek@smykla.com>
Automaat
reviewed
Nov 7, 2024
Signed-off-by: Bart Smykla <bartek@smykla.com>
Signed-off-by: Bart Smykla <bartek@smykla.com>
…proxy-documentation-overhaul
Signed-off-by: Bart Smykla <bartek@smykla.com>
…proxy-documentation-overhaul
…proxy-documentation-overhaul
…proxy-documentation-overhaul Signed-off-by: Bart Smykla <bartek@smykla.com>
Signed-off-by: Bart Smykla <bartek@smykla.com>
Signed-off-by: Bart Smykla <bartek@smykla.com>
…proxy-documentation-overhaul
Automaat
reviewed
Nov 8, 2024
|
|
||
| A transparent proxy is a type of server that can intercept network traffic to and from a service without changes to the client application code. In the case of {{ Kuma }} it is used to capture traffic and redirect it to `kuma-dp` so Mesh policies can be applied. | ||
|
|
||
| To accomplish this, {{ Kuma }} utilizes [`iptables`](https://linux.die.net/man/8/iptables) and offers additional, experimental support for [`eBPF`]({{ docs }}/production/dp-config/cni/#merbridge-cni-with-ebpf). The examples provided in this section will concentrate on iptables to clearly illustrate the point. |
There was a problem hiding this comment.
Suggested change
| To accomplish this, {{ Kuma }} utilizes [`iptables`](https://linux.die.net/man/8/iptables) and offers additional, experimental support for [`eBPF`]({{ docs }}/production/dp-config/cni/#merbridge-cni-with-ebpf). The examples provided in this section will concentrate on iptables to clearly illustrate the point. | |
| To accomplish this, {{ Kuma }} utilizes [iptables](https://linux.die.net/man/8/iptables) and offers additional, experimental support for [eBPF](https://ebpf.io/). The examples provided in this section will concentrate on iptables to clearly illustrate the point. |
lahabana
reviewed
Nov 8, 2024
| @@ -173,8 +173,14 @@ Vuejs | |||
| websockets? | |||
| wireframes? | |||
| workspace | |||
| yaml | |||
| yaml|YAML | |||
There was a problem hiding this comment.
I'm off the opinion of being opiniated and when both are accepted only tolerate one.
lahabana
reviewed
Nov 8, 2024
| UIDs? | ||
| use_original_dst | ||
| orin | ||
| ConfigMap |
There was a problem hiding this comment.
Please respect the lexico order on this file
lahabana
reviewed
Nov 8, 2024
app/_src/introduction/concepts.md
Outdated
|
|
||
| A transparent proxy is a server that intercepts network traffic going to and from a service without requiring any changes to the application code. In {{ site.mesh_product_name}}, it captures this traffic and routes it to the data plane proxy, allowing policies to be applied. | ||
|
|
||
| For more details, see the [Transparent Proxy](/docs/{{ page.version}}/{% if_version lte:2.8.x inline:true %}production/dp-config/transparent-proxying/{% endif_version %}{% if_version gte:2.9.x inline:true %}/networking/transparent-proxy/introduction/{% endif_version %}) documentation. |
There was a problem hiding this comment.
Should this be a subsection in the data plane entry? I feel like you'd read dp, inbound, outbound and then transparent proxy WDYT?
|
|
||
| ## Transparent proxy | ||
|
|
||
| A transparent proxy is a server that intercepts network traffic going to and from a service without requiring any changes to the application code. In {{ site.mesh_product_name}}, it captures this traffic and routes it to the data plane proxy, allowing policies to be applied. |
There was a problem hiding this comment.
a server?!
Maybe you should step back a little and approach from the user point view something like:
Data planes are usually configured in a setup that is called `transparent proxy`. In this case, both inbound and outbound traffic will be transparently routed through the data plane proxy. This enables users to use {{ site.mesh_product_name }} without any change to the data plane app.
| Universal mode is best combined with {% if_version lte:2.1.x %}[transparent proxy](/docs/{{ page.release }}/networking/transparent-proxying){% endif_version%}{% if_version gte:2.2.x %}[transparent proxy](/docs/{{ page.release }}/production/dp-config/transparent-proxying/){% endif_version%}. For backward compatibility only, you can consume an external service from within the mesh by filling the proper `outbound` section of the relevant data plane resource: | ||
| {% capture tproxy-link %}/docs/{{ page.release }}/{% if_version lte:2.1.x %}networking/transparent-proxying/{% endif_version%}{% if_version gte:2.2.x lte:2.8.x %}production/dp-config/transparent-proxying/{% endif_version%}{% if_version gte:2.9.x %}networking/transparent-proxy/introduction/{% endif_version%}{% endcapture %} | ||
|
|
||
| Universal mode is best combined with [transparent proxy]({{ tproxy-link }}). For backward compatibility only, you can consume an external service from within the mesh by filling the proper `outbound` section of the relevant data plane resource: |
There was a problem hiding this comment.
What's the story with MES?
| @@ -5,7 +5,7 @@ content_type: how-to | |||
|
|
|||
| In order for traffic to flow through the {{site.mesh_product_name}} data plane, all inbound and | |||
| outbound traffic for a service needs to go through its data plane proxy. | |||
| The recommended way of accomplishing this is via {% if_version lte:2.1.x %}[transparent proxying](/docs/{{ page.release }}/networking/transparent-proxying){% endif_version %}{% if_version gte:2.2.x %}[transparent proxying](/docs/{{ page.release }}/production/dp-config/transparent-proxying/){% endif_version %}. | |||
| The recommended way of accomplishing this is via [transparent proxying](/docs/{{ page.release }}/{% if_version lte:2.1.x %}networking/transparent-proxying/{% endif_version %}{% if_version gte:2.2.x lte:2.8.x %}production/dp-config/transparent-proxying/{% endif_version %}{% if_version gte:2.9.x %}networking/transparent-proxy/introduction/{% endif_version %}). | |||
There was a problem hiding this comment.
Should the CNI page just be in transparent proxy?
| By default, with the transparent proxy enabled, each data plane proxy follows all other proxies in the mesh. In large meshes, a data plane proxy usually connects to only a few services. Defining this list of reachable services can significantly improve {{site.mesh_product_name}}'s performance. {% if_version lte:2.8.x %}Benefits include: | ||
| * The control plane generates a much smaller XDS configuration (fewer clusters/listeners), saving CPU and memory. | ||
| * Smaller configurations reduce network bandwidth. | ||
| * Envoy manages fewer clusters/listeners, reducing statistics and memory usage. |
There was a problem hiding this comment.
Worth doing:
- Reduce CPU/Memory usage on the CP: As the configuration is smaller
- Lower network bandwidth: Because configuration is smaller and that it will change less often
- Reduce CPU/Memory usage on the DP: As there are less clusters/listeners.
People care about the effect more than the reason for it.
|
|
||
| Reachable Backends provides similar functionality to [Reachable Services]({{ docs }}/networking/transparent-proxy/reachable-services/), but it applies to resources such as [MeshService]({{ docs }}/networking/meshservice), [MeshExternalService]({{ docs }}/networking/meshexternalservice), and [MeshMultiZoneService]({{ docs }}/networking/meshmultizoneservice). | ||
|
|
||
| By default, each data plane proxy tracks all other data planes in the mesh, which can impact performance and use more resources. Configuring `reachableBackends` allows you to specify only the services your application actually needs to communicate with, improving efficiency. |
There was a problem hiding this comment.
Suggested change
| By default, each data plane proxy tracks all other data planes in the mesh, which can impact performance and use more resources. Configuring `reachableBackends` allows you to specify only the services your application actually needs to communicate with, improving efficiency. | |
| By default, each data plane proxy can access all other services in the mesh. This impacts performance and resources consumption. With `reachableBackends` you specify a subset of service services your application communicates with, which enables {{ Kuma }} to trim the configuration and be more efficient. |
| - **MeshExternalService** | ||
| - **MeshMultiZoneService** | ||
| - **name**: Name of the resource. | ||
| - **namespace**: (Kubernetes only) Namespace where the resource is located. Required if using `namespace`. |
There was a problem hiding this comment.
I don't get this. namespace is required when using namespace?
| name: demo-app | ||
| namespace: kuma-demo | ||
| annotations: | ||
| kuma.io/reachable-backends: "" |
There was a problem hiding this comment.
Would it be easier to understand with refs: [] ?
| refs: | ||
| - kind: MeshService | ||
| labels: | ||
| k8s.kuma.io/namespace: kuma-demo |
There was a problem hiding this comment.
There can be a universal equivalent to this right?
A universal workload that only talks to stuff in a kuberenetes namespace (in another zone)
| - **MeshMultiZoneService** | ||
| - **name**: Name of the resource. | ||
| - **namespace**: (Kubernetes only) Namespace where the resource is located. Required if using `namespace`. | ||
| - **labels**: A list of labels to match resources. You can define either `labels` or `name`. |
There was a problem hiding this comment.
It's worth mentioning here that when we use this it matches ALL the workloads that have these labels. I think that's how reachableBackends is so much better than reachableServices
…ocumentation-overhaul
Signed-off-by: Bart Smykla <bartek@smykla.com>
Signed-off-by: Bart Smykla <bartek@smykla.com>
Signed-off-by: Bart Smykla <bartek@smykla.com>
…ocumentation-overhaul
Signed-off-by: Bart Smykla <bartek@smykla.com>
Signed-off-by: Bart Smykla <bartek@smykla.com>
…ocumentation-overhaul
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Transparent proxy docs are now consolidated under "Using Kuma / Service Discovery & Networking / Transparent Proxy". The former "Kuma in Production" content is now "Introduction" in this group, and "Using Kuma / Transparent Proxying" is now "Technical Overview". Reachable Services, Reachable Backends, installation, and configuration are split into separate pages.
Added a Transparent Proxy Configuration Reference.
Did you sign your commit? Instructions: 👍
Have you read Contributing guidelines?: 👍