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.
