day 2 of my CKA study course - this one was a bit long and it is Friday - but yeah I happen to be free today so why not :) had I plans I would have skipped a writeup today but it's 10pm and my house is in good order and I just happen to have nothing planned. Tomorrow is a different story I've got plans from 8am on basically, should be fun and a good break, though if I've got time in the middle of the day I'll work more on the course.
kube-api server does a lot! It's the primary management component in kubernetes. The kubectl command line utility is always reaching out to the kube-api server - it authenticates and validates the request, then retrieves the data from the etcd cluster and responds with the requested information.
That pretty much sounds like a typical API request, and it is, as you can also send POST requests directly without the CLI.
The course goes into creating a pod as an example to illustrate how the kube-api server is core to all the functions and behind the scenes with kubernetes, so let's look at that example -
- The request is authenticated and validated
- The API server creates a pod object without assigning it to a node
- The API server updates the etcd server with information, and updates the user that the pod is created
- The scheduler continually monitors the api server, then realises a new pod is now created with no node assigned - it will then kick in to find the right node on which to schedule the pod, and then it will communicate this information back to the API server
- The API server then updates the information in the etcd cluster, and passes that information to the kubelet on the worker node
- The Kubelet then creates the pod on that node, and instructs the container runtime engine to deploy the application image. Once that takes place, the Kubelet updates the status back to the API server, and the API server then updates the etcd cluster.
Wow that's quite a bit of work to get a pod created and scheduled on a node! Might I mention that a similar pattern is followed every single time a change is requested - the kube-api server is at the centre of all these different tasks that need to be performed to make a change in the cluster. The kube-api server is the only component that interacts directly with the etcd data store - the other components such as the scheduler, kube control manager, and the kubelet, use the API server to make updates in the cluster in their respective areas.
To reiterate some of this again, the kube-api server is responsible for:
- Authenticating users
- Validating requests
- Retrieving data (and updates)
- Updating etcd
- The Scheduler
- The Kubelet
The kube-api server is available as a binary in the kubernetes release page - you can download and configure it to run as a service on your kubernetes master/control plane node.
Kubernetes architecture consists of a lot of different components working with each other, talking to each other in so many different ways, so they all need to know where the other components are. Additionally, there are different modes of authentication, authorisation, encryption/security, etc. - many options exist with this. The kube-apiserver.service file has these options and configurations, a lot of the config being certificates that are used to secure connectivity between different components (all the components have certificates associated with them).
Depending again on how you set up the cluster, viewing the kube-api server options will differ.
If it was set up with the kube admin tool (kubeadm), kube admin deploys the kube-apiserver as a pod in the kube-system namespace (kubectl get pods -n kube-system) on the master/control plane node - (/etc/systemd/system/kubeapi-server.service).
If it was set up without kubeadm, you can inspect the options with a kubeapiserver.service or do ps -aux | grep kube-apiserver to see running processes and effective options by listing the processes.
An additional piece to the notes above - this is coming from The Kubernetes Book by Nigel Poulton, 2024 Edition, The kube-api server is the front-end of Kubernetes - even the internal control plane services communicate to each other via the kube-api server. It is a RESTful API over HTTPS, so all the requests are subject to authentication and authorisation.
That's in the intro, which is where I'm at right now in the CKA course as well - it looks like there is also a whole chapter on the API in general that includes JSON serialisation, named API groups, inspecting the API, alpha and beta and stable, resource deprecation, and extending the API. Flipping through the headers, it doesn't seem as bad as I thought - I did see something about extending the API in a Kelsey Hightower Kubernetes book that is about a decade old by now, which I don't know about, but it's otherwise seemingly a pretty standard API, which I know pretty well working with APIs to test things and with the web development work from before.
That's all I have today - it's getting late actually. Hopefully this is helpful and anyone else interested in studying together or if this helped, leave a comment! Trying to make Kubernetes interesting but it's just a lot of work really ;)
- Catt
Top comments (0)