SYS.DOCS // DOCS

Workload Resources

The Resources tab in Clusters → Observability lists every workload in the cluster with its CPU and memory usage over the last 7 days, its current requests and limits, and the requests and limits Edka advises from that usage.

Usage covers every pod the workload ran in the window, including pods that were replaced by a rollout or a restart. A pod started an hour ago still gets advice from the full week of its Deployment, StatefulSet, DaemonSet, or CronJob.

Requirements

VictoriaMetrics installed from Observability → Settings. Without it the tab shows an Open Settings button instead of the table.
kube-state-metrics for OOM kills of pods that no longer exist. Edka installs it alongside VictoriaMetrics.

Find workloads to resize

Open Clusters → your cluster → Observability → Resources. You can also follow By workload from the Resource Pressure card on the Monitoring tab.
Pick a view:
- Your workloads shows your deployments, apps, databases, messaging, Actions runners, and anything else you run. This is the default.
- Platform shows what Edka installs to run the cluster: add-ons, observability services, gateways, and system components.
- All shows both.
Filter by finding: At risk, Over-provisioned, or No requests. Each filter shows how many workloads it matches.
Click a column header to sort by it. Click it again to reverse the order. The default order puts the most severe finding first.
Narrow the list with the namespace selector or the search field. Search matches workload, namespace, owner, pod, and container names.

The summary above the table shows the number of workloads, the CPU and memory requests of their running pods now and with every piece of advice applied, the CPU and memory the cluster’s nodes can schedule, and how many workloads are at risk.

Usage data refreshes every 5 minutes. Requests, limits, and owners are read from the cluster on every load.

Read the table

Each row is one workload. The line under its name shows who configures it and its namespace.

Column	Shows
Pods	Pods running now. Hover for the pods seen in the window and the confidence of the advice.
p95	95th percentile of usage. The bar under it shows usage as a share of the request, red above 100%.
Max / Peak	Highest CPU and memory usage in the window.
Request / Limit	The current value, and the advised value after the arrow when it differs.
Advice	The most severe finding for the workload.

Values are per pod. For a workload with several containers, the row adds up its containers. Click the arrow next to the name to see one row per container.

The request cells take the color of the finding: red for under-provisioned, amber for over-provisioned or a missing request, green when the request fits.

Findings

Finding	Meaning
OOMKilled	A container was killed for exceeding its memory limit in the last 7 days.
Under-provisioned	The request is below 90% of p95 usage.
CPU throttled	The CPU limit throttled the container in at least 10% of CPU periods.
Peak near limit	Peak usage reached 90% of the limit.
No CPU request / No memory request	The container has no request for that resource.
Over-provisioned	The request is more than 1.5 times the advised request.
Sized right	The request is within those bounds.
Not enough history	Less than an hour of usage is recorded, so there is no advice yet.
No usage data	No usage is recorded for the container.
Advice off	The workload opted out with the `edka.io/resource-advice` annotation.

The Advice column names the resource when the finding applies to one, for example Memory under-provisioned. The first four findings count as At risk and mark the row in red.

How the advice is calculated

Value	Advice
CPU request	p95 usage + 15%
Memory request	Peak usage + 15%
Memory limit	Peak usage + 30%
CPU limit	Peak usage + 50%, never below the current limit. Raised by 50% while the container is throttled. Only advised when the container already has a CPU limit.

After an OOM kill, the current memory limit counts as the peak, since usage could not go higher than the limit. Advice has a floor of 10m CPU and 16Mi memory, and rounds up to readable steps.

Confidence follows how much history exists: low under one day, medium under three days, high from three days on. Low-confidence advice can miss weekly patterns, such as weekend batch jobs.

Apply the advice

The actions at the end of each row depend on who configures the workload.

Edka deployments. Apply opens a dialog with each current and advised value. Apply and roll out saves them to the deployment settings and rolls out new pods. With autoscaling on, the autoscaler’s CPU and memory targets are a percentage of the request, so new requests also change when it adds replicas.
Apps. Apply opens the app’s Settings on the tab that holds its resource fields, with the advised values filled in. Review them and click Update App. Apply appears when the app has resource fields for the workload’s containers.
Everything else. The copy button copies the advised resources block as YAML, one block per container. Paste it into the Helm values, manifest, or GitOps repository the workload comes from. Rows for add-ons, databases, gateways, and other Edka resources link to the page where they are configured.

Click a workload’s name to open its newest pod on the Resources tab in Explorer.

Turn advice off for a workload

Some workloads are sized on purpose, such as JVM apps with a fixed heap or services kept large for load spikes. Add this annotation to the workload, or to its pod template, to turn advice off:

metadata:
    annotations:
        edka.io/resource-advice: ignore

The workload keeps its row with usage, requests, and limits, shows Advice off, and no longer counts toward findings, filters, or the advised totals. Set the annotation in the Helm values, manifest, or GitOps repository the workload comes from, so the next upgrade or sync keeps it. Remove it to turn advice back on.

Per-pod view in Explorer

Every pod in Explorer → Workloads → Pods has a Resources tab with the same usage and advice for that pod’s workload, one row per container and resource. All workloads on that tab opens this dashboard filtered to the pod’s namespace.

Below the table, two charts show the hourly usage peaks over the last 7 days with the current request and limit and the advised request as lines, one container at a time. A limit more than three times higher than everything else stays off the chart so the other lines remain readable, and the chart title names it.

Troubleshooting

No CPU throttling shows for any workload. Open Observability → Settings and save the VictoriaMetrics settings once to update its scrape configuration. Throttling only exists for containers with a CPU limit.

OOM kills of replaced pods are missing. Check that the kube-state-metrics add-on is installed. Without it, the tab only shows OOM kills of pods that still exist.

A workload is missing. The tab lists workloads that have pods in the cluster now, including completed Job pods that recorded usage in the window.