Understanding Kubernetes Architecture: A Beginner’s Guide 😀
Part 1
Docker VS K8s
We have used Docker to create containers and images, and to run our applications. However, we've noticed some drawbacks, such as the lack of auto-scaling, specific version rollbacks, and occasional downtime. Even though there are features like manual scaling and self-healing, these limitations can be problematic for us. To address these issues, Kubernetes helps by solving these problems in real time. We use Docker for mid-range and small applications where downtime and other factors are negligible, but for large enterprise needs, we rely on Kubernetes, which, although more costly, provides the necessary scalability and reliability.
How does Kubernetes Architecture Work? 🤔
Kubernetes follows a Master-Worker (Control Plane–Node) architecture.
Control Plane (Master Node)
The Control Plane is the brain of Kubernetes.
It manages the entire cluster and controls what runs and where it runs.
The main components of the Control Plane are:
API Server
Entry point of Kubernetes
Receives all requests from operator , automation tools, or kubectl
Sends instructions to other control plane components
We interact with Kubernetes using kubectl, which is a command-line tool installed on our local machine.
kubectl → sends request → API Server
Here “tools” means automation or DevOps tools that also talk to the Kubernetes API Server, just like kubectl does.
Tools like:
CI/CD tools → Jenkins, GitLab CI, GitHub Actions
Deployment tools → ArgoCD, FluxCD
Infrastructure tools → Terraform, Ansible
Package tools → Helm
Monitoring tools → Prometheus, Kube-State-Metrics
The Kubernetes API Server is used only for cluster management and communication between Kubernetes components, not for user application traffic.
Scheduler
Decides on which worker node a Pod should run
It checks resource availability like CPU, RAM, disk, node health, etc.
It makes decisions based on information it gets from the worker nodes
Controller Manager
Continuously monitors the cluster
Ensures the desired state = actual state
Example: If a pod crashes, it makes sure a new one is created.
There are of 3 types
Replication Controller / ReplicaSet
The Replication Controller (older) or ReplicaSet (newer and commonly used through Deployments) constantly watches pods and makes sure the required number of replicas are always running. If a pod crashes, gets deleted, or fails for any reason, the controller automatically creates a new pod to replace it. Kubernetes continuously checks the state of pods in the background and ensures the desired state matches the actual state.
So simply: If a pod goes down, Kubernetes will recreate it automatically.
(There are no fixed “5 seconds” or “30 seconds” times to check . Kubernetes continuously monitors using its reconciliation loops.)
Node Controller
Node Controller continuously monitors the status of worker nodes. If a node becomes unreachable or goes down, Kubernetes marks it as “NotReady.” After a certain timeout period, the pods running on that node are considered unhealthy, and Kubernetes reschedules those pods onto other healthy nodes.
So simply: If a node fails, Kubernetes moves workloads to healthy nodes.
Service Controller
The Service Controller in Kubernetes is responsible for managing Service objects, which are how applications inside the cluster communicate with each other or with the outside world.
A Service gives a stable IP address and DNS name for pods, so even if pods are created or deleted, the Service always points to the right pods. The Service Controller makes sure this connection between Services and pods always works.
For example, suppose you have 3 pods running a web app. If one pod crashes or a new pod is added, the Service Controller ensures that traffic to the Service still reaches all the available pods correctly.
In cloud environments, if you create a Service of type LoadBalancer, the Service Controller also talks to the cloud provider (like AWS, GCP, or Azure) to create a public load balancer. This load balancer gets a public IP so users on the internet can access your application.
etcd
The database of Kubernetes
Stores the entire cluster state (pods, nodes, configs, secrets, etc.)
It is a key–value store
etcd doesnt have any full form
Worker Nodes
Worker nodes are where the actual applications run.
Each worker node contains:
kubelet
Agent running inside every node
Shares node health, resource usage, and pod status with the control plane
Makes sure pods are running as expected on the node
Actually creates and manages containers on that node
If kubelet stops:
node becomes NotReady
pods on that node stop being managed
new pods won’t be scheduled there
This information is what helps the scheduler decide where to place pods.
kube-proxy
Handles networking inside the cluster
Forwards traffic to the correct pod
Ensures communication between services and pods
Pod
It is the smallest object we can create in Kubernetes. A pod contains one or more containers, which are short-lived objects within the pod. These containers share the same network and namespace.
Types of clusters:
Self-Managed cluster (Kops , minikube , k3d )
Cloud-Managed cluster (EKS , AKS , GKE )
MiniKube
Minikube is a tool that allows you to run a single-node Kubernetes cluster locally on your laptop or desktop. It’s mainly used for learning, testing, and development purposes. With Minikube, you can experiment with Kubernetes without needing a full multi-node cluster or cloud setup.
Works on any kind of OS
Support multi containerzation platform
Very Easy to Use
Kubectl
It is a command-line tool that lets us interact with Kubernetes to perform tasks such as creating, deleting, managing pods, monitoring, debugging, and troubleshooting.
To get all type objects in kubernetes
kubectl api-resources
There are two ways we can create objects
Imperative way (Created Using Command)
Declarative way ( Created Using manifest file , Mostly used in real time)
To create a pod
kubectl run myfirstpod --image=nginx
To get list of pods
kubectl get pods (or) kubectl get pod (or) kubectl get po
To get only one pod
kubectl get one myfirstpod
To delete a pod
kubectl delete pod myfirstpod
To describe a pod
kubectl describe pod myfirstpod
Simple pod creation using manifest file
apiVersion: v1
kind: Pod
metadata:
name: flm-pod
spec:
containers:
- name: mycont
image: <myimage>
ports:
- containerport: 80
Conclusion
Kubernetes is a powerful container orchestration platform designed to overcome the scalability and management challenges of Docker in large environments. With capabilities like auto-scaling, smooth rollbacks, and built-in high availability, it ensures applications remain efficient, reliable, and resilient, even in complex enterprise systems. Gaining a solid understanding of its architecture—especially the Control Plane and Worker Nodes—is essential to fully utilize its benefits. Whether you’re experimenting with tools like Minikube or running production workloads, Kubernetes proves to be an indispensable solution for modern application deployment and management.
If you found this guide useful, please like ❤️, comment, and share your thoughts or questions. Stay tuned for the next part, where we'll explore advanced Docker concepts and practices.
Thank you,
Yours, Rama Grandhi