Workloads

A sortable table of every workload in the cluster, with search and a namespace filter.

Columns

Column	What it shows
Status	Healthy / Failed / Degraded, derived below.
Namespace	With a compact namespace badge.
Name	Plus a kind tag — Deploy, STS, DS.
Ready	ready / desired replicas.
Restarts	Lifetime restart count, with the time of the last restart.
CPU	Live millicores, as a bar against the request or limit.
Mem	Live MiB, same treatment.
Age	Time since creation.

How status is derived

This one is worth knowing, because a naive reading of restart counts is misleading:

1. ready < desired is a live condition and always means Failed.
2. Otherwise, restarts only downgrade the status when the last restart was recent.
3. A workload that restarted heavily last month and has been stable since reads Healthy.

Restart count is a lifetime total that never decreases. Scoring on it directly would leave a workload permanently marked degraded for something that ended weeks ago — so the status is time-aware and the count stays visible in the badge for history.

Usage bars with no request set

When a container has no CPU or memory request or limit, there is no denominator to draw a bar against. Rather than hide the row, the bar is drawn against a fixed reference (100m CPU, 512 MiB memory) and the tooltip says so explicitly. A workload with no requests set is itself a finding — see Right-Sizing.

From the CLI

rtz get deploy -n payments -o wide
rtz describe payments/checkout