From 1cc3a500ea3aac6ed17624c6a5e24fb171b967aa Mon Sep 17 00:00:00 2001 From: Charly Molter Date: Wed, 12 Jul 2023 12:05:57 +0200 Subject: [PATCH 1/4] fix: remove some reference to generated and remove a line break Signed-off-by: Charly Molter --- app/_src/networking/service-discovery.md | 2 +- app/_src/policies/introduction.md | 4 +--- app/_src/production/dp-config/transparent-proxying.md | 4 ++-- 3 files changed, 4 insertions(+), 6 deletions(-) diff --git a/app/_src/networking/service-discovery.md b/app/_src/networking/service-discovery.md index f872c7d6f..899083367 100644 --- a/app/_src/networking/service-discovery.md +++ b/app/_src/networking/service-discovery.md @@ -17,7 +17,7 @@ The connection between the data-planes and the control-plane is not on the execu While doing so, the data-planes also advertise the IP address of each service. The IP address is retrieved: * On Kubernetes by looking at the address of the `Pod`. -* On Universal by looking at the inbound listeners that have been configured in the [`inbound` property](/docs/{{ page.version }}/generated/resources/proxy_dataplane) of the data-plane specification. +* On Universal by looking at the inbound listeners that have been configured in the [`inbound` property](/docs/{{ page.version }}/dp-config/dpp-on-universal#dataplane-configuration) of the data-plane specification. The IP address that's being advertised by every data-plane to the control-plane is also being used to route service traffic from one `kuma-dp` to another `kuma-dp`. This means that {{site.mesh_product_name}} knows at any given time what are all the IP addresses associated to every replica of every service. Another use-case where the IP address of the data-planes is being used is for metrics scraping by Prometheus. diff --git a/app/_src/policies/introduction.md b/app/_src/policies/introduction.md index 04174752c..b1fe7a00f 100644 --- a/app/_src/policies/introduction.md +++ b/app/_src/policies/introduction.md @@ -3,9 +3,7 @@ title: Policies --- Here you can find the list of Policies that {{site.mesh_product_name}} supports. -Going forward from version 2.0, {{site.mesh_product_name}} is transitioning from [source/destination policies](/docs/{{ -page.version }}/policies/general-notes-about-kuma-policies) to [`targetRef` policies](/docs/{{ page.version -}}/policies/targetref). +Going forward from version 2.0, {{site.mesh_product_name}} is transitioning from [source/destination policies](/docs/{{ page.version }}/policies/general-notes-about-kuma-policies) to [`targetRef` policies](/docs/{{ page.version }}/policies/targetref). The following table shows the equivalence between source/destination and `targetRef` policies: diff --git a/app/_src/production/dp-config/transparent-proxying.md b/app/_src/production/dp-config/transparent-proxying.md index a1ec349cb..a3969450c 100644 --- a/app/_src/production/dp-config/transparent-proxying.md +++ b/app/_src/production/dp-config/transparent-proxying.md @@ -16,11 +16,11 @@ All incoming and outgoing traffic is automatically intercepted by `kuma-dp` with ## Universal -On **Universal** `kuma-dp` leverages the [data plane proxy specification](/docs/{{ page.version }}/generated/resources/proxy_dataplane) associated to it for receiving incoming requests on a pre-defined port. +On **Universal** `kuma-dp` leverages the [data plane proxy specification](/docs/{{ page.version }}/dp-config/dpp-on-universal#dataplane-configuration) associated to it for receiving incoming requests on a pre-defined port. There are several advantages for using transparent proxying in universal mode: - * Simpler [Dataplane resource](/docs/{{ page.version }}/generated/resources/proxy_dataplane), as the `outbound` section becomes obsolete and can be skipped. + * Simpler [Dataplane resource](/docs/{{ page.version }}/dp-config/dpp-on-universal), as the `outbound` section becomes obsolete and can be skipped. * Universal service naming with `.mesh` [DNS domain](/docs/{{ page.version }}/networking/dns) instead of explicit outbound like `https://localhost:10001`. * Support for hostnames of your choice using [VirtualOutbounds](/docs/{{ page.version }}/policies/virtual-outbound) that lets you preserve existing service naming. * Better service manageability (security, tracing). From 729ff7bca95f27eed76dc2e21510ed33955cfc6c Mon Sep 17 00:00:00 2001 From: Charly Molter Date: Wed, 12 Jul 2023 12:10:27 +0200 Subject: [PATCH 2/4] fix: rename use-kuma to use-mesh This avoids having to do magic on docs.konghq.com Signed-off-by: Charly Molter --- app/_data/docs_nav_kuma_2.2.x.yml | 2 +- app/_data/docs_nav_kuma_2.3.x.yml | 2 +- app/_data/docs_nav_kuma_dev.yml | 2 +- app/_src/explore/gateway.md | 2 +- app/_src/production/cp-deployment/multi-zone.md | 2 +- app/_src/production/secure-deployment/api-server-auth.md | 2 +- app/_src/production/{use-kuma.md => use-mesh.md} | 0 7 files changed, 6 insertions(+), 6 deletions(-) rename app/_src/production/{use-kuma.md => use-mesh.md} (100%) diff --git a/app/_data/docs_nav_kuma_2.2.x.yml b/app/_data/docs_nav_kuma_2.2.x.yml index 5affd73f8..0fd92fb2f 100644 --- a/app/_data/docs_nav_kuma_2.2.x.yml +++ b/app/_data/docs_nav_kuma_2.2.x.yml @@ -42,7 +42,7 @@ items: - text: Install kumactl url: /production/install-kumactl/ - text: Use Kuma - url: /production/use-kuma/ + url: /production/use-mesh/ - title: Control plane deployment group: true items: diff --git a/app/_data/docs_nav_kuma_2.3.x.yml b/app/_data/docs_nav_kuma_2.3.x.yml index 1effbae5a..f7252bf42 100644 --- a/app/_data/docs_nav_kuma_2.3.x.yml +++ b/app/_data/docs_nav_kuma_2.3.x.yml @@ -40,7 +40,7 @@ items: - text: Install kumactl url: /production/install-kumactl/ - text: Use Kuma - url: /production/use-kuma/ + url: /production/use-mesh/ - title: Control plane deployment group: true items: diff --git a/app/_data/docs_nav_kuma_dev.yml b/app/_data/docs_nav_kuma_dev.yml index 8b4a4f57a..c7d04cdcb 100644 --- a/app/_data/docs_nav_kuma_dev.yml +++ b/app/_data/docs_nav_kuma_dev.yml @@ -40,7 +40,7 @@ items: - text: Install kumactl url: /production/install-kumactl/ - text: Use Kuma - url: /production/use-kuma/ + url: /production/use-mesh/ - title: Control plane deployment group: true items: diff --git a/app/_src/explore/gateway.md b/app/_src/explore/gateway.md index 61d4f734e..e62cdb117 100644 --- a/app/_src/explore/gateway.md +++ b/app/_src/explore/gateway.md @@ -77,7 +77,7 @@ These instructions are mostly taken from the [Kong docs](https://docs.konghq.com 1. [Install {{site.mesh_product_name}}](/docs/{{ page.version }}/installation/kubernetes) on your cluster and have the `default` [namespace labelled with sidecar-injection](/docs/{{ page.version }}/explore/dpp-on-kubernetes). {% endif_version %} {% if_version gte:2.2.x %} -1. [Install {{site.mesh_product_name}}](/docs/{{ page.version }}/production/use-kuma/) on your cluster and have the `default`[namespace labelled with sidecar-injection](/docs/{{ page.version }}/production/dp-config/dpp-on-kubernetes/). +1. [Install {{site.mesh_product_name}}](/docs/{{ page.version }}/production/use-mesh/) on your cluster and have the `default`[namespace labelled with sidecar-injection](/docs/{{ page.version }}/production/dp-config/dpp-on-kubernetes/). {% endif_version %} 2. Install [Kong using helm](https://docs.konghq.com/kubernetes-ingress-controller/2.1.x/deployment/k4k8s/#helm). diff --git a/app/_src/production/cp-deployment/multi-zone.md b/app/_src/production/cp-deployment/multi-zone.md index e475bdee5..5550de689 100644 --- a/app/_src/production/cp-deployment/multi-zone.md +++ b/app/_src/production/cp-deployment/multi-zone.md @@ -69,7 +69,7 @@ The global control plane on Kubernetes must reside on its own Kubernetes cluster {{site.mesh_namespace}} {{site.mesh_cp_name}} ClusterIP 10.105.12.133 5681/TCP,443/TCP,5676/TCP,5677/TCP,5678/TCP,5679/TCP,5682/TCP,5653/UDP 90s ``` - By default, it's exposed on [port 5685]({% if_version lte:2.1.x %}/docs/{{ page.version }}/networking/networking{% endif_version %}{% if_version gte:2.2.x %}/docs/{{ page.version }}/production/use-kuma#control-plane-ports{% endif_version %}). In this example the value is `35.226.196.103:5685`. You pass this as the value of `` when you set up the zone control planes. + By default, it's exposed on [port 5685]({% if_version lte:2.1.x %}/docs/{{ page.version }}/networking/networking{% endif_version %}{% if_version gte:2.2.x %}/docs/{{ page.version }}/production/use-mesh#control-plane-ports{% endif_version %}). In this example the value is `35.226.196.103:5685`. You pass this as the value of `` when you set up the zone control planes. {% endtab %} diff --git a/app/_src/production/secure-deployment/api-server-auth.md b/app/_src/production/secure-deployment/api-server-auth.md index dac8c7076..26b6a0be6 100644 --- a/app/_src/production/secure-deployment/api-server-auth.md +++ b/app/_src/production/secure-deployment/api-server-auth.md @@ -3,7 +3,7 @@ title: Authentication with the API server content_type: how-to --- -{{site.mesh_product_name}} exposes API server on [ports]({% if_version lte:2.1.x %}/docs/{{ page.version }}/networking/networking{% endif_version %}{% if_version gte:2.2.x %}/docs/{{ page.version }}/production/use-kuma#control-plane-ports{% endif_version %}) `5681` and `5682` (protected by TLS). +{{site.mesh_product_name}} exposes API server on [ports]({% if_version lte:2.1.x %}/docs/{{ page.version }}/networking/networking{% endif_version %}{% if_version gte:2.2.x %}/docs/{{ page.version }}/production/use-mesh#control-plane-ports{% endif_version %}) `5681` and `5682` (protected by TLS). An authenticated user can be authorized to execute administrative actions such as * Managing administrative resources like {{site.mesh_product_name}} Secrets on Universal diff --git a/app/_src/production/use-kuma.md b/app/_src/production/use-mesh.md similarity index 100% rename from app/_src/production/use-kuma.md rename to app/_src/production/use-mesh.md From 5e17b808501c65a1c98fa66e985dd839037c7406 Mon Sep 17 00:00:00 2001 From: Charly Molter Date: Wed, 12 Jul 2023 12:14:19 +0200 Subject: [PATCH 3/4] correct path Signed-off-by: Charly Molter --- app/_src/networking/service-discovery.md | 2 +- app/_src/production/dp-config/transparent-proxying.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/app/_src/networking/service-discovery.md b/app/_src/networking/service-discovery.md index 899083367..f027af6a8 100644 --- a/app/_src/networking/service-discovery.md +++ b/app/_src/networking/service-discovery.md @@ -17,7 +17,7 @@ The connection between the data-planes and the control-plane is not on the execu While doing so, the data-planes also advertise the IP address of each service. The IP address is retrieved: * On Kubernetes by looking at the address of the `Pod`. -* On Universal by looking at the inbound listeners that have been configured in the [`inbound` property](/docs/{{ page.version }}/dp-config/dpp-on-universal#dataplane-configuration) of the data-plane specification. +* On Universal by looking at the inbound listeners that have been configured in the [`inbound` property](/docs/{{ page.version }}/production/dp-config/dpp-on-universal#dataplane-configuration) of the data-plane specification. The IP address that's being advertised by every data-plane to the control-plane is also being used to route service traffic from one `kuma-dp` to another `kuma-dp`. This means that {{site.mesh_product_name}} knows at any given time what are all the IP addresses associated to every replica of every service. Another use-case where the IP address of the data-planes is being used is for metrics scraping by Prometheus. diff --git a/app/_src/production/dp-config/transparent-proxying.md b/app/_src/production/dp-config/transparent-proxying.md index a3969450c..a7c4836fe 100644 --- a/app/_src/production/dp-config/transparent-proxying.md +++ b/app/_src/production/dp-config/transparent-proxying.md @@ -16,11 +16,11 @@ All incoming and outgoing traffic is automatically intercepted by `kuma-dp` with ## Universal -On **Universal** `kuma-dp` leverages the [data plane proxy specification](/docs/{{ page.version }}/dp-config/dpp-on-universal#dataplane-configuration) associated to it for receiving incoming requests on a pre-defined port. +On **Universal** `kuma-dp` leverages the [data plane proxy specification](/docs/{{ page.version }}/production/dp-config/dpp-on-universal#dataplane-configuration) associated to it for receiving incoming requests on a pre-defined port. There are several advantages for using transparent proxying in universal mode: - * Simpler [Dataplane resource](/docs/{{ page.version }}/dp-config/dpp-on-universal), as the `outbound` section becomes obsolete and can be skipped. + * Simpler [Dataplane resource](/docs/{{ page.version }}/production/dp-config/dpp-on-universal), as the `outbound` section becomes obsolete and can be skipped. * Universal service naming with `.mesh` [DNS domain](/docs/{{ page.version }}/networking/dns) instead of explicit outbound like `https://localhost:10001`. * Support for hostnames of your choice using [VirtualOutbounds](/docs/{{ page.version }}/policies/virtual-outbound) that lets you preserve existing service naming. * Better service manageability (security, tracing). From e0d8566401745ff824c976e91554dd6df382d6dd Mon Sep 17 00:00:00 2001 From: Charly Molter Date: Wed, 12 Jul 2023 13:42:38 +0200 Subject: [PATCH 4/4] clean redirects and stuff Signed-off-by: Charly Molter --- .github/workflows/ci.yml | 4 ++-- app/_common_redirects | 7 ------- app/_posts/2020-09-10-multi-cluster-cloud.md | 8 ++++---- app/_src/index.md | 2 +- app/_src/introduction/how-kuma-works.md | 2 +- app/_src/networking/service-discovery.md | 2 +- app/_src/production/cp-deployment/multi-zone.md | 6 ++++-- app/_src/production/dp-config/transparent-proxying.md | 4 ++-- 8 files changed, 15 insertions(+), 20 deletions(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 145e7f8d5..6f9958f8d 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -40,10 +40,10 @@ jobs: max_timeout: 1200 - name: link checker run: | - $(go env GOPATH)/bin/muffet ${URL} --buffer-size 8192 --exclude https://twitter.com --max-connections-per-host=8 --exclude 127.0.0.1 --exclude 'https://github.com/kumahq/kuma/pull' --exclude 'https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md.*' --rate-limit 50 --timeout 60 + $(go env GOPATH)/bin/muffet ${URL} --buffer-size 8192 --exclude https://twitter.com --max-connections-per-host=8 --exclude 127.0.0.1 --exclude 'https://github.com/kumahq/kuma/pull' --exclude 'https://github.com//kumahq/kuma/pull' --exclude 'https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md.*' --rate-limit 50 --timeout 60 - name: link checker dev docs run: | - $(go env GOPATH)/bin/muffet ${URL}/docs/dev --buffer-size 8192 --exclude https://twitter.com --max-connections-per-host=8 --exclude 127.0.0.1 --exclude 'https://github.com/kumahq/kuma/pull' --exclude 'https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md.*' --exclude https://download.konghq.com --rate-limit 50 --timeout 60 + $(go env GOPATH)/bin/muffet ${URL}/docs/dev --buffer-size 8192 --exclude https://twitter.com --max-connections-per-host=8 --exclude 127.0.0.1 --exclude 'https://github.com/kumahq/kuma/pull' --exclude 'https://github.com//kumahq/kuma/pull' --exclude 'https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md.*' --exclude https://download.konghq.com --rate-limit 50 --timeout 60 installer-sh: name: Test installer.sh diff --git a/app/_common_redirects b/app/_common_redirects index 3ed4941f8..daba6d513 100644 --- a/app/_common_redirects +++ b/app/_common_redirects @@ -35,12 +35,5 @@ /docs/:version/documentation/deployments/ /docs/:version/introduction/deployments 301 # kuma IA redirects (pages that do exist take precedence on these so it's safe to use `:version` for pages moved in newer versions). -/docs/:version/deployments/multi-zone /docs/:version/production/cp-deployment/multi-zone/ -/docs/:version/deployments/stand-alone /docs/:version/production/cp-deployment/stand-alone/ -/docs/:version/introduction/what-is-a-service-mesh/ /docs/:version/introduction/about-service-meshes -/docs/:version/introduction/what-is-kuma/ /docs/:version/introduction/overview-of-kuma -/docs/:version/introduction/deployments /docs/:version/production/deployment/ -/docs/:version/policies/mesh /docs/:version/production/mesh/ /docs/:version/policies/proxy-template/ /docs/:version/reference/proxy-template/ -/docs/:version/explore/dpp/* /docs/:version/production/dp-config/dpp/ /docs/:version/installation/* /docs/:version/production/install-kumactl/ diff --git a/app/_posts/2020-09-10-multi-cluster-cloud.md b/app/_posts/2020-09-10-multi-cluster-cloud.md index 2077a4614..f13998913 100644 --- a/app/_posts/2020-09-10-multi-cluster-cloud.md +++ b/app/_posts/2020-09-10-multi-cluster-cloud.md @@ -16,7 +16,7 @@ Starting from Kuma 0.6, which was released this summer with a new advanced multi Kuma creates a service connectivity overlay across hybrid infrastructure to discover and connect services automatically, including hybrid Kubernetes + VM services. -This [multi-zone capability](/docs/latest/deployments/multi-zone/) has been added in addition to the [multi-mesh support](/docs/latest/policies/mesh/) that Kuma introduced since day one to create multiple isolated meshes on the same cluster (with dedicated mTLS CAs) in order to reduce team coordination, increase isolation and improve security rather than one large service mesh that everybody is sharing. Also, since multi-zone leverages the first-class K8s + VM support that shipped since the first version of Kuma, all teams and workloads in the organizations can benefit from service mesh and not just our greenfield initiatives. +This [multi-zone capability](/docs/latest/production/cp-deployment/multi-zone/) has been added in addition to the [multi-mesh support](/docs/latest/production/mesh/) that Kuma introduced since day one to create multiple isolated meshes on the same cluster (with dedicated mTLS CAs) in order to reduce team coordination, increase isolation and improve security rather than one large service mesh that everybody is sharing. Also, since multi-zone leverages the first-class K8s + VM support that shipped since the first version of Kuma, all teams and workloads in the organizations can benefit from service mesh and not just our greenfield initiatives. A Kuma service mesh distributed across every cloud, cluster and workload that the teams are using can therefore be managed from one individual cluster of Kuma itself. Meanwhile, multiple service meshes can be virtually provisioned on one Kuma control plane (horizontally scalable) to simplify mesh management across the organization – very similar to how Kubernetes and its namespaces work. @@ -67,7 +67,7 @@ Among other use cases, cross-zone connectivity is useful for: 1. A new “ingress” data plane proxy mode processes incoming traffic into a zone. There will be one Kuma ingress deployment per zone, that can be scaled horizontally as the traffic increases. The “ingress” data plane mode is being added in addition to the default proxying one and the “gateway” one (to support third-party API gateways). Because of the new “ingress” mode, Kuma doesn’t require a flat networking topology between zones and can support more complex infrastructure. 2. A built-in service discovery DNS server resolves the address of a service to either an IP address of a replica in the same zone or the address of an ingress proxy in another zone. - Likewise with the “global” and “remote” control planes, the ingress and the DNS service discovery can also be installed in one click by following the [multi-zone instructions](/docs/latest/deployments/multi-zone/) on Kuma. + Likewise with the “global” and “remote” control planes, the ingress and the DNS service discovery can also be installed in one click by following the [multi-zone instructions](/docs/latest/production/cp-deployment/multi-zone/) on Kuma. When it comes to service discovery, Kuma creates a “.mesh” DNS entry on the built-in DNS resolver that can be used to resolve services across the same zone or in other zones, effectively “flattening” the discovery of services across a complex infrastructure. Kuma will – accordingly to the traffic routing policies that have been configured – determine if we should be consuming a replica of the service in the local zone or if we should resolve the request to the IP address of a Kuma ingress in another zone, which will then leverage SNI to determine what service has been requested and route the request accordingly. @@ -77,7 +77,7 @@ In this example, we have three services (users, invoices and billing). Requests Since SNI resolution is mandatory for cross-zone communication, the [mTLS policy](/docs/latest/policies/mutual-tls/) must be enabled on the mesh. Also, since Kuma already knows where all the services are running, cross-zone discovery and connectivity happen automatically. -When a new service is registered into Kuma, a new “kuma.io/zone” tag is added to the data plane definition so that we can use the [attribute-based policy selectors](/docs/latest/explore/dpp/#tags) to configure Kuma policies like [Traffic Route](/docs/latest/policies/traffic-route/) to determine the behavior of cross-zone traffic (blue/green or canary across different zones, weighted traffic, as well as traffic shifting). +When a new service is registered into Kuma, a new “kuma.io/zone” tag is added to the data plane definition so that we can use the [attribute-based policy selectors](/docs/latest/production/dp-config/dpp/) to configure Kuma policies like [Traffic Route](/docs/latest/policies/traffic-route/) to determine the behavior of cross-zone traffic (blue/green or canary across different zones, weighted traffic, as well as traffic shifting). When consuming any “{service-name}.mesh” on default port 80 (even if the service is not listening on port 80), the DNS resolver – in addition to resolving the address of the service – will also automatically resolve the port of the destination service and inject it into the connection in order to keep the uptime of the overall connectivity even when a team decides to re-assign ports of a service that other teams may be using. This feature reduces the team coordination required to maintain a large number of services and connections in a Kuma mesh. @@ -85,7 +85,7 @@ When consuming any “{service-name}.mesh” on default port 80 (even if the ser Thanks to the new multi-zone capability that Kuma provides since v0.6+, we can now easily run a service mesh across multiple Kubernetes clusters, clouds and regions. Since Kuma natively supports both containerized and VM workloads, this functionality can also be used to create service connectivity across hybrid architectures. -By providing [one-click installation steps](/docs/latest/documentation/deployments/) to automate the installation of new zones as well as features like global/remote control planes, built-in service discovery and a native Kuma ingress, Kuma abstracts away service connectivity by creating a network overlay that effectively flattens out how services can discover and consume each other across complex network topologies. This makes it a great fit for any enterprise or distributed environment. +By providing [one-click installation steps](/docs/latest/production/use-mesh) to automate the installation of new zones as well as features like global/remote control planes, built-in service discovery and a native Kuma ingress, Kuma abstracts away service connectivity by creating a network overlay that effectively flattens out how services can discover and consume each other across complex network topologies. This makes it a great fit for any enterprise or distributed environment. To get up and running with Kuma, you can check out the [installation page](/install) as well as the official [Slack channel](/community). diff --git a/app/_src/index.md b/app/_src/index.md index 483cf7e8e..ddc69b4d5 100644 --- a/app/_src/index.md +++ b/app/_src/index.md @@ -25,7 +25,7 @@ The core maintainer of Kuma is **Kong**, the maker of the popular open-source Ko [Explore the API](/docs/{{ page.version }}/reference/http-api) {% endif_version %} -{% if_version gte:2.1.x %} +{% if_version gte:2.2.x %} [Read about service mesh](/docs/{{ page.version }}/introduction/about-service-meshes) [Read about Kuma](/docs/{{ page.version }}/introduction/overview-of-kuma) diff --git a/app/_src/introduction/how-kuma-works.md b/app/_src/introduction/how-kuma-works.md index c867376cb..9cca4b58b 100644 --- a/app/_src/introduction/how-kuma-works.md +++ b/app/_src/introduction/how-kuma-works.md @@ -69,7 +69,7 @@ By reducing the code that our teams create and maintain, we can modernize our ap Out of the box, {{site.mesh_product_name}} ships with a bundled [Envoy](https://www.envoyproxy.io/) data plane proxy ready to use for our services, so that you don't have to worry about putting all the pieces together. {% tip %} -{{site.mesh_product_name}} ships with an executable `kuma-dp` that executes the bundled `envoy` executable to create the data plane proxy. For details, see the [Overview](/docs/{{ page.version }}/introduction/overview-of-kuma). +{{site.mesh_product_name}} ships with an executable `kuma-dp` that executes the bundled `envoy` executable to create the data plane proxy. For details, see the [Overview]({%if_version lte:2.1.x %}/docs/{{ page.version }}/introduction/what-is-kuma{%endif_version%}{%if_version gte:2.2.x %}/docs/{{ page.version }}/introduction/overview-of-kuma{%endif_version%}). {% endtip %} [Install {{site.mesh_product_name}}](/install/) and follow the instructions to get up and running in a few steps. diff --git a/app/_src/networking/service-discovery.md b/app/_src/networking/service-discovery.md index f027af6a8..51e60bbb9 100644 --- a/app/_src/networking/service-discovery.md +++ b/app/_src/networking/service-discovery.md @@ -17,7 +17,7 @@ The connection between the data-planes and the control-plane is not on the execu While doing so, the data-planes also advertise the IP address of each service. The IP address is retrieved: * On Kubernetes by looking at the address of the `Pod`. -* On Universal by looking at the inbound listeners that have been configured in the [`inbound` property](/docs/{{ page.version }}/production/dp-config/dpp-on-universal#dataplane-configuration) of the data-plane specification. +* On Universal by looking at the inbound listeners that have been configured in the [`inbound` property]({%if_version lte:2.1.x %}/docs/{{ page.version }}/explore/dpp-on-universal/{%endif_version%}{%if_version gte:2.2.x %}/docs/{{ page.version }}/production/dp-config/dpp-on-universal#dataplane-configuration{%endif_version%}) of the data-plane specification. The IP address that's being advertised by every data-plane to the control-plane is also being used to route service traffic from one `kuma-dp` to another `kuma-dp`. This means that {{site.mesh_product_name}} knows at any given time what are all the IP addresses associated to every replica of every service. Another use-case where the IP address of the data-planes is being used is for metrics scraping by Prometheus. diff --git a/app/_src/production/cp-deployment/multi-zone.md b/app/_src/production/cp-deployment/multi-zone.md index 5550de689..fddd04a50 100644 --- a/app/_src/production/cp-deployment/multi-zone.md +++ b/app/_src/production/cp-deployment/multi-zone.md @@ -216,7 +216,7 @@ You need the following values to pass to each zone control plane setup: where `zone` is the same value for all zone control planes in the same zone. - Add `--egress-enabled` to list of arguments if you want to deploy optional [Zone Egress](/docs/{{ page.version }}/production/cp-deployment/zoneegress/). + Add `--egress-enabled` to list of arguments if you want to deploy optional [Zone Egress]({% if_version lte:2.1.x %}/docs/{{ page.version }}/explore/zoneegress/{% endif_version %}{% if_version gte:2.2.x %}/docs/{{ page.version }}/production/cp-deployment/zoneegress/{% endif_version %}). {% if_version gte:2.3.x %} `--set {{site.set_flag_values_prefix}}controlPlane.tls.kdsZoneClient.skipVerify=true` is required because the default global control plane's certificate is self-signed. @@ -254,7 +254,7 @@ You need the following values to pass to each zone control plane setup: where `controlPlane.zone` is the same value for all zone control planes in the same zone. - Add `--set {{site.set_flag_values_prefix}}egress.enabled=true` to list of arguments if you want to deploy optional [Zone Egress](/docs/{{ page.version }}/production/cp-deployment/zoneegress/). + Add `--set {{site.set_flag_values_prefix}}egress.enabled=true` to list of arguments if you want to deploy optional [Zone Egress]({% if_version lte:2.1.x %}/docs/{{ page.version }}/explore/zoneegress/{% endif_version %}{% if_version gte:2.2.x %}/docs/{{ page.version }}/production/cp-deployment/zoneegress/{% endif_version %}). {% if_version gte:2.3.x %} `--set {{site.set_flag_values_prefix}}controlPlane.tls.kdsZoneClient.skipVerify=true` is required because the default global control plane's certificate is self-signed. @@ -522,3 +522,5 @@ spec: With this setting, the global control plane will stop exchanging configuration with this zone. As a result, the zone's ingress from zone-1 will be deleted from other zone and traffic won't be routed to it anymore. The zone will show as **Offline** in the GUI and CLI. + +[zoneegress]: https://kuma.io/docs/latest/security/zoneproxy-auth/ diff --git a/app/_src/production/dp-config/transparent-proxying.md b/app/_src/production/dp-config/transparent-proxying.md index a7c4836fe..779b0e83b 100644 --- a/app/_src/production/dp-config/transparent-proxying.md +++ b/app/_src/production/dp-config/transparent-proxying.md @@ -16,11 +16,11 @@ All incoming and outgoing traffic is automatically intercepted by `kuma-dp` with ## Universal -On **Universal** `kuma-dp` leverages the [data plane proxy specification](/docs/{{ page.version }}/production/dp-config/dpp-on-universal#dataplane-configuration) associated to it for receiving incoming requests on a pre-defined port. +On **Universal** `kuma-dp` leverages the [data plane proxy specification]({%if_version lte:2.1.x %}/docs/{{ page.version }}/explore/dpp-on-universal/{%endif_version%}{%if_version gte:2.2.x %}/docs/{{ page.version }}/production/dp-config/dpp-on-universal#dataplane-configuration{%endif_version%}) associated to it for receiving incoming requests on a pre-defined port. There are several advantages for using transparent proxying in universal mode: - * Simpler [Dataplane resource](/docs/{{ page.version }}/production/dp-config/dpp-on-universal), as the `outbound` section becomes obsolete and can be skipped. + * Simpler Dataplane resource, as the `outbound` section becomes obsolete and can be skipped. * Universal service naming with `.mesh` [DNS domain](/docs/{{ page.version }}/networking/dns) instead of explicit outbound like `https://localhost:10001`. * Support for hostnames of your choice using [VirtualOutbounds](/docs/{{ page.version }}/policies/virtual-outbound) that lets you preserve existing service naming. * Better service manageability (security, tracing).