The cluster health check feature is a service provided by Tencent Kubernetes Engine (TKE) for checking the status and health of each resource in a cluster. The resulting check report displays the detailed status and configuration of components, nodes, workloads, and other check items. If an exception is detected, this feature can describe the exception in detail, automatically analyze the severity, cause, and impact, and propose rectification suggestions.
Note
During the health check, namespace tke-cluster-inspection will be automatically created in your cluster, and a Daemonset will be installed to collect node information. Both objects will be automatically deleted after the health check is completed.
Main Check Items
Check Category
Check Items
Check Content
Self-Deployed Clusters Only
Resource status
kube-apiserver status
Check whether the component is running. If the component runs as a pod, the health check feature checks whether it has restarted over the past 24 hours
Yes
kube-scheduler status
Yes
kube-controller-manager status
Yes
etcd status
Yes
kubelet status
No
kube-proxy status
No
dockerd status
No
Master node status
Check whether the node status is Ready and free of any other exceptions, such as insufficient memory and insufficient disk space
Yes
Worker node status
Check whether the node status is Ready and free of any other exceptions, such as insufficient memory and insufficient disk space
No
Status of each workload
Check whether the number of currently available pods of the workload meets the expected number of pods
No
Running status
Parameter configuration of kube-apiserver
The following parameters are checked based on the Master node configuration:
max-requests-inflight: The maximum number of non-change requests running within a specified period.
max-mutating-requests-inflight: The maximum number of mutating requests running within a specified time period.
Yes
Parameter configuration of kube-scheduler
The following parameters are checked based on the Master node configuration:
kube-api-qps: The QPS used when requesting kube-apiserver.
kube-api-burst: maximum burst value during communication with kube-apiserver
Yes
Parameter configuration of kube-controller-manager
The following parameters are checked based on the Master node configuration:
kube-api-qps: The QPS used when requesting kube-apiserver.
kube-api-burst: maximum burst value during communication with kube-apiserver
Yes
Parameter configuration of etcd
Check the following parameter based on the master node configuration:quota-backend-bytes: storage capacity
Yes
Reasonability of the master node configuration
Check whether the current master node configuration is sufficient to the current cluster scale
Yes
High availability of nodes
Check whether the current cluster is a single-node cluster; verify if the cluster nodes support multi-AZ disaster recovery, i.e., when one availability zone becomes unavailable, whether the total resources of the remaining availability zones are sufficient to support the current cluster's workload.
No
Request and Limit configuration of workloads
Check whether workloads have configured resource-limiting containers. Configuring resource limits helps improve resource planning, pod scheduling, cluster availability, and other functions
No
Anti-affinity configuration of workloads
Check whether workloads have configured affinity or anti-affinity. Configuring anti-affinity helps improve the high availability of business
No
PDB configuration of workloads
Check whether workloads have configured PDB, which can help prevent your business from becoming unavailable due to eviction.
No
Health check configuration of workloads
Check whether a health check is configured for workloads. Health check helps detect business exceptions
No
HPA-IP configuration
Check whether the current number of remaining pod IP addresses in the cluster meets the maximum number for HPA scale-out
No
Instructions
1. Log in to the TKE console and select Operation Center > Health Check in the left sidebar.
2. Navigate to the "Health Check" page, select the cluster that requires a health check, and choose an appropriate check method. There are three health check methods: Batch Check, Immediate Check, and Automatic Check.
Auto-check: Suitable for clusters that require periodic checks. Select the cluster that needs periodic checks and click Auto-check, as shown below:
In the "Auto Check Settings" pop-up window, you can configure the enablement status, check cycle, and time according to your needs, as shown in the figure below:
3. After selecting the check method, wait for the check to complete and view the progress. As shown below:
4. After the check is completed, click View Results to view the check report, as shown below:
On the check report page, select Resource Status and Running Status to view the resource status and exceptions, respectively. Click Check Items to display the specific check items, and click Exceptions to view the exception level, description, cause, impact, and rectification suggestions, as shown below: