K8S guide for beginners

Introduction

Docker felt powerful enough. I could build images, run containers, expose ports — so what was missing?

In this post, I want to clearly explain what stays the same when moving from Docker to Kubernetes, and what fundamentally changes. This is written from the perspective of someone who is just transitioning from Docker to Kubernetes.

The Core Idea (Read This First)

Before diving into details, here’s the mental model that made things click for me:

Docker is about running containers. Kubernetes is about running containers reliably at scale.

This is why k8s is called a container orchestration platform. Extends

What Stays the Same

Kubernetes does not throw away your Docker knowledge. A lot of it still applies.

1. Containers Are Still the Foundation

Even with Kubernetes:

• You still build container images
• You still use a Dockerfile
• You still push images to a container registry

Kubernetes does not care how the image was built — it only needs an image reference.

2. Your Application Code Does Not Change

Your application:

• Runs on the same port
• Uses the same environment variables
• Writes logs to stdout/stderr

Kubernetes wraps your container — it does not rewrite your app.

3. Basic Networking Concepts Still Exist

Containers still:

• Communicate over IP
• Expose ports
• Receive HTTP requests

However, Kubernetes adds an abstraction layer so applications don’t break when containers restart.

This abstraction decouples applications from individual container lifecycles, allowing Kubernetes to restart, replace, or scale containers without breaking communication. ie, when container restarts the IP changes and applications would fail to communicate when containers restart and receive new IP addresses.

What Changes (The Real Kubernetes Shift)

This is where Kubernetes starts to feel very different from Docker.

1. From Imperative to Declarative

With Docker, you usually tell the system what to do:

docker run -p 3000:3000 myapp

With Kubernetes, you describe how the system should look, and Kubernetes figures out the rest.

in k8s we ‘declare’ how we want our system to look like, a desired state and k8s will manage the WHAT part.

2. Containers Are No Longer Long-Lived

In Docker, we often care about a specific container.

In Kubernetes:

• Containers can crash
• Pods can be recreated
• Nodes can disappear

And this is expected behavior.

In Kubernetes, containers are expected to die because crashes, restarts, scaling, and updates are normal events, not exceptions.

3. Scaling Is No Longer Manual

In Docker, scaling means manually running more containers.

In Kubernetes, you simply declare:

replicas: 3

Kubernetes continuously ensures that this state is maintained.

In production environments, load fluctuates constantly, and declarative scaling allows Kubernetes to respond to demand while maintaining availability.

4. One Container ≠ One Machine Anymore

With Docker, containers often feel like lightweight VMs.

With Kubernetes:

• Pods can move across nodes
• Nodes are replaceable
• Infrastructure is disposable

Think of containers like employees and nodes like office desks. In Docker, each employee must sit at a fixed desk (a fixed machine). If the desk breaks, the employee can’t work. In Kubernetes, employees can move to any available desk automatically. The company (Kubernetes) ensures work continues, even if desks or rooms fail. You only care about the tasks being done, not which desk they sit at.

Kubernetes Architecture — A High-Level View

To really understand Kubernetes, it helps to know how it is structured internally. At a high level, a Kubernetes cluster is made up of two main parts:

• Control Plane — the brain of the cluster
• Worker Nodes — where your applications actually run

Kubernetes follows a control vs execution model.

Kubernetes Cluster Architecture

Control Plane — The Brain 🧠

The control plane is responsible for managing the state of the cluster. It does not run your application containers.

1. API Server

The API Server is the entry point to Kubernetes.

• All requests go through it
• kubectl, CI/CD pipelines, and internal components talk to it
• It validates and processes requests

By separating control and execution, Kubernetes ensures that even if worker nodes fail, the control plane can reschedule workloads and maintain the cluster’s desired state.

2. etcd — The Source of Truth

etcd is a distributed key–value store used by Kubernetes.

It stores:

• Desired state of the cluster
• Current state of the cluster
• Configuration and metadata

If etcd is lost, Kubernetes loses its memory.

etcd is the single source of truth for the cluster, holding all configuration, state, and metadata needed to manage workloads, like Kubernetes’ memory, storing what should be running and what is actually running.

3. Scheduler

The scheduler decides:

• Which node a pod should run on

It considers:

• Available resources
• Constraints
• Policies

4. Controller Manager

Controllers continuously compare:

• Desired state
• Actual state

If there is a mismatch, controllers act to fix it.

Example:

• You want 3 replicas
• Only 2 are running
• Controller creates another pod

Worker Nodes — Where Work Happens ⚙️

Worker nodes are responsible for running your application workloads.

Each worker node contains the following key components:

1. kubelet

kubelet is the agent running on each node.

It:

• Communicates with the API Server
• Starts containers using the container runtime
• Reports pod status back

2. Container Runtime

This is the software that actually runs containers.

Examples:

• containerd, CRI-O, Docker (earlier setups)

Kubernetes does not run containers directly — it delegates this job.

Kubernetes stays runtime-agnostic so it can work with different container runtimes (like Docker, containerd, or CRI-O) without changing how you define or run your applications.

3. kube-proxy

kube-proxy handles networking rules on each node.

It enables:

• Pod-to-pod communication
• Service abstraction

How This All Connects (End-to-End Flow)

A simplified flow looks like this:

1. A Deployment is applied
2. API Server receives the request
3. Desired state is stored in etcd
4. Scheduler assigns pods to nodes
5. kubelet creates containers
6. kube-proxy enables networking

Final Thoughts

Kubernetes does not replace Docker — it builds on top of it.

If Docker answers:

“How do I run this container?”

Kubernetes answers:

“How do I run this container reliably, at scale, in production?”

In the next part of this series, I’ll dive into Pods — why Kubernetes doesn’t run containers directly, and how this design choice enables scaling and resilience.