Understanding config file in Kubernetes.

Introduction

To interact with the Kubernetes cluster you install kubectl (a command line utility), and you run the command kubectl apply -f pod.yaml or kubectl run my-pod --image=nginx . when you run the command your request goes to the API server and then the request proceeds.

but, how kubectl know to which cluster it has to send the request, and if the request is sent how will API-Server figure out whether this request is coming from a valid user or not? Let's understand it in this blog.

What is a kubeconfig file?

when you create a Kubernetes cluster you get a config file, by default in path ~/.kube/config

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: <certificate-authority-data>
    server: <server_URL>
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
- context:
    cluster: kubernetes
    namespace: default
    user: vishal
  name: dev-context
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: <client-certificate-data>
    client-key-data: <client-key-data>
- name: vishal
  user:
    client-certificate: /root/vishal.cert
    client-key: /root/vishal.key

Key Components of a Kubeconfig File:

let’s understand the different attributes of config file.

• clusters: contains the information about Kubernetes clusters including the certificate authority and url of the server.

• user: contains information about user , kubernetes itself does not manage users rather it depends on external authentication mechanisms like certificate-based authentication or External Identity provider.

• context: maps users and clusters.

• current-context: contains the context that will be executed, when the command is run on kubectl.

How kubectl Interacts with the Kubernetes API Server

Now let's understand how it works when you run the command kubectl get pods

1. kubectl will see on current context to which API-Server as which user request has to be sent.

2. The request goes to API-Server.

3. API Server will validate request using Authentication Authorization and Admission.

Authentication Authorization and Admission.

Authentication: Validate whether the user is valid or not, depending on his key and certificate.

Authorization: Authorize weather you are allowed to perform that task or not, authorization is performed depending on role and role-binding.

Admission: The admission controller does certain things validate: checks whether the request has the correct structure and format. mutate: automatically fills the missing fields. depending upon the rules if admission is successfully completed.

Pod scheduling and running

kube-scheduler then find best-fit node and schedule the pod to run on that node. then kubelet on that node with help of container runtime creates pod and sends update to API-Server. and communication between different components of Kubernetes happens throug API-Server.

Conclusion

So the next time when you run kubectl apply -f pod.yaml you know what happens!
kubectl using the configuration in the kube-config file sends a request to the API server, The API server then performs authentication, authorization and admission then the kube-scheduler schedules it in the best-fit node, kubelet deploys the pod and sends report to API-Server.

thanks for reading and happy learning.