eG Monitoring
 

Measures reported by KuberApiAccessTest

The API server is the component on the master that exposes the Kubernetes API. It is the front-end for the Kubernetes control plane. All communication paths from the cluster to the master terminate at the API server. The cluster receives Object specs from users via the API server on the master node. While the master uses the API server to forward the Object specs to the scheduler and to the kubelets, the kubelets also update the master with the Object status via the API server. Instructions for creating, starting, destroying objects on a worker node are also sent to worker nodes via the API server only.

This implies that the non-availability of the API server can bring the entire cluster to a standstill! Administrators may no longer be able to stop, update, or start new pods, services, or the replication controller. Moreover, users will be denied access to the cluster, and consequently, to the business-critical applications/services running within! To avoid this, administrators must periodically check if the API server is available and promptly detect its unavailability. This is exactly what the API Server Connectivity test does!

At configured intervals, this test checks whether/not the API server is available, and instantly alerts administrators if it is not. This way, the test urges administrators to investigate the reason for the non-availability and fix it, so that cluster operations resume quickly.

Outputs of the test:One set of results for the Kubernetes cluster being monitored.

The measures made by this test are as follows:

Measurement Description Measurement Unit Interpretation
Availability Indicates whether/not the API server is available. Percent If the value of this measure is 0, it indicates that the API server is unavailable. The value 100 on the other hand indicates that the API server is available.

In the event of the non-availability of the API server, you can use the detailed diagnosis of this measure to figure out the reason for the non-available. You can also use the /var/log/kube-apiserver.log file on the master node to figure out what could have caused the failure of the server.

The common causes for the unavailability of the API server are as follows:

  • API server VM shutting down or crashing;

  • API server losing access to its backing storage

To ensure the high availability of the API server, you may want to consider the following courses of action:

  • Use IaaS provider’s automatic VM restarting feature for IaaS VMs;

  • Use IaaS providers reliable storage (e.g. GCE PD or AWS EBS volume) for VMs with apiserver+etcd