Applications¶

A named group of workloads — picked from a list or matched by label — with a single health verdict that always carries its reason, plus right-sizing and per-workload traffic.

Tier: Free

What it does¶

Kubernetes has no concept of "an application". It has pods, deployments and services that happen to share labels, and the connection between them lives in your head. Applications makes that connection explicit: you name a group of workloads — either by picking them from a list or by saving a label selector — and from then on KubeManta treats them as one thing.

The health verdict is deliberately a SINGLE verdict, decided worst-member-wins, and it always carries the REASON. An application whose web tier is fine and whose database is crashlooping is not "mostly healthy" — it is broken, and the reason names which member made it so. Averaging member states would produce a comfortable number that hides the incident, which is the opposite of what this screen is for.

Selector-based membership is discovered live rather than stored, so a workload that gains the label joins the application and one that loses it leaves. An application matching nothing says so plainly instead of rendering an empty, healthy-looking application — a typo and a genuinely empty namespace are different situations and must not look alike.

Picking workloads, without knowing their labels¶

You do not have to know a label to define an application. The editor opens as a full page inside Applications — with a Back to applications link — and lists the Deployments, StatefulSets, DaemonSets and Jobs you can see. Filter by namespace, by name or label text, and by resource type; clicking a workload adds it. Use this when you run several products in one cluster and could not say from memory which labels each of them carries.

The list shows what the application already contains, not just what you have picked. A workload matched by your labels is marked as already included and explains itself; a workload you added by name is marked separately, because that one is removable here and the matched one belongs to the selector — removing it would only bring it straight back on the next evaluation. A counter above the list gives the whole picture: how many are in the application, how many arrived by label, and how many were pinned by name.

Each workload in that list shows the labels it carries, and clicking a label uses it as the selector instead — so if the workloads are labelled consistently, you can discover that and switch to the label-based form without leaving the page.

The two ways combine. An application can be a selector, a set of picked workloads, or both; picked workloads are simply added to whatever the selector matches, and a workload found both ways counts once.

Picked workloads are remembered by name, which is safe because a Deployment, StatefulSet, DaemonSet or Job keeps its name across every rollout. Picking a pod stores the workload that owns it, for the opposite reason: pod names are regenerated on every deploy, so a pinned pod name would quietly stop applying. A bare pod with no owner cannot be added, and the form says why.

If a picked workload is later deleted, the application reports it as missing rather than dropping it. Silently shrinking would leave the remaining pods looking healthy while the application had stopped covering part of what it was built to cover.

Only workload kinds can be picked. A Service or ConfigMap has no pods and so contributes nothing to a health verdict, and an application that showed a green tick while never checking its Service would be exactly the dishonest verdict this screen exists to avoid.

Matching a family of workloads¶

A label value may end in * to match a family. app=checkout-* covers checkout-api, checkout-worker and anything else sharing that prefix, which saves listing them one by one when a team runs many related apps.

Kubernetes itself has no wildcard in label selectors, so KubeManta resolves the pattern into the set the API does understand before asking the cluster. The practical consequence is that the pattern is matched against label values, not pod names.

Live and Fixed membership¶

When your selector carries a pattern, you choose what happens as the cluster changes:

Live — new workloads that start matching the pattern join automatically. This is the default, and the behaviour most teams want.
Fixed — the pattern is resolved when you save and the label values it found are frozen. A value that appears later stays out.

The choice acts on patterns and nothing else. A selector with no * in it — app.kubernetes.io/name=checkout — already names one exact value, so there is nothing to freeze: a workload that gains that label joins in either mode.

Fixed remembers the label values that matched, not the pods. That matters: pods are replaced with new names on every rollout, so remembering names would quietly empty the stack the next time you deployed. Redeploying checkout-api keeps it in the stack; a brand-new checkout-export stays out until you say otherwise.

You can also remove individual matches you do not want, in either mode. Those removals are remembered by label value too, and survive a redeploy for the same reason.

The list, and the explorer behind it¶

The Applications tab opens on your applications as cards, with everything KubeManta found in your cluster on its own tab beside them. That page is where you browse, search, filter by status, and save something discovery found.

