diff --git a/app/_src/documentation/configuration.md b/app/_src/documentation/configuration.md index 0f39d5440..ec921aad2 100644 --- a/app/_src/documentation/configuration.md +++ b/app/_src/documentation/configuration.md @@ -52,7 +52,7 @@ helm install -f values.yaml {{ site.kuma_install_name }} {{ site.mesh_helm_repo If you have a lot of configuration you can just write them all in a YAML file and use: ```shell -helm install {{ site.mesh_helm_install_name }} {{ site.mesh_helm_repo }} --set-file controlPlace.config=cp-conf.yaml +helm install {{ site.mesh_helm_install_name }} {{ site.mesh_helm_repo }} --set-file {{set_flag_values_prefix}}controlPlane.config=cp-conf.yaml ``` The value of the configmap `{{site.mesh_cp_name}}-config` is now the content of `cp-conf.yaml`. diff --git a/app/_src/explore/gateway-api.md b/app/_src/explore/gateway-api.md index 48610fdb3..68970ab0f 100644 --- a/app/_src/explore/gateway-api.md +++ b/app/_src/explore/gateway-api.md @@ -43,7 +43,7 @@ Gateway API [`Gateways`](https://gateway-api.sigs.k8s.io/api-types/gateway/) are The `Gateway` resource represents the proxy instance that handles traffic for a set of Gateway API routes. Every `Gateway` refers to a [`GatewayClass`](https://gateway-api.sigs.k8s.io/api-types/gatewayclass/). - The `GatewayClass` represents the class of `Gateway`, in this case Kuma's builtin edge + The `GatewayClass` represents the class of `Gateway`, in this case {{site.mesh_product_name}}'s builtin edge gateway, and points to a controller that should manage these `Gateways`. It can also hold [additional configuration](#customization). diff --git a/app/_src/policies/how-kuma-chooses-the-right-policy-to-apply.md b/app/_src/policies/how-kuma-chooses-the-right-policy-to-apply.md index 8dcc9ef34..4f76f828f 100644 --- a/app/_src/policies/how-kuma-chooses-the-right-policy-to-apply.md +++ b/app/_src/policies/how-kuma-chooses-the-right-policy-to-apply.md @@ -43,7 +43,7 @@ conf: backend: splunk ``` -What does `Kuma` do when it encounters multiple matching policies? +What does {{site.mesh_product_name}} do when it encounters multiple matching policies? ## General rules diff --git a/app/_src/policies/meshloadbalancingstrategy.md b/app/_src/policies/meshloadbalancingstrategy.md index 8ddc8df6e..2c17f3f90 100644 --- a/app/_src/policies/meshloadbalancingstrategy.md +++ b/app/_src/policies/meshloadbalancingstrategy.md @@ -131,7 +131,7 @@ kind: MeshLoadBalancingStrategy apiVersion: kuma.io/v1alpha1 metadata: name: ring-hash - namespace: kuma-system + namespace: {{site.mesh_namespace}} labels: kuma.io/mesh: mesh-1 spec: @@ -196,7 +196,7 @@ kind: MeshLoadBalancingStrategy apiVersion: kuma.io/v1alpha1 metadata: name: disable-la-to-backend - namespace: kuma-system + namespace: {{site.mesh_namespace}} labels: kuma.io/mesh: mesh-1 spec: diff --git a/app/_src/policies/protocol-support-in-kuma.md b/app/_src/policies/protocol-support-in-kuma.md index 33050d9b4..780c34038 100644 --- a/app/_src/policies/protocol-support-in-kuma.md +++ b/app/_src/policies/protocol-support-in-kuma.md @@ -2,7 +2,7 @@ title: Protocol support in Kuma --- -At its core, `Kuma` distinguishes between the following major categories of traffic: `http`, `grpc`, `kafka` and opaque `tcp` traffic. +At its core, {{site.mesh_product_name}} distinguishes between the following major categories of traffic: `http`, `grpc`, `kafka` and opaque `tcp` traffic. For `http`, `grpc` and `kafka` traffic {{site.mesh_product_name}} provides deep insights down to application-level transactions, in the latter `tcp` case the observability is limited to connection-level statistics. @@ -96,7 +96,7 @@ Note that in this case no advanced HTTP or GRPC statistics or logging are availa {{site.mesh_product_name}} out of the box support's `Websocket` protocol. The service exposing `Websocket` should be marked as `tcp`. -As `Websockets` use pure `TCP` connections under the hood, your service have to be recognised by `Kuma` as the `TCP` one. It's also the default behavior for {{site.mesh_product_name}} to assume the service's `inbound` interfaces are the TCP ones, so you don't have to do anything, but if you want to be explicit, you can configure your services exposing `Websocket` endpoints with `appProtocol` property. I.e.: +As `Websockets` use pure `TCP` connections under the hood, your service have to be recognised by {{site.mesh_product_name}} as the `TCP` one. It's also the default behavior for {{site.mesh_product_name}} to assume the service's `inbound` interfaces are the TCP ones, so you don't have to do anything, but if you want to be explicit, you can configure your services exposing `Websocket` endpoints with `appProtocol` property. I.e.: {% tabs websocket-support useUrlFragment=false %} {% tab websocket-support Kubernetes %} diff --git a/app/_src/policies/traffic-metrics.md b/app/_src/policies/traffic-metrics.md index d5009478f..28e730252 100644 --- a/app/_src/policies/traffic-metrics.md +++ b/app/_src/policies/traffic-metrics.md @@ -9,7 +9,7 @@ You can add metrics to a mesh configuration, or to an individual data plane prox {{site.mesh_product_name}} provides full integration with Prometheus: * Each proxy can expose its metrics in [Prometheus format](https://prometheus.io/docs/instrumenting/exposition_formats/#text-based-format). -* Because metrics are part of the mesh configuration, Kuma exposes an API called the monitoring assignment service (MADS) which exposes every proxy in the mesh. +* Because metrics are part of the mesh configuration, {{site.mesh_product_name}} exposes an API called the monitoring assignment service (MADS) which exposes every proxy in the mesh. To collect metrics from {{site.mesh_product_name}}, you need to expose metrics from proxies and applications. diff --git a/app/_src/production/dp-config/cni.md b/app/_src/production/dp-config/cni.md index 10851d64f..32cd3d7e5 100644 --- a/app/_src/production/dp-config/cni.md +++ b/app/_src/production/dp-config/cni.md @@ -220,7 +220,7 @@ helm install --create-namespace --namespace {{site.mesh_namespace}} \ {% tab insallation OpenShift 3.11 %} 1. Follow the instructions in [OpenShift 3.11 installation](/docs/{{ page.version }}/installation/openshift/#2-run-kuma) - to get the `MutatingAdmissionWebhook` and `ValidatingAdmissionWebhook` enabled (this is required for regular kuma installation). + to get the `MutatingAdmissionWebhook` and `ValidatingAdmissionWebhook` enabled (this is required for regular {{site.mesh_product_name}} installation). 2. You need to grant privileged permission to kuma-cni service account: diff --git a/app/_src/production/upgrades-tuning/fine-tuning.md b/app/_src/production/upgrades-tuning/fine-tuning.md index d205f0db8..919c5b031 100644 --- a/app/_src/production/upgrades-tuning/fine-tuning.md +++ b/app/_src/production/upgrades-tuning/fine-tuning.md @@ -18,7 +18,7 @@ Follow the {% if_version lte:2.1.x %}[transparent proxying](/docs/{{ page.versio ## Postgres -If you choose `Postgres` as a configuration store for `Kuma` on Universal, +If you choose `Postgres` as a configuration store for {{site.mesh_product_name}} on Universal, please be aware of the following key settings that affect performance of {{site.mesh_product_name}} Control Plane. * `KUMA_STORE_POSTGRES_CONNECTION_TIMEOUT` : connection timeout to the Postgres database (default: 5s) diff --git a/app/docs/1.2.x/documentation/cli.md b/app/docs/1.2.x/documentation/cli.md index 00843e1e3..47c4cb9b6 100644 --- a/app/docs/1.2.x/documentation/cli.md +++ b/app/docs/1.2.x/documentation/cli.md @@ -8,7 +8,7 @@ Kuma ships in a bundle that includes a few executables: * `kuma-dp`: this is the Kuma data plane proxy executable that - under the hood - invokes `envoy`. * `envoy`: this is the Envoy executable that we bundle for convenience into the archive. * `kumactl`: this is the the user CLI to interact with Kuma (`kuma-cp`) and its data. -* `kuma-prometheus-sd`: this is a helper tool that enables native integration between `Kuma` and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them. +* `kuma-prometheus-sd`: this is a helper tool that enables native integration between {{site.mesh_product_name}} and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them. * `kuma-tcp-echo`: this is a sample application that echos back the requests we are making, used for demo purposes. According to the [installation instructions](/install/), some of these executables are automatically executed as part of the installation workflow, while some other times you will have to execute them directly. @@ -52,4 +52,4 @@ Available commands on `kumactl` are: * `kumactl generate tls-certificate`: used to generate a TLS certificate for client or server. * `kumactl manage ca [..]`: used to manage certificate authorities. * `kumactl help [..]`: help dialog that explains the commands available. -* `kumactl version [--detailed]`: shows the version of the program. \ No newline at end of file +* `kumactl version [--detailed]`: shows the version of the program. diff --git a/app/docs/1.2.x/documentation/dps-and-data-model.md b/app/docs/1.2.x/documentation/dps-and-data-model.md index 445fcd6f7..4c69b0f62 100644 --- a/app/docs/1.2.x/documentation/dps-and-data-model.md +++ b/app/docs/1.2.x/documentation/dps-and-data-model.md @@ -117,7 +117,7 @@ E.g., * you can turn `Envoy Admin API` off by using `--admin-port=` {% warning %} -If you choose to turn `Envoy Admin API` off, you will not be able to leverage some of `Kuma` features, such as enabling `Prometheus` metrics on that dataplane. +If you choose to turn `Envoy Admin API` off, you will not be able to leverage some of {{site.mesh_product_name}} features, such as enabling `Prometheus` metrics on that dataplane. {% endwarning %} ## Tags diff --git a/app/docs/1.2.x/documentation/fine-tuning.md b/app/docs/1.2.x/documentation/fine-tuning.md index f2c1923cf..08d46be95 100644 --- a/app/docs/1.2.x/documentation/fine-tuning.md +++ b/app/docs/1.2.x/documentation/fine-tuning.md @@ -4,7 +4,7 @@ title: Fine-tuning ## Postgres -If you choose `Postgres` as a configuration store for `Kuma` on Universal, +If you choose `Postgres` as a configuration store for {{site.mesh_product_name}} on Universal, please be aware of the following key settings that affect performance of Kuma Control Plane. * `KUMA_STORE_POSTGRES_CONNECTION_TIMEOUT` : connection timeout to the Postgres database (default: 5s) @@ -78,4 +78,4 @@ Then, you can analyze the retrieved profiling data using an application like [Sp {% warning %} After a successful debugging session, please remember to turn off the debugging endpoints since anybody could execute heap dumps on them potentially exposing sensitive data. -{% endwarning %} \ No newline at end of file +{% endwarning %} diff --git a/app/docs/1.2.x/documentation/overview.md b/app/docs/1.2.x/documentation/overview.md index 31fd07d5c..e4d52fd78 100644 --- a/app/docs/1.2.x/documentation/overview.md +++ b/app/docs/1.2.x/documentation/overview.md @@ -27,7 +27,7 @@ Since Kuma bundles a data-plane in addition to the control-plane, we decided to * `kuma-dp`: this is the Kuma data-plane executable that - under the hood - invokes `envoy`. * `envoy`: this is the Envoy executable that we bundle for convenience into the archive. * `kumactl`: this is the the user CLI to interact with Kuma (`kuma-cp`) and its data. -* `kuma-prometheus-sd`: this is a helper tool that enables native integration between `Kuma` and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them. +* `kuma-prometheus-sd`: this is a helper tool that enables native integration between {{site.mesh_product_name}} and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them. * `kuma-tcp-echo`: this is a sample application that echos back the requests we are making, used for demo purposes. A minimal Kuma deployment involves one or more instances of the control-plane (`kuma-cp`), and one or more instances of the data-planes (`kuma-dp`) which will connect to the control-plane as soon as they startup. Kuma supports two modes: diff --git a/app/docs/1.2.x/policies/general-notes-about-kuma-policies.md b/app/docs/1.2.x/policies/general-notes-about-kuma-policies.md index 613441136..d1763ea1f 100644 --- a/app/docs/1.2.x/policies/general-notes-about-kuma-policies.md +++ b/app/docs/1.2.x/policies/general-notes-about-kuma-policies.md @@ -2,7 +2,7 @@ title: General notes about Kuma policies --- -You may have already noticed that most `Kuma` policies have very similar structure, namely +You may have already noticed that most {{site.mesh_product_name}} policies have very similar structure, namely ```yaml sources: @@ -25,7 +25,7 @@ where * `destinations` - a list of selectors to match those `Dataplanes` where network traffic destined at * `conf` - configuration to apply to network traffic between `sources` and `destinations` -To keep configuration model simple and consistent, `Kuma` assumes that every `Dataplane` represents a `service`, even if it's a cron job that doesn't normally handle incoming traffic. +To keep configuration model simple and consistent, {{site.mesh_product_name}} assumes that every `Dataplane` represents a `service`, even if it's a cron job that doesn't normally handle incoming traffic. Consequently, `service` tag is mandatory for `sources` and `destinations` selectors. @@ -87,4 +87,4 @@ For example, policies that get applied on the client side of a connection betwee In some cases there is a fundamental technical cause for that (e.g., `TrafficRoute`), in other cases it's a simplification of the initial implementation (e.g., `TrafficLog` and `HealthCheck`). Please let us know if such constraints become critical to your use case. -{% endwarning %} \ No newline at end of file +{% endwarning %} diff --git a/app/docs/1.2.x/policies/how-kuma-chooses-the-right-policy-to-apply.md b/app/docs/1.2.x/policies/how-kuma-chooses-the-right-policy-to-apply.md index 0ffee23b4..ec15c9755 100644 --- a/app/docs/1.2.x/policies/how-kuma-chooses-the-right-policy-to-apply.md +++ b/app/docs/1.2.x/policies/how-kuma-chooses-the-right-policy-to-apply.md @@ -38,7 +38,7 @@ conf: backend: splunk ``` -What does `Kuma` do when it encounters multiple matching policies? +What does {{site.mesh_product_name}} do when it encounters multiple matching policies? ## General rules diff --git a/app/docs/1.2.x/policies/protocol-support-in-kuma.md b/app/docs/1.2.x/policies/protocol-support-in-kuma.md index eae6385b0..66ddd53fb 100644 --- a/app/docs/1.2.x/policies/protocol-support-in-kuma.md +++ b/app/docs/1.2.x/policies/protocol-support-in-kuma.md @@ -2,7 +2,7 @@ title: Protocol support in Kuma --- -At its core, `Kuma` distinguishes between the following major categories of traffic: `http`, `grpc`, `kafka` and opaque `tcp` traffic. +At its core, {{site.mesh_product_name}} distinguishes between the following major categories of traffic: `http`, `grpc`, `kafka` and opaque `tcp` traffic. For `http`, `grpc` and `kafka` traffic Kuma provides deep insights down to application-level transactions, in the latter `tcp` case the observability is limited to connection-level statistics. @@ -76,7 +76,7 @@ Note that in this case no advanced HTTP or GRPC statistics or logging are availa Kuma out of the box support's `Websocket` protocol. The service exposing `Websocket` should be annotated with `kuma.io/protocol: tcp` annotation -As `Websockets` use pure `TCP` connections under the hood, your service have to be recognised by `Kuma` as the `TCP` one. It's also the default behavior for Kuma to assume the service's `inbound` interfaces are the TCP ones, so you don't have to do anything, but if you want to be explicit, you can annotate your services exposing `Websocket` endpoints with `kuma.io/protocol: tcp` annotation. I.e.: +As `Websockets` use pure `TCP` connections under the hood, your service have to be recognised by {{site.mesh_product_name}} as the `TCP` one. It's also the default behavior for Kuma to assume the service's `inbound` interfaces are the TCP ones, so you don't have to do anything, but if you want to be explicit, you can annotate your services exposing `Websocket` endpoints with `kuma.io/protocol: tcp` annotation. I.e.: {% tabs websocket-support useUrlFragment=false %} {% tab websocket-support Kubernetes %} @@ -111,4 +111,4 @@ networking: kuma.io/protocol: tcp ``` {% endtab %} -{% endtabs %} \ No newline at end of file +{% endtabs %} diff --git a/app/docs/1.2.x/policies/traffic-log.md b/app/docs/1.2.x/policies/traffic-log.md index 3c6b90db6..b48ca33c4 100644 --- a/app/docs/1.2.x/policies/traffic-log.md +++ b/app/docs/1.2.x/policies/traffic-log.md @@ -6,7 +6,7 @@ With `TrafficLog` policy you can easily set up access logs on every data-plane i [//]: # (The logs can be then forwarded to a collector that can further transmit them into systems like Splunk, ELK and Datadog.) -Configuring access logs in `Kuma` is a 3-step process: +Configuring access logs in {{site.mesh_product_name}} is a 3-step process: * [1. Add a logging backend](#add-a-logging-backend) * [2. Add a TrafficLog resource](#add-a-trafficlog-resource) @@ -16,7 +16,7 @@ Configuring access logs in `Kuma` is a 3-step process: A _logging backend_ is essentially a sink for access logs. -In the current release of `Kuma`, a _logging backend_ can be either a _file_ or a _TCP log collector_, such as Logstash. +In the current release of {{site.mesh_product_name}}, a _logging backend_ can be either a _file_ or a _TCP log collector_, such as Logstash. {% tabs logging-backend useUrlFragment=false %} {% tab logging-backend Kubernetes %} @@ -158,7 +158,7 @@ When `backend ` field of a `TrafficLog` policy is omitted, the logs will be forw ## Log aggregation and visualisation -`Kuma` is presenting a simple solution to aggregate the **logs of your containers** and the **access logs of your data-planes**. +{{site.mesh_product_name}} is presenting a simple solution to aggregate the **logs of your containers** and the **access logs of your data-planes**. {% tabs log-aggregation useUrlFragment=false %} {% tab log-aggregation Kubernetes %} @@ -250,7 +250,7 @@ You can also forward the access logs to a collector (such as logstash) that can ### Access Log Format -`Kuma` gives you full control over the format of access logs. +{{site.mesh_product_name}} gives you full control over the format of access logs. The shape of a single log record is defined by a template string that uses [command operators](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#command-operators) to extract and format data about a `TCP` connection or an `HTTP` request. @@ -265,7 +265,7 @@ where `%START_TIME%` and `%KUMA_SOURCE_SERVICE%` are examples of available _comm A complete set of supported _command operators_ consists of: 1. All _command operators_ [supported by Envoy](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#command-operators) -2. _Command operators_ unique to `Kuma` +2. _Command operators_ unique to {{site.mesh_product_name}} The latter include: @@ -283,7 +283,7 @@ All access log _command operators_ are valid to use with both `TCP` and `HTTP` t If a _command operator_ is specific to `HTTP` traffic, such as `%REQ(X?Y):Z%` or `%RESP(X?Y):Z%`, it will be replaced by a symbol "`-`" in case of `TCP` traffic. -Internally, `Kuma` [determines traffic protocol](/docs/{{ page.version }}/policies/protocol-support-in-kuma) based on the value of `kuma.io/protocol` tag on the `inbound` interface of a `destination` `Dataplane`. +Internally, {{site.mesh_product_name}} [determines traffic protocol](/docs/{{ page.version }}/policies/protocol-support-in-kuma) based on the value of `kuma.io/protocol` tag on the `inbound` interface of a `destination` `Dataplane`. The default format string for `TCP` traffic is: diff --git a/app/docs/1.2.x/policies/traffic-metrics.md b/app/docs/1.2.x/policies/traffic-metrics.md index 3daf875df..88dbe6cd4 100644 --- a/app/docs/1.2.x/policies/traffic-metrics.md +++ b/app/docs/1.2.x/policies/traffic-metrics.md @@ -95,7 +95,7 @@ By default all available metrics are returned. {% tabs override useUrlFragment=false %} {% tab override Kubernetes %} -To override `Mesh`-wide defaults for a particular `Pod`, use `Kuma`-specific annotations: +To override `Mesh`-wide defaults for a particular `Pod`, use {{site.mesh_product_name}}-specific annotations: * `prometheus.metrics.kuma.io/port` - to override `Mesh`-wide default port * `prometheus.metrics.kuma.io/path` - to override `Mesh`-wide default path diff --git a/app/docs/1.3.x/documentation/cli.md b/app/docs/1.3.x/documentation/cli.md index 00843e1e3..47c4cb9b6 100644 --- a/app/docs/1.3.x/documentation/cli.md +++ b/app/docs/1.3.x/documentation/cli.md @@ -8,7 +8,7 @@ Kuma ships in a bundle that includes a few executables: * `kuma-dp`: this is the Kuma data plane proxy executable that - under the hood - invokes `envoy`. * `envoy`: this is the Envoy executable that we bundle for convenience into the archive. * `kumactl`: this is the the user CLI to interact with Kuma (`kuma-cp`) and its data. -* `kuma-prometheus-sd`: this is a helper tool that enables native integration between `Kuma` and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them. +* `kuma-prometheus-sd`: this is a helper tool that enables native integration between {{site.mesh_product_name}} and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them. * `kuma-tcp-echo`: this is a sample application that echos back the requests we are making, used for demo purposes. According to the [installation instructions](/install/), some of these executables are automatically executed as part of the installation workflow, while some other times you will have to execute them directly. @@ -52,4 +52,4 @@ Available commands on `kumactl` are: * `kumactl generate tls-certificate`: used to generate a TLS certificate for client or server. * `kumactl manage ca [..]`: used to manage certificate authorities. * `kumactl help [..]`: help dialog that explains the commands available. -* `kumactl version [--detailed]`: shows the version of the program. \ No newline at end of file +* `kumactl version [--detailed]`: shows the version of the program. diff --git a/app/docs/1.3.x/documentation/dps-and-data-model.md b/app/docs/1.3.x/documentation/dps-and-data-model.md index 8e5bf47ef..cbe719bda 100644 --- a/app/docs/1.3.x/documentation/dps-and-data-model.md +++ b/app/docs/1.3.x/documentation/dps-and-data-model.md @@ -117,7 +117,7 @@ E.g., * you can turn `Envoy Admin API` off by using `--admin-port=` {% warning %} -If you choose to turn `Envoy Admin API` off, you will not be able to leverage some of `Kuma` features, such as enabling `Prometheus` metrics on that dataplane. +If you choose to turn `Envoy Admin API` off, you will not be able to leverage some of {{site.mesh_product_name}} features, such as enabling `Prometheus` metrics on that dataplane. {% endwarning %} ## Tags diff --git a/app/docs/1.3.x/documentation/fine-tuning.md b/app/docs/1.3.x/documentation/fine-tuning.md index 859162e4f..5566f3d04 100644 --- a/app/docs/1.3.x/documentation/fine-tuning.md +++ b/app/docs/1.3.x/documentation/fine-tuning.md @@ -4,7 +4,7 @@ title: Fine-tuning ## Postgres -If you choose `Postgres` as a configuration store for `Kuma` on Universal, +If you choose `Postgres` as a configuration store for {{site.mesh_product_name}} on Universal, please be aware of the following key settings that affect performance of Kuma Control Plane. * `KUMA_STORE_POSTGRES_CONNECTION_TIMEOUT` : connection timeout to the Postgres database (default: 5s) @@ -78,4 +78,4 @@ Then, you can analyze the retrieved profiling data using an application like [Sp {% warning %} After a successful debugging session, please remember to turn off the debugging endpoints since anybody could execute heap dumps on them potentially exposing sensitive data. -{% endwarning %} \ No newline at end of file +{% endwarning %} diff --git a/app/docs/1.3.x/documentation/overview.md b/app/docs/1.3.x/documentation/overview.md index 31fd07d5c..e4d52fd78 100644 --- a/app/docs/1.3.x/documentation/overview.md +++ b/app/docs/1.3.x/documentation/overview.md @@ -27,7 +27,7 @@ Since Kuma bundles a data-plane in addition to the control-plane, we decided to * `kuma-dp`: this is the Kuma data-plane executable that - under the hood - invokes `envoy`. * `envoy`: this is the Envoy executable that we bundle for convenience into the archive. * `kumactl`: this is the the user CLI to interact with Kuma (`kuma-cp`) and its data. -* `kuma-prometheus-sd`: this is a helper tool that enables native integration between `Kuma` and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them. +* `kuma-prometheus-sd`: this is a helper tool that enables native integration between {{site.mesh_product_name}} and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them. * `kuma-tcp-echo`: this is a sample application that echos back the requests we are making, used for demo purposes. A minimal Kuma deployment involves one or more instances of the control-plane (`kuma-cp`), and one or more instances of the data-planes (`kuma-dp`) which will connect to the control-plane as soon as they startup. Kuma supports two modes: diff --git a/app/docs/1.3.x/policies/how-kuma-chooses-the-right-policy-to-apply.md b/app/docs/1.3.x/policies/how-kuma-chooses-the-right-policy-to-apply.md index 0ffee23b4..ec15c9755 100644 --- a/app/docs/1.3.x/policies/how-kuma-chooses-the-right-policy-to-apply.md +++ b/app/docs/1.3.x/policies/how-kuma-chooses-the-right-policy-to-apply.md @@ -38,7 +38,7 @@ conf: backend: splunk ``` -What does `Kuma` do when it encounters multiple matching policies? +What does {{site.mesh_product_name}} do when it encounters multiple matching policies? ## General rules diff --git a/app/docs/1.3.x/policies/protocol-support-in-kuma.md b/app/docs/1.3.x/policies/protocol-support-in-kuma.md index eae6385b0..66ddd53fb 100644 --- a/app/docs/1.3.x/policies/protocol-support-in-kuma.md +++ b/app/docs/1.3.x/policies/protocol-support-in-kuma.md @@ -2,7 +2,7 @@ title: Protocol support in Kuma --- -At its core, `Kuma` distinguishes between the following major categories of traffic: `http`, `grpc`, `kafka` and opaque `tcp` traffic. +At its core, {{site.mesh_product_name}} distinguishes between the following major categories of traffic: `http`, `grpc`, `kafka` and opaque `tcp` traffic. For `http`, `grpc` and `kafka` traffic Kuma provides deep insights down to application-level transactions, in the latter `tcp` case the observability is limited to connection-level statistics. @@ -76,7 +76,7 @@ Note that in this case no advanced HTTP or GRPC statistics or logging are availa Kuma out of the box support's `Websocket` protocol. The service exposing `Websocket` should be annotated with `kuma.io/protocol: tcp` annotation -As `Websockets` use pure `TCP` connections under the hood, your service have to be recognised by `Kuma` as the `TCP` one. It's also the default behavior for Kuma to assume the service's `inbound` interfaces are the TCP ones, so you don't have to do anything, but if you want to be explicit, you can annotate your services exposing `Websocket` endpoints with `kuma.io/protocol: tcp` annotation. I.e.: +As `Websockets` use pure `TCP` connections under the hood, your service have to be recognised by {{site.mesh_product_name}} as the `TCP` one. It's also the default behavior for Kuma to assume the service's `inbound` interfaces are the TCP ones, so you don't have to do anything, but if you want to be explicit, you can annotate your services exposing `Websocket` endpoints with `kuma.io/protocol: tcp` annotation. I.e.: {% tabs websocket-support useUrlFragment=false %} {% tab websocket-support Kubernetes %} @@ -111,4 +111,4 @@ networking: kuma.io/protocol: tcp ``` {% endtab %} -{% endtabs %} \ No newline at end of file +{% endtabs %} diff --git a/app/docs/1.3.x/policies/traffic-log.md b/app/docs/1.3.x/policies/traffic-log.md index a9b9c1d7f..dd0419684 100644 --- a/app/docs/1.3.x/policies/traffic-log.md +++ b/app/docs/1.3.x/policies/traffic-log.md @@ -6,7 +6,7 @@ With `TrafficLog` policy you can easily set up access logs on every data-plane i [//]: # (The logs can be then forwarded to a collector that can further transmit them into systems like Splunk, ELK and Datadog.) -Configuring access logs in `Kuma` is a 3-step process: +Configuring access logs in {{site.mesh_product_name}} is a 3-step process: * [1. Add a logging backend](#add-a-logging-backend) * [2. Add a TrafficLog resource](#add-a-trafficlog-resource) @@ -16,7 +16,7 @@ Configuring access logs in `Kuma` is a 3-step process: A _logging backend_ is essentially a sink for access logs. -In the current release of `Kuma`, a _logging backend_ can be either a _file_ or a _TCP log collector_, such as Logstash. +In the current release of {{site.mesh_product_name}}, a _logging backend_ can be either a _file_ or a _TCP log collector_, such as Logstash. {% tabs logging-backend useUrlFragment=false %} {% tab logging-backend Kubernetes %} @@ -158,7 +158,7 @@ When `backend ` field of a `TrafficLog` policy is omitted, the logs will be forw ## Log aggregation and visualisation -`Kuma` is presenting a simple solution to aggregate the **logs of your containers** and the **access logs of your data-planes**. +{{site.mesh_product_name}} is presenting a simple solution to aggregate the **logs of your containers** and the **access logs of your data-planes**. {% tabs log-aggregation useUrlFragment=false %} {% tab log-aggregation Kubernetes %} @@ -250,7 +250,7 @@ You can also forward the access logs to a collector (such as logstash) that can ### Access Log Format -`Kuma` gives you full control over the format of access logs. +{{site.mesh_product_name}} gives you full control over the format of access logs. The shape of a single log record is defined by a template string that uses [command operators](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#command-operators) to extract and format data about a `TCP` connection or an `HTTP` request. @@ -265,7 +265,7 @@ where `%START_TIME%` and `%KUMA_SOURCE_SERVICE%` are examples of available _comm A complete set of supported _command operators_ consists of: 1. All _command operators_ [supported by Envoy](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#command-operators) -2. _Command operators_ unique to `Kuma` +2. _Command operators_ unique to {{site.mesh_product_name}} The latter include: @@ -283,7 +283,7 @@ All access log _command operators_ are valid to use with both `TCP` and `HTTP` t If a _command operator_ is specific to `HTTP` traffic, such as `%REQ(X?Y):Z%` or `%RESP(X?Y):Z%`, it will be replaced by a symbol "`-`" in case of `TCP` traffic. -Internally, `Kuma` [determines traffic protocol](/docs/{{ page.version }}/policies/protocol-support-in-kuma) based on the value of `kuma.io/protocol` tag on the `inbound` interface of a `destination` `Dataplane`. +Internally, {{site.mesh_product_name}} [determines traffic protocol](/docs/{{ page.version }}/policies/protocol-support-in-kuma) based on the value of `kuma.io/protocol` tag on the `inbound` interface of a `destination` `Dataplane`. The default format string for `TCP` traffic is: diff --git a/app/docs/1.3.x/policies/traffic-metrics.md b/app/docs/1.3.x/policies/traffic-metrics.md index 884caf00f..9a5460d23 100644 --- a/app/docs/1.3.x/policies/traffic-metrics.md +++ b/app/docs/1.3.x/policies/traffic-metrics.md @@ -95,7 +95,7 @@ By default all available metrics are returned. {% tabs override-prometheus useUrlFragment=false %} {% tab override-prometheus Kubernetes %} -To override `Mesh`-wide defaults for a particular `Pod`, use `Kuma`-specific annotations: +To override `Mesh`-wide defaults for a particular `Pod`, use {{site.mesh_product_name}}-specific annotations: * `prometheus.metrics.kuma.io/port` - to override `Mesh`-wide default port * `prometheus.metrics.kuma.io/path` - to override `Mesh`-wide default path diff --git a/app/docs/1.4.x/documentation/cli.md b/app/docs/1.4.x/documentation/cli.md index c913778dc..3ceebd092 100644 --- a/app/docs/1.4.x/documentation/cli.md +++ b/app/docs/1.4.x/documentation/cli.md @@ -8,7 +8,7 @@ Kuma ships in a bundle that includes a few executables: * `kuma-dp`: this is the Kuma data plane proxy executable that - under the hood - invokes `envoy`. * `envoy`: this is the Envoy executable that we bundle for convenience into the archive. * `kumactl`: this is the the user CLI to interact with Kuma (`kuma-cp`) and its data. -* `kuma-prometheus-sd`: this is a helper tool that enables native integration between `Kuma` and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them. +* `kuma-prometheus-sd`: this is a helper tool that enables native integration between {{site.mesh_product_name}} and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them. * `kuma-tcp-echo`: this is a sample application that echos back the requests we are making, used for demo purposes. According to the [installation instructions](/install/), some of these executables are automatically executed as part of the installation workflow, while some other times you will have to execute them directly. diff --git a/app/docs/1.4.x/documentation/dps-and-data-model.md b/app/docs/1.4.x/documentation/dps-and-data-model.md index 34728e84a..b458ab59b 100644 --- a/app/docs/1.4.x/documentation/dps-and-data-model.md +++ b/app/docs/1.4.x/documentation/dps-and-data-model.md @@ -117,7 +117,7 @@ E.g., * you can turn `Envoy Admin API` off by using `--admin-port=` {% warning %} -If you choose to turn `Envoy Admin API` off, you will not be able to leverage some of `Kuma` features, such as enabling `Prometheus` metrics on that dataplane. +If you choose to turn `Envoy Admin API` off, you will not be able to leverage some of {{site.mesh_product_name}} features, such as enabling `Prometheus` metrics on that dataplane. {% endwarning %} ## Tags diff --git a/app/docs/1.4.x/documentation/fine-tuning.md b/app/docs/1.4.x/documentation/fine-tuning.md index bd75949cc..7b19962cf 100644 --- a/app/docs/1.4.x/documentation/fine-tuning.md +++ b/app/docs/1.4.x/documentation/fine-tuning.md @@ -4,7 +4,7 @@ title: Fine-tuning ## Postgres -If you choose `Postgres` as a configuration store for `Kuma` on Universal, +If you choose `Postgres` as a configuration store for {{site.mesh_product_name}} on Universal, please be aware of the following key settings that affect performance of Kuma Control Plane. * `KUMA_STORE_POSTGRES_CONNECTION_TIMEOUT` : connection timeout to the Postgres database (default: 5s) diff --git a/app/docs/1.4.x/documentation/overview.md b/app/docs/1.4.x/documentation/overview.md index a8c4534f8..ee5924368 100644 --- a/app/docs/1.4.x/documentation/overview.md +++ b/app/docs/1.4.x/documentation/overview.md @@ -27,7 +27,7 @@ Since Kuma bundles a data-plane in addition to the control-plane, we decided to * `kuma-dp`: this is the Kuma data-plane executable that - under the hood - invokes `envoy`. * `envoy`: this is the Envoy executable that we bundle for convenience into the archive. * `kumactl`: this is the the user CLI to interact with Kuma (`kuma-cp`) and its data. -* `kuma-prometheus-sd`: this is a helper tool that enables native integration between `Kuma` and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them. +* `kuma-prometheus-sd`: this is a helper tool that enables native integration between {{site.mesh_product_name}} and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them. * `kuma-tcp-echo`: this is a sample application that echos back the requests we are making, used for demo purposes. A minimal Kuma deployment involves one or more instances of the control-plane (`kuma-cp`), and one or more instances of the data-planes (`kuma-dp`) which will connect to the control-plane as soon as they startup. Kuma supports two modes: diff --git a/app/docs/1.4.x/policies/how-kuma-chooses-the-right-policy-to-apply.md b/app/docs/1.4.x/policies/how-kuma-chooses-the-right-policy-to-apply.md index 0ffee23b4..ec15c9755 100644 --- a/app/docs/1.4.x/policies/how-kuma-chooses-the-right-policy-to-apply.md +++ b/app/docs/1.4.x/policies/how-kuma-chooses-the-right-policy-to-apply.md @@ -38,7 +38,7 @@ conf: backend: splunk ``` -What does `Kuma` do when it encounters multiple matching policies? +What does {{site.mesh_product_name}} do when it encounters multiple matching policies? ## General rules diff --git a/app/docs/1.4.x/policies/protocol-support-in-kuma.md b/app/docs/1.4.x/policies/protocol-support-in-kuma.md index eae6385b0..66ddd53fb 100644 --- a/app/docs/1.4.x/policies/protocol-support-in-kuma.md +++ b/app/docs/1.4.x/policies/protocol-support-in-kuma.md @@ -2,7 +2,7 @@ title: Protocol support in Kuma --- -At its core, `Kuma` distinguishes between the following major categories of traffic: `http`, `grpc`, `kafka` and opaque `tcp` traffic. +At its core, {{site.mesh_product_name}} distinguishes between the following major categories of traffic: `http`, `grpc`, `kafka` and opaque `tcp` traffic. For `http`, `grpc` and `kafka` traffic Kuma provides deep insights down to application-level transactions, in the latter `tcp` case the observability is limited to connection-level statistics. @@ -76,7 +76,7 @@ Note that in this case no advanced HTTP or GRPC statistics or logging are availa Kuma out of the box support's `Websocket` protocol. The service exposing `Websocket` should be annotated with `kuma.io/protocol: tcp` annotation -As `Websockets` use pure `TCP` connections under the hood, your service have to be recognised by `Kuma` as the `TCP` one. It's also the default behavior for Kuma to assume the service's `inbound` interfaces are the TCP ones, so you don't have to do anything, but if you want to be explicit, you can annotate your services exposing `Websocket` endpoints with `kuma.io/protocol: tcp` annotation. I.e.: +As `Websockets` use pure `TCP` connections under the hood, your service have to be recognised by {{site.mesh_product_name}} as the `TCP` one. It's also the default behavior for Kuma to assume the service's `inbound` interfaces are the TCP ones, so you don't have to do anything, but if you want to be explicit, you can annotate your services exposing `Websocket` endpoints with `kuma.io/protocol: tcp` annotation. I.e.: {% tabs websocket-support useUrlFragment=false %} {% tab websocket-support Kubernetes %} @@ -111,4 +111,4 @@ networking: kuma.io/protocol: tcp ``` {% endtab %} -{% endtabs %} \ No newline at end of file +{% endtabs %} diff --git a/app/docs/1.4.x/policies/traffic-log.md b/app/docs/1.4.x/policies/traffic-log.md index a9b9c1d7f..dd0419684 100644 --- a/app/docs/1.4.x/policies/traffic-log.md +++ b/app/docs/1.4.x/policies/traffic-log.md @@ -6,7 +6,7 @@ With `TrafficLog` policy you can easily set up access logs on every data-plane i [//]: # (The logs can be then forwarded to a collector that can further transmit them into systems like Splunk, ELK and Datadog.) -Configuring access logs in `Kuma` is a 3-step process: +Configuring access logs in {{site.mesh_product_name}} is a 3-step process: * [1. Add a logging backend](#add-a-logging-backend) * [2. Add a TrafficLog resource](#add-a-trafficlog-resource) @@ -16,7 +16,7 @@ Configuring access logs in `Kuma` is a 3-step process: A _logging backend_ is essentially a sink for access logs. -In the current release of `Kuma`, a _logging backend_ can be either a _file_ or a _TCP log collector_, such as Logstash. +In the current release of {{site.mesh_product_name}}, a _logging backend_ can be either a _file_ or a _TCP log collector_, such as Logstash. {% tabs logging-backend useUrlFragment=false %} {% tab logging-backend Kubernetes %} @@ -158,7 +158,7 @@ When `backend ` field of a `TrafficLog` policy is omitted, the logs will be forw ## Log aggregation and visualisation -`Kuma` is presenting a simple solution to aggregate the **logs of your containers** and the **access logs of your data-planes**. +{{site.mesh_product_name}} is presenting a simple solution to aggregate the **logs of your containers** and the **access logs of your data-planes**. {% tabs log-aggregation useUrlFragment=false %} {% tab log-aggregation Kubernetes %} @@ -250,7 +250,7 @@ You can also forward the access logs to a collector (such as logstash) that can ### Access Log Format -`Kuma` gives you full control over the format of access logs. +{{site.mesh_product_name}} gives you full control over the format of access logs. The shape of a single log record is defined by a template string that uses [command operators](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#command-operators) to extract and format data about a `TCP` connection or an `HTTP` request. @@ -265,7 +265,7 @@ where `%START_TIME%` and `%KUMA_SOURCE_SERVICE%` are examples of available _comm A complete set of supported _command operators_ consists of: 1. All _command operators_ [supported by Envoy](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#command-operators) -2. _Command operators_ unique to `Kuma` +2. _Command operators_ unique to {{site.mesh_product_name}} The latter include: @@ -283,7 +283,7 @@ All access log _command operators_ are valid to use with both `TCP` and `HTTP` t If a _command operator_ is specific to `HTTP` traffic, such as `%REQ(X?Y):Z%` or `%RESP(X?Y):Z%`, it will be replaced by a symbol "`-`" in case of `TCP` traffic. -Internally, `Kuma` [determines traffic protocol](/docs/{{ page.version }}/policies/protocol-support-in-kuma) based on the value of `kuma.io/protocol` tag on the `inbound` interface of a `destination` `Dataplane`. +Internally, {{site.mesh_product_name}} [determines traffic protocol](/docs/{{ page.version }}/policies/protocol-support-in-kuma) based on the value of `kuma.io/protocol` tag on the `inbound` interface of a `destination` `Dataplane`. The default format string for `TCP` traffic is: diff --git a/app/docs/1.4.x/policies/traffic-metrics.md b/app/docs/1.4.x/policies/traffic-metrics.md index 5ee6bcb38..940ab04ff 100644 --- a/app/docs/1.4.x/policies/traffic-metrics.md +++ b/app/docs/1.4.x/policies/traffic-metrics.md @@ -98,7 +98,7 @@ By default all available metrics are returned. {% tabs override-prometheus useUrlFragment=false %} {% tab override-prometheus Kubernetes %} -To override `Mesh`-wide defaults for a particular `Pod`, use `Kuma`-specific annotations: +To override `Mesh`-wide defaults for a particular `Pod`, use {{site.mesh_product_name}}-specific annotations: * `prometheus.metrics.kuma.io/port` - to override `Mesh`-wide default port * `prometheus.metrics.kuma.io/path` - to override `Mesh`-wide default path diff --git a/app/docs/1.5.x/documentation/cli.md b/app/docs/1.5.x/documentation/cli.md index c913778dc..3ceebd092 100644 --- a/app/docs/1.5.x/documentation/cli.md +++ b/app/docs/1.5.x/documentation/cli.md @@ -8,7 +8,7 @@ Kuma ships in a bundle that includes a few executables: * `kuma-dp`: this is the Kuma data plane proxy executable that - under the hood - invokes `envoy`. * `envoy`: this is the Envoy executable that we bundle for convenience into the archive. * `kumactl`: this is the the user CLI to interact with Kuma (`kuma-cp`) and its data. -* `kuma-prometheus-sd`: this is a helper tool that enables native integration between `Kuma` and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them. +* `kuma-prometheus-sd`: this is a helper tool that enables native integration between {{site.mesh_product_name}} and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them. * `kuma-tcp-echo`: this is a sample application that echos back the requests we are making, used for demo purposes. According to the [installation instructions](/install/), some of these executables are automatically executed as part of the installation workflow, while some other times you will have to execute them directly. diff --git a/app/docs/1.5.x/documentation/fine-tuning.md b/app/docs/1.5.x/documentation/fine-tuning.md index c6ef446c4..01c4cd39d 100644 --- a/app/docs/1.5.x/documentation/fine-tuning.md +++ b/app/docs/1.5.x/documentation/fine-tuning.md @@ -17,7 +17,7 @@ Follow the [transparent proxying](/docs/{{ page.version }}/networking/transparen ## Postgres -If you choose `Postgres` as a configuration store for `Kuma` on Universal, +If you choose `Postgres` as a configuration store for {{site.mesh_product_name}} on Universal, please be aware of the following key settings that affect performance of Kuma Control Plane. * `KUMA_STORE_POSTGRES_CONNECTION_TIMEOUT` : connection timeout to the Postgres database (default: 5s) diff --git a/app/docs/1.5.x/documentation/overview.md b/app/docs/1.5.x/documentation/overview.md index a8c4534f8..ee5924368 100644 --- a/app/docs/1.5.x/documentation/overview.md +++ b/app/docs/1.5.x/documentation/overview.md @@ -27,7 +27,7 @@ Since Kuma bundles a data-plane in addition to the control-plane, we decided to * `kuma-dp`: this is the Kuma data-plane executable that - under the hood - invokes `envoy`. * `envoy`: this is the Envoy executable that we bundle for convenience into the archive. * `kumactl`: this is the the user CLI to interact with Kuma (`kuma-cp`) and its data. -* `kuma-prometheus-sd`: this is a helper tool that enables native integration between `Kuma` and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them. +* `kuma-prometheus-sd`: this is a helper tool that enables native integration between {{site.mesh_product_name}} and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them. * `kuma-tcp-echo`: this is a sample application that echos back the requests we are making, used for demo purposes. A minimal Kuma deployment involves one or more instances of the control-plane (`kuma-cp`), and one or more instances of the data-planes (`kuma-dp`) which will connect to the control-plane as soon as they startup. Kuma supports two modes: diff --git a/app/docs/1.5.x/policies/how-kuma-chooses-the-right-policy-to-apply.md b/app/docs/1.5.x/policies/how-kuma-chooses-the-right-policy-to-apply.md index 2f980838d..13e5c7ee2 100644 --- a/app/docs/1.5.x/policies/how-kuma-chooses-the-right-policy-to-apply.md +++ b/app/docs/1.5.x/policies/how-kuma-chooses-the-right-policy-to-apply.md @@ -38,7 +38,7 @@ conf: backend: splunk ``` -What does `Kuma` do when it encounters multiple matching policies? +What does {{site.mesh_product_name}} do when it encounters multiple matching policies? ## General rules diff --git a/app/docs/1.5.x/policies/protocol-support-in-kuma.md b/app/docs/1.5.x/policies/protocol-support-in-kuma.md index 891d85c74..f66755596 100644 --- a/app/docs/1.5.x/policies/protocol-support-in-kuma.md +++ b/app/docs/1.5.x/policies/protocol-support-in-kuma.md @@ -2,7 +2,7 @@ title: Protocol support in Kuma --- -At its core, `Kuma` distinguishes between the following major categories of traffic: `http`, `grpc`, `kafka` and opaque `tcp` traffic. +At its core, {{site.mesh_product_name}} distinguishes between the following major categories of traffic: `http`, `grpc`, `kafka` and opaque `tcp` traffic. For `http`, `grpc` and `kafka` traffic Kuma provides deep insights down to application-level transactions, in the latter `tcp` case the observability is limited to connection-level statistics. @@ -96,7 +96,7 @@ Note that in this case no advanced HTTP or GRPC statistics or logging are availa Kuma out of the box support's `Websocket` protocol. The service exposing `Websocket` should be marked as `tcp`. -As `Websockets` use pure `TCP` connections under the hood, your service have to be recognised by `Kuma` as the `TCP` one. It's also the default behavior for Kuma to assume the service's `inbound` interfaces are the TCP ones, so you don't have to do anything, but if you want to be explicit, you can configure your services exposing `Websocket` endpoints with `appProtocol` property. I.e.: +As `Websockets` use pure `TCP` connections under the hood, your service have to be recognised by {{site.mesh_product_name}} as the `TCP` one. It's also the default behavior for Kuma to assume the service's `inbound` interfaces are the TCP ones, so you don't have to do anything, but if you want to be explicit, you can configure your services exposing `Websocket` endpoints with `appProtocol` property. I.e.: {% tabs websocket-support useUrlFragment=false %} {% tab websocket-support Kubernetes %} diff --git a/app/docs/1.5.x/policies/traffic-log.md b/app/docs/1.5.x/policies/traffic-log.md index e82b27521..4a603e7b9 100644 --- a/app/docs/1.5.x/policies/traffic-log.md +++ b/app/docs/1.5.x/policies/traffic-log.md @@ -6,7 +6,7 @@ With `TrafficLog` policy you can easily set up access logs on every data-plane i [//]: # (The logs can be then forwarded to a collector that can further transmit them into systems like Splunk, ELK and Datadog.) -Configuring access logs in `Kuma` is a 3-step process: +Configuring access logs in {{site.mesh_product_name}} is a 3-step process: * [1. Add a logging backend](#add-a-logging-backend) * [2. Add a TrafficLog resource](#add-a-trafficlog-resource) @@ -16,7 +16,7 @@ Configuring access logs in `Kuma` is a 3-step process: A _logging backend_ is essentially a sink for access logs. -In the current release of `Kuma`, a _logging backend_ can be either a _file_ or a _TCP log collector_, such as Logstash. +In the current release of {{site.mesh_product_name}}, a _logging backend_ can be either a _file_ or a _TCP log collector_, such as Logstash. {% tabs logging-backend useUrlFragment=false %} {% tab logging-backend Kubernetes %} @@ -159,7 +159,7 @@ When `backend ` field of a `TrafficLog` policy is omitted, the logs will be forw ## Log aggregation and visualisation -`Kuma` is presenting a simple solution to aggregate the **logs of your containers** and the **access logs of your data-planes**. +{{site.mesh_product_name}} is presenting a simple solution to aggregate the **logs of your containers** and the **access logs of your data-planes**. {% tabs log-aggregation useUrlFragment=false %} {% tab log-aggregation Kubernetes %} @@ -251,7 +251,7 @@ You can also forward the access logs to a collector (such as logstash) that can ### Access Log Format -`Kuma` gives you full control over the format of access logs. +{{site.mesh_product_name}} gives you full control over the format of access logs. The shape of a single log record is defined by a template string that uses [command operators](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#command-operators) to extract and format data about a `TCP` connection or an `HTTP` request. @@ -266,7 +266,7 @@ where `%START_TIME%` and `%KUMA_SOURCE_SERVICE%` are examples of available _comm A complete set of supported _command operators_ consists of: 1. All _command operators_ [supported by Envoy](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#command-operators) -2. _Command operators_ unique to `Kuma` +2. _Command operators_ unique to {{site.mesh_product_name}} The latter include: @@ -284,7 +284,7 @@ All access log _command operators_ are valid to use with both `TCP` and `HTTP` t If a _command operator_ is specific to `HTTP` traffic, such as `%REQ(X?Y):Z%` or `%RESP(X?Y):Z%`, it will be replaced by a symbol "`-`" in case of `TCP` traffic. -Internally, `Kuma` [determines traffic protocol](/docs/{{ page.version }}/policies/protocol-support-in-kuma) based on the value of `kuma.io/protocol` tag on the `inbound` interface of a `destination` `Dataplane`. +Internally, {{site.mesh_product_name}} [determines traffic protocol](/docs/{{ page.version }}/policies/protocol-support-in-kuma) based on the value of `kuma.io/protocol` tag on the `inbound` interface of a `destination` `Dataplane`. The default format string for `TCP` traffic is: diff --git a/app/docs/1.5.x/policies/traffic-metrics.md b/app/docs/1.5.x/policies/traffic-metrics.md index b9e23d0dd..2f23989d5 100644 --- a/app/docs/1.5.x/policies/traffic-metrics.md +++ b/app/docs/1.5.x/policies/traffic-metrics.md @@ -98,7 +98,7 @@ By default all available metrics are returned. {% tabs override-prometheus useUrlFragment=false %} {% tab override-prometheus Kubernetes %} -To override `Mesh`-wide defaults for a particular `Pod`, use `Kuma`-specific annotations: +To override `Mesh`-wide defaults for a particular `Pod`, use {{site.mesh_product_name}}-specific annotations: * `prometheus.metrics.kuma.io/port` - to override `Mesh`-wide default port * `prometheus.metrics.kuma.io/path` - to override `Mesh`-wide default path diff --git a/app/docs/1.6.x/documentation/fine-tuning.md b/app/docs/1.6.x/documentation/fine-tuning.md index bbd8e37d4..8e2a7da20 100644 --- a/app/docs/1.6.x/documentation/fine-tuning.md +++ b/app/docs/1.6.x/documentation/fine-tuning.md @@ -17,7 +17,7 @@ Follow the [transparent proxying](/docs/{{ page.version }}/networking/transparen ## Postgres -If you choose `Postgres` as a configuration store for `Kuma` on Universal, +If you choose `Postgres` as a configuration store for {{site.mesh_product_name}} on Universal, please be aware of the following key settings that affect performance of Kuma Control Plane. * `KUMA_STORE_POSTGRES_CONNECTION_TIMEOUT` : connection timeout to the Postgres database (default: 5s) @@ -142,4 +142,4 @@ kuma-dp run \ ``` {% endtab %} -{% endtabs %} \ No newline at end of file +{% endtabs %} diff --git a/app/docs/1.6.x/explore/cli.md b/app/docs/1.6.x/explore/cli.md index 1547ca902..cc64ad24e 100644 --- a/app/docs/1.6.x/explore/cli.md +++ b/app/docs/1.6.x/explore/cli.md @@ -8,7 +8,7 @@ Kuma ships in a bundle that includes a few executables: * `kuma-dp`: this is the Kuma data plane proxy executable that - under the hood - invokes `envoy`. * `envoy`: this is the Envoy executable that we bundle for convenience into the archive. * `kumactl`: this is the the user CLI to interact with Kuma (`kuma-cp`) and its data. -* `kuma-prometheus-sd`: this is a helper tool that enables native integration between `Kuma` and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them. +* `kuma-prometheus-sd`: this is a helper tool that enables native integration between {{site.mesh_product_name}} and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them. * `kuma-tcp-echo`: this is a sample application that echos back the requests we are making, used for demo purposes. According to the [installation instructions](/install/), some of these executables are automatically executed as part of the installation workflow, while some other times you will have to execute them directly. diff --git a/app/docs/1.6.x/explore/overview.md b/app/docs/1.6.x/explore/overview.md index 27dcf76af..69bcbd120 100644 --- a/app/docs/1.6.x/explore/overview.md +++ b/app/docs/1.6.x/explore/overview.md @@ -27,7 +27,7 @@ Since Kuma bundles a data-plane in addition to the control-plane, we decided to * `kuma-dp`: this is the Kuma data-plane executable that - under the hood - invokes `envoy`. * `envoy`: this is the Envoy executable that we bundle for convenience into the archive. * `kumactl`: this is the the user CLI to interact with Kuma (`kuma-cp`) and its data. -* `kuma-prometheus-sd`: this is a helper tool that enables native integration between `Kuma` and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them. +* `kuma-prometheus-sd`: this is a helper tool that enables native integration between {{site.mesh_product_name}} and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them. * `kuma-tcp-echo`: this is a sample application that echos back the requests we are making, used for demo purposes. A minimal Kuma deployment involves one or more instances of the control-plane (`kuma-cp`), and one or more instances of the data-planes (`kuma-dp`) which will connect to the control-plane as soon as they startup. Kuma supports two modes: diff --git a/app/docs/1.6.x/policies/how-kuma-chooses-the-right-policy-to-apply.md b/app/docs/1.6.x/policies/how-kuma-chooses-the-right-policy-to-apply.md index 7352c37bc..8a9c668fd 100644 --- a/app/docs/1.6.x/policies/how-kuma-chooses-the-right-policy-to-apply.md +++ b/app/docs/1.6.x/policies/how-kuma-chooses-the-right-policy-to-apply.md @@ -38,7 +38,7 @@ conf: backend: splunk ``` -What does `Kuma` do when it encounters multiple matching policies? +What does {{site.mesh_product_name}} do when it encounters multiple matching policies? ## General rules diff --git a/app/docs/1.6.x/policies/protocol-support-in-kuma.md b/app/docs/1.6.x/policies/protocol-support-in-kuma.md index 891d85c74..f66755596 100644 --- a/app/docs/1.6.x/policies/protocol-support-in-kuma.md +++ b/app/docs/1.6.x/policies/protocol-support-in-kuma.md @@ -2,7 +2,7 @@ title: Protocol support in Kuma --- -At its core, `Kuma` distinguishes between the following major categories of traffic: `http`, `grpc`, `kafka` and opaque `tcp` traffic. +At its core, {{site.mesh_product_name}} distinguishes between the following major categories of traffic: `http`, `grpc`, `kafka` and opaque `tcp` traffic. For `http`, `grpc` and `kafka` traffic Kuma provides deep insights down to application-level transactions, in the latter `tcp` case the observability is limited to connection-level statistics. @@ -96,7 +96,7 @@ Note that in this case no advanced HTTP or GRPC statistics or logging are availa Kuma out of the box support's `Websocket` protocol. The service exposing `Websocket` should be marked as `tcp`. -As `Websockets` use pure `TCP` connections under the hood, your service have to be recognised by `Kuma` as the `TCP` one. It's also the default behavior for Kuma to assume the service's `inbound` interfaces are the TCP ones, so you don't have to do anything, but if you want to be explicit, you can configure your services exposing `Websocket` endpoints with `appProtocol` property. I.e.: +As `Websockets` use pure `TCP` connections under the hood, your service have to be recognised by {{site.mesh_product_name}} as the `TCP` one. It's also the default behavior for Kuma to assume the service's `inbound` interfaces are the TCP ones, so you don't have to do anything, but if you want to be explicit, you can configure your services exposing `Websocket` endpoints with `appProtocol` property. I.e.: {% tabs websocket-support useUrlFragment=false %} {% tab websocket-support Kubernetes %} diff --git a/app/docs/1.6.x/policies/traffic-log.md b/app/docs/1.6.x/policies/traffic-log.md index 8a0786f4b..edff9313a 100644 --- a/app/docs/1.6.x/policies/traffic-log.md +++ b/app/docs/1.6.x/policies/traffic-log.md @@ -6,7 +6,7 @@ With `TrafficLog` policy you can easily set up access logs on every data-plane i `TrafficLog` only logs outbound traffic. It doesn't log inbound traffic. -Configuring access logs in `Kuma` is a 3-step process: +Configuring access logs in {{site.mesh_product_name}} is a 3-step process: * [1. Add a logging backend](#add-a-logging-backend) * [2. Add a TrafficLog resource](#add-a-trafficlog-resource) @@ -159,7 +159,7 @@ When `backend ` field of a `TrafficLog` policy is omitted, the logs will be forw ## Log aggregation and visualisation -`Kuma` is presenting a simple solution to aggregate the **logs of your containers** and the **access logs of your data-planes**. +{{site.mesh_product_name}} is presenting a simple solution to aggregate the **logs of your containers** and the **access logs of your data-planes**. {% tabs log-aggregation useUrlFragment=false %} {% tab log-aggregation Kubernetes %} @@ -256,7 +256,7 @@ You can also forward the access logs to a collector (such as logstash) that can ### Access Log Format -`Kuma` gives you full control over the format of access logs. +{{site.mesh_product_name}} gives you full control over the format of access logs. The shape of a single log record is defined by a template string that uses [command operators](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#command-operators) to extract and format data about a `TCP` connection or an `HTTP` request. @@ -271,7 +271,7 @@ where `%START_TIME%` and `%KUMA_SOURCE_SERVICE%` are examples of available _comm A complete set of supported _command operators_ consists of: 1. All _command operators_ [supported by Envoy](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#command-operators) -2. _Command operators_ unique to `Kuma` +2. _Command operators_ unique to {{site.mesh_product_name}} The latter include: @@ -289,7 +289,7 @@ All access log _command operators_ are valid to use with both `TCP` and `HTTP` t If a _command operator_ is specific to `HTTP` traffic, such as `%REQ(X?Y):Z%` or `%RESP(X?Y):Z%`, it will be replaced by a symbol "`-`" in case of `TCP` traffic. -Internally, `Kuma` [determines traffic protocol](/docs/{{ page.version }}/policies/protocol-support-in-kuma) based on the value of `kuma.io/protocol` tag on the `inbound` interface of a `destination` `Dataplane`. +Internally, {{site.mesh_product_name}} [determines traffic protocol](/docs/{{ page.version }}/policies/protocol-support-in-kuma) based on the value of `kuma.io/protocol` tag on the `inbound` interface of a `destination` `Dataplane`. The default format string for `TCP` traffic is: diff --git a/app/docs/1.6.x/policies/traffic-metrics.md b/app/docs/1.6.x/policies/traffic-metrics.md index 455515e63..00829dc22 100644 --- a/app/docs/1.6.x/policies/traffic-metrics.md +++ b/app/docs/1.6.x/policies/traffic-metrics.md @@ -98,7 +98,7 @@ By default all available metrics are returned. {% tabs override-prometheus useUrlFragment=false %} {% tab override-prometheus Kubernetes %} -To override `Mesh`-wide defaults for a particular `Pod`, use `Kuma`-specific annotations: +To override `Mesh`-wide defaults for a particular `Pod`, use {{site.mesh_product_name}}-specific annotations: * `prometheus.metrics.kuma.io/port` - to override `Mesh`-wide default port * `prometheus.metrics.kuma.io/path` - to override `Mesh`-wide default path diff --git a/app/docs/1.7.x/documentation/fine-tuning.md b/app/docs/1.7.x/documentation/fine-tuning.md index bbd8e37d4..8e2a7da20 100644 --- a/app/docs/1.7.x/documentation/fine-tuning.md +++ b/app/docs/1.7.x/documentation/fine-tuning.md @@ -17,7 +17,7 @@ Follow the [transparent proxying](/docs/{{ page.version }}/networking/transparen ## Postgres -If you choose `Postgres` as a configuration store for `Kuma` on Universal, +If you choose `Postgres` as a configuration store for {{site.mesh_product_name}} on Universal, please be aware of the following key settings that affect performance of Kuma Control Plane. * `KUMA_STORE_POSTGRES_CONNECTION_TIMEOUT` : connection timeout to the Postgres database (default: 5s) @@ -142,4 +142,4 @@ kuma-dp run \ ``` {% endtab %} -{% endtabs %} \ No newline at end of file +{% endtabs %} diff --git a/app/docs/1.7.x/explore/cli.md b/app/docs/1.7.x/explore/cli.md index 1823088fa..a52d72179 100644 --- a/app/docs/1.7.x/explore/cli.md +++ b/app/docs/1.7.x/explore/cli.md @@ -8,7 +8,7 @@ Kuma ships in a bundle that includes a few executables: * `kuma-dp`: this is the Kuma data plane proxy executable that - under the hood - invokes `envoy`. * `envoy`: this is the Envoy executable that we bundle for convenience into the archive. * `kumactl`: this is the the user CLI to interact with Kuma (`kuma-cp`) and its data. -* `kuma-prometheus-sd`: this is a helper tool that enables native integration between `Kuma` and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them. +* `kuma-prometheus-sd`: this is a helper tool that enables native integration between {{site.mesh_product_name}} and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them. * `kuma-tcp-echo`: this is a sample application that echos back the requests we are making, used for demo purposes. According to the [installation instructions](/install/), some of these executables are automatically executed as part of the installation workflow, while some other times you will have to execute them directly. diff --git a/app/docs/1.7.x/explore/overview.md b/app/docs/1.7.x/explore/overview.md index 27dcf76af..69bcbd120 100644 --- a/app/docs/1.7.x/explore/overview.md +++ b/app/docs/1.7.x/explore/overview.md @@ -27,7 +27,7 @@ Since Kuma bundles a data-plane in addition to the control-plane, we decided to * `kuma-dp`: this is the Kuma data-plane executable that - under the hood - invokes `envoy`. * `envoy`: this is the Envoy executable that we bundle for convenience into the archive. * `kumactl`: this is the the user CLI to interact with Kuma (`kuma-cp`) and its data. -* `kuma-prometheus-sd`: this is a helper tool that enables native integration between `Kuma` and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them. +* `kuma-prometheus-sd`: this is a helper tool that enables native integration between {{site.mesh_product_name}} and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them. * `kuma-tcp-echo`: this is a sample application that echos back the requests we are making, used for demo purposes. A minimal Kuma deployment involves one or more instances of the control-plane (`kuma-cp`), and one or more instances of the data-planes (`kuma-dp`) which will connect to the control-plane as soon as they startup. Kuma supports two modes: diff --git a/app/docs/1.7.x/policies/how-kuma-chooses-the-right-policy-to-apply.md b/app/docs/1.7.x/policies/how-kuma-chooses-the-right-policy-to-apply.md index 7352c37bc..8a9c668fd 100644 --- a/app/docs/1.7.x/policies/how-kuma-chooses-the-right-policy-to-apply.md +++ b/app/docs/1.7.x/policies/how-kuma-chooses-the-right-policy-to-apply.md @@ -38,7 +38,7 @@ conf: backend: splunk ``` -What does `Kuma` do when it encounters multiple matching policies? +What does {{site.mesh_product_name}} do when it encounters multiple matching policies? ## General rules diff --git a/app/docs/1.7.x/policies/protocol-support-in-kuma.md b/app/docs/1.7.x/policies/protocol-support-in-kuma.md index 891d85c74..f66755596 100644 --- a/app/docs/1.7.x/policies/protocol-support-in-kuma.md +++ b/app/docs/1.7.x/policies/protocol-support-in-kuma.md @@ -2,7 +2,7 @@ title: Protocol support in Kuma --- -At its core, `Kuma` distinguishes between the following major categories of traffic: `http`, `grpc`, `kafka` and opaque `tcp` traffic. +At its core, {{site.mesh_product_name}} distinguishes between the following major categories of traffic: `http`, `grpc`, `kafka` and opaque `tcp` traffic. For `http`, `grpc` and `kafka` traffic Kuma provides deep insights down to application-level transactions, in the latter `tcp` case the observability is limited to connection-level statistics. @@ -96,7 +96,7 @@ Note that in this case no advanced HTTP or GRPC statistics or logging are availa Kuma out of the box support's `Websocket` protocol. The service exposing `Websocket` should be marked as `tcp`. -As `Websockets` use pure `TCP` connections under the hood, your service have to be recognised by `Kuma` as the `TCP` one. It's also the default behavior for Kuma to assume the service's `inbound` interfaces are the TCP ones, so you don't have to do anything, but if you want to be explicit, you can configure your services exposing `Websocket` endpoints with `appProtocol` property. I.e.: +As `Websockets` use pure `TCP` connections under the hood, your service have to be recognised by {{site.mesh_product_name}} as the `TCP` one. It's also the default behavior for Kuma to assume the service's `inbound` interfaces are the TCP ones, so you don't have to do anything, but if you want to be explicit, you can configure your services exposing `Websocket` endpoints with `appProtocol` property. I.e.: {% tabs websocket-support useUrlFragment=false %} {% tab websocket-support Kubernetes %} diff --git a/app/docs/1.8.x/documentation/configuration.md b/app/docs/1.8.x/documentation/configuration.md index 13638fb67..0bb355766 100644 --- a/app/docs/1.8.x/documentation/configuration.md +++ b/app/docs/1.8.x/documentation/configuration.md @@ -52,7 +52,7 @@ helm install -f values.yaml {{ site.mesh_helm_install_name }} {{ site.mesh_helm_ If you have a lot of configuration you can just write them all in a YAML file and use: ```shell -helm install {{ site.mesh_helm_install_name }} {{ site.mesh_helm_repo }} --set-file controlPlace.config=cp-conf.yaml +helm install {{ site.mesh_helm_install_name }} {{ site.mesh_helm_repo }} --set-file {{set_flag_values_prefix}}controlPlane.config=cp-conf.yaml ``` The value of the configmap `{{site.mesh_cp_name}}-config` is now the content of `cp-conf.yaml`. diff --git a/app/docs/1.8.x/documentation/fine-tuning.md b/app/docs/1.8.x/documentation/fine-tuning.md index bbd8e37d4..8e2a7da20 100644 --- a/app/docs/1.8.x/documentation/fine-tuning.md +++ b/app/docs/1.8.x/documentation/fine-tuning.md @@ -17,7 +17,7 @@ Follow the [transparent proxying](/docs/{{ page.version }}/networking/transparen ## Postgres -If you choose `Postgres` as a configuration store for `Kuma` on Universal, +If you choose `Postgres` as a configuration store for {{site.mesh_product_name}} on Universal, please be aware of the following key settings that affect performance of Kuma Control Plane. * `KUMA_STORE_POSTGRES_CONNECTION_TIMEOUT` : connection timeout to the Postgres database (default: 5s) @@ -142,4 +142,4 @@ kuma-dp run \ ``` {% endtab %} -{% endtabs %} \ No newline at end of file +{% endtabs %} diff --git a/app/docs/1.8.x/explore/cli.md b/app/docs/1.8.x/explore/cli.md index f81966bd6..bbd799803 100644 --- a/app/docs/1.8.x/explore/cli.md +++ b/app/docs/1.8.x/explore/cli.md @@ -8,7 +8,7 @@ Kuma ships in a bundle that includes a few executables: * `kuma-dp`: this is the Kuma data plane proxy executable that - under the hood - invokes `envoy`. * `envoy`: this is the Envoy executable that we bundle for convenience into the archive. * `kumactl`: this is the the user CLI to interact with Kuma (`kuma-cp`) and its data. -* `kuma-prometheus-sd`: this is a helper tool that enables native integration between `Kuma` and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them. +* `kuma-prometheus-sd`: this is a helper tool that enables native integration between {{site.mesh_product_name}} and `Prometheus`. Thanks to it, `Prometheus` will be able to automatically find all dataplanes in your Mesh and scrape metrics out of them. * `kuma-tcp-echo`: this is a sample application that echos back the requests we are making, used for demo purposes. According to the [installation instructions](/install/), some of these executables are automatically executed as part of the installation workflow, while some other times you will have to execute them directly. diff --git a/app/docs/1.8.x/policies/how-kuma-chooses-the-right-policy-to-apply.md b/app/docs/1.8.x/policies/how-kuma-chooses-the-right-policy-to-apply.md index 7352c37bc..8a9c668fd 100644 --- a/app/docs/1.8.x/policies/how-kuma-chooses-the-right-policy-to-apply.md +++ b/app/docs/1.8.x/policies/how-kuma-chooses-the-right-policy-to-apply.md @@ -38,7 +38,7 @@ conf: backend: splunk ``` -What does `Kuma` do when it encounters multiple matching policies? +What does {{site.mesh_product_name}} do when it encounters multiple matching policies? ## General rules diff --git a/app/docs/1.8.x/policies/protocol-support-in-kuma.md b/app/docs/1.8.x/policies/protocol-support-in-kuma.md index 891d85c74..f66755596 100644 --- a/app/docs/1.8.x/policies/protocol-support-in-kuma.md +++ b/app/docs/1.8.x/policies/protocol-support-in-kuma.md @@ -2,7 +2,7 @@ title: Protocol support in Kuma --- -At its core, `Kuma` distinguishes between the following major categories of traffic: `http`, `grpc`, `kafka` and opaque `tcp` traffic. +At its core, {{site.mesh_product_name}} distinguishes between the following major categories of traffic: `http`, `grpc`, `kafka` and opaque `tcp` traffic. For `http`, `grpc` and `kafka` traffic Kuma provides deep insights down to application-level transactions, in the latter `tcp` case the observability is limited to connection-level statistics. @@ -96,7 +96,7 @@ Note that in this case no advanced HTTP or GRPC statistics or logging are availa Kuma out of the box support's `Websocket` protocol. The service exposing `Websocket` should be marked as `tcp`. -As `Websockets` use pure `TCP` connections under the hood, your service have to be recognised by `Kuma` as the `TCP` one. It's also the default behavior for Kuma to assume the service's `inbound` interfaces are the TCP ones, so you don't have to do anything, but if you want to be explicit, you can configure your services exposing `Websocket` endpoints with `appProtocol` property. I.e.: +As `Websockets` use pure `TCP` connections under the hood, your service have to be recognised by {{site.mesh_product_name}} as the `TCP` one. It's also the default behavior for Kuma to assume the service's `inbound` interfaces are the TCP ones, so you don't have to do anything, but if you want to be explicit, you can configure your services exposing `Websocket` endpoints with `appProtocol` property. I.e.: {% tabs websocket-support useUrlFragment=false %} {% tab websocket-support Kubernetes %} diff --git a/app/docs/2.0.x/deployments/multi-zone.md b/app/docs/2.0.x/deployments/multi-zone.md index 922983d12..0dec167c2 100644 --- a/app/docs/2.0.x/deployments/multi-zone.md +++ b/app/docs/2.0.x/deployments/multi-zone.md @@ -127,7 +127,7 @@ The global control plane on Kubernetes must reside on its own Kubernetes cluster 1. Set the `controlPlane.mode` value to `global` in the chart (`values.yaml`), then install. On the command line, run: ```sh - helm install {{ site.mesh_helm_install_name }} --create-namespace --namespace {{site.mesh_namespace}} --set controlPlane.mode=global {{ site.mesh_helm_repo }} + helm install {{ site.mesh_helm_install_name }} --create-namespace --namespace {{site.mesh_namespace}} --set {{set_flag_values_prefix}}controlPlane.mode=global {{ site.mesh_helm_repo }} ``` Or you can edit the chart and pass the file to the `helm install {{ site.mesh_helm_install_name }}` command. To get the default values, run: @@ -209,10 +209,10 @@ You need the following values to pass to each zone control plane setup: helm install {{ site.mesh_helm_install_name }} \ --create-namespace \ --namespace {{site.mesh_namespace}} \ - --set controlPlane.mode=zone \ - --set controlPlane.zone= \ - --set ingress.enabled=true \ - --set controlPlane.kdsGlobalAddress=grpcs://:5685 {{ site.mesh_helm_repo }} + --set {{set_flag_values_prefix}}controlPlane.mode=zone \ + --set {{set_flag_values_prefix}}controlPlane.zone= \ + --set {{set_flag_values_prefix}}ingress.enabled=true \ + --set {{set_flag_values_prefix}}controlPlane.kdsGlobalAddress=grpcs://:5685 {{ site.mesh_helm_repo }} ``` where `controlPlane.zone` is the same value for all zone control planes in the same zone. @@ -225,11 +225,11 @@ You need the following values to pass to each zone control plane setup: helm install {{ site.mesh_helm_install_name }} \ --create-namespace \ --namespace {{site.mesh_namespace}} \ - --set controlPlane.mode=zone \ - --set controlPlane.zone= \ - --set ingress.enabled=true \ - --set egress.enabled=true \ - --set controlPlane.kdsGlobalAddress=grpcs://:5685 {{ site.mesh_helm_repo }} + --set {{set_flag_values_prefix}}controlPlane.mode=zone \ + --set {{set_flag_values_prefix}}controlPlane.zone= \ + --set {{set_flag_values_prefix}}ingress.enabled=true \ + --set {{set_flag_values_prefix}}egress.enabled=true \ + --set {{set_flag_values_prefix}}controlPlane.kdsGlobalAddress=grpcs://:5685 {{ site.mesh_helm_repo }} ``` where `controlPlane.zone` is the same value for all zone control planes in the same zone. diff --git a/app/docs/2.0.x/documentation/configuration.md b/app/docs/2.0.x/documentation/configuration.md index 32c9fdad5..c8afd711f 100644 --- a/app/docs/2.0.x/documentation/configuration.md +++ b/app/docs/2.0.x/documentation/configuration.md @@ -31,8 +31,8 @@ kumactl install control plane \ When using `helm`, you can override the configuration with the `envVars` field. For example, to configure the refresh interval for configuration with the data plane proxy, specify: ```sh helm install \ - --set controlPlane.envVars.KUMA_XDS_SERVER_DATAPLANE_CONFIGURATION_REFRESH_INTERVAL=5s \ - --set controlPlane.envVars.KUMA_XDS_SERVER_DATAPLANE_STATUS_FLUSH_INTERVAL=5s \ + --set {{set_flag_values_prefix}}controlPlane.envVars.KUMA_XDS_SERVER_DATAPLANE_CONFIGURATION_REFRESH_INTERVAL=5s \ + --set {{set_flag_values_prefix}}controlPlane.envVars.KUMA_XDS_SERVER_DATAPLANE_STATUS_FLUSH_INTERVAL=5s \ {{ site.mesh_helm_install_name }} {{ site.mesh_helm_repo }} ``` @@ -52,7 +52,7 @@ helm install -f values.yaml {{ site.mesh_helm_install_name }} {{ site.mesh_helm_ If you have a lot of configuration you can just write them all in a YAML file and use: ```shell -helm install {{ site.mesh_helm_install_name }} {{ site.mesh_helm_repo }} --set-file controlPlace.config=cp-conf.yaml +helm install {{ site.mesh_helm_install_name }} {{ site.mesh_helm_repo }} --set-file {{set_flag_values_prefix}}controlPlane.config=cp-conf.yaml ``` The value of the configmap `{{site.mesh_cp_name}}-config` is now the content of `cp-conf.yaml`. diff --git a/app/docs/2.0.x/documentation/fine-tuning.md b/app/docs/2.0.x/documentation/fine-tuning.md index 2476d7bfc..385ac499b 100644 --- a/app/docs/2.0.x/documentation/fine-tuning.md +++ b/app/docs/2.0.x/documentation/fine-tuning.md @@ -17,7 +17,7 @@ Follow the [transparent proxying](/docs/{{ page.version }}/networking/transparen ## Postgres -If you choose `Postgres` as a configuration store for `Kuma` on Universal, +If you choose `Postgres` as a configuration store for {{site.mesh_product_name}} on Universal, please be aware of the following key settings that affect performance of {{site.mesh_product_name}} Control Plane. * `KUMA_STORE_POSTGRES_CONNECTION_TIMEOUT` : connection timeout to the Postgres database (default: 5s) @@ -142,4 +142,4 @@ kuma-dp run \ ``` {% endtab %} -{% endtabs %} \ No newline at end of file +{% endtabs %} diff --git a/app/docs/2.0.x/generated/cmd/kumactl/kumactl_install_control-plane.md b/app/docs/2.0.x/generated/cmd/kumactl/kumactl_install_control-plane.md index 9aec9d0fb..7ead1ad9b 100644 --- a/app/docs/2.0.x/generated/cmd/kumactl/kumactl_install_control-plane.md +++ b/app/docs/2.0.x/generated/cmd/kumactl/kumactl_install_control-plane.md @@ -55,7 +55,7 @@ kumactl install control-plane [flags] --mode string kuma cp modes: one of standalone|zone|global (default "standalone") --namespace string namespace to install Kuma Control Plane to (default "kuma-system") --registry string registry for all images (default "docker.io/kumahq") - --set helm template --set ... set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2), This is similar to helm template --set ... to use set-file or set-string just use helm instead + --set {{set_flag_values_prefix}}helm template --set ... set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2), This is similar to helm template --set ... to use set-file or set-string just use helm instead --tls-api-server-client-certs-secret string Secret that contains list of .pem certificates that can access admin endpoints of Kuma API on HTTPS --tls-api-server-secret string Secret that contains tls.crt, tls.key for protecting Kuma API on HTTPS --tls-general-ca-bundle string Base64 encoded CA certificate (the same as in controlPlane.tls.general.secret#ca.crt) diff --git a/app/docs/2.0.x/policies/how-kuma-chooses-the-right-policy-to-apply.md b/app/docs/2.0.x/policies/how-kuma-chooses-the-right-policy-to-apply.md index 8dcc9ef34..4f76f828f 100644 --- a/app/docs/2.0.x/policies/how-kuma-chooses-the-right-policy-to-apply.md +++ b/app/docs/2.0.x/policies/how-kuma-chooses-the-right-policy-to-apply.md @@ -43,7 +43,7 @@ conf: backend: splunk ``` -What does `Kuma` do when it encounters multiple matching policies? +What does {{site.mesh_product_name}} do when it encounters multiple matching policies? ## General rules diff --git a/app/docs/2.0.x/policies/protocol-support-in-kuma.md b/app/docs/2.0.x/policies/protocol-support-in-kuma.md index 33050d9b4..780c34038 100644 --- a/app/docs/2.0.x/policies/protocol-support-in-kuma.md +++ b/app/docs/2.0.x/policies/protocol-support-in-kuma.md @@ -2,7 +2,7 @@ title: Protocol support in Kuma --- -At its core, `Kuma` distinguishes between the following major categories of traffic: `http`, `grpc`, `kafka` and opaque `tcp` traffic. +At its core, {{site.mesh_product_name}} distinguishes between the following major categories of traffic: `http`, `grpc`, `kafka` and opaque `tcp` traffic. For `http`, `grpc` and `kafka` traffic {{site.mesh_product_name}} provides deep insights down to application-level transactions, in the latter `tcp` case the observability is limited to connection-level statistics. @@ -96,7 +96,7 @@ Note that in this case no advanced HTTP or GRPC statistics or logging are availa {{site.mesh_product_name}} out of the box support's `Websocket` protocol. The service exposing `Websocket` should be marked as `tcp`. -As `Websockets` use pure `TCP` connections under the hood, your service have to be recognised by `Kuma` as the `TCP` one. It's also the default behavior for {{site.mesh_product_name}} to assume the service's `inbound` interfaces are the TCP ones, so you don't have to do anything, but if you want to be explicit, you can configure your services exposing `Websocket` endpoints with `appProtocol` property. I.e.: +As `Websockets` use pure `TCP` connections under the hood, your service have to be recognised by {{site.mesh_product_name}} as the `TCP` one. It's also the default behavior for {{site.mesh_product_name}} to assume the service's `inbound` interfaces are the TCP ones, so you don't have to do anything, but if you want to be explicit, you can configure your services exposing `Websocket` endpoints with `appProtocol` property. I.e.: {% tabs websocket-support useUrlFragment=false %} {% tab websocket-support Kubernetes %} diff --git a/app/docs/2.0.x/policies/traffic-metrics.md b/app/docs/2.0.x/policies/traffic-metrics.md index 0dab1a80b..b5c974abf 100644 --- a/app/docs/2.0.x/policies/traffic-metrics.md +++ b/app/docs/2.0.x/policies/traffic-metrics.md @@ -9,7 +9,7 @@ You can add metrics to a mesh configuration, or to an individual data plane prox {{site.mesh_product_name}} provides full integration with Prometheus: * Each proxy can expose its metrics in [Prometheus format](https://prometheus.io/docs/instrumenting/exposition_formats/#text-based-format). -* Because metrics are part of the mesh configuration, Kuma exposes an API called the monitoring assignment service (MADS) which exposes every proxy in the mesh. +* Because metrics are part of the mesh configuration, {{site.mesh_product_name}} exposes an API called the monitoring assignment service (MADS) which exposes every proxy in the mesh. To collect metrics from {{site.mesh_product_name}}, you need to expose metrics from proxies and applications. diff --git a/app/docs/2.0.x/security/certificates.md b/app/docs/2.0.x/security/certificates.md index c6a985d01..5dd75df27 100644 --- a/app/docs/2.0.x/security/certificates.md +++ b/app/docs/2.0.x/security/certificates.md @@ -89,8 +89,8 @@ kubectl create secret generic general-tls-certs -n \ Point to this secret when installing {{site.mesh_product_name}}: ```sh helm install --create-namespace --namespace {{mesh_helm_install_name}} {{mesh_helm_repo}} \ - --set controlPlane.tls.general.secretName=general-tls-certs \ - --set controlPlane.tls.general.caBundle=$(cat /tmp/ca.crt | base64) + --set {{set_flag_values_prefix}}controlPlane.tls.general.secretName=general-tls-certs \ + --set {{set_flag_values_prefix}}controlPlane.tls.general.caBundle=$(cat /tmp/ca.crt | base64) ``` The data plane proxy Injector in the control plane automatically provides the CA to the {{site.mesh_product_name}} DP sidecar @@ -221,7 +221,7 @@ kubectl create secret tls api-server-tls -n \ Point to this secret when installing {{site.mesh_product_name}}: ```sh helm install --create-namespace --namespace {{mesh_helm_install_name}} {{mesh_helm_repo}} \ - --set controlPlane.tls.apiServer.secretName=api-server-tls + --set {{set_flag_values_prefix}}controlPlane.tls.apiServer.secretName=api-server-tls ``` {% endtab %} @@ -310,7 +310,7 @@ kubectl create secret tls kds-server-tls -n \ Point to this secret when installing {{site.mesh_product_name}}: ```sh helm install --create-namespace --namespace {{mesh_helm_install_name}} {{mesh_helm_repo}} \ - --set controlPlane.tls.kdsGlobalServer.secretName=kds-server-tls + --set {{set_flag_values_prefix}}controlPlane.tls.kdsGlobalServer.secretName=kds-server-tls ``` {% endtab %} @@ -352,7 +352,7 @@ kubectl create secret generic kds-ca-certs -n \ Point to this secret when installing {{site.mesh_product_name}}: ```sh helm install --create-namespace --namespace {{mesh_helm_install_name}} {{mesh_helm_repo}} \ - --set controlPlane.tls.kdsZoneClient.secretName=kds-ca-certs + --set {{set_flag_values_prefix}}controlPlane.tls.kdsZoneClient.secretName=kds-ca-certs ``` {% endtab %}