Tables & the inspector
Live tables for 28 kinds plus every CRD, and an inspector with metrics, YAML, logs, shell, events and the ownership chain.
The tables are where day-to-day work happens: live views over the cache,
updating as the cluster moves, with none of the refresh-and-squint of
kubectl get -w. 28 kinds ship in the sidebar — Workloads, Network, Config,
Storage, Access Control and Cluster — and pods and workloads carry live CPU
and memory columns with usage bars, so what's hot is visible from the list.
Filtering understands labels (label:team=payments) as well as names, and
namespace scope sits one dropdown away.
The inspector
Click any row and the inspector opens — the same drawer from every direction, whether you arrived from a table, a Triage finding, the Atlas, or search.
| Tab | What it holds |
|---|---|
| Overview | The computed describe — status, conditions, the fields that matter for this kind |
| Metrics | CPU, memory (working set and RSS), network rates — pods only |
| YAML | The full object; Secret values arrive redacted until you explicitly reveal them |
| Logs | Streaming, per container, for pods and for workloads across their pods |
| Shell | An exec terminal into a pod's container |
| Events | The object's events, which expire from the cluster but are right here |
| Related | The ownership chain and references — the object's corner of the Atlas |
Row actions cover the interventions you'd otherwise type: rollout restart, scale, cordon and uncordon, view owned pods, delete. The destructive ones are marked, confirm, and respect the read-only guard — a guarded cluster hides Shell and refuses every mutation.
Metrics without metrics-server
Moonway scrapes each node's stats summary through the API server proxy —
CPU, working set, RSS, network rates, volume and node-filesystem usage —
held in bounded in-memory rings. Nothing to install in the cluster, no
metrics-server required; it does require get on nodes/proxy, which is
the one permission gap that
leaves metrics empty.
Custom resources
Every CRD the cluster serves gets the same treatment: the Custom Resources page lists installed types — including operators installed after Moonway connected — and renders each with the printer columns its authors declared, so a cert-manager Certificate or an Argo Rollout looks the way its CRD says it should.
Helm
The Helm Releases page reads Helm's own release records straight from the
cluster — every release with its status, revision and chart, no helm binary
involved. Installs, upgrades, rollbacks and failures also land in the
journal, timestamped next to everything else that
changed.
Port forwards
Forward a port from any pod and it lands on the Port Forwards page — one place to see what's forwarded where, and to stop what you're done with.