Workloads¶

The primary table view for every Kubernetes resource type KubeManta manages — the day-to-day equivalent of a resource listing command, without leaving the browser.

Tier: Free

What it does¶

Resource type tabs across the top switch between Pods, Deployments, StatefulSets, DaemonSets, Jobs, Services, Ingresses, ConfigMaps, and Secrets. An All Resources entry at the end of the same strip browses every other kind in the namespace, including CronJobs and PersistentVolumeClaims. The pod table includes readiness (X/Y containers ready), status, restart count, age, pod IP, and node, refreshed automatically every 3 seconds so the table stays current without a manual reload. Which kinds have a tab, and which columns each table shows, are yours to choose; see Choosing your tabs and columns below.

Every row has an actions menu: the ⋮ button at the end of the row, or right-click. On a pod, Deployment, StatefulSet, DaemonSet or Job, View logs opens a resizable log console with multi-container selection; on a workload that runs several pods you pick the pod first. Describe shows what kubectl describe prints for the row (see Describe, View YAML and Edit YAML below). Run AI Diagnosis on a pod or workload row starts an AI root-cause analysis of it. Click a pod row itself for its pod details: phase, node, recent events, each container's image and state, labels and conditions, with a Diagnose button. Cascade relationships — the owner chain from Pod up through ReplicaSet to Deployment, which Services select this workload, and PVC status — are in the Diagnose tab rather than on a workload row.

Reading the Status column¶

Pods, Deployments, StatefulSets, DaemonSets and Jobs each have a Status column. Every status sits in a small box with a hexagon and a word, centred in its column like every other cell. The box's word and border stay calm on a healthy row, so a hundred healthy rows read as one calm column; a tinted box appears only where someone has to act.

The hexagon's colour says how healthy the row is:

Green: running, or on its way there (Running, Available, a rollout or scale in progress, a pod that is running but not yet ready).
Amber, with a short reason beside the box, means needs a look: a pod that is not ready or still pending after five minutes, a Degraded workload with some replicas unavailable, a Paused rollout with replicas missing, or a Job that is retrying after failed pods.
Red, with a reason, means needs action: CrashLoopBackOff (with its restart count), OOMKilled, an image that cannot be pulled, an evicted or failed pod, a failed Job, Unavailable when no replicas are available, or Error for a rollout past its progress deadline.
Grey: finished or scaled away (Completed, Scaled to 0, or No nodes for a DaemonSet that matches no node), and states where nothing runs yet or any more: a pod that is pending or terminating, or a Job that is running. Unknown is a dashed outline, because a solid shape would claim a verdict KubeManta does not have.

A rollout or scale in progress also shows its ready count beside the box.

The hexagon's shape says whether the state is settled or changing. A settled state is a solid hexagon and nothing moves. A changing state shows the hexagon's outline with one bright side travelling round it: a pod scheduling, starting or terminating, a pod that is running but not yet ready, a rollout or scale in progress, or a Job running with no failures yet. Motion is kept to those states on purpose. A container that Kubernetes keeps restarting, an image that cannot be pulled, or a pod that has waited too long is a problem to act on, not a process to watch, so those rows are red or amber and still. If your system asks for reduced motion, the travelling side rests on the upper-right edge.

Hover over a status, or focus it with the keyboard, to see the evidence, such as the container's last exit code or the rollout's message. Click it to keep that detail open, and press Escape to close it. The Ready and Restarts columns are plain numbers, because the Status cell carries the row's signal.

Names, nodes and reasons that are too long for their cell are shortened with an ellipsis. Rest the pointer on one for a moment, or focus it with the keyboard, and the full text appears in a small card; Escape closes it. Text that fits shows no card.

The CVSS column¶

When the Vulnerability Scanner has finished a scan of a workload's images and found something at your threshold, a small badge appears in the CVSS column, right after the workload's name. The badge shows the worst CVSS v3 score among the workload's most severe findings, or the severity's letter when the CVE has no v3 score. Its colour follows the score, as in the Vulnerability Scanner: solid red for 9.0 and above, solid amber for 7.0 to 8.9, and solid grey below that. A critical badge breathes. A workload with nothing at your threshold, or whose images have not been scanned, has an empty cell. Hover, focus or click the badge to see:

the counts per severity;
the worst CVE, its fix, and where its score came from: the CVSS version, the source (NVD, Red Hat, GitHub and so on) and the vector, as the scanner shows them. "source not stated" means the scan report did not say;
how many of the findings have a fix;
which images carry them;
when the scan finished, and a note when that scan ended with errors, because some images may not have been read.

The detail also links to View findings for this workload in the scanner.

The counts are things to fix: one CVE in one image counts once. They are the same current, non-excluded findings the scanner shows. Excluding a finding there updates the badge as soon as you are back on Workloads, without a new scan. A Workloads view already open in another browser tab catches up within 30 seconds.

