status/

d8 status - Cluster Status Report

d8 status prints a single, read-only health snapshot of a running Deckhouse Kubernetes Platform (DKP) cluster. One invocation queries the Kubernetes API (and, for the queue section, execs the Deckhouse controller once) and renders a colorized report covering the control-plane nodes, the Deckhouse pods, and the platform's releases, edition, settings, registry, alerts, CNI modules, and reconciliation queue.

It takes no subcommands and no arguments - it is a dashboard you read, not a tool you drive. Because it only reads, it is safe to run against any cluster you can reach with a kubeconfig.

© Flant JSC 2025

Table of contents

• Synopsis
• Global flags
• The report
• Report sections
• Data sources and prerequisites
• Examples
• Notes

Synopsis

d8 status [flags]

No positional arguments, no subcommands, no aliases.

Global flags

Unlike d8 system, d8 status does not pre-validate the kubeconfig path; an unreachable cluster or a bad path surfaces as an error when the report runs.

The report

Output is written to stdout and always has the same shape:

Generated by Deckhouse CLI v1.x.y          (faint byline: the d8 version that produced the report)
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃      Cluster Status Report     ┃          (cyan header)
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

┌ Master Nodes Status:                       (nine sections, in the order listed below,
├ ...                                          each drawn with ┌ ├ └ │ box characters)
...

A few properties are worth knowing:

• Colors auto-strip when piped. Colorization uses fatih/color, which detects a non-terminal stdout, so d8 status > report.txt (or piping into less/tee) yields clean plain text suitable for tickets and CI logs.
• Sections are independent and best-effort. Each section is collected on its own; if one fails it prints a red Error getting <section>: ... line and the rest of the report still renders. A single unreachable resource never aborts the whole report.
• Read-only. Every section performs get/list calls (plus one controller queue list exec); nothing in the cluster is modified.
• Empty states are marked, not errored. A section with no matching objects prints a yellow notice (❗ No ... found, or ✅ No Cluster Alerts found) rather than a red error.

Report sections

The report always contains these nine sections, in this order:

Section behaviors that are easy to miss:

• Edition reads a single annotation on the deckhouse Deployment. If the annotation is absent, the section renders a red error rather than an empty notice.
• ModuleConfig settings dumps spec.settings verbatim as an indented tree, masking credentials: any value under a key whose name contains password, secret, token, license, dockercfg, apikey, accesskey, or credential (case-insensitive) is replaced with ***, and that masking is inherited by everything nested beneath such a key. When spec.settings is empty the section prints nothing at all - no header, no placeholder.
• Cluster Alerts groups duplicate alerts (same severity + name) into a single row with a SUM count; the per-alert phase is read but not shown.
• Modules is filtered client-side to entries whose name contains cni, and its ENABLED / READY columns are derived from the module's status.conditions (EnabledByModuleConfig / EnabledByModuleManager, and IsReady). A cluster whose CNI module is named differently may show ❗ No CNI modules found.
• Deckhouse Queue is the only section that leaves the API server: it opens an exec stream into the pod labeled app=deckhouse,leader=true in d8-system (container deckhouse) and runs deckhouse-controller queue list. Note this differs from d8 system queue, which curls the controller's HTTP self-API instead.

Data sources and prerequisites

• Namespaced reads (d8-system): Deckhouse Pods, Edition (the deckhouse Deployment), Registry (the deckhouse-registry Secret), and the Queue leader pod.
• Cluster-scoped reads: Master Nodes, Deckhouse Releases, Cluster Alerts, Modules, and the deckhouse ModuleConfig.
• RBAC: you need read access (get/list) to the resources above, plus - for the queue section specifically - permission to create pods/exec in d8-system. The deckhouse-controller binary must exist in the deckhouse container (it does in a normal install). If there is no leader=true pod, only the queue section errors; the rest of the report is unaffected.
• Sensitivity: although ModuleConfig credentials are masked, a saved report still contains the registry host, node IP addresses, and alert text. Treat it accordingly when attaching it to a ticket.

Examples

# Full status report
d8 status

# Plain text (colors are auto-stripped when redirected) for a ticket or CI log
d8 status > cluster-status.txt

# Run against a specific cluster / context
d8 status --kubeconfig ~/.kube/prod.config --context prod

# Quick control-plane glance
d8 status | sed -n '/Master Nodes/,/Deckhouse Pods/p'

Notes

• Age formatting (the pod AGE and release TRANSITIONTIME columns) is humanized to the two largest non-zero units, e.g. 2d 3h, 3h 4m, 5m 7s, 9s. An unset or zero timestamp shows <unknown>; a release timestamp that cannot be parsed shows Parse Error.
• Column widths adapt to the longest node/alert name, and over-long names are truncated with a ... suffix so rows stay aligned.
• The report is generated fresh on every run; there is no caching, no watch mode, and no machine-readable (JSON/YAML) output format - it is a human-facing snapshot. For scriptable queue output use d8 system queue; for module state use d8 system module list.