🚀 API Server: Explained like Never Before (Episode 4)

This is your Kubernetes API Server exposing RESTful APIs.

If you visit:

CODE Kopieren

http://localhost:8001/api

you'll see the core Kubernetes API information.

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 👋