Clicking an application opens the EXPLORER, and the page changes shape: a narrow navigator of your saved applications on the left, and the application itself taking the rest of the width. It behaves like a file explorer — the navigator stays put while you read, and clicking another application swaps only the right-hand side.

Two consequences are deliberate:

Discovery does not come with you. The navigator lists the applications you have saved and nothing else. What was found in the cluster stays on the page you came from, because that is a browsing task and this is a reading one.
Neither panel makes the page scroll. The navigator scrolls inside itself, the detail scrolls inside itself, and only the rows actually on screen exist in the browser — so a hundred saved applications cost the same as five.

← All applications returns you to the cards. On a narrow screen the navigator is dropped entirely and the detail takes the full width, which is the same trade every two-pane layout makes on a phone.

The navigator is FLAT and ALPHABETICAL, and it stays that way when an application degrades. Sorting worst-first sounds helpful and is not: the list refreshes every few seconds, so a row that reordered itself would move under your cursor at exactly the moment you were reaching for it. Worst-first is a FILTER instead — the status chips, and a N need attention button that narrows the list to everything unhealthy in one click.

Each row answers three questions before you open anything:

Its verdict — Healthy, Degraded, Down or Unknown, as a glyph as well as a colour, so the state never rests on colour alone.
What it is MADE OF — 6 Deploy · 2 STS · 1 DS · 2 Jobs. This counts WORKLOADS, not pods. A 30-replica Deployment is one Deploy, because a Deployment is the thing you scale, roll back or delete; thirty identical pod names would tell you nothing you can act on. Kinds are abbreviated (Deployment → Deploy, StatefulSet → STS, DaemonSet → DS) and always appear in the same order, so two applications are comparable at a glance.
How many of its pods are ready.

Search covers names, namespaces AND labels, and the status chips narrow the list to one verdict. When a filter leaves nothing on screen the page says WHY — which filter is responsible, how many applications the other filters would match, and a button that clears exactly the one in the way. "No results" with no route back is how a filter gets mistaken for an empty cluster.

What is inside an application¶

Opening one lists the workloads it contains, worst first, with the count of workloads above. A workload that is not healthy names the pod that explains it and the reason — CrashLoopBackOff on checkout-api-7d4f9c-x2p1 — rather than a bare warning triangle. That sub-line is usually the whole diagnosis.

The list shows the first eight and reveals the rest in one step. Expanded, it scrolls within its own region rather than growing without limit: a 200-workload application would otherwise push the alert policy, the selector and everything else below the fold, and the detail view would stop being a summary. The count above the list is always the true total, so the bound never hides how big the application really is.

The Attention column¶

Beside CPU and memory, each pod carries any resource findings that apply to it. There are six, in three deliberately different treatments — collapsing them into one warning colour would page someone for the wrong thing.

Chip	Colour	What it means
Near memory limit	red	At or above 90% of its memory LIMIT. The next allocation can get it OOM-killed.
No requests set	purple	The pod spec asks for no CPU and no memory.
No CPU request	purple	No CPU request; memory is set.
No memory request	purple	No memory request; CPU is set.
CPU above request	blue	Using more CPU than it reserved.
Memory above request	blue	Using more memory than it reserved, still inside its limit.

Red is the only one that is urgent. A pod near its memory limit is about to be killed, and that is an incident.

Purple is a configuration gap, not a fault — nothing is on fire, and the fix is in the manifest rather than in the cluster. It matters because Kubernetes schedules on REQUESTS, not on usage: a pod that requests nothing is placed as though it needs nothing, is class BestEffort, and is the first thing evicted when a node comes under pressure. It can also be packed onto a node with no headroom left for it. The pod may be running perfectly today and still be the one that disappears first tonight.

Blue is informational and usually correct behaviour. Using more than you reserved is what bursty work looks like when it is working; requests are a floor for the scheduler, not a cap. The cap is the limit, which is what the red chip watches.

Expect the first thing you see flagged to be infrastructure you did not deploy. On most clusters the CNI's own DaemonSet — calico-node and friends — ships with no requests set. That is a real finding about a real pod, and it is also not yours to fix; it is a fair illustration of why the chip is purple and not red. Hovering any chip gives the same explanation in one line.

Sizing and usage¶

Each application shows CPU and memory per member: what is used, what is requested, and what the limit allows. Bars are drawn so the used value sits against the request notch with the limit at the right edge, which makes the two questions this screen exists for — "is this over-provisioned" and "is this about to be throttled or OOM-killed" — readable at a glance.

Sizing is read with the selector exactly as you wrote it, which is not always the same set as membership. An application matched by a * pattern reports no sizing rows at all, and one defined only by picked workloads — no selector — sizes every pod in its namespaces rather than only its members. A plain k=v selector is the form whose table describes the application and nothing else.

Absence is never shown as zero. A pod whose usage cannot be measured reports no value, not 0, and the panel says why (metrics-server missing, or the kubelet network scrape not enabled). A zero would render an unmonitored application as an idle one, which is the more dangerous of the two readings.

Totals cover the MEASURED pods only, and say how many of the total that is. This matters more than it sounds: summing requests across every pod while usage covered only some compares two different populations, and the error runs in one direction — it inflates the request total, making an over-subscribed application look comfortably provisioned. That is exactly backwards on a right-sizing screen.

Usage over time¶

Alongside what an application is using now, the detail carries CPU and memory as a series over the same window the traffic charts use — 1h, 6h, 24h or 7d, set once and shared, because two window pickers on one screen is how two charts end up showing different hours side by side.

CPU and memory are two charts, never one. Millicores and bytes share no axis, and a single chart carrying both invites "memory crossed CPU", which is a comparison with no meaning between them.

The series sums the application's pods, which is the question this screen is for — what is this application costing the cluster. The per-pod breakdown is one tab away under sizing, where a single greedy pod is visible.

No samples is not zero. An application whose pods have not been measured yet says so rather than drawing a flat line along the bottom, because a chart at zero reads as "this uses nothing" and that is a different, wrong answer. The sampler writes one sample a minute, so a newly saved application has a chart within a couple of minutes rather than instantly.

Traffic¶

Network is reported PER WORKLOAD and never summed into an application total. One total hides "the database is saturated while the web tier is idle", which is usually the thing you opened the screen to find.

Alongside the current rate, a traffic-over-time chart per workload answers the questions a single number cannot: is it climbing, when did it spike, and which workload is carrying the load. Windows of 1h, 6h, 24h and 7d are available.

Know the real granularity rather than expecting a live feed. CPU and memory come from metrics-server, which scrapes kubelet roughly every 15 seconds. Network comes from KubeManta's own sampler, which writes one sample per minute and derives rates from consecutive samples — so a rate needs two samples and can be up to a minute behind. Both refresh on their own while the panel is open.

Being told when it breaks¶

An application is usually defined so that someone can be told when it stops working, so the control to arrange that is the bell in the first column of the application list — not four screens away in the alert editor.

Turning it on creates an ordinary alert rule — the same kind the Alerts tab manages, visible and editable there — that fires when the application is DEGRADED, which covers "down" as well; nobody wants silence through a total outage.

Not everything in an application should wake you up¶

A stack usually holds more than one kind of thing: Deployments, StatefulSets, Pods, and often Jobs. A Job exiting non-zero is frequently a normal outcome — a retry, a nightly reconcile that found nothing to do, a batch step with a non-zero convention. Left alone, that would page you on a schedule until you turned the whole application off.

So each application decides which of its members may raise an alert. Open the application and use the kind chips under Which members can raise an alert:

Jobs and CronJobs start excluded. This is the default because it is right far more often than not. One click puts them back.
An excluded member is still a member. It stays in the application, it is still listed, and it still counts toward the health you see on screen. It simply does not page anyone.
Displayed health is never filtered. An application whose only fault is a failed Job still reads DEGRADED — because it is — and stays silent. The bell carries a small count of how many members are excluded, so "armed" never hides "…but two of these cannot alert".

