Cluster Operations Dashboard Scripts

This document describes how to use pod-list.sh, pod-stat.sh, and node-list.sh from dashboard.tar.gz for routine inspection and resource troubleshooting in a deployed NineData high-availability cluster.

Common Use Cases

Quickly review Pod status, node placement, and real-time resource usage across namespaces.
Continuously watch CPU, memory, and network throughput for a specific critical Pod.
Inspect node-level CPU, memory, disk usage, and Pod request watermarks for capacity analysis and fault diagnosis.

Before you begin

Upload dashboard.tar.gz to a host that can access the NineData Kubernetes cluster. Running the scripts on any Master node is recommended.
The current environment must have a working kubectl context and permissions to read Pods, Nodes, the Metrics API, and the Node Proxy API.
metrics-server must be healthy in the cluster. Otherwise, CPU and memory values in pod-list.sh and node-list.sh may be reported as 0.
The package already includes a jq binary. If that binary cannot run on the current host, install a host-level jq; the scripts use the host-level binary first when available.

Prepare the Scripts

Extract the package and enter the directory.

   tar -zxvf dashboard.tar.gz
   cd dashboard

Add execute permissions to the scripts and bundled jq.

   chmod +x pod-list.sh pod-stat.sh node-list.sh jq

If the bundled jq is not usable, install a system jq.

   yum install -y jq

   apt-get update && apt-get install -y jq

List Pods: `pod-list.sh`

pod-list.sh filters Pods by namespace, node, Pod name, and status, then shows creation time, current status, assigned node, real-time CPU / memory, requests, and limits.

Command Syntax

./pod-list.sh [Options]

Options

Option	Description
`-n, --namespace `	Filter by namespace. Use commas to provide multiple namespaces.
`-N, --node `	Filter by node name.
`-p, --pod `	Fuzzy match Pod names.
`-s, --status `	Filter by Pod status, such as `Running` or `Succeeded`.
`--sort `	Sort by actual CPU or memory usage.
`--asc`	Sort in ascending order. Descending is the default.
`-h, --help`	Show help.

Output Columns

Column	Description
`NAMESPACE`	Kubernetes namespace of the Pod.
`POD_NAME`	Pod name.
`CREATED`	Pod creation timestamp.
`STATUS`	Current Pod phase, such as `Running`, `Pending`, or `Succeeded`.
`NODE`	Node where the Pod is scheduled.
`CPU`	Real-time CPU usage in millicores.
`MEMORY`	Real-time memory usage.
`REQUEST`	Aggregated CPU / memory requests for the Pod.
`LIMIT`	Aggregated CPU / memory limits for the Pod.

Examples

./pod-list.sh
./pod-list.sh -n jz-component,jzcloud-console
./pod-list.sh --sort cpu
./pod-list.sh -p nginx --sort mem --asc
./pod-list.sh -N worker-01 -s Running

Sample Output

NAMESPACE         POD_NAME                                   CREATED              STATUS     NODE           CPU  MEMORY  REQUEST       LIMIT
----------------  -----------------------------------------  -------------------  ---------  -------------  ---  ------  ------------  ------------
default           rp-dhcec38w47mw-full-s2rtm                 2026-03-26 03:50:58  Pending    -              0m   0Mi     2000m/2048Mi  2000m/2048Mi
default           rp-dhcec38w47mw-reader-inc-reader-mzgpq    2026-03-26 03:33:43  Running    192.168.2.178  13m  426Mi   1000m/2048Mi  1000m/2048Mi
jz-component      kafka-0                                    2026-03-25 07:04:58  Running    192.168.2.178  13m  459Mi   50m/200Mi     1000m/2048Mi
jz-component      ninedata-meta-cluster-0                    2026-03-25 06:51:53  Running    192.168.2.178  34m  1013Mi  0m/0Mi        0m/0Mi
jzcloud-console   jzcloud-console-5d789db8c4-6f4vm           2026-03-25 06:57:41  Running    192.168.2.178  13m  1115Mi  30m/600Mi     1000m/2048Mi
jzcloud-console   jzcloud-console-frontend-7589776cd9-zzx5b  2026-03-25 06:57:40  Running    192.168.2.178  68m  5Mi     1m/10Mi       100m/64Mi

Monitor a Single Pod: `pod-stat.sh`

pod-stat.sh continuously monitors CPU, memory, and network throughput for a single Pod. The script resolves the current node of the Pod during each loop, so it can continue collecting metrics even after rescheduling.

Command Syntax

./pod-stat.sh <namespace> <pod_name>

If the required arguments are not provided, the script prints the help message.

Arguments

Argument	Description
`namespace`	Namespace of the Pod. Defaults to `default` when omitted.
`pod_name`	Name of the Pod to monitor.

Output Columns

Column	Description
`COLLECT_TIME`	Local collection time.
`CPU`	Real-time CPU usage in millicores, calculated from CPU nanosecond deltas.
`MEMORY`	Pod working set memory.
`NET_IN`	Incoming network throughput.
`NET_OUT`	Outgoing network throughput.

Examples

./pod-stat.sh jz-component kafka-0
./pod-stat.sh kube-system coredns-85cb-xyz

Sample Output

