Skip to content

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), a status badge, restart count, age, pod IP, and node, refreshed automatically every 3 seconds so the table stays current without a manual reload — an open Workloads tab is a genuinely live table, not a periodic snapshot.

From any row you can open Logs — a resizable log console for the pod, with multi-container selection — or Describe, a detail modal covering the overview, each container's image and state, labels, conditions, and recent events. Describe is not limited to pods; see below. 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. An unhealthy pod row links straight into Diagnose for AI root-cause analysis.

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 works on any kind the cluster serves, not a fixed list — the kind is resolved against the cluster's own discovery, so a ServiceAccount, Role, HPA, PodDisruptionBudget or one of your own CRDs describes exactly like a Deployment. Events are the generic half and work everywhere; readiness is reported as Unknown where the kind has no meaningful notion of ready, rather than guessed. That honesty is what makes describing a ServiceAccount useful instead of a polite lie. Secret is the one exception and is never describable.

View YAML / Edit YAML opens the resource's manifest. The label tells you which one you are getting: kinds KubeManta can apply back (Deployment, StatefulSet, DaemonSet, ReplicaSet, Service, Ingress, ConfigMap, Pod, Job, CronJob, PersistentVolumeClaim, Secret) open as Edit YAML; everything else opens read-only as View YAML. 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 noise is stripped first — status, managedFields, resourceVersion, uid, creationTimestamp, generation, ownerReferences and the last-applied-configuration annotation. On a typical Deployment those fields are most of the document, and leaving them in produced something that looked like a manifest, could not be applied, and was silently truncated on the way to the editor.

The editor validates as you type — schema-aware, served by the agent rather than by a browser worker, so it works the same in every editor in the product.

Writes are governed as writes: Edit YAML applies only with rbac.allowWrites and the admin role, and Delete additionally refuses Secret. A viewer sees View YAML and Describe and nothing that would fail.

Exec into a container

A shell in a single container, opened from the pod's own row, 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 clicked, with no kubectl in between.

It needs three things: the admin role, 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. Note the permission pair if you grant it by hand: the Python client streams exec over a WebSocket, which the API server authorises as get on pods/exec, not only create — which is why exec can work in k9s and still be refused here on a hand-rolled role.

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 — 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 apps, so Delete Deployment and Delete StatefulSet are refused by the API server even with writes enabled. 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. 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 describe modal 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.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.