> For the complete documentation index, see [llms.txt](https://docs.tensorwave.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tensorwave.com/kubernetes/health-overview.md).
# Health Overview
The Kubernetes section of the **Health** tab gives you a glance summary of your cluster's Kubernetes workload health. Unlike the Kubernetes tab, which lets you drill into individual resources, this view is designed for quick status checks and early problem detection.
To access it, navigate to your cluster and select the **Health** tab. The Kubernetes section will appear on the page alongside other cluster health information.
***
### Namespace Filter
A **Namespace** dropdown at the top of the section lets you filter all cards by a specific Kubernetes namespace. By default it is set to **All Namespaces**, which aggregates metrics across the entire cluster. Select a specific namespace to scope the view down to the workloads running within it.
***
### Node Health
The **Node Health** card shows the readiness state of every node in your cluster.
| Metric | Description |
| --------------- | ------------------------------------------------------------------------------------------------------------------------ |
| **Ready** | The number of nodes that are healthy and available to schedule workloads. Displayed in green. |
| **Not Ready** | The number of nodes that are unhealthy or unavailable. Displayed in red. Any non-zero value here warrants investigation. |
| **Readiness** | A percentage representing the proportion of nodes currently in a Ready state, shown as a progress bar. |
| **Total Nodes** | The total number of nodes across the cluster, shown below the progress bar. |
***
### Pod Status
The **Pod Status** card displays a donut chart summarizing the state of all pods in the cluster (or selected namespace).
The total pod count is shown at the center of the chart. The legend below it breaks pods down by phase:
| Phase | Description |
| ------------- | ----------------------------------------------------------------------- |
| **Running** | Pods that are actively running and have at least one container started. |
| **Succeeded** | Pods that have completed successfully and exited cleanly. |
> **Note:** If pods appear in unexpected states such as `Pending`, `Failed`, or `Unknown`, they will also appear in the chart. Investigate any pods not in a `Running` or `Succeeded` state.
***
### Deployments
The **Deployments** card shows a summary of the health of all Kubernetes Deployments in the cluster.
The card displays the number of available Deployments out of the total (e.g. `54 / 54 available`). When all Deployments are healthy, the message **All deployments healthy** is shown. If any Deployments are degraded or unavailable, the count will reflect this and the healthy message will not appear.
***
### Slurm Node States
The **Slurm Node States** card summarizes the state of nodes managed by the Slurm workload manager running alongside Kubernetes (if applicable) on your cluster.
The header shows the number of **active** nodes out of the **total** Slurm managed nodes, along with a progress bar. Below that, each state is broken down individually:
| State | Indicator | Description |
| ---------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Idle** | Green | Nodes that are available and waiting to be assigned a job. |
| **Allocated** | Blue | Nodes currently assigned to one or more running jobs. |
| **Mixed** | Green | Nodes that are partially allocated, with some resources in use and some available. |
| **Down** | Red | Nodes that Slurm has marked as unavailable. A non-zero value here may indicate a hardware or configuration issue. |
| **Drained / Draining** | Orange | Nodes that have been manually taken out of service. A draining node is finishing existing jobs before going offline, a drained node is fully offline and accepting no new work. |
***
### Slurm Job Queue
The **Slurm Job Queue** card shows the number of jobs currently in the Slurm queue, broken down by state. The total job count is displayed prominently at the top of the card.
| State | Indicator | Description |
| ----------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Running** | Green | Jobs that are actively executing on one or more nodes. |
| **Pending** | Orange | Jobs that are queued and waiting for resources to become available. A high pending count may indicate resource contention or that nodes are down. |
| **Other** | Gray | Jobs in any other state, such as completing, suspended, or held. |
### Note: Downloading Your Kubeconfig
Each cluster page includes a **Kubeconfig** download button in the top header, next to the cluster name. Clicking this button downloads a kubeconfig file for your cluster, which you can use to authenticate and interact with it via `kubectl` from your local machine.
> **Note:** Keep your kubeconfig file secure. It contains credentials that grant access to your cluster.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.tensorwave.com/kubernetes/health-overview.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.