Cluster Monitoring Overview
This section introduces how to view monitoring information on the cluster overview page.
For other information on the cluster overview page, see Cluster Overview.
Prerequisites
You should join a cluster and have the Monitoring Viewing permission within the cluster. For more information, refer to "Cluster Members" and "Cluster Roles".
WhizardTelemetry Monitoring should have been installed and enabled.
Steps
Log in to the KubeSphere web console with a user who has the Monitoring Viewing permission, and access your cluster.
Click Overview in the left navigation pane.
The Overview page provides the following monitoring information:
Area Description Cluster Quota Statistics
The CPU quota and memory quota of containers and projects in the current cluster, including quantity request, quantity limit, and total quantity.
Node Resource Usage
The total and real-time usage of CPU, memory, and disk for all nodes, as well as the total number of pods allowed to be created in the cluster and the number of pods already created. By default, each node allows a maximum of 110 pods to be created.
Pods
The number of various types of pods in the current cluster.
Pod status includes:
Running: The pod has been assigned to a node, all containers in the pod have been created, and at least one container is running, starting, or restarting.
Pending: The pod has been accepted by the system, but at least one container has not been created or is not running. This state may indicate that the pod is waiting for scheduling or for the container image to be downloaded.
Completed: All containers in the pod have terminated successfully (with an exit code of 0) and will not be restarted.
Failed: All containers in the pod have terminated, and at least one container has terminated with a non-zero exit code.
Unknown: The system is unable to get the status of the pod. This state usually occurs when the system fails to communicate with the host where the pod is located.
Pod QoS (Quality of Service) types include:
Guaranteed: Each container in the pod has memory limits, memory requests, CPU limits, and CPU requests, and the memory limit is equal to the memory request, and the CPU limit is equal to the CPU request.
Burstable: At least one container in the pod does not meet the requirements of the Guaranteed type.
BestEffort: Containers in the pod do not configured with any memory limits, memory requests, CPU limits, or CPU requests.
The QoS type of the pod determines the running priority of the pod. When resources in the system is insufficient to run all pods, the system gives priority to running pods of QoS type Guaranteed first, followed by pods of QoS type Burstable, and finally, pods of QoS type BestEffort.
Kubernetes Status
The number of API requests per second, API request latency, pod scheduling times, and pod scheduling failure times in the current cluster.
Resource Usage Ranking
The top 5 nodes, pods, and projects with the highest resource usage in the current cluster.
Select nodes, pods, or projects from the dropdown list on the left, and select different sorting criteria from the dropdown list on the right.
Click / above the list to sort in ascending/descending order.
Click View More below to view the resource usage details of nodes, pods, and projects.
Feedback
Was this page Helpful?
Receive the latest news, articles and updates from KubeSphere
Thanks for the feedback. If you have a specific question about how to use KubeSphere, ask it on Slack. Open an issue in the GitHub repo if you want to report a problem or suggest an improvement.