Namespaces Data

This topic discusses the Namespaces Overview page and helps you understand its gauge charts and the data displayed on them.

About Namespaces Overview

Namespaces are virtual clusters on a physical cluster. They provide logical separation between the teams and their environments. The Namespaces Overview page provides key metrics indicating the health, capacity, and performance of each Namespace in your cluster.

Interpret the Namespaces Data

This topic gives insight into the metrics displayed on the Namespaces Overview screen.

Pod Restarts

The chart highlights the latest value returned by avg(timeAvg(kubernetes.pod.restart.rate)).

What Is It?

The sparkline shows the trend of pod restarts rate across all the pods in a selected Namespace. The number shows the most recent rate of restarts per second.

For instance, the image shows a rate of 0.04 restarts per second for the last 2-hours, given the selected time window is one day. The trend also suggests a non-flat pattern (periodic crashes).

Last hour: 6 steps, each for a 10-minute time slice
Last 6 hours: 12 steps, each for a 20-minute time slice
Last day: 12 steps, each for a 2-hour time slice

What to Expect?

Expect 0 restarts for any pod.

What to Do Otherwise?

A few restarts across the last one hour or larger time windows might not indicate a serious problem. In the event restart loop, identify the root cause as follows:

Drill down to the Workloads page in Overview to identify the Workloads that have been stuck at a restart loop.
Drill down to the Kubernetes Namespace Overview to see a detailed trend broken down by pods:

Pods Available vs Desired

The chart shows the latest value returned by sum(avg(kubernetes.namespace.pod.available.count)) / sum(avg(kubernetes.namespace.pod.desired.count)).

What Is It?

The chart displays the ratio between available and desired pods, averaged across the selected time window, in a given Namespace.

The upper bound shows the number of desired pods in the namespace.

For instance, the image below shows 42 desired pods that are available:

What to Expect?

Expect 100% on the chart.

If certain pods take a significant amount of time to become available due to delays (image pull time, pod initialization, readiness probe) you might temporarily see a ratio lower than 100%.

What to Do Otherwise?

Identify one or more Workloads that have low availability by drilling down to the Workloads page.
Once you identify the Workload, drill down to the related dashboard in Explore. For example, Kubernetes Deployment Overview to determine the trend and the state of the pods.
For instance, in the following image, the ratio is 98% (3.93 / 4 x 100). The decline is due to an update that caused pods to be terminated and consequently to be started with a newer version.

CPU Used vs Requests

The chart shows the latest value returned by sum(avg(cpu.cores.used)) / sum(avg(kubernetes.pod.resourceRequests.cpuCores)).

What Is It?

The chart shows the ratio between the total CPU usage across all the pods in the Namespace and the total CPU requested by all the pods.

The upper bound shows the total CPU requested by all the pods. The value is expressed as the number of CPU cores.

For instance, the image below shows the pods in a Namespace requests for 40 CPU cores, of which only 43% is being used (about 17 cores):

What to Expect?

The value you see depends on the type of Workloads running in the Namespace.

Typically, values that fall between 80% and 120% is considered healthy. Values higher than 100% is considered healthy relatively for a short amount of time.

For applications whose resource usage is constant (such as background processes), expect the ratio to be close to 100%.

For “bursty” applications, such as an API server, expect the ratio to be less than 100%. Note that this value is averaged for the selected time window, therefore, a usage spike would be compensated by an idle period.

What to Do Otherwise?

A low usage indicates that the application is not properly running (not executing the expected functions) or the Workload configuration is not accurate (requests are too high compared to what the pods actually need).

A high usage indicates that the application is operating with a heavy load or the workload configuration is not accurate (requests are too low compared to what pods actually need).

In either case, drill down to the Workloads page to determine the workload that requires a deeper analysis.

Can the Value Be Higher than 100%?

Yes, it can.

You can configure requests without limits, or requests lower than the limits. In either case, you are allowing the containers to use more resources than requested, typically to handle temporary overloads.
Consider a Namespace with two Workloads with one pod each. Say, one Workload is configured to request for 1 CPU core and uses 1 CPU core (ratio of Used vs Request is 100%). The other Workload is configured without any request and uses 1 CPU core. In this example, 2 CPU cores used to 1 CPU core requested ratio at the Namespace level is 200%.

Memory Used vs Requests

The chart shows the latest value returned by sum(avg(memory.bytes.used)) / sum(avg(kubernetes.pod.resourceRequests.memBytes)).

What Is It?

The chart shows the ratio between the total memory usage across all pods of the Namespace and the total memory requested by all pods.

The upper bound shows the total memory requested by all the pods, expressed in a specified unit for bytes.

For instance, the image below shows that all the pods in the Namespace requests for 120 GiB, of which only 24% is being used (about 29 GiB):

What to Expect?

It depends on the type of Workloads you run in the Namespace. Typically, values that fall between 80% and 120% are considered healthy.

Values that are higher than 100% considered normal for a relatively short amount of time.

What to Do Otherwise?

A low usage indicates the application is not properly running (not executing the expected functions) or the workload configuration is not accurate (high requests compared to what the pods actually need).

A high usage indicates the application is operating with a high load or the Workload configuration is not accurate (Fewer requests compared to what the pods actually need).

Given the configured limits for the Workloads and the memory pressure on the nodes, if the Workloads use more memory than what’s requested they are at risk of eviction. See Exceed a Container’s Limit for more information.

In both cases, you may want to drill down to the Workloads page to determine which Workload requires a deeper analysis.

Can the Value Be Higher than 100%?

Yes, it can.

You can configure requests without limits, or requests lower than the limits. In either case, you are allowing the containers to use more resources than requested, typically to handle temporary overloads.
Consider a Namespace with two Workloads with one pod each. Say, one Workload is configured to request for 1 GiB of memory and uses 1 GiB (Used vs Request ratio is 100%). The other Workload is configured without any request and uses 1 GiB. In this example, 2 GiB of Memory Used to1 GiB Requested ratio at the Namespace level is 200%.

Network I/O

The chart shows the latest value returned by avg(avg(net.bytes.total)).

What Is It?

The sparkline shows the trend of network traffic (inbound and outbound) for all the pods in the Namespace. The number shows the most recent rate, expressed in restarts per second.

For reference, the sparklines show the following number of steps (sampling):

Last hour: 6 steps, each for a 10-minute time slice
Last 6 hours: 12 steps, each for a 30-minute time slice
Last day: 12 steps, each for a 2-hour time slice

What to Expect?

The type of applications run in the Namespace determine the metrics. Drilling down to the Kubernetes Namespace Overview Dashboard in Explore provides additional details, such as network activity across pods.

Feedback

Was this page helpful?

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.