Kubernetes Architecture Deep Dive

In this post, we’ll explore the architecture of Kubernetes, diving into its core components and how they work together. We’ll also look at what happens when you run a kubectl command and discuss the concepts of pods and containers.

Kubernetes Architecture

Kubernetes follows a master-worker architecture, also known as the control plane and data plane.

Control Plane Components

Let’s break down the function of each control plane component in simple terms:

1. API Server:

   • Think of it as the front desk of Kubernetes.
   • It’s where all communication goes through.
   • When you want to do something in Kubernetes, you talk to the API Server.

2. Scheduler:

   • This is like a smart placement system.
   • It decides which worker node is best to run your application.
   • It considers things like available resources and any special requirements your app might have.

3. Controller Manager:

   • Imagine a group of watchdogs, each responsible for a different aspect of the cluster.
   • They constantly check if everything is running as it should be.
   • If something’s wrong, they try to fix it.

4. etcd:

   • This is the cluster’s memory bank.
   • It stores all the important information about the cluster.
   • Whenever something changes in the cluster, it’s recorded here.

Worker Node Components

1. Kubelet:

   • Think of this as the node’s manager.
   • It makes sure containers are running in a Pod.
   • It reports back to the control plane about the health of the node and its pods.

2. Container Runtime:

   • This is the engine that actually runs your containers.
   • Examples include Docker, containerd, or CRI-O.

3. Kube-proxy:

   • This is like a traffic controller for network communication.
   • It maintains network rules on nodes to allow communication to your Pods from inside or outside of your cluster.

What Happens When You Run a Kubectl Command?

When you run a kubectl command, a series of steps occur:

1. You enter a kubectl command in your terminal.
2. The command is sent to the API Server.
3. The API Server authenticates and authorizes the request.
4. If valid, the API Server processes the request (e.g., creating a new resource).
5. The change is stored in etcd.
6. If needed, the Scheduler assigns the new resource to a node.
7. The Kubelet on the chosen node creates the resource (e.g., starts a new Pod).
8. A response is sent back through the API Server to your terminal.

Pods and Containers

A Pod is the smallest deployable unit in Kubernetes. Think of it as a wrapper around one or more containers. Here’s what you need to know:

• Pods run on worker nodes in the cluster.
• A Pod can contain one or more containers, but usually, it’s just one.
• Containers in the same Pod share resources and can communicate easily with each other.
• Pods are ephemeral - they can be created, destroyed, and recreated as needed.

Containers, on the other hand, are the actual environments where your application code runs. They package your application and its dependencies together, ensuring consistency across different environments.

Conclusion

Understanding Kubernetes architecture is crucial for effectively managing containerized applications at scale. By breaking down the components and processes into simpler terms, we can better grasp how Kubernetes orchestrates our containers and manages our cluster.

References

1. Kubernetes Official Documentation: Kubernetes Components
2. The Kubernetes Book by Nigel Poulton
3. Kubernetes: Up and Running by Brendan Burns, Joe Beda, and Kelsey Hightower