A workload with no badge either has nothing at your threshold or has not been scanned yet. KubeManta never shows a "clean" mark, because no data is not a good result. While a re-scan is running, the badge from the last finished scan stays; a scan that is still running or that failed never adds one.

Use View in the Workloads toolbar to turn Vulnerable-image badges on or off and to choose Critical only or High and critical (the default). The column shows on Deployments, StatefulSets, DaemonSets and Jobs. On Pods it is off by default, because a controller's score would repeat on each of its pods; switch on CVSS column on Pods in the same popover to see it there. The settings are saved to your account, so they follow you to other browsers.

Choosing your tabs and columns¶

The View control in the Workloads toolbar opens a small panel with three sections. Everything in it is saved to your account, so the same view follows you to every browser you sign in from, and nothing in it changes what anyone else sees.

Tabs. Each built-in kind has a switch. Switch a kind off and its tab leaves the strip; the kind is still one click away under All Resources, so nothing becomes unreachable. Switch it back on and the tab returns at the end of its group. The arrows beside a tab move it up or down within its group (Workloads or Config & Net), and the strip follows the order you set. The last remaining tab cannot be switched off.

You can also add a tab for any kind the cluster serves and you are allowed to list: a CronJob, a HorizontalPodAutoscaler, a PersistentVolumeClaim, an EndpointSlice, or one of your own custom resources. Choose Add a kind from All Resources under either group, type part of the kind's name and pick it. Kinds you cannot list are not offered, and a kind that already has a built-in tab is not offered twice. An added tab lists exactly what kubectl get <kind> prints — the same columns and the same values, straight from the cluster — and polls like the other tabs. Its rows offer Describe, View YAML or Edit YAML, and Delete where the kind allows it, the same actions All Resources offers. The × beside an added tab removes it again.

Columns. Pick a kind, then tick the columns you want. The built-in kinds offer today's columns plus extras that are already in the data the table reads, so a column never costs an extra request:

Pods: Ready, Status, Restarts, Age, IP, Node, CPU and Mem (the last two when metrics-server is installed), plus Controlled by, Containers, Images and Labels.
Deployments: Ready, Status, Up-to-date, Available, Age, plus Desired, Images and Labels.
StatefulSets: Ready, Status, Age, plus Current, Images and Labels.
DaemonSets: Desired, Ready, Status, Node Selector, Age, plus Available, Images and Labels.
Jobs: Status, Completions, Age, plus Active, Failed, Images and Labels.
Services: Type, Cluster IP, Ports, Age, plus Selector and Labels.
Ingresses: Hosts, Address, Ports, Age, plus Class and Labels.
ConfigMaps: Keys, Key Names, Age, plus Labels.
Secrets: Type, Keys, Age, plus Labels.

For a kind added from All Resources the choice is the API server's own columns: the ones kubectl get prints are on by default, and the ones marked wide are what kubectl get -o wide adds. The Name column and the Actions column always show, and the CVSS column follows the badge settings below.

Badges. The vulnerable-image badge switch, its threshold and CVSS column on Pods, described under The CVSS column above.

Reset to default puts everything back to the view a new user sees: the nine built-in tabs in their original order, each kind's default columns, and badges on for high and critical.

Describe, View YAML and Edit YAML — on any kind¶

Every row carries the same three actions, from the per-kind tables, from All Resources and from the network map, so a resource behaves the same way wherever you meet it.

Describe shows what kubectl describe prints, on every tab and in All Resources alike: the same drawer, with the equivalent command and a Copy button (see All Resources reads like kubectl below). It works on any kind the cluster serves, not a fixed list, so a ServiceAccount, Role, HPA, PodDisruptionBudget or one of your own CRDs describes exactly like a Deployment. Secret is the one exception and is never describable; its rows offer no Describe.

All Resources reads like kubectl¶

The All Resources table shows, for every kind, the columns kubectl get <kind> prints by default, with the same values. They come from the cluster itself, so your own CRDs show the columns their authors defined. An EndpointSlice, for example, shows NAME, ADDRESSTYPE, PORTS, ENDPOINTS and AGE, and ENDPOINTS lists up to three addresses followed by + N more..., just as kubectl does. When the table is showing every namespace, a NAMESPACE column comes first. If the cluster cannot describe a kind's columns, the table falls back to NAME and AGE. A name or value too long for its column ends in an ellipsis; hover or focus it to read it in full.

Right-click a row and choose Describe to see what kubectl describe prints for it: the same fields in the same layout, followed by its Events for the kinds kubectl shows Events for. The drawer shows the equivalent kubectl describe command and a Copy button. Kinds kubectl has its own layout for get that layout, including Pod, Deployment, ReplicaSet, ReplicationController, StatefulSet, DaemonSet, Job, CronJob, Service, Endpoints, EndpointSlice, Ingress, IngressClass, ConfigMap, PersistentVolumeClaim, PersistentVolume, StorageClass, Node, Namespace, ResourceQuota, LimitRange, PriorityClass, ServiceAccount, Role, RoleBinding, ClusterRole, ClusterRoleBinding, NetworkPolicy, HorizontalPodAutoscaler and PodDisruptionBudget. Every other kind, including CRDs, gets kubectl's generic layout: name, namespace, labels, annotations, then the object's fields and its Events.

