Kubernetes has become the most popular choice to deploy and manage micro-services. If you are new to Kubernetes or you’ve recently started using it, you’d be aware of the advantages it provides. With more and more organizations adopting micro-services architecture and moving towards containerization of the services. It’s important to understand the flow of data from and to the Kubernetes client and API server. In this article, we are going to talk about what happens when you run kubectl get pods.
Kubeconfig
When a kubectl command is executed, the first thing that kubectl does is, find the kubeconfig file. If the path to the kubeconfig file is provided with --kubeconfig flag, it gets the highest precedence. If not, then $KUBECONFIG env is evaluated for the path. The default path when nothing is provided is ~/.kube/config.
HTTP Request
After the file is parsed, it determines the current context, and cluster it is pointed to. If the user provides --username flag, it is evaluated. Else, current user information kubeconfig is used for auth. Kubectl then encapsulates the HTTP request using the client’s configuration.
Authentication and Authorisation
Next comes Authentication. It can be done via certificate, auth-token, username and password or OpenID connect. Bearer tokens are sent in the “Authorisation” HTTP header. If authentication fails, an aggregated error is returned. Else, the Authorisation header is removed from the request, and user information is added to its context.
Once authenticated, authorizers come into the picture. There are multiple authorizers like ABAC, RBAC, webhook, etc. If all of them deny the request, a Forbidden response is returned. If all authorizers deny the request, the request results in a Forbidden response and goes no further. If a single authorizer approves, the request proceeds.
HTTP Response
If the user has access to built-in API-groups for resources pod with the verb get. The request would proceed to fetch the required object from the etcd. It is then fetched and the response is then sent to the client.
Note: This is just a bird’s eye view of what happens when you run kubectl command, there are a lot of things that happen under the hood like informers, cache, queue, controllers, shared informer factory, controller manager, etc. In upcoming articles, we’ll be diving deep into some of the above topics and after that, we can stitch topics to understand the detailed process.
If you like the article, please share and subscribe to the blog.
