Basics & Architecture of Kubernetes.

#kubernetes #aws #devops #cloud

Introduction
I’ve recently started my Kubernetes learning journey, and instead of waiting until I “know everything,” I decided to document my learnings from day one. This helps me solidify concepts and might also help others who are just getting started.

This post covers my current understanding of Kubernetes fundamentals, especially its architecture and core components.

What is Kubernetes?

Kubernetes is a container orchestration platform.
In simple terms, it helps you deploy, manage, scale, and heal containerized applications automatically.
Instead of manually running and monitoring containers, Kubernetes does that work for you.

Kubernetes Architecture: Nodes
A Kubernetes cluster consists of nodes, which are essentially servers (physical or virtual machines).

There are two main types of nodes:

1. Control Plane
The control plane is responsible for managing the cluster.
It does not run application containers directly; instead, it makes decisions and maintains the desired state of the cluster.

2. Worker Nodes
Worker nodes are where the actual application workloads (containers) run.

Control Plane Components
The control plane consists of several key components:

kube-apiserver

Acts as the entry point to the Kubernetes cluster
All requests (from users, controllers, scheduler, etc.) go through the API server
It is the only component that talks directly to etcd

etcd

A distributed key-value store
Stores all cluster state (Pods, nodes, configs, secrets, etc.)
Acts as the single source of truth for Kubernetes
You can think of etcd as the brain’s memory of the cluster.

kube-scheduler

Decides which worker node a Pod should run on
Considers resource availability, constraints, and policies
It does not create Pods — it only assigns them to nodes

kube-controller-manager

Runs multiple controllers
Each controller continuously compares desired state vs actual state
If there’s a mismatch, it takes corrective action
Examples: Node Controller ReplicaSet Controller Job Controller

This is what enables Kubernetes’ self-healing nature.

Worker Node Components
Each worker node runs the following components:

kubelet

An agent running on every worker node
Communicates with the kube-apiserver
Ensures that Pods assigned to the node are running as expected
Interacts with the container runtime to start/stop containers

Container Runtime

Responsible for actually running containers
Examples: containerd, CRI-O, Docker (via CRI)

kube-proxy

Handles networking for Services
Maintains network rules (iptables/IPVS)
Enables stable access to Pods via Services

Pods

A Pod is the smallest deployable unit in Kubernetes
A Pod can contain one or more containers
Containers in the same Pod: Share the same network namespace Can communicate via localhost

In most cases, a Pod contains one container, but multi-container Pods are used for sidecar patterns.

How kubectl Fits In
As a user or DevOps engineer, we interact with Kubernetes using kubectl, which is a command-line interface (CLI).
Flow:
User → kubectl → kube-apiserver → cluster components

kubectl sends requests to the API server
The API server validates and stores state in etcd
Scheduler and controllers watch the API server and act accordingly
kubelet executes the decisions on worker nodes

Final Thoughts
This is my Day 1 understanding of Kubernetes.
I’m intentionally starting with fundamentals before jumping into deployments, services, and YAML files.
If you’re also learning Kubernetes, I’d highly recommend: