Ever wondered what happens at the Kubernetes API Server whenever we execute any kubectl command? Since the name contains API so we can guess that it would be some REST API but what’s exactly happening underneath?

In this blog, I’ll try to answer such questions.

Interacting with Kubernetes API Server is something rare and not done in day to day operations. The official Kubernetes documentation is awesome on showing how’s it done. You may check it out here. But the question that arises here is, how do you start interacting with different API calls for various operations?

In order to interact, we can simply use kubectl. Just add verbose logging level of 8+ and you will get the API calls!

In order to get the Kubernetes API call to get all if the pods in the default namespace, use the following command:

kubectl get pods -v=8

The output would be something like this:

In the above log snippet, we see a lot of interesting things but the main thing that we were actually interested to know was the API call and that API call can be seen in second line of the log. After inspected that line we can conclude that to get all pods in the default namespace, the API call is GET on api/v1/namespaces/default/pods.

Another example for this can be to find out the api call when we try to create a job with busybox image, without actually creating it.

kubectl create job my-job --image=busybox --dry-run=server -v=8

We can see with the output that it is a POST on apis/batch/v1/namespaces/default/jobs with the request body of {"kind":"Job","apiVersion":"batch/v1","metadata":{"name":"my-job","creationTimestamp":null},"spec":{"template":{"metadata":{"creationTimestamp":null},"spec":{"containers":[{"name":"my-job","image":"busybox","resources":{}}],"restartPolicy":"Never"}}},"status":{}}

And since this was a dry run, the job wasn’t created. I’ve redacted the other parts of log like the complete API call and response body purposely. Hit the above command and checkout the call. It’s quite interesting and worth a shot!

I hope this blog post was useful and showed an easy way to see API calls for operations we run through kubectl!

error: Content is protected !!
%d bloggers like this: