Cluster Status and Health

Use cluster status and health information to determine whether a cluster is ready for workloads, needs attention, or is still completing a lifecycle operation. Cluster status is the first signal, but member node readiness, admin state, and notifications together give the complete picture.

Start from the Clusters List

Open Infrastructure > Fleet > Clusters. The list shows each cluster with its name, Status, member count, project, and age. Use the Status filter to narrow the list to clusters in a particular state. If your enterprise has at least one cluster running in ZEDEDA Edge Kubernetes Service mode, the list also shows a Mode column (Edge Node Cluster, K8s Cluster, or Imported K8s Cluster) and a matching Mode filter. A cluster that uses two-node HA with a witness shows a Two-node HA badge in the Mode column. Its Status column shows the HA state instead of the run state once the controller reports one.

Separate the Signals

Status, admin state, node readiness, and notifications answer different questions.

Signal	What it tells you	Where to check
Status	The cluster’s current operational run state.	Cluster list and detail page ribbon
Admin state	Whether the cluster is administratively active, inactive, or in transition.	Cluster detail page ribbon
Member node readiness	Whether each member node is healthy and accepting workloads.	Cluster detail Nodes tab and Overview topology tile
Notifications	Errors, warnings, and notices reported by EVE-OS (Edge Virtualization Engine) for the cluster.	Notifications bell in the detail page header
Two-node HA state	Quorum health of a two-node HA cluster, including the witness and per-node recovery.	Cluster list Status column and the Two-node HA panel on the Overview tab
EVE-OS upgrade status	Progress or failure of an EVE-OS upgrade applied to the cluster.	Banner on the detail page when an upgrade is in progress

Interpret Cluster Status

The Status field shown in the cluster list and on the detail page ribbon reflects the cluster’s operational run state. The cluster list and the detail page use the same label and the same color for a given run state.

Status	Color	Meaning	Usual next check
Online	Green	The cluster is reachable and healthy.	Confirm member node readiness and application health.
Provisioned	Blue	The cluster completed provisioning and is coming into service.	Wait for the status to reach Online, then confirm member node readiness.
Provisioning	Amber	The cluster is initializing or completing setup.	Wait for provisioning to complete, then confirm the status updates to Online.
Unprovisioned	Purple	The cluster record exists but the cluster has not been provisioned yet. For an imported Kubernetes cluster, this means you have not yet run the registration commands.	For an imported cluster, run the registration commands from the cluster detail page. For other clusters, confirm that member nodes are online.
Partially Healthy	Amber	Some, but not all, of the cluster is healthy.	Review the Nodes tab for Not Ready members and open notifications.
Unhealthy	Amber	The cluster is reachable but reporting an unhealthy state.	Review the Nodes tab, open notifications, and inspect member node health.
Suspect	Amber	The cluster is reachable but behaving unexpectedly.	Review the Nodes tab for Not Ready members, open notifications, and check recent events.
Error	Red	The cluster has entered an error state.	Open notifications for the error message, review the Nodes tab, and inspect member node health.
Offline	Red	The cluster is not reachable.	Verify that member nodes are powered on and connected. Check each node’s status under Infrastructure > Fleet > Nodes.
Halted	Grey	The cluster is halted.	Confirm that the halt was intentional and check the admin state.
None	Grey	The cluster has not reported a run state.	Wait for member nodes to report. If the state persists, check node connectivity.

Any run state that is not in the preceding table appears with its name formatted for display and a grey indicator. If no run state data is available, the Status field shows a dash. This typically occurs when a cluster was just created and member nodes have not yet reported their state.

Interpret Two-Node HA State

On a cluster that uses two-node HA with a witness, the HA state replaces the run state in the cluster list Status column. The Two-node HA panel on the cluster Overview tab shows the same state with the witness status, recovery generation, and per-node recovery rows. See Manage Two-Node HA.

HA state	Color	Meaning	Usual next check
Healthy	Green	Both nodes are Ready and online, and the witness joined at the configured address.	No action needed.
Restoring	Blue	Membership, readiness, or the witness has not finished converging.	Wait, then review the Witness field and the Node recovery rows.
Degraded	Red	One node is hosting etcd and the witness. The cluster has no redundancy until you add a replacement node.	Replace the failed non-seed node, or reset the quorum if the seed failed permanently.
Unknown	Amber	Cluster information is stale while members remain reachable, so health cannot be trusted.	Wait for fresh status. Check node connectivity if the state persists.
Unreachable	Amber	No cluster member is reachable from the controller. This is a connectivity problem, not necessarily a quorum problem.	Verify node power and connectivity before you consider a quorum reset.

A cluster can report Degraded while both nodes are still configured members, for example when only one node reports Ready. The no physical redundancy banner appears only when the cluster has one configured node, which happens after a quorum reset. A cluster keeps its Two-node HA badge while it runs on one node. The Witness field shows Pending until the node reports that the witness joined the configured address. After a quorum reset, the configured witness address changes, so the witness shows Pending until the surviving node reports the new address.

Interpret Admin State

The admin state appears as a secondary label in the cluster ribbon. It reflects the cluster’s administrative lifecycle and is separate from the operational run state shown in Status.

Admin state	Meaning
Active	The cluster is administratively enabled and operational.
Registered	The cluster is registered but not yet activated.
Inactive	The cluster is administratively disabled.
Deleting	A deletion is in progress.
Created	The cluster record exists but activation has not started.
Deleted	The cluster has been deleted.
Unknown	The admin state cannot be determined.

Review the Cluster Overview

Open a cluster from the list to see a detailed health view. The Overview tab is the default landing view and provides a snapshot across the following areas.

Area	What to inspect
Cluster ribbon	Status, member count (for example, 2/3 ready), last updated, type, project, and applications.
Cluster topology	Ready, Not Ready, and Unspecified member counts, plus role breakdown (Server, Agent, Tie Breaker). Use this tile to identify how many nodes are currently healthy.
Identity	Confirm admin state is Active and run state reflects the expected status. Verify that the project assignment is correct.
Workloads	Check whether applications are present and whether any show a non-Online run state.

Move to the Nodes tab when the topology tile shows Not Ready members. Move to the Applications tab when workloads are not running as expected. For a full description of each tab and its fields, see Manage Clusters.

Interpret Member Node Readiness

The Nodes tab and the cluster topology tile surface member node readiness. Readiness is a Kubernetes-level signal that reflects whether each node is healthy from the cluster’s perspective, independent of its EVE-OS-level status.

Readiness	Indicator	Meaning
Ready	Green	The node is healthy and accepts workload scheduling.
Scheduling Disabled	Amber	The node is cordoned. It is reachable but will not accept new workload pods.
Not Ready	Red	The node is unhealthy and does not accept workload scheduling.
Unspecified	Muted	The node has not reported readiness data yet.

A Ready node might also report secondary conditions that appear alongside the primary readiness label. These indicate resource pressure that has not taken the node offline.

Secondary condition	Meaning
Memory Pressure	The node has insufficient available memory.
Disk Pressure	The node has insufficient available disk space.
PID Pressure	The node has too many running processes.
Network Unavailable	The node’s network configuration is incorrect or unavailable.

For example, a node can show Ready, Disk Pressure, which means it is accepting workloads but is approaching a resource limit that might affect future scheduling.

Review Health Signals

Notifications

The Notifications bell appears in the cluster detail page header. A color-coded badge on the bell shows the count and highest severity:

Red badge: one or more errors are present.
Amber badge: one or more warnings are present, no errors.
Blue badge: one or more notices are present, no errors or warnings.

When no notifications are present, the panel shows All clear. Select the bell to view each notification with its severity, explanation, and suggested fix. Notifications come from the cluster’s EVE-OS error information and use the same structure as node notifications. When an EVE-OS upgrade is in progress or has completed, a banner appears on the cluster detail page. The banner color reflects the upgrade status.