A few things are deliberately shown differently from kubectl:

Payloads are never shown. Any resource that keeps data in a data, stringData or binaryData map, such as a custom resource that stores credentials the way a Secret does, shows each key's size in bytes instead of its value.
ConfigMap values follow the YAML view. Values are shown, but a value under a key that looks like a credential (password, token, …) is replaced with <redacted>, and values that look like secrets are masked.
Credential-named environment variables are masked. In a pod or pod template, a literal value for a variable such as DB_PASSWORD is shown as <redacted>, and other literal values that look like secrets are masked. Values from a Secret or ConfigMap reference are shown as the reference, as kubectl does.
On a Node, pods in namespaces hidden from you are not listed. The allocated-resource totals still count every pod on the node, and a line says how many rows were left out.

View YAML and Edit YAML open the resource's manifest. In the per-kind tables every row has View YAML, and a kind KubeManta can apply back (Deployment, StatefulSet, DaemonSet, ReplicaSet, Service, Ingress, ConfigMap, Pod, Job, CronJob, PersistentVolumeClaim, Secret) also has Edit YAML. In All Resources the single entry is labelled for what you are getting: Edit YAML for those kinds, and View YAML, read-only, for everything else. A read-only kind is never presented as editable, so you cannot spend time on a change that had nowhere to go.

The manifest you get back is editable, not a dump of the live object. Server-managed fields are stripped first — status, managedFields, resourceVersion, uid, creationTimestamp, generation, ownerReferences and the last-applied-configuration annotation — so what you edit can be applied as it stands. A manifest too large to show in full opens read-only.

The editor checks as you type: YAML syntax, and the basic shape of a Kubernetes object (apiVersion, kind, and metadata with a name), marked at the line that is wrong. Apply stays disabled until a dry-run plan of your change succeeds, so you see the diff before anything changes.

Writes are governed as writes: Edit YAML applies changes only for an admin, with Expert Mode on and a Pro licence, through the same path as Resource Builder Apply, and every apply is audited. For anyone else the editor opens read-only. Delete refuses Secret.

Exec into a container¶

A shell in a single container, opened with Exec Shell from a pod's row, or from a Deployment, StatefulSet, DaemonSet or Job row after you pick one of its pods, for the times the question is "what does this process actually see". It is separate from the Terminal tab: this one lands inside the container you chose, with no kubectl in between.

It needs three things: the admin role (or the developer role on Pro and Enterprise, outside system and KubeManta namespaces), rbac.allowWrites=true in the Helm values (because pods/exec is a write verb in Kubernetes regardless of what you type once you are in), and Expert Mode. Enabling Expert Mode is two steps: install with --set expertMode.enabled=true to deploy the expert-exec pod, then switch Expert Mode on at Admin → System. The Helm flag alone deploys the capability but does not turn it on. If any of the three is missing the socket closes instead of opening a shell. If you grant the permission by hand, grant both get and create on pods/exec: exec streams over a WebSocket, which the API server authorises as get, so a role with only create is refused.

Setup¶

Use the namespace selector in the top bar to scope the table, and the resource-type tabs to switch kinds. No additional configuration is required to read workload state.

Write operations — restart on deployments, statefulsets and daemonsets, scale on deployments and statefulsets, and pod delete (one pod, or several selected with the row checkboxes) — are disabled by default. They require rbac.allowWrites=true in the Helm values, which grants the reader ServiceAccount patch and update on apps resources and their scale subresource, plus create and delete on pods. It does not grant delete on Deployments, StatefulSets, DaemonSets, Services, Ingresses or ConfigMaps, so those Delete entries are refused by the API server even with writes enabled. Deleting a DaemonSet, Job, Service, Ingress or ConfigMap from the table also needs Expert Mode. Delete and scale ask for confirmation in the UI before they run; restart is issued immediately. Every mutating action is recorded in the audit trail with actor attribution.

Troubleshooting¶

The write entries are absent from a row's context menu entirely for the viewer role — they are omitted, not disabled. A developer sees only the entries their role allows (Restart, Scale, Exec Shell and Delete Pod). For an admin they are always present, because the UI does not read the cluster's RBAC; if one returns a permissions error when used, the most common cause is rbac.allowWrites still being at its default false — check the Helm values used at install or upgrade time. If a pod's logs or details come back empty for a pod that clearly exists, confirm the namespace isn't excluded by the system-namespace blocklist or an administrator-configured namespace allowlist; KubeManta will not show data for a namespace it has been told to ignore, even if the underlying RBAC would permit it.

Generated from KubeManta 1.5.0 — this page is rendered from the product's own documentation, so it cannot drift from what ships. Manifest built 2026-11-03T12:53:14Z.