Table of contents
No headings in the article.
Kube API Server is the only component that as a user we will directly interact with. When we run a simple kubectl command (imperative style, we can also use an yaml file instead) like below
$ kubectl get pods
Behind the scenes kubectl will convert our yaml to json and sends over to the API Server. Also, behind the scenes converts the api as below, i.e., an api call
GET /api/v1/namespaces/{namespace}/pods/{name}/status
and pings the Kubernetes API Server. Kube API server exposes the api, as seen above. Hence, we do not need to use the kubectl for all interactions with Kube API Server, but can also hit the api server with api endpoints using tools like curl or postman. We can also use any SDK that has implemented the api's exposed by the Kube API Server.
Find the officially supported and 3rd party SDK's here
As a kubernetes user, all that you will do is, request the API Server to create, update or delete an object. Internally Kube API Server will talk to other Kubernetes components i.e., etcd, kube scheduled, kube controller before returning the response depending on the type (fetch, create, update or delete) requested by the user for the resource.
So, far we have seen the Kube API Server as one big giant monolith, but inside it consists of several sub components as shown in the below image.
What is happening here is that, when we send a request the kube api server, the API HTTP Handler (that acts like a web server) keeps listening to the requests and forwards to the next component i.e., Authentication which checks if it's the correct user requesting to get into the cluster. Once the user is authenticated successfully, it passed onto the next component i.e., Authorization which checks what accesses does the user have and can perform. After that it's passed onto the Mutation Admission Controller, which received the request and updates the yaml with default values. It then passes onto Schema Validation, where the schema of the manifest file is validated. If the validation is passed it then sends over to the last sub component i.e., Validation Admission Controller. This last check when passed successfully, will save the request into a highly available and key-value store database called etcd.
Next, we will see what is etcd, and get into deep waters of etcd how it works and why Kubernetes team has selected etcd over other key-value databases.
Resources
- Official documentation of Kubernetes API Server