Metrics Server

Metrics Server collects CPU and memory metrics from the kubelets and exposes them through the Kubernetes Metrics API. Edka installs the kubernetes-sigs Metrics Server Helm chart into kube-system with RBAC created. It is a required add-on.

1. CPU and memory metrics for all pods and nodes
2. Backs the Horizontal Pod Autoscaler (HPA)
3. Backs the Vertical Pod Autoscaler (VPA)
4. Serves kubectl top for pods and nodes

Features available

• Resource Metrics API exposed through the Kubernetes API server
• Metrics scraped from kubelets across every node
• RBAC created on install
• Runs in kube-system

How it fits in Edka

Metrics Server is a required add-on, and satellite clusters install it automatically alongside cert-manager and node-exporter. The rest of the platform reads from the Metrics API it serves. The Edka app view shows pod CPU and memory from it, and CPU autoscaling on a deployment depends on it.

Several apps in the catalog declare it as a required add-on and pull it in automatically:

• n8n and Buzz for pod metrics and optional CPU autoscaling
• Meilisearch and Plausible for resource usage in the app view
• Prometheus Stack, alongside cert-manager, letsencrypt-issuer, and node-exporter

Verifying it works

Once the add-on reports as installed, both commands return values rather than an error:

kubectl top nodes
kubectl top pods -A

If they report that metrics are not available, give the first scrape a moment to land. Metrics Server needs one scrape interval before it can answer.

What it does not do

Metrics Server holds only the most recent reading for each pod and node, in memory. It answers “what is this pod using now”, not “what did it use last Tuesday”. There is no query language and no retention.

For history, dashboards, and alerting, run Prometheus Stack, which scrapes and stores metrics over time. The two work side by side. Autoscaling reads from Metrics Server while Prometheus keeps the record.

Related docs

• Add-ons overview
• Observability