You can also set the severity (critical, high, warning, medium, low), whether it fires on degraded or worse or only when nothing is serving, and how long it must stay bad first.

Three more behaviours are deliberate:

Turning it off disables the rule, it does not delete it. A cooldown you tuned on the rule survives flipping the bell twice. The channel selection does not: the application owns that field and re-applies it on every save, so a rule narrowed in Alerts Manager to one integration returns to every enabled integration the next time the bell, the severity or a kind chip changes.
The rule is not pinned to one namespace. An application already carries its own namespaces in its selector, so scoping the rule to a single one would silently narrow a multi-namespace application to part of itself.
It tells you when the alert would reach nobody. If no integration is enabled, the bell is refused and offers the one action that fixes it, instead of reading "on" while nothing is delivered.

One rule covers the whole application, so a three-pod application pages once rather than three times.

Alerting is Free, and the number of rules is unlimited. The operational integrations (PagerDuty, Datadog, CloudWatch, generic webhook), retained firing history and AI auto-investigation are Pro.

Your applications, and the ones we found¶

With applications saved, the page opens on Your applications. What KubeManta has discovered from the cluster's own labels moves to a second sub-tab, whose label carries the count — "Found in your cluster (10)" — so a find is announced without a click while your own applications keep the top of the page. With nothing saved yet, discovery is the whole page, because then it is the useful thing rather than a distraction.

Setup¶

Reach Applications from the OBSERVE group in the sidebar. Create one by naming it, then either picking its workloads from the list in the form or entering a label selector (for example app.kubernetes.io/name=checkout, or app=checkout-* to match a family) — or both. Optionally scope it to specific namespaces, and if the selector uses a * pattern, choose Live or Fixed membership for it. KubeManta can also suggest applications by looking for common labelling conventions already present in the cluster, which is usually faster than typing selectors by hand.

To be alerted on an application, click the bell in the first column of the application list. That is the whole setup — no rule to write — but it only delivers if at least one integration is configured under Alerts Manager → Integrations, and the list will tell you if none is. To choose which members may raise an alert, or to set severity, open the application. Alerting is Free with unlimited rules, delivered to Slack, Telegram or email; the operational integrations, firing history and auto-investigation are Pro. Everything else on this page is Free.

The rest here is Free and read-only, and viewers see it. Network history additionally requires the kubelet scrape (metrics.kubeletScrape.enabled), which is on by default; where it has been turned off the traffic sections say so rather than showing an empty chart.

Troubleshooting¶

An application showing no members means nothing currently matches — check the selector against the labels the workloads actually carry, remembering that a selector is an exact match on every key you list. The labels shown beside each workload in the create form are the fastest way to check that.

A member listed as missing with no pods is a picked workload that has been deleted from the cluster. Either restore it or remove it from the application; it is reported rather than dropped so the change cannot pass unnoticed. If sizing shows dashes rather than numbers, check the selector first: an application matched by a * pattern reports no sizing whether or not metrics-server is present. Otherwise metrics-server is not installed or not answering, and the Metrics tab will say the same thing in more detail.

Chips in the Attention column are findings about the pod SPEC as much as about the pod. No requests set will not clear by restarting anything — add resources.requests to the manifest and redeploy. If the pod is not yours (the CNI's DaemonSet is the usual first hit), the honest answer is to leave it: the chip is purple rather than red precisely because it describes a risk under pressure, not a fault today. Near memory limit is the one worth acting on straight away — raise the limit, or find what is growing.

If the traffic charts are empty while the rest of the panel is populated, the scrape that collects those samples is failing or has been turned off — that is a cluster-wide setting, not a per-application one, and without it there are no network samples for any workload. The metrics source's scrape-health fields name the cause per node: a self-signed kubelet serving certificate (choose viaProxy or insecureSkipVerify), or port 10250 firewalled away from pods (viaProxy). A chart that is genuinely empty for a window says so; it does not draw a flat line at zero, because "not collected" and "no traffic" are different answers.

Generated from KubeManta 1.2.0 — this page is rendered from the product's own documentation, so it cannot drift from what ships. Manifest built 2026-09-12T02:14:45Z.