Users interact with their Kubernetes cluster using the Kubernetes Server API. Hence, it can be rightfully considered as the front end part of the control plane in Kubernetes. The API server tests whether or not a request is legitimate before handling it.
The API Server is the interface for handling, developing, and configuring Kubernetes clusters. Using the API Server, the cluster’s users, external modules, and components interact with one another.
The Kubernetes API server and the HyperText Transfer Protocol API it exposes are the core components of the control plane of Kubernetes. The API server enables users to query and manage the Kubernetes objects’ states. But before diving into the working of Kubernetes API Server, it’s important to understand what Kubernetes is and how it works. So, let’s get started.
Kubernetes and Kubernetes API Server
Kubernetes is a container orchestration framework that is open source. A container is a technology that allows you to package and isolate applications along with their entire runtime environment so that they can be easily moved between stages (build, deployment, etc.) and environments (on-premise, cloud, or virtual machines) while maintaining complete functionality.
Kubernetes automates several manual tasks involved in maintaining, distributing, and scaling containerized applications.
You build a cluster by merging the servers (nodes that can be physical or virtual) that run the containerized applications, which you then control and orchestrate with Kubernetes.
A “pod” is a collection of containers that operate on a single computer or node and share resources. However, a pod may often only have one container, and in that case, the word “pod” can be replaced with the word “container”.
The control and applications plane makes up a Kubernetes cluster. The API Server of Kubernetes is found in the control plane, which allows a user to communicate with the cluster and tells it what to do using kubectl (an interactive CLI). The cluster, users, and external modules can all communicate with each other using the API.
Each cluster has a desired state, which specifies the applications or workloads that must be running and other configuration information such as required images and resources. The API is used to set or change the desired state of a particular cluster, either via the kubectl CLI or by communicating with the cluster through the API.
Kubernetes API Server in Detail
All interactions and activities between the control plane components of the system and the users or clients, such as kubectl, in Kubernetes, are converted into RESTful API calls that the API server handles. The Kubernetes API server can be considered as a Representational State web application that uses HTTP to process API calls and hold or modify objects in the etcd datastore.
Kubernetes is made up of a number of nodes (cluster machines) with each node having a different purpose. The Kubernetes API server, task or job scheduler, and the controller manager make up the control plane on the master node(s). The API server acts as the central control agent and is the only feature that communicates explicitly with etcd, which is a distributed storage component. The API server’s key roles are as follows:
- The first is to have access to the Kubernetes API. The master modules, worker nodes, and the Kubernetes-native applications all use this API internally, and clients, like kubectl, use it externally.
- The next role is to stream logs or serve kubectl exec sessions. It can also be used to proxy cluster elements like the Kubernetes dashboard.
The Kubernetes API Server is simply an HTTP API that uses JSON as its primary serialization schema. It also provides protocol buffers, which are used mostly for cluster-to-cluster communication. Kubernetes supports various API variants at separate API paths for extensibility purposes, such as /apis/extensions/v1beta1 or /api/v1. Various API versions indicate varying degrees of stability and support.
Despite its complicated architecture, the Kubernetes API server is pretty easy to handle from a management perspective. The Kubernetes API server is stateless and is often reused to manage loads of requests and to rectify fault tolerance since all of the server’s transient state is stored in a database that is unknown to the server. The API server is normally repeated three times in a highly accessible cluster.
In terms of the logs it generates, the API server can be very chatty. For each request it receives, it outputs at least one segment. As a result, a kind of log rolling must be applied to the API server so that it does not use any of the available storage space. However, since API server logs are critical to learning how the API server works, we strongly advise that logs be sent from the API server to a log aggregation provider for experimentation and querying in order to debug user requests for the APIs.
API Server Core Functions
There are 3 core functions essential for Kubernetes API Server to operate properly that are as follows:
1. API Management
Since the API’s primary purpose is to serve specific client requests, the client must first understand how to make an API request. Since the API server is essentially an HTTP server, each API request is an HTTP request. However, the attributes of such HTTP requests must be specified for the client and server to interact effectively. It’s good to get an API server up and running so you can hack at it for the sake of experimentation. You may either use an established Kubernetes cluster that you have exposure to or build a local Kubernetes cluster using the minikube app.
2. Request Processing
As discussed, the Kubernetes API server is responsible for receiving and processing HTTP requests for API. These requests generate from other Kubernetes components or from clients and users. In any case, the Kubernetes API server processes them all in the same way. List, post, delete, and get are some examples of requests.
3. Internal Control Loops
The API server has a few internal utilities that incorporate aspects of the Kubernetes API, in addition to the fundamentals of running the HTTP RESTful service. These types of control loops typically run in a different server called the controller manager. However, there are a few control loops that must be executed inside the API server such as the CRD loop.
Conclusion
The Kubernetes API Server is the main functionality that you offer to your customers as an operator. Understanding the key components of Kubernetes as well as how your users can combine APIs to create applications is crucial to deploying a useful and stable Kubernetes cluster. We hope that after reading this article, you now have a clear understanding of the Kubernetes API Server.