The other components
Storage has its own page, and so do ingress and logging. This page covers the remaining components in daily use — what each gives you, the first commands to reach for, and the one thing about each that is not obvious.
As on the two pages before it, the usage here is guidance for your assistance: BKE installs and upgrades these components at tested versions, and how you use them — labels, dashboards, autoscaling — is your own configuration to operate.
metrics-server
metrics-server collects how much CPU and memory every node and pod is actually using. Two things consume those figures:
kubectl top nodes
kubectl top pods -A --sort-by=memory
is the quick answer to “what is using this cluster”, and worth knowing before capacity questions become urgent — a node consistently near its memory is a node that will start evicting pods.
The second consumer is autoscaling: a HorizontalPodAutoscaler on one of your
applications reads its figures from metrics-server. Nothing needs configuring
for either; the component works from installation.
Kuma
Kuma is a service mesh: it puts a proxy beside each of your application’s pods and controls the traffic between them — encryption between services, retries, timeouts, and per-service traffic figures, all without changing application code.
Installing it changes nothing by itself, and that is deliberate. No proxy is added to any pod until you ask for one, so enabling the component is safe on a running cluster. Applications join the mesh one namespace at a time:
kubectl label namespace retail kuma.io/sidecar-injection=enabled
The proxy is added when a pod is created, so pods already running in that
namespace join as they are next restarted — a deploy, or
kubectl -n retail rollout restart deployment/<name>, brings them in.
Treat the mesh as an undertaking rather than a switch: start with one non-critical namespace, and consult Kuma’s own documentation for policies — mutual TLS, retries, timeouts — before enrolling anything that matters. A namespace can leave the mesh the same way it joined: remove the label and restart the workloads.
netdata
netdata is per-node monitoring with per-second resolution: CPU, memory, disks, network, containers, and the applications it recognises, each node collecting its own figures and streaming them to a parent inside the cluster.
The dashboard is not exposed outside the cluster by default. To look at it, forward the parent’s port to your own machine:
kubectl -n monitoring get svc
kubectl -n monitoring port-forward svc/<the parent service> 19999:19999
then open http://localhost:19999. Substitute the namespace your config.yaml
names.
If you use Netdata Cloud, the cloud.* settings on the config.yaml page
claim the cluster into your space there — and the claim token belongs in
/etc/bke/secrets.d/, not in config.yaml. One failure mode is worth
repeating from the Secrets page: a missing claim token is silent. netdata
runs, the dashboards work, and the cluster simply never appears in Netdata
Cloud — if you expected it there and it is absent, check that Secret first.
Certificates
cert-manager is covered where it is used: Ingress with Kong shows the issuer you create once and the two lines each application adds to get and renew a TLS certificate.
Raising a support ticket
Support is raised through the console, under Support. Response times are those of your support plan.
A ticket that names the following can usually be answered in one round rather than three:
-
The BKE version, from any node:
curl -sL https://bke.maml.uk/version.sh | sh - The exact text of the refusal or warning, pasted rather than summarised. Every refusal names its cause, and the wording identifies the check that produced it.
- What was run, on which node — the command, and whether the node is a control-plane member or a worker.
- What
check.shsays now, if the problem is an install or an upgrade — run it on the affected node and paste the failures.
The report apply.sh prints before --commit is safe to paste: it contains
object names and version numbers, never credentials.