Try Kubius
⌘K

Working with resources

Workloads (Deployments, StatefulSets, DaemonSets, Jobs, CronJobs)

All controller-style resources share a similar detail layout: a header with status badges and action menu, an Overview tab with replica gauges and container specs, related resources, and live YAML.

Managing a workload

Every workload detail view has an Actions ▾ menu in its header. Depending on the kind it offers some of:

  • Scale… - change the replica count (Deployments, StatefulSets, ReplicaSets) or a Job’s parallelism/completions. Opens a modal - see Scaling below.
  • Edit Resources… - set CPU & memory requests and limits per container. Opens a modal - see Editing resources below.
  • Restart - rolling restart (Deployments, StatefulSets, DaemonSets) via the restartedAt annotation.
  • Right-Size… - sample real usage and get a recommendation (a Pro feature; see the Right-Sizing help).
  • Delete - graceful delete, with confirmation.
  • Force Delete - immediate delete with gracePeriodSeconds=0.

You can also delete from any list without opening the detail view: right-click a row → Delete X. The right-click menu only ever offers a graceful delete (Force Delete lives in the detail Actions menu). The same right-click menu has Copy kubectl…, whose items show the short command (e.g. kubectl get deployment) but copy the full command with the name, namespace, and flags.

Scaling

Picking Scale… opens a modal:

  • Deployment / StatefulSet / ReplicaSet - a stepper for the desired replica count. Scaling to 0 stops all Pods (the workload serves no traffic until scaled back up). If a HorizontalPodAutoscaler manages the workload, the modal warns you - a manual scale will be overwritten by the autoscaler, so adjust the HPA instead for a lasting change.
  • Job - Jobs don’t have replicas. Instead you set parallelism and completions (explained in the modal):
    • Completions - the total number of Pods that must finish successfully (exit 0) before the whole Job is marked Complete - i.e. “this Job must complete N units of work”. With completions: 5, the Job keeps starting Pods until 5 have succeeded. Left unset, the Job needs just one success.
    • Parallelism - the maximum number of Pods that run at the same time. Raise it to finish sooner; set it to 0 to pause the Job without deleting it.
    • Parallelism can be changed on a running Job. Completions is usually immutable once a Job is created - Kubernetes rejects a change unless it’s an elastic Indexed Job, and the modal shows that error if so.

Editing resources (requests / limits)

Edit Resources… opens a per-container editor with four fields each: CPU/memory request (guaranteed and used for scheduling) and limit (the hard cap). CPU accepts cores or millicores (0.5, 250m); memory accepts byte units (256Mi, 1Gi). Leave a field blank to remove that value. Kubius checks the quantities parse and that each limit is ≥ its request before sending.

Applying patches spec.template.spec.containers[].resources. Whether existing Pods are recreated automatically depends on the controller’s update strategy - the modal tells you which case applies:

  • Deployment - always rolls automatically (new Pods with the new resources).
  • StatefulSet / DaemonSet with the default RollingUpdate strategy - rolls automatically (StatefulSets highest-ordinal first). With OnDelete, Kubernetes will not touch running Pods - you must delete each Pod yourself for the change to take effect (right-click a Pod → Delete Pod). A StatefulSet partition also holds back lower-ordinal Pods.
  • ReplicaSet - a bare ReplicaSet does not recreate running Pods when its template changes; delete the Pods to recreate them, or edit the owning Deployment instead.
  • CronJob - applies to future Jobs only.
  • Job - the Pod template is usually immutable after the Job starts, so Kubernetes may reject the change (shown in the modal).

Available for Deployment, StatefulSet, DaemonSet, ReplicaSet, Job and CronJob - Pods themselves are immutable and can’t be edited this way.

Deployments

The Deployment list shows:

  • Status - Available, Progressing, or Failed. While a rollout is in progress you’ll see a spinner and percentage
  • Replicas - ready/desired
  • Up-to-date - pods running the current spec
  • Strategy - RollingUpdate or Recreate

Deployment detail tabs

  • Overview - sections in operational-priority order: Resource Usage → Replica Status → Containers → Pods → Related Resources → Conditions → Update Strategy → Scheduling → Deployment Info → Labels / Annotations / Template Labels
  • Pods - the backing pods as a compact list
  • Events - Pulls events for the deployment, its ReplicaSets, and up to 10 backing pods. Sorted newest first
  • Graph - dependency visualisation
  • Logs - combined logs from every backing pod
  • YAML - live manifest

