Skip to main content
Welcome to this comprehensive guide on the Kube API Server in Kubernetes. In this article, we explore how the Kube API Server acts as the central management component in a Kubernetes cluster by handling requests from kubectl, validating and authenticating them, interfacing with the etcd datastore, and coordinating with other system components. When you execute a command like:
the utility sends a request to the API Server. The server processes this request by authenticating the user, validating the request, fetching data from the etcd cluster, and replying with the desired information. For example, the output of the command might be:

​
API Server Request Lifecycle

When a direct API POST request is made to create a pod, the API Server:
  1. Authenticates and validates the request.
  2. Constructs a pod object (initially without a node assignment) and updates the etcd store.
  3. Notifies the requester that the pod has been created.
For instance, using a curl command:
The scheduler continuously monitors the API Server for pods that need node assignments. Once a new pod is detected, the scheduler selects an appropriate node and informs the API Server. The API Server then updates the etcd datastore with the new assignment and passes this information to the Kubelet on the worker node. The Kubelet deploys the pod via the container runtime and later updates the pod status back to the API Server for synchronization with etcd.
At the heart of these operations is the Kube API Server, ensuring secure and validated communication between the cluster components.
The image lists six steps related to the Kube-api Server: Authenticate User, Validate Request, Retrieve Data, Update ETCD, Scheduler, and Kubelet.

​
Deployment and Setup

If your cluster is bootstrapped with a kube admin tool, most of these intricate details are abstracted. However, when setting up a cluster on your own hardware, you need to download the Kube API Server binary from the Kubernetes release page, configure it, and run it as a service on the Kubernetes master node.

​
Typical Service Configuration

The Kube API Server is launched with a variety of parameters to secure communication and manage the cluster effectively. Below is an example of a typical service configuration file:
The configuration includes several certificate-related options, securing communication channels between various Kubernetes components. In upcoming sections, we will take a deeper look at SSL/TLS certificates and their role in ensuring secure interactions.

​
Verifying the Deployment

For clusters set up with kube-admin tools, the Kube API Server is deployed as a pod in the kube-system namespace. To inspect these pods, run:
Expected output may include:
For non-kube-admin setups, you can examine the container command options directly within the pod manifest. Here’s an excerpt from a pod definition:
Another way to review the active API Server configuration is by checking the systemd service file on the master node:
An example excerpt from this file might be:

​
Quick Reference Table

Below is a summary of some key Kubernetes components involved in the Kube API Server workflow:

​
Summary

In this article, we provided an overview of the Kube API Server, its interactions with other essential components, and various methods to inspect its configuration—both through pod manifests and systemd service files. In subsequent sections, we will delve deeper into certificate management, including SSL/TLS configurations, to reinforce secure communications within your Kubernetes cluster.
For a deeper understanding of Kubernetes and its components, explore the Kubernetes Documentation.
This concludes our discussion on the Kube API Server.

Watch Video