Banner color	Meaning
Amber	The upgrade is in progress (downloading, upgrading, installing, or pending).
Green	The upgrade completed successfully.
Red	The upgrade failed or encountered an error.

If the banner shows red, open notifications for the specific error message.

Readiness Checklist

A cluster is generally ready for workloads when:

Status is Online.
Admin state is Active.
The topology tile shows all members as Ready with no secondary conditions.
No errors or warnings appear in the notifications panel.
Applications on the cluster are in an Online run state.
No EVE-OS upgrade is in progress.

Troubleshoot by Symptom

Symptom	What to check first
Cluster is Offline	Verify that member nodes are powered on and reachable. Check each node’s status under Infrastructure > Fleet > Nodes.
Cluster is Suspect or Error	Open notifications on the cluster detail page. Review the Nodes tab for Not Ready members and inspect those nodes individually.
Cluster shows Provisioning for an extended period	Confirm that all member nodes are online and that the cluster network interface is correctly configured on each node.
Cluster shows Unprovisioned	For an imported Kubernetes cluster, run the registration commands from the cluster detail page. For other clusters, confirm that all member nodes are online and reporting.
One or more members show Not Ready	Open the Nodes tab and review the readiness conditions on affected nodes. Check the corresponding node detail pages for EVE-OS errors or resource pressure.
Members show secondary conditions (Disk Pressure, Memory Pressure)	Address the resource constraint on the affected node. Secondary conditions that persist might eventually cause the node to transition to Not Ready.
Applications are not running on the cluster	Check the Applications tab for application run states. Verify that all member nodes are Ready. Review the Virtual Interfaces tab for network issues.
Two-node HA cluster shows Degraded	Open the Two-node HA panel and the Nodes tab. Replace the failed non-seed node, or reset the quorum if the seed node failed permanently.
Two-node HA cluster shows Unreachable	Verify that the nodes are powered on and connected. Do not reset the quorum to fix a connectivity problem.
EVE-OS upgrade banner shows red	Open notifications for the specific error message. Verify the upgrade status with `zcli edge-node-cluster show <name> --upgrade`.

Next Steps

Manage Clusters

Operations such as update, replace a node, and delete.

App Instance Failover in Clusters

Understand how applications behave during node failures.

Node Status and Health

Interpret the health of individual member nodes.

Upgrade EVE-OS on a Cluster

Upgrade EVE-OS on a cluster with ZCLI.

Start Here

Infrastructure Services Overview

Core infrastructure

Build

Applications and delivery

Edge Kubernetes

Operations

Monitor

Administration and Security

Troubleshooting

Partnerships

Start from the Clusters List

Separate the Signals

Interpret Cluster Status

Interpret Two-Node HA State

Interpret Admin State

Review the Cluster Overview

Interpret Member Node Readiness

Review Health Signals

Notifications

EVE-OS upgrade banner

Readiness Checklist

Troubleshoot by Symptom

Next Steps

Manage Clusters

App Instance Failover in Clusters

Node Status and Health

Upgrade EVE-OS on a Cluster

​Start from the Clusters List

​Separate the Signals

​Interpret Cluster Status

​Interpret Two-Node HA State

​Interpret Admin State

​Review the Cluster Overview

​Interpret Member Node Readiness

​Review Health Signals

​Notifications

​EVE-OS upgrade banner

​Readiness Checklist

​Troubleshoot by Symptom

​Next Steps

Manage Clusters

App Instance Failover in Clusters

Node Status and Health

Upgrade EVE-OS on a Cluster

Start from the Clusters List

Separate the Signals

Interpret Cluster Status

Interpret Two-Node HA State

Interpret Admin State

Review the Cluster Overview

Interpret Member Node Readiness

Review Health Signals

Notifications

EVE-OS upgrade banner

Readiness Checklist

Troubleshoot by Symptom

Next Steps