--- title: Kubernetes cross-cluster UI source: https://docs.newrelic.com/docs/kubernetes-pixie/kubernetes-integration/understand-use-data/kubernetes-cross-cluster --- > #### 💡 PREVIEW > > We're still working on this feature, but we'd love for you to try it out! > > This feature is currently provided as part of a preview program pursuant to our [pre-release policies](https://docs.newrelic.com/docs/licenses/license-information/referenced-policies/new-relic-pre-release-policy). Modern Kubernetes environments have evolved into complex, **multi-cluster fleets**, but traditional observability tools often provide only a fractured, siloed view of individual clusters. This Kubernetes cross-cluster UI provides a unified command center that transforms this multi-cluster complexity into fleet-wide clarity. This unified view helps Platform Engineers and SREs to: - **Unify fleet-wide observability** on a single dashboard that's compatible with clusters monitored by New Relic agents or OpenTelemetry. - **Accelerate root cause analysis** with a guided triage workflow. - **Reduce costs** by identifying wasted resources across the entire fleet. - **Empower developers** with an application-centric view for self-service. ![K8s cross-cluster UI](https://docs.newrelic.com/images/k8s-cross-cluster.webp "K8s cross-cluster UI") ## Access the new UI [#access] You can access the new Kubernetes cross-cluster UI from the Kubernetes option in the left navigation in the New Relic platform. To access the Kubernetes cross-cluster UI: 1. Go to **[one.newrelic.com > All capabilities](https://one.newrelic.com/all-capabilities) > Kubernetes** 2. Click the **Try it out** button at the top right corner of the page. The Kubernetes cross-cluster UI is structured to provide both a high-level overview and deep-dive capabilities into your entire Kubernetes fleet. The main components of the UI include: - **Feedback button**: Lets you easily share feedback on your experience with the UI. - **Entity filters**: Filter and triage issues using **tags and values** at the **cluster or node level**. - **Cluster filter**: Filter to isolate the UI to a single or smaller set of Kubernetes clusters. - **Colored scorecards**: Display relevant high-level metrics to surface the most important issues that need attention across the entire fleet. - Clicking a scorecard **orders the table** in the context of that metric, surfacing the clusters and nodes with the most critical issues at the top. - It also enables a **line chart** to visualize the metric's evolution over the selected time range. - **Line chart**: Provides the **evolution of the metric** over the selected time frame for trend analysis. - **Table**: Lists all entities in the fleet and provides **detailed metric data** for each cluster under the five main tabs. - **Health focus**: The table provides a filter to only list "unhealthy" entities to focus your attention where it is really needed. - **Search**: A text search bar allows you to filter table rows based on **free text** entered. - **Color-coding**: Like the scorecards, table cells are color-coded (Yellow, Red) to quickly draw attention to entities with issues that meet a specific **severity threshold**. ## Drill-down capabilities for triage [#drill-down] The cross-cluster UI is specifically designed to accelerate root cause analysis with a **guided triage workflow**. The primary mechanism for this deep investigation is the ability to drill down from a fleet-wide metric to a single cluster's view: - **From scorecard to cluster ranking:** When you click a **colored scorecard** (e.g., Unhealthy Pods), the clusters table immediately re-sorts. This places the clusters with the worst performance for that specific metric at the top, enabling you to identify where the issue is most critical across your entire fleet. - **From table metric to Kubernetes navigator:** Click a metric value within any cell of the table for a specific cluster or node to automatically launch the **Kubernetes navigator**. The navigator's view is automatically **predefined/filtered** for that specific cluster and metric of interest, allowing you to continue your investigation with a deep dive. ## Tab-specific metrics [#tab] The UI is organized into five main tabs: - [Overview](#overview) - [Health](#health) - [Performance](#performance) - [Resources](#resources) - [Workloads](#workloads) Each tab provides specific metrics both at the aggregate (Scorecard) and cluster/node (Metric) level, along with their associated color-coded thresholds for quick triage. **Overview tab** The **Overview** tab provides a general summary of the **operational health, capacity, and risk** across your entire Kubernetes fleet. | Metric name | Scorecard | Metric (cluster/node) | Importance | Thresholds | | ------------------------------- | ------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | | `Total Clusters` | The total count of Kubernetes clusters currently reporting telemetry. | N/A | Verifies the connectivity and scope of your entire fleet monitoring estate. | N/A | | `Unhealthy Nodes` | Percentage of nodes in the fleet reporting `NotReady` or `Unknown`. | Percentage of nodes in the specific cluster reporting `NotReady`. | Signals widespread instability and potential zone failures across the infrastructure. | `Fleet:` Yellow: 1% to 5%; Red: 5%. `Cluster:` Yellow: 1% to 5%; Red: 5%. | | `Unhealthy Pods` | Percentage of pods in the fleet in `Pending, Failed, or Unknown` states. | Percentage of pods in the specific cluster in `Pending, Failed, or Unknown` states. | Measures widespread application instability across all clusters. | `Fleet:` Yellow: 1% to 5%; Red: 5%. `Cluster:` Yellow: 1% to 5%; Red: 5%. | | `Unhealthy Workloads` | Count of workloads (Deployments, Daemonset or Statefulsets) in the fleet with `missing replicas`. | Count of workloads in the specific cluster with `missing replicas`. | Indicates failure to reconcile desired states across the organization. | `Fleet:` Yellow: 1 to 5; Red: 6. `Cluster:` Yellow: 1 to 3; Red: 4. | | `CPU Usage % vs Allocatable` | Percentage of total fleet CPU capacity currently consumed. | Percentage of the specific cluster's CPU capacity currently consumed. | Measures aggregate node saturation risk across the entire estate. | Yellow: 75% to 95%; Red: 95-100%. | | `Memory Usage % vs Allocatable` | Percentage of total fleet memory capacity currently consumed. | Percentage of the specific cluster's memory capacity currently consumed. | High values indicate risk of aggregate eviction storms across clusters. | Yellow: 75% to 95%; Red: 95-100%. | | `Ephemeral Storage %` | % of `disk capacity` consumed across fleet. | % of `disk capacity` consumed. | Critical to prevent Kubelet crashes. | Yellow: 80% to 95%; Red: > 95%. | | `Persistent Storage %` | % of persistent volume capacity consumed across fleet. | % of persistent volume capacity consumed. | Critical to prevent stateful application crashes and data write failures. | Yellow: 80% to 95%; Red: > 95%. | | `Warning Events` | Number of `Warning type K8s cluster events` across the fleet. | Number of `Warning type K8s cluster events` in this cluster. | High noise levels obscure critical alerts and indicate config debt. | `Fleet:` Yellow: 1 to 50; Red: 50. `Cluster:` Yellow: 1 to 20; Red: 21. | **Health tab** The **Health** tab focuses on metrics related to the **availability and current status** of your nodes and pods to detect immediate failure risks. | Metric name | Scorecard | Metric (cluster/node) | Importance | Thresholds | | ----------------------- | ---------------------------------------------------------------- | ----------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | `Nodes Total` | Total count of nodes detected in the fleet. | Count of nodes in the specific cluster. | Zero indicates fundamental control plane failure. | Red: 0. | | `Nodes Ready` | Percentage of nodes in the fleet reporting `Ready` status. | Percentage of nodes in the cluster reporting `Ready` status. | Availability metric; values below 95% signal severe fleet instability. | `Fleet:` Yellow: 95% to 99%; Red: < 95%. `Cluster:` Yellow: 99%; Red: < 99%. | | `Nodes Memory Pressure` | Percentage of nodes in fleet rejecting pods due to `low memory`. | Percentage of nodes in cluster rejecting pods due to `low memory` at cluster level. | Predicts widespread eviction storms. | `Fleet:` Yellow: >0% to 5%; Red: ≥ 6%. `Cluster:` Yellow: >0% to <1%; Red: ≥ 1%. | | `Nodes Disk Pressure` | Percentage of nodes in fleet with `low disk availability`. | Percentage of nodes in cluster with `low disk availability` at cluster level. | Risk of widespread node failures due to disk exhaustion. | `Fleet:` Yellow: >0% to 5%; Red: ≥ 6%. `Cluster:` Yellow: >0% to <1%; Red: ≥ 1%. | | `Pods Running` | Percentage of fleet pods successfully in `Running` phase. | Percentage of cluster pods successfully in `Running` phase. | Operational success rate; <90% indicates widespread failure. | `Fleet:` Yellow: 90% to 94%; Red: < 90%. `Cluster:` Yellow: 95% to 99%; Red: < 95%. | | `Pods Pending` | Sustained count of pods `waiting to be scheduled` across fleet. | Sustained count of pods `waiting to be scheduled`. | Indicates scheduler failure or capacity starvation. | `Fleet:` Yellow: 1 to 5; Red: ≥ 6. `Cluster:` Yellow: 1; Red: ≥ 2. | | `Container Restarts` | Count of restarts `per period` across the fleet. | Count of restarts `per period`. | Symptom of CrashLoopBackOff or OOMKills. | `Fleet:` Yellow: 1 to 5; Red: 6. `Cluster:` Yellow: 1; Red: 2. | | `Network Errors / sec` | Rate of `packet drops/errors` across the fleet. | Rate of `packet drops/errors`. | Symptom of hardware failure or systemic CNI issues. | `Fleet:` Yellow: 11 to 50; Red: > 50. `Cluster:` Yellow: 5 to 10; Red: > 11. | **Performance tab** The **Performance** tab measures **utilization against total capacity and limits** to identify node saturation and risk of performance degradation. | Metric name | Scorecard | Metric (cluster/node) | Importance | Thresholds | | ------------------------------- | ---------------------------------------------------- | ------------------------------------------- | -------------------------------------------------- | ----------------------------------------------------------------------------------- | | `CPU Usage % vs Allocatable` | % of fleet `CPU capacity` used. | % of cluster/node `CPU capacity` used. | Measures saturation risk across the entire estate. | Yellow: 75% to 95%; Red: 95-100%. | | `CPU Usage % vs Limits` | % of `CPU hard limits` consumed across fleet. | % of `CPU hard limits` consumed in cluster. | Measures proximity to throttling. | Yellow: 75% to 95%; Red: 95-100%. | | `Memory Usage % vs Allocatable` | % of fleet `memory capacity` used across fleet. | % of cluster/node `memory capacity` used. | Proximity to eviction thresholds. | Yellow: 75% to 95%; Red: 95-100%. | | `Memory Usage % vs Limits` | % of `memory hard limits` consumed across fleet. | % of `memory hard limits` consumed. | Proximity to OOMKill events. | Yellow: 75% to 95%; Red: 95-100%. | | `Ephemeral Storage %` | % of `disk capacity` consumed across fleet. | % of `disk capacity` consumed. | Critical to prevent Kubelet crashes. | Yellow: 80% to 95%; Red: > 95%. | | `Pods Capacity %` | % of `max allowed pod count` scheduled across fleet. | % of `max allowed pod count` scheduled. | Measures resource density and slot exhaustion. | `Fleet:` Yellow: 85% to 100%; Red: 100%. `Cluster:` Yellow: 85% to 100%; Red: 100%. | **Resources tab** The **Resources** tab analyzes **Request vs. Usage and Request vs. Limits** to assess resource allocation efficiency and identify waste or sizing inaccuracies. | Metric name | Scorecard | Metric (cluster/node) | Importance | Thresholds | | ---------------------------- | ------------------------------------------------------- | ---------------------------------------------- | ------------------------------------------------------------------------------ | -------------------------------------------------------------- | | `CPU Usage % vs Request` | % of `CPU usage vs requests` across fleet. | % of `CPU usage vs requests`. | Governance metric for sizing accuracy and waste. | Yellow: < 70% or > 200%. | | `CPU Request % vs Limits` | % of `CPU request vs limit` across fleet. | % of `CPU request vs limit`. | Measures performance headroom and burst capacity. | Yellow: 75% to 95%; Red: 95-100%. | | `CPU Throttling %` | Ratio of `throttled time to active time` across fleet. | Ratio of `throttled time to active time`. | Measures latency/lag caused by CFS quotas. | `Fleet:` Yellow: 10% to 50%; Red: 50%. | | `Memory Usage % vs Request` | % of `memory usage to requests` across fleet. | % of `memory usage to requests`. | Governance metric for memory sizing accuracy. | Yellow: < 70% or > 200%. | | `Memory Request % vs Limits` | % of `limit reserved by requests` across fleet. | % of `limit reserved by requests`. | Helps to assess resource allocation efficiency and potential overprovisioning. | Yellow: 75% to 95%; Red: 95-100%. | | `Pod Evictions` | Count of `forced pod terminations by Kubelet` in fleet. | Count of `forced pod terminations by Kubelet`. | Symptom of node resource starvation. | `Fleet:` Yellow: 1 to 5; Red: 6. `Cluster:` Yellow: 1; Red: 2. | **Workloads tab** The **Workloads** tab provides an application-centric view, focusing on metrics such as **restarts, and missing replicas** to diagnose application instability and poor QoS. | Metric name | Scorecard | Metric (cluster/node) | Importance | Thresholds | | ----------------------------- | -------------------------------------------------- | ------------------------------------------------------- | --------------------------------------------------- | --------------------------------------------------------------- | | `CPU Usage % vs Limits` | % of `CPU hard limits` consumed by workloads. | % of `CPU hard limits` consumed by specific workload. | Measures performance cap proximity. | Yellow: 75% to 95%; Red: 95-100%. | | `Memory Usage % vs Limits` | % of `memory limits` consumed across workloads. | % of `memory limits` consumed by specific workload. | Proximity to OOMKill. | Yellow: 75% to 95%; Red: 95-100%. | | `Pods Total` | Total count of pods in fleet workloads. | Total count of pods for specific workload. | Baseline metric for capacity. | Red: 0. | | `Pods Unavailable` | Pods. | Pods Pod running, scheduling, or ready in the workload. | Indicates service availaility. | `Fleet:` Yellow: 1 to 5; Red: 6. `Workload:` Yellow: 1; Red: 2. | | `Pods Missing` | Gap between `desired and ready replicas` in fleet. | Gap between `desired and ready replicas` for workload. | Indicates service degradation. | `Fleet:` Yellow: 1 to 5; Red: 6. `Workload:` Yellow: 1; Red: 2. | | `Pod Evictions` | Count of `evictions` for workloads in fleet. | Count of `evictions` for specific workload. | Workload is causing node pressure or misconfigured. | `Fleet:` Yellow: 1 to 5; Red: 6. `Workload:` Yellow: 1; Red: 2. | | `Container Restarts` | Count of `restarts` for workloads in fleet. | Count of `restarts` for specific workload. | Persistent failure state (CrashLoopBackOff). | `Fleet:` Yellow: 1 to 5; Red: 6. `Workload:` Yellow: 1; Red: 2. | | `Container Images Restarting` | Restarts caused by `image/config errors` in fleet. | Restarts caused by `image/config errors` for workload. | Specific symptom of registry failure or bad tags. | `Fleet:` Yellow: 1; Red: 2. `Workload:` Yellow: 1; Red: 2. |