COLLECT_TIME         CPU        MEMORY       NET_IN          NET_OUT
------------------------------------------------------------------------------------------------
2026-03-26 16:31:53  11m        459.13MB     374B/s          148B/s
2026-03-26 16:32:09  11m        459.13MB     386B/s          154B/s

Notes

The script loops every 5 seconds internally, but it prints a new row only after the Kubelet Summary API refreshes. In practice, the visible refresh interval is usually around 10 to 15 seconds.
Seeing only the table header right after startup is normal. Wait for the next valid sample.
If the Pod has not been scheduled yet or has already been removed, the script keeps reporting that the Pod is missing or not scheduled.

Inspect Node Resource Summary: `node-list.sh`

node-list.sh provides a node-level resource summary, including node status, kubelet version, CPU, memory, root filesystem disk usage, and the aggregated Pod requests on each node.

Command Syntax

./node-list.sh [Options]

Options

Option	Description
`-N, --node `	Filter by node name.
`-s, --status `	Filter by node status, such as `Ready` or `NotReady`.
`-i, --ip `	Filter by internal IP address.
`--sort `	Sort by `cpu`, `mem`, `disk`, `req_cpu`, or `req_mem`.
`--asc`	Sort in ascending order. Descending is the default.
`-h, --help`	Show help.

Output Columns

Column	Description
`NAME`	Node name.
`STATUS`	Node readiness status.
`CREATED`	Node registration time.
`IP`	Internal node IP address.
`VERSION`	Kubelet version.
`CPU`	Real-time CPU usage.
`MEMORY`	Real-time memory usage.
`DISK`	Root filesystem usage and percentage.
`REQUEST(%)`	Aggregated Pod CPU / memory requests on the node and their percentages of allocatable capacity.
`CAPACITY`	Total allocatable CPU / memory on the node.

Examples

./node-list.sh
./node-list.sh --sort disk
./node-list.sh -s NotReady
./node-list.sh -N node-01 --sort cpu
./node-list.sh --sort req_mem --asc

Sample Output

NAME            STATUS   CREATED               IP              VERSION        CPU    MEMORY   DISK        REQUEST(%)               CAPACITY
-------------   ------   -------------------   -------------   ------------   ----   ------   ---------   ----------------------   ------------
192.168.2.178   Ready    2026-03-25 06:32:38   192.168.2.178   v1.34.3+k3s1   302m   5857Mi   36Gi(26%)   2532m(63%)/5909Mi(80%)   4000m/7344Mi

Notes

The script collects disk data from each node sequentially through the Kubelet Summary API, so runtime increases with cluster size.
DISK reflects the root filesystem (node.fs) usage of the node, not a separate application data disk.
REQUEST(%) is useful for evaluating node pressure and deciding whether scale-out or workload migration is needed.

Troubleshooting

`jq` is not found

If the script reports that jq is missing, first confirm that the bundled jq has execute permission. If it still cannot run, install a system jq and rerun the script.

CPU or memory shows `0`

This usually means metrics-server is unavailable, returning invalid data, or there is no matching real-time metric for the current Pod or node. Check:

kubectl top pod -A
kubectl top node

`pod-stat.sh` only displays the header

This usually means one of the following:

the script just started and the Kubelet Summary API has not refreshed yet;
the target Pod has not been scheduled successfully;
the current account cannot access /api/v1/nodes/<node>/proxy/stats/summary.

Disk information is empty

If DISK is abnormal in node-list.sh, verify that each node's Kubelet Summary API is reachable and returns a valid stats/summary response.

`node-list.sh` fails with `Cannot index object with null`

If node-list.sh prints the following error:

jq: error (at /tmp/tmp.xxxxx:xxxxx): Cannot index object with null

first check whether the cluster contains Pods that have not been scheduled to any node yet:

kubectl get pods -A --field-selector spec.nodeName=

This usually means the script encountered one or more Pods that have not been scheduled to any node yet while aggregating Pod requests. Update to a corrected script version that filters empty spec.nodeName values, then rerun the command.

Cluster Operations Dashboard Scripts

Common Use Cases​

Before you begin​

Prepare the Scripts​

List Pods: pod-list.sh​

Command Syntax​

Options​

Output Columns​

Examples​

Sample Output​

Monitor a Single Pod: pod-stat.sh​

Command Syntax​

Arguments​

Output Columns​

Examples​

Sample Output​

Notes​

Inspect Node Resource Summary: node-list.sh​

Command Syntax​

Options​

Output Columns​

Examples​

Sample Output​

Notes​

Troubleshooting​

jq is not found​

CPU or memory shows 0​

pod-stat.sh only displays the header​

Disk information is empty​

node-list.sh fails with Cannot index object with null​

Related Documents​

Common Use Cases

Before you begin

Prepare the Scripts

List Pods: `pod-list.sh`

Command Syntax

Options

Output Columns

Examples

Sample Output

Monitor a Single Pod: `pod-stat.sh`

Command Syntax

Arguments

Output Columns

Examples

Sample Output

Notes

Inspect Node Resource Summary: `node-list.sh`

Command Syntax

Options

Output Columns

Examples

Sample Output

Notes

Troubleshooting

`jq` is not found

CPU or memory shows `0`

`pod-stat.sh` only displays the header

Disk information is empty

`node-list.sh` fails with `Cannot index object with null`

Related Documents