Sections on Overview

  • Resource Usage - live CPU / memory charts (always rendered, even before the first poll arrives)
  • Replica Status - Desired / Ready / Available / Updated / Unavailable tiles
  • Containers - per-container card with image, ports, resources, plus structured cards for command, args, lifecycle.preStop / postStart, and startupProbe / readinessProbe / livenessProbe (probes render side-by-side in a 2-column grid; all four K8s probe action types are supported - HTTP GET, TCP, EXEC, and gRPC - with per-type detail cells; exec commands get their own monospaced selectable block with a copy pill)
  • Pods - backing pods (compact list)
  • Related Resources - owning ReplicaSet, matching Services (icon tinted by endpoint health), HPAs, Ingresses
  • Conditions - Available, Progressing, ReplicaFailure (False = healthy). Folded into Overview, no longer a dedicated tab
  • Update Strategy - Type (RollingUpdate / Recreate), Max Surge, Max Unavailable, Min Ready Seconds, Progress Deadline - all in one place, no duplication with Deployment Info
  • Scheduling - structured cards for nodeSelector, tolerations, and topologySpreadConstraints plus terminationGracePeriodSeconds and priorityClassName - each in a 2-column grid of labelled cells matching the rest of the app
  • Deployment Info - basic identity (Name, Namespace, Created, API Version, Kind)
  • Labels / Annotations / Template Labels - as 2-column key/value grids

Actions

  • Port Forward - opens a session to one of the deployment’s ready pods
  • Scale… - set the desired replica count (with scale-to-zero and HPA warnings)
  • Edit Resources… - set per-container CPU/memory requests & limits (triggers a rolling restart)
  • Restart Deployment - patches the pod template with kubectl.kubernetes.io/restartedAt, triggering a rolling restart
  • Delete Deployment - removes the deployment and all ReplicaSets and Pods. Cascading delete
  • Force Delete - gracePeriodSeconds=0

Rollout indicator

The Status column shows a spinner and rollout percentage while pods are being replaced. A rollout is “in progress” when updatedReplicas < spec.replicas or there are unavailableReplicas. A rollout notification fires when a deploy succeeds or fails, after a 30-second settle window (so surge pods don’t cause a false failure). A deployment that’s only scaling - replica count changed with no template change, e.g. an HPA scale-up - is detected separately and routes to the Deployment scaling notification, which is off by default (a scale isn’t a rollout). See Preferences → Notifications.

ReplicaSets

ReplicaSets are usually managed by Deployments - the list shows current ones first, with the Show 0-replica toggle to include old / scaled-down sets.

Detail view shows the owning Deployment, the backing pods, and an inline Logs tab that aggregates from every pod in the set. The Actions menu offers Scale…, Edit Resources…, Delete, and Force Delete - though for a ReplicaSet owned by a Deployment, prefer scaling/editing the Deployment, since its controller will otherwise reconcile the ReplicaSet back.

StatefulSets

Similar to Deployments but with ordered pod naming and stable network identities.

Detail tabs are the same as Deployments. The Logs tab aggregates from every pod in the set. The Actions menu offers Port Forward (to a ready pod), Scale…, Edit Resources…, Restart StatefulSet (same annotation-patch trick), Right-Size…, Delete StatefulSet, and Force Delete. The Overview includes a StatefulSet Info card (governing service, pod management policy, PVC retention), Update Strategy (Type + Partition + Max Unavailable), and the shared Scheduling + Container-extras structured cards.

DaemonSets

One pod per node (or per matching node). The detail view shows desired vs ready vs available counts and the per-node pod list. Includes its own Update Strategy (Type + Max Surge + Max Unavailable) and Scheduling sections. The Actions menu offers Edit Resources…, Restart DaemonSet, Right-Size…, Delete, and Force Delete - there’s no Scale…, because a DaemonSet has no replica count (it runs one Pod per matching node; you change its reach with nodeSelector/affinity, not a number).

Jobs

Run-to-completion workloads.

  • Status - Active, Complete, Failed, Pending
  • Completions - succeeded/desired
  • Active / Failed counters
  • Start / completion timestamps

The Overview tab includes the pod template containers; logs are accessible per backing pod from the Related Resources section.

Actions

The detail header’s Actions menu offers:

  • Scale… - change parallelism (how many Pods run at once) and completions (how many must succeed for the Job to finish). The modal explains each; completions is usually immutable once the Job is created. See Scaling
  • Edit Resources… - set per-container requests/limits (a Job’s template is usually immutable after it starts, so this may be rejected)
  • Delete Job - deletes the Job with propagationPolicy=Background, so its pods are garbage-collected too
  • Force Delete - adds gracePeriodSeconds=0

CronJobs

Scheduled Jobs.

  • Schedule - cron expression
  • Last Schedule - when it last fired
  • Last Successful - last successful run

Actions

The detail header’s Actions menu offers:

  • Run now - creates an ad-hoc Job from the CronJob’s template, useful for testing or manually triggering. The item shows a checkmark briefly on success
  • Edit Resources… - set per-container requests/limits; applies to future Jobs the CronJob creates (running Jobs are unaffected)
  • Right-Size… - opens the right-sizing analysis for the CronJob’s pod template
  • Delete CronJob - removes the CronJob (its already-created Jobs are left intact)
  • Force Delete - adds gracePeriodSeconds=0

Horizontal Pod Autoscalers

The HPA detail view shows:

  • Target resource (Deployment / StatefulSet name + kind)
  • Min / Max / Current / Desired replicas

Custom metric specs are shown in the YAML tab - Kubius doesn’t currently render them structurally.