Hola Amigos 👋
Welcome to Episode 4 of K8s-With-Pravesh.
In the previous episode, we followed the complete journey of the kubectl apply command and saw what really happens inside Kubernetes when we deploy an application. If you haven't checked it out yet, here it is:
In that blog, our journey started with the front-door keeper of the Kubernetes cluster: the API Server.
The API Server is the central administrative hub and the only entry point for managing a Kubernetes cluster. It exposes a RESTful HTTP API that processes, validates, and stores requests for Kubernetes objects like Pods, Services, Deployments, ConfigMaps, and much more.
Interesting Fact: The Kubernetes API Server is completely stateless. It doesn't permanently store anything by itself. Instead, it relies on etcd (Kubernetes' distributed key-value database) to store the entire cluster state.
How does the API Server work?
Whenever we execute a command like:
kubectl apply -f deployment.yml
the request travels through the API Server in a highly structured lifecycle:
[ Request ]
↓
[ Authentication ]
↓
[ Authorization (RBAC) ]
↓
[ Mutating Admission ]
↓
[ Schema Validation ]
↓
[ Validating Admission ]
↓
[ etcd Data Store ]
↓
[ Watch Events ]
↓
[ Controller Manager ]
↓
[ Scheduler ]
↓
[ Kubelet ]
Everything inside Kubernetes starts with the API Server.
Once a request reaches the API Server, it is first authenticated using client certificates, tokens, or other authentication methods. After that, authorization checks whether the user has permission to perform the requested action using RBAC (Role-Based Access Control).
Next come the Admission Controllers. These can modify the request, inject default values, or reject it before it reaches the cluster.
The object is then checked against the official Kubernetes schema to ensure it follows the correct structure. If everything is valid, the API Server stores the object inside etcd.
But the story doesn't end there.
Once the object is stored, every Kubernetes component watching the API Server immediately notices the change. The Controller Manager starts reconciliation, the Scheduler decides where the Pod should run, and finally the Kubelet on the selected node creates the container.
Beginner Mistake: Many beginners think
kubectldirectly talks to a Deployment and creates Pods. In reality,kubectlonly sends a request to the API Server. Everything else happens because multiple Kubernetes components continuously reconcile the desired state.
If we simplify what happens after running kubectl apply, the flow looks like this:
-
kubectlreads the YAML. - Converts it into JSON.
- Creates an HTTPS REST request.
- Sends it to the API Server.
- API Server authenticates the request.
- API Server authorizes the request.
- Admission Controllers validate and mutate the object.
- The object is stored inside etcd.
- Controllers notice the change.
- The Scheduler assigns a node.
- The Kubelet creates the container.
Key functions of the API Server
Single Source of Truth
The API Server is the only Kubernetes component that communicates directly with etcd. No Scheduler, Controller Manager, or Kubelet ever talks to etcd directly.
The Watch Mechanism
Instead of continuously polling etcd, Kubernetes components use the API Server's Watch API. This allows them to receive real-time updates whenever the cluster state changes.
Cluster Synchronization
The API Server acts as the coordinator between the control plane and worker nodes. Every component observes changes through the API Server and works toward making the actual state match the desired state.
Let's see it in action
To see the API Server in real life, start a Minikube cluster and run:
kubectl proxy
Now open:
http://localhost:8001
You will see a list of Kubernetes API endpoints.
This is your Kubernetes API Server exposing RESTful APIs.
If you visit:
http://localhost:8001/api
you'll see the core Kubernetes API information.
Now let's do something even more interesting.
Remember the Deployment we created in Episode 3? Apply that Deployment again using kubectl apply.
Once the Pods are running, open:
http://localhost:8001/api/v1/namespaces/default/pods
You'll see a large JSON document describing every Pod in the default namespace.
This is the same information that kubectl get pods displays in a much cleaner format. kubectl is simply calling the Kubernetes API Server and presenting the response in a human-readable way.
You can even compare the Pod names and IDs with the output of kubectl get pods and see that they're exactly the same.
Why do different Kubernetes objects have different API versions?
When I first started learning Kubernetes, I always wondered why different resources had different API versions.
For example:
- Pods use
v1 - Deployments use
apps/v1 - Jobs use
batch/v1
The reason is simple.
Pods belong to the Core API Group, so they use v1.
Deployments belong to the Apps API Group, so they use apps/v1.
Similarly, Jobs belong to the Batch API Group, so they use batch/v1.
As Kubernetes evolved, related resources were grouped into different API groups, each with its own versioning.
Every communication happening inside a Kubernetes cluster goes through the API Server. Even though etcd stores the cluster data, no component reads or writes directly to it.
For example, when you run:
kubectl get deployments
kubectl sends a request to the API Server.
The API Server reads the Deployment object from etcd and returns the response back to kubectl.
Everything flows through the API Server.
That's the end of our deep dive into the Kubernetes API Server.
I hope this helped you understand how the API Server isn't just the front door of Kubernetes, but also the central communication hub that connects every component inside the cluster.
In the next episode, we'll explore the data hub of Kubernetes—etcd—and understand how Kubernetes stores and manages the entire cluster state.
If you enjoyed this blog, make sure to follow me on LinkedIn, X, YouTube, GitHub, Dev.to, and Medium.
Till then,
Happy Coding 👋
Top comments (0)