Originally posted by @bdecoste in kumahq/kuma#1948

Summary

Links to Listeners, Clusters, etc are broken here: https://kuma.io/docs/1.1.4/policies/proxy-template/

Feedback from the community

Ryan Collins
that's super hard to find in the docs and DataPlane does not make any mention of it

• We need to put reference to Protocol page in more places.
• Protocol page on the left should be more visible.
• We could add some help in the GUI ?

Several of the documentation pages do not provide full examples of the policy/object specification. Since these specifications do not appear to be publicly documented elsewhere (barring someone manually reviewing the code), the Kuma documentation should be updated to include full examples of the specification for all policies/objects.

As of 28 June, the following policies/objects did not appear to provide full examples (if the examples provided are full examples, it is not made clear to the reader/viewer):

• Mesh
• Traffic Permissions
• Traffic Metrics
• Traffic Trace
• Fault Injection
• Health Check
• Proxy Template (but I can understand why this one wouldn't)
• External Service
• Retry
• Timeout

In some cases (like Rate Limit), it appears that we document some of the fields outside of an example, which is fine for now. Ultimately, though, we should strive for consistency in how we document and present this information to Kuma users.

From discussions in the community, the interest to running Kuma in Universal or Hybrid mode is very big. We lack best practices examples of: systemd, Docker, Docker Compose. With the advancements in Kuma, we now have various deployment scenarios which we may need to go through in a systematic and practical manner.

On several locations in the docs and blogs, it's stated (taken from https://kuma.io/blog/2020/multi-cluster-cloud/):

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 (opens new window) to configure Kuma policies like Traffic Route (opens new window) to determine the behavior of cross-zone traffic (blue/green or canary across different zones, weighted traffic, as well as traffic shifting).

With link to TrafficRoute (just as an example):
https://kuma.io/docs/1.0.6/policies/traffic-route/#load-balancer-types

But I can't find any explanation about how to actually do the cross-cluster routing. Imagine a global CP acting as Ingress, forwarding requests to multiple clusters in different datacenters. How is this possible?

Summary

• I'd like to run dev server inside a Docker container (instead of running it on a host machine)
• so, I start a container with docker run -ti -p 8080:8080 -v ${PWD}:/source circleci/node bash
• however, when I run yarn docs:dev inside it, I can't access http://localhost:8080 from the host (apparently, dev server is started on 127.0.0.1:8080 instead of 0.0.0.0:8080, which makes it inaccessible through standard docker run -p 8080:8080)

Add annotation that to modify HTTP filter you need to first configure dataplane with protocol HTTP

Originally posted by @bdecoste in kumahq/kuma#1949

Summary

Doc here is now outdated and broken. Latest envoy does not support v2: https://kuma.io/docs/1.1.4/policies/proxy-template/#examples

'@type': type.googleapis.com/envoy.config.filter.http.lua.v2.Lua

needs to be

'@type': type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua

Also, the inline_code is also broken:
[2021-05-05 16:23:17.043][16353][info][lua] [source/extensions/filters/http/lua/lua_filter.cc:175] envoy_on_response() function not found. Lua filter will not hook responses

Steps To Reproduce

[2021-05-05 16:18:40.952][16353][warning][misc] [source/common/protobuf/utility.cc:294] Configuration does not parse cleanly as v3. v2 configuration is deprecated and will be removed from Envoy at the start of Q1 2021: envoy.config.filter.http.lua.v2.Lua
[2021-05-05 16:18:40.965][16353][warning][config] [source/common/config/grpc_subscription_impl.cc:107] gRPC config for type.googleapis.com/envoy.config.listener.v3.Listener rejected: Error adding/updating listener(s) outbound:240.0.0.0:80: The v2 xDS major version is deprecated and disabled by default. Support for v2 will be removed from Envoy at the start of Q1 2021. You may make use of v2 in Q4 2020 by following the advice in https://www.envoyproxy.io/docs/envoy/latest/faq/api/transition. (envoy.config.filter.http.lua.v2.Lua)
outbound:240.0.0.1:80: The v2 xDS major version is deprecated and disabled by default. Support for v2 will be removed from Envoy at the start of Q1 2021. You may make use of v2 in Q4 2020 by following the advice in https://www.envoyproxy.io/docs/envoy/latest/faq/api/transition. (envoy.config.filter.http.lua.v2.Lua)
outbound:240.0.0.4:80: The v2 xDS major version is deprecated and disabled by default. Support for v2 will be removed from Envoy at the start of Q1 2021. You may make use of v2 in Q4 2020 by following the advice in https://www.envoyproxy.io/docs/envoy/latest/faq/api/transition. (envoy.config.filter.http.lua.v2.Lua)
outbound:240.0.0.3:80: The v2 xDS major version is deprecated and disabled by default. Support for v2 will be removed from Envoy at the start of Q1 2021. You may make use of v2 in Q4 2020 by following the advice in https://www.envoyproxy.io/docs/envoy/latest/faq/api/transition. (envoy.config.filter.http.lua.v2.Lua)
outbound:240.0.0.6:80: The v2 xDS major version is deprecated and disabled by default. Support for v2 will be removed from Envoy at the start of Q1 2021. You may make use of v2 in Q4 2020 by following the advice in https://www.envoyproxy.io/docs/envoy/latest/faq/api/transition. (envoy.config.filter.http.lua.v2.Lua)

• we copy all labels from Pod
• we add service tag based on the matched Service object
• we add protocol tag based on service.kuma.io/protocol annotation

We should make clear to the users that mesh is a higher-level concept than namespace. Meaning - you can have one mesh across multiple namespaces.
Also add a note that when Kuma applies policies, it fetches them from all the namespaces.

The file that is passed to the kuma-dp --dataplane-file option is a mustache template that can be expanded with variables taken from the --dataplane-var.

It would be great if this was documented, possibly with examples about how it can be useful for different deploments, e.g. the use case in examples/ecs/workload.yaml.

The header says:
https://kuma.io/docs/0.5.0/policies/traffic-trace/#add-a-tracking-backend

But all the other references to what is being added refer to it as "tracing backend" which is confusing.

You can parametrize resource for kumactl like this:

mtls:
  backends:
  - name: vault-1
    type: {{ caType }}
    dpCert:
      rotation:
        expiration: 10h
name: default
type: Mesh

kumactl apply -f ~/res/mesh.yaml -v caType=builtin

I see no doc for this feature

With each version release of Kuma, the Helm install instructions should specify that is the version being installed. With any Helm install documentation version you are always getting the latest version of Kuma.

From:
$ helm install --create-namespace --namespace kuma-system kuma kuma/kuma

To:

$ helm install --version x.y.z --create-namespace --namespace kuma-system kuma kuma/kuma

The helm install command specifies the version of the chart, not the version of Kuma, so that needs to be taken into consideration for each version release.

Originally posted by @bdecoste in kumahq/kuma#1810

Summary

The link at used to generate Dataplane Token is bad: https://kuma.io/docs/1.1.2/documentation/cli/#kumactl

Issue comes up regularly, most recently in comments on PR #504

I noticed that kumactl generates a markdown HELP.md, which seems pretty useful. Cobra has built-in support for generating markdown documentation.

It would be pretty nice to generate reference pages for all the commands that ship as part of Kuma and include it in the website as reference material.

there is a link to Tag page in https://github.com/kumahq/kuma-website/blame/master/docs/docs/0.7.2/policies/traffic-permissions.md#L58 but Tag page https://kuma.io/docs/0.7.2/documentation/tags/ is empty.

Until we refactor Dataplane of type Ingress to cluster-scoped ZoneIngress. It would be great to mention somewhere that you have to have 1 Ingress per zone, not per mesh

The entire page is now only partly copyedited. Needs a full rework and thorough technical review for all the bits that haven't been touched in a long time.

In https://kuma.io/docs/1.1.6/documentation/dps-and-data-model/#ingress, creating an ingress dataplane is described like this

The recommended way to deploy an Ingress dataplane in Kubernetes is to use kumactl, or the Helm charts as specified in multi-zone. It works as a separate deployment of a single-container pod.

What are the specific kumactl commands that I need to use to create an ingress Dataplane? It's not obvious from the kumactl help or from the source.

At this page: https://kuma.io/docs/1.2.3/policies/traffic-log/#add-a-logging-backend

The yaml is not valid yaml

Recently I had a task to install Kuma in EKS cluster. I noticed that whether I have multi zone or standalone setup there are steps that are missing or hard to find in documentation.
For example, in Amazon EKS installation one has to make sure to install following:
1- Kuma DNS: to resolve the virtual IPs
2- Kong Ingress controller: it can be misleading, one may try to use Kuma Ingress, but that's only for the cross zone communication and for Kuma internals and can not be used as ingress controller. Thus we should install Kong Ingress (DB Less) otherwise after enabling MTLS all Amazon NLB's will fail due to mTLS cert checking for SAN of NLB...
3- For multi zone setup, Kuma Ingress is also required.
4- Ingress resource sample / template that will be required in this case to allow traffic from outside of EKS cluster to micro services.
I can contribute to create the initial draft of what needs to be installed / configured with some syntax.

The Kuma community page at https://kuma.io/community/ lets you subscribe to the the calendar (I guess that's what the email does?), but it would also be really useful if there was a link to the notes from the calls and the recordings of those calls.

Hey! When I go to the Kuma documentation and click on for example the CLI link in the left sidebar, site scrolls down but not to the CLI section. At least not every time.

To reproduce this bug go to the site and click on the links a few times. Try also the incognito window. I use Chrome Version 76.0.3809.132 (Official Build) (64-bit) and macOS Mojave Version 10.14.5

Take the example YAML from https://kuma.io/docs/1.2.3/policies/traffic-route/#usage and apply it with kumactl:

jpeach@greenling:~/upstream/konghq/kuma$ kumactl apply -f /tmp/t
Error: YAML contains invalid resource: error converting YAML to JSON: yaml: line 30: found unknown escape character
jpeach@greenling:~/upstream/konghq/kuma$ kumactl apply -f /tmp/t
Error: YAML contains invalid resource: error converting YAML to JSON: yaml: line 35: found unknown escape character

The problem is escapes pattern substitutions like "\2/instance/\1". Because of the double-quote, the YAML parser tries (and fails) to interpret this as an escape. This should be using single quotes.

Provide instruction that to disable mTLS you need to pass an empty string to enabledBackend or remove it from YAML.

TrafficLog can be used to log on stdout with path: /dev/stdout. Add this as a tip to docs

Summary

• formatting is broken in section 4. Done! of Ubuntu installation page (https://kuma.io/docs/0.2.2/installation/ubuntu/)

There is pretty good explanatory documentation describing what a Dataplane resource is and how it fits into the Kuma resource model, but I wasn't able to find an reference documentation. It would be helpful to have reference material describing all the available fields in this resource.

From kumahq/kuma#2691, document

• The kuma-dp --concurrency flag
• Kubernetes concurrency autotuning based on proxy container limits
• Overriding the autotuning with the kuma.io/sidecar-proxy-concurrency annotation

The current traffic permission docs for kubernetes just use service name to match which is incorrect. Need to update docs since on kuberenetes the service name changes to something like redis-master.kuma-demo.svc:6379

There are image differences between v0.4.0 and v0.5.0.

So some image links are broken in v0.5.0 docs as below:
https://github.com/Kong/kuma-website/search?q=diagram-02.jpg+OR+diagram-03.jpg+OR+diagram-06.jpg+OR+diagram-07.jpg+OR+diagram-10.jpg+OR+diagram-11.jpg+path%3A%2Fdocs%2Fdocs%2F0.5.0&unscoped_q=diagram-02.jpg+OR+diagram-03.jpg+OR+diagram-06.jpg+OR+diagram-07.jpg+OR+diagram-10.jpg+OR+diagram-11.jpg+path%3A%2Fdocs%2Fdocs%2F0.5.0

It would be good to fix this for kuma users.

Something has gone wrong on the tracing example https://kuma.io/docs/1.2.3/policies/traffic-trace/#add-jaeger-backend. Note that the Universal tab contains both Kubernetes and Universal YAML blocks

Recently out of the blue, I started getting build errors on Netlify:

After doing some digging, there seems to be a common recurring issue where builds will exceed the 15-minute cap that Netlify sets on build times. Because our latest builds are now slightly exceeding this number, they are failing.

To make things even more difficult, the build process works flawlessly on my local machine both with yarn docs:build and with netlify build (using Netlify's own CLI tool). In fact, the build time locally is about half of what Netlify's is.

I've published a Netlify community forum post to get help on the issue. The Netlify team should be able to increase our build limit to 30 minutes as a solution, but I'd also like to try and make the build pipeline a little more streamlined for the site.

This is something I can't take on by myself. I'm looking at Netlify's docs, and also looking at threads like this on the VuePress repository. There is also vuepress-next but I think it's in too early of the development cycle to consider moving to.

Steps to reproduce (Ubuntu)

1. Go to https://kuma.io/docs/0.1.2/installation/ubuntu/
2. Follow the Getting Started Guide and run

wget downloads.kuma.io/0.1.2/kuma-0.1.2-ubuntu.tar.gz

3. wget fails with an error

--2019-09-13 11:00:47--  http://downloads.kuma.io/0.1.2/kuma-0.1.2-ubuntu.tar.gz
Resolving downloads.kuma.io (downloads.kuma.io)... failed: nodename nor servname provided, or not known.
wget: unable to resolve host address <<downloads.kuma.io

Steps to reproduce (Debian)

1. Go to https://kuma.io/docs/0.1.2/installation/debian/
2. Click on You can download Kuma from here link
3. Broken URL https://kong.bintray.com/kuma/:kuma-0.1.2-debian.tar.gz is opened in a new tab

Resources HTTP API should have kuma.io/ prefix in tags

The locality-aware load balancing implementation in all releases of Kuma so far doesn't actually use these tags, so they have no effect whatsoever. We should remove them from the documentation.

The default deployment, generated by kumactl, comes with a replicaCount of 1 for kuma-cp. Although the documentation mentions, that the kuma-cp is horizontally scalable, the documentation lacks the information about a recommended setting for production use.

In the Community Slack, we had a discussion about this topic and it turned out that a quorum-able count (reads: 2/3, 3/5, 4/7, etc) seems to be the recommended option. Reference: https://kuma-mesh.slack.com/archives/CN2GN4HE1/p1615466512113300

Recommendations of this kind help people like me to get a good start with kuma ;)

Today we show all the versions, like:

• 0.7.0, 0.7.1, 0.8.0, 0.8.1

Change this so that we show only the latest minor for each major release, like:

• 0.7.x, 0.8.x

Summary

Kuma sidecar CPU and Memory requests and limits are global , this should configurable per service via annotations, something like
kuma.io/sidecar-cpu-request
kuma.io/sidecar-cpu-limit
kuma.io/sidecar-mem-request
kuma.io/sidecar-mem-limit

This will help services which can only scale vertically. If no annotation is provided may be it can default to global setting.

Right now, step four in the kubernetes docs is:

kumactl config control-planes add --name=XYZ --address=http://address.to.kuma:5681

without any additional information.

Need to add following:

1. kubectl port-forward .. or kubectl proxy to make the kuma-control-plane available to kumactl on the host
2. the use the cluster ip of kube-control-plane as the address.to.kuma

Kuma has better out-of-the-box metrics for investigating traffic than Istio, but it is difficult to understand what metrics are actually exposed by looking at Kuma's Metrics page. It would be nice to do something like Istio's Standard Metrics, where some key metrics are listed and briefly explained.

hi, I'm trying to use kuma-demo with universal mode following to https://kuma.io/docs/0.7.2/quickstart/universal/ .
I did step by step "1. Run the Marketplace application" -> "2. Enable Mutual TLS and Traffic Permissions" -> "3. Visualize Traffic Metrics" but when I try to see Grafana dashboard at http://192.168.33.80:3000 , Grafana dashboard itself is shown, but there is no metrics data. And also when I checked Prometheus dashboard at http://192.168.33.80:9090/targets , all targets are down with error message "read: connection reset by peer".

Then, I applied below Traffic Metric Policy following to https://github.com/kumahq/kuma-demo/blob/master/vagrant/README.md#traffic-metrics , Ican see metric data at Grafana dashboard.

$ cat <<EOF | kumactl apply -f -
type: Mesh
name: default
mtls:
  enabledBackend: ca-1
  backends:
  - name: ca-1
    type: builtin
metrics:
  enabledBackend: prometheus-1
  backends:
  - name: prometheus-1
    type: prometheus
    conf:
      skipMTLS: true
EOF

So, I think this doc https://kuma.io/docs/0.7.2/quickstart/universal/ causes misunderstanding. IMO it's better to replace with above manifest in "3. Visualize Traffic Metrics". How do you think?

My enviroment:

• OS: Ubuntu 18.04
• mode: Universal mode
• kuma version; 0.7.2

Summary

I am trying to create the kuma control plane on a GKE cluster by following the standalone instructions as detailed here although after everything has completed it seems kuma is stuck at creating the default mesh. The control plane logs indicates

with INFO defaults trying to create default Mesh repeating.

I have tried to creating a mesh manually by applying the follow with kubectl -f mesh.yml:

mesh.yml

apiVersion: kuma.io/v1alpha1
kind: Mesh
metadata:
  name: my-mesh
spec:
  mtls:
    enabledBackend: test
    backends:
      - name: test
        type: builtin
    enabled: true

but this resulted in the following error:

Error from server (InternalError): error when creating "test.yml": Internal error occurred: failed calling webhook "mesh.defaulter.kuma-admission.kuma.io": Post https://kuma-control-plane.kuma-system.svc:443/default-kuma-io-v1alpha1-mesh?timeout=30s: context deadline exceeded

Steps To Reproduce

1. Setup a GKE cluster using the following parameters

gcloud beta container clusters create test \
  --no-enable-basic-auth \
  --cluster-version "1.17.17-gke.1101" \
  --machine-type "n1-standard-2" \
  --image-type "COS" \
  --disk-type "pd-standard" \
  --disk-size "20" \
  --metadata disable-legacy-endpoints=true, \
  --service-account limited-gke-service-account \
  --max-pods-per-node "30" \
  --num-nodes "3" \
  --enable-stackdriver-kubernetes  \
  --enable-private-nodes \
  --master-ipv4-cidr "$MASTER_IPV4" \
  --enable-ip-alias \
  --default-max-pods-per-node "110" \
  --enable-autoscaling \
  --min-nodes "0" \
  --max-nodes "3" \
  --enable-network-policy \
  --enable-master-authorized-networks \
  --master-authorized-networks 0.0.0.0/0 \
  --addons HorizontalPodAutoscaling,HttpLoadBalancing \
  --enable-autoupgrade \
  --enable-autorepair \
  --enable-shielded-nodes

The limited-gke-service-account has a Kubernetes Engine Admin IAM role as well as the Metric Writer role.

2. Use the 1.1.1 release of kuma, and deploy the control plane as described here
3. Monitor the control plane logs and see the repeat logging of the default mesh trying to be created. When you access the UI you will also note that there isn't a default mesh displayed.
4. While this is occurring you may try and deploy the mesh.yml above to create the my-mesh mesh which should result in the following error: Error from server (InternalError): error when creating "test.yml": Internal error occurred: failed calling webhook "mesh.defaulter.kuma-admission.kuma.io": Post https://kuma-control-plane.kuma-system.svc:443/default-kuma-io-v1alpha1-mesh?timeout=30s: context deadline exceeded

Additional Details & Logs

• Version

Tested on both kuma 1.1.1 and 1.1.0

• Error logs

There doesn't seem to be any other logs indicating error besides the repeating of the trying to create default Mesh INFO entries

Update: leaving the control plane in this state after a while results in this error message:

ERROR mesh-insight-resyncer component terminated with an error {"generationID": 1, "error": "stop channel was closed", "errorVerbose": "stop channel was closed\ngithub.com/kumahq/kuma/pkg/events.(*reader).Recv\n\t/go/src/github.com/kumahq/kuma/pkg/events/eventbus.go:57\ngithub.com/kumahq/kuma/pkg/insights.(*resyncer).Start\n\t/go/src/github.com/kumahq/kuma/pkg/insights/resyncer.go:101\ngithub.com/kumahq/kuma/pkg/core/runtime/component.(*resilientComponent).Start.func1\n\t/go/src/github.com/kumahq/kuma/pkg/core/runtime/component/resilient.go:43\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1374"}

Although it could be due to GKE restarting the pod.

• Configuration

Default quick start, no custom changes.

• Platform and Operating System

GKE

• Installation Method (Helm, kumactl, AWS CloudFormation, etc.)

This occurs in the latest helm charts as well as with the kumactl client.

The download links for Kuma 1.2.3 are all kuma--foo, where they should be kuma-1.2.3-foo.

jpeach@greenling:~/upstream/konghq/kuma-website$ git grep kuma-- ./docs/docs/1.2.3/
docs/docs/1.2.3/installation/amazonlinux.md:or you can [download](https://download.konghq.com/mesh-alpine/kuma--centos-amd64.tar.gz) the distribution manually.
docs/docs/1.2.3/installation/centos.md:or you can [download](https://download.konghq.com/mesh-alpine/kuma--centos-amd64.tar.gz) the distribution manually.
docs/docs/1.2.3/installation/debian.md:or you can [download](https://download.konghq.com/mesh-alpine/kuma--debian-amd64.tar.gz) the distribution manually.
docs/docs/1.2.3/installation/docker.md:* [CentOS](https://download.konghq.com/mesh-alpine/kuma--centos-amd64.tar.gz)
docs/docs/1.2.3/installation/docker.md:* [RedHat](https://download.konghq.com/mesh-alpine/kuma--rhel-amd64.tar.gz)
docs/docs/1.2.3/installation/docker.md:* [Debian](https://download.konghq.com/mesh-alpine/kuma--debian-amd64.tar.gz)
docs/docs/1.2.3/installation/docker.md:* [Ubuntu](https://download.konghq.com/mesh-alpine/kuma--ubuntu-amd64.tar.gz)
docs/docs/1.2.3/installation/docker.md:* [macOS](https://download.konghq.com/mesh-alpine/kuma--darwin-amd64.tar.gz)
docs/docs/1.2.3/installation/eks.md:* [CentOS](https://download.konghq.com/mesh-alpine/kuma--centos-amd64.tar.gz)
docs/docs/1.2.3/installation/eks.md:* [RedHat](https://download.konghq.com/mesh-alpine/kuma--rhel-amd64.tar.gz)
docs/docs/1.2.3/installation/eks.md:* [Debian](https://download.konghq.com/mesh-alpine/kuma--debian-amd64.tar.gz)
docs/docs/1.2.3/installation/eks.md:* [Ubuntu](https://download.konghq.com/mesh-alpine/kuma--ubuntu-amd64.tar.gz)
docs/docs/1.2.3/installation/eks.md:* [macOS](https://download.konghq.com/mesh-alpine/kuma--darwin-amd64.tar.gz) or run `brew install kumactl`
docs/docs/1.2.3/installation/kubernetes.md:* [CentOS](https://download.konghq.com/mesh-alpine/kuma--centos-amd64.tar.gz)
docs/docs/1.2.3/installation/kubernetes.md:* [RedHat](https://download.konghq.com/mesh-alpine/kuma--rhel-amd64.tar.gz)
docs/docs/1.2.3/installation/kubernetes.md:* [Debian](https://download.konghq.com/mesh-alpine/kuma--debian-amd64.tar.gz)
docs/docs/1.2.3/installation/kubernetes.md:* [Ubuntu](https://download.konghq.com/mesh-alpine/kuma--ubuntu-amd64.tar.gz)
docs/docs/1.2.3/installation/kubernetes.md:* [macOS](https://download.konghq.com/mesh-alpine/kuma--darwin-amd64.tar.gz) or run `brew install kumactl`
docs/docs/1.2.3/installation/macos.md:* [Download Kuma](https://download.konghq.com/mesh-alpine/kuma--darwin-amd64.tar.gz)
docs/docs/1.2.3/installation/openshift.md:* [CentOS](https://download.konghq.com/mesh-alpine/kuma--centos-amd64.tar.gz)
docs/docs/1.2.3/installation/openshift.md:* [RedHat](https://download.konghq.com/mesh-alpine/kuma--rhel-amd64.tar.gz)
docs/docs/1.2.3/installation/openshift.md:* [Debian](https://download.konghq.com/mesh-alpine/kuma--debian-amd64.tar.gz)
docs/docs/1.2.3/installation/openshift.md:* [Ubuntu](https://download.konghq.com/mesh-alpine/kuma--ubuntu-amd64.tar.gz)
docs/docs/1.2.3/installation/openshift.md:* [macOS](https://download.konghq.com/mesh-alpine/kuma--darwin-amd64.tar.gz) or `brew install kumactl`
docs/docs/1.2.3/installation/redhat.md:or you can [download](https://download.konghq.com/mesh-alpine/kuma--rhel-amd64.tar.gz) the distribution manually.
docs/docs/1.2.3/installation/ubuntu.md:or you can [download](https://download.konghq.com/mesh-alpine/kuma--ubuntu-amd64.tar.gz) the distribution manually.

People not familiar with Grafana would take a while to figure what to do to search their loki traffic logs.
We should explain what to do.

This issue is pending resolution of this issue: kumahq/kuma#2689

Once this issue is resolved and "proper" locality-aware load balancing functionality has been implemented, we need to update the documentation for locality-aware load balancing.

This issue covers improving the explanation for the current implementation. Docs will be updated when the above issue is completed.