The API Server

Previously, we learned about the Kubernetes API. Let’s now take a closer look at the API server.

Introduction to the API server

The API server exposes the API over a RESTful HTTPS interface. It acts as the front-end to the API and is a bit like Grand Central station for Kubernetes — everything talks to everything else via REST API calls to the API server. For example:

• All kubectl commands go to the API server (creating, retrieving, updating, and deleting objects).

• All kubelets watch the API server for new tasks and report the status to the API server.

• All control plane services communicate with each other via the API server

Let’s dig deeper and demystify more jargon.

The API server is a Kubernetes control plane service that some clusters run as a set of Pods in the kube-system Namespace. If we build and manage our own clusters, we need to ensure the control plane is highly available and has enough performance to ensure the API server can respond to requests quickly. If we’re using hosted Kubernetes, the API server implementation, including performance and availability, is hidden.

The main job of the API server is to expose the API to clients inside and outside the cluster. It uses TLS to encrypt the client connection, and it leverages authentication and authorization mechanisms to ensure only valid requests are accepted and executed. Requests from internal and external sources all have to pass through the same authentication and authorization.

The API is RESTful. This is jargon for a modern web API that accepts CRUD-style requests via standard HTTP methods. CRUD-style operations are simple create, read, update, delete operations, and they map to the standard POST, GET, PUT, PATCH, and DELETE HTTP methods.

The following table shows how CRUD operations, HTTP methods, and kubectl commands match up. Please note that we use the term verb to refer to CRUD operations.