DEV Community

Yash Sonawane
Yash Sonawane

Posted on

Kubernetes Is Not Magic: Understanding How Kubernetes Actually Works

#kubernetes #webdev #programming #ai

Kubernetes can look intimidating when you first encounter it.

You see:

kubectl get pods
kubectl get deployments
kubectl get services
kubectl describe pod
kubectl apply -f deployment.yaml
Enter fullscreen mode Exit fullscreen mode

Then you open a Kubernetes manifest and find:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
Enter fullscreen mode Exit fullscreen mode

And you think:

"What is actually happening here?"

That question is more important than memorizing kubectl commands.

Kubernetes becomes much easier once you stop treating it as a collection of commands and start understanding the system behind those commands.

In this article, we'll build that mental model from the ground up.

What Problem Does Kubernetes Solve?

Imagine you have one application.

You could run it on one server:

User
  ↓
Server
  ↓
Application
Enter fullscreen mode Exit fullscreen mode

Simple.

But eventually you might need:

  • Multiple application instances
  • Automatic recovery
  • Load balancing
  • Rolling updates
  • Service discovery
  • Configuration management
  • Secret management
  • Resource management
  • Container orchestration

Now your architecture becomes:

                 Users
                   ↓
              Application
             /     |     \
           App    App    App
           │       │      │
         Container Container Container
Enter fullscreen mode Exit fullscreen mode

Managing this manually becomes increasingly difficult.

Kubernetes is designed to orchestrate containerized workloads.

Kubernetes Is a Desired-State System

This is one of the most important concepts in Kubernetes.

Instead of constantly telling Kubernetes exactly what to do, you describe the state you want.

For example:

replicas: 3
Enter fullscreen mode Exit fullscreen mode

You're effectively saying:

"I want three replicas of this application."

Kubernetes continuously works toward that desired state.

Conceptually:

Desired State
     ↓
Kubernetes Control Plane
     ↓
Actual Cluster State
     ↓
Reconciliation
Enter fullscreen mode Exit fullscreen mode

If one Pod disappears:

Desired: 3 Pods
Actual:  2 Pods
Enter fullscreen mode Exit fullscreen mode

Kubernetes can detect the difference and work to restore the desired state.

This idea of reconciliation is fundamental to Kubernetes.

What Is a Cluster?

A Kubernetes cluster is generally made up of:

             Kubernetes Cluster
                    │
          ┌─────────┴─────────┐
          │                   │
    Control Plane          Worker Nodes
                              │
                     ┌────────┼────────┐
                     │        │        │
                    Pod      Pod      Pod
Enter fullscreen mode Exit fullscreen mode

The cluster has two major conceptual areas:

Control Plane

Responsible for managing the cluster.

Worker Nodes

Where application workloads run.

Understanding this separation is extremely important.

The Control Plane

The control plane is essentially the management layer of Kubernetes.

Important components include:

  • API Server
  • Scheduler
  • Controller Manager
  • etcd

Let's understand them.

1. Kubernetes API Server

The API Server is one of the most important components.

When you run:

kubectl get pods
Enter fullscreen mode Exit fullscreen mode

your request goes through the Kubernetes API.

Conceptually:

You
 ↓
kubectl
 ↓
Kubernetes API Server
 ↓
Cluster
Enter fullscreen mode Exit fullscreen mode

The API Server provides the interface through which Kubernetes resources are managed.

This is why understanding the Kubernetes API is more useful than simply memorizing kubectl commands.

2. etcd

Kubernetes needs a place to store cluster state.

That's where etcd comes in.

You can think of it as a distributed key-value store used by Kubernetes for cluster state.

Conceptually:

Kubernetes
    ↓
API Server
    ↓
etcd
    ↓
Cluster State
Enter fullscreen mode Exit fullscreen mode

If you're preparing for the CKA, understanding the role of etcd is important.

3. Scheduler

Imagine you create a Pod.

Kubernetes needs to decide:

"Which worker node should run this Pod?"

That's one of the scheduler's responsibilities.

Conceptually:

New Pod
   ↓
Scheduler
   ↓
Node A
Node B
Node C
   ↓
Selected Node
Enter fullscreen mode Exit fullscreen mode

The scheduler considers things such as resource requirements and scheduling constraints.

4. Controller Manager

Controllers continuously observe the cluster and work toward the desired state.

For example:

Desired:
3 replicas

Actual:
2 replicas
Enter fullscreen mode Exit fullscreen mode

A controller detects the difference and works toward:

3 replicas
Enter fullscreen mode Exit fullscreen mode

This is the reconciliation loop.

You can think of Kubernetes as constantly asking:

"What should the cluster look like?"

"What does it look like right now?"

"What needs to change?"

That is one of the core ideas behind Kubernetes.

What Is a Pod?

Now we reach one of the most important Kubernetes concepts.

Pod.

A Pod is the smallest deployable unit in Kubernetes.

A Pod can contain one or more containers.

For a simple application:

Pod
 └── Container
      └── Application
Enter fullscreen mode Exit fullscreen mode

For a multi-container Pod:

Pod
 ├── Container A
 └── Container B
Enter fullscreen mode Exit fullscreen mode

Containers in the same Pod share certain resources and networking characteristics.

But don't think:

"Pod = VM."

A Pod is not a virtual machine.

It is a Kubernetes abstraction around one or more containers.

Why Not Just Run Containers Directly?

You can run Docker containers manually:

docker run my-app
Enter fullscreen mode Exit fullscreen mode

But imagine managing:

100 Containers
500 Containers
1000 Containers
Enter fullscreen mode Exit fullscreen mode

You now need to handle:

  • Scheduling
  • Networking
  • Health checks
  • Scaling
  • Updates
  • Failures
  • Service discovery

That's where orchestration becomes useful.

Kubernetes provides abstractions for managing these workloads.

Deployments

You generally don't want to manually create individual Pods for your application.

Instead, you can use a Deployment.

Example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: web-app
          image: nginx
Enter fullscreen mode Exit fullscreen mode

The important line is:

replicas: 3
Enter fullscreen mode Exit fullscreen mode

You're declaring that you want three replicas.

Conceptually:

Deployment
    ↓
ReplicaSet
    ↓
┌──────┬──────┬──────┐
│ Pod  │ Pod  │ Pod  │
└──────┴──────┴──────┘
Enter fullscreen mode Exit fullscreen mode

This is much more powerful than manually starting containers.

What Happens If a Pod Dies?

Suppose you have:

3 Pods
Enter fullscreen mode Exit fullscreen mode

Then one crashes:

Pod 1 → Running
Pod 2 → Failed
Pod 3 → Running
Enter fullscreen mode Exit fullscreen mode

The Deployment's desired state is still:

3 replicas
Enter fullscreen mode Exit fullscreen mode

Kubernetes can create another Pod.

Eventually:

Pod 1 → Running
Pod 2 → Running
Pod 3 → Running
Enter fullscreen mode Exit fullscreen mode

This is one of the reasons Kubernetes is powerful.

You describe what you want.

Kubernetes continuously works toward maintaining it.

Services Solve a Major Problem

Pods are not permanent.

They can be recreated.

That means their individual network identities shouldn't be treated as permanent application endpoints.

Imagine:

Pod A → 10.x.x.1
Pod B → 10.x.x.2
Pod C → 10.x.x.3
Enter fullscreen mode Exit fullscreen mode

Pod B dies.

A new Pod appears:

Pod D → 10.x.x.7
Enter fullscreen mode Exit fullscreen mode

Now how should another application find the correct Pods?

That's where a Kubernetes Service helps.

Kubernetes Services

A Service provides a stable way to access a group of Pods.

Conceptually:

             Service
            /   |   \
           /    |    \
        Pod    Pod    Pod
Enter fullscreen mode Exit fullscreen mode

The Pods can change.

The Service remains the stable abstraction.

For example:

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web-app
  ports:
    - port: 80
      targetPort: 80
Enter fullscreen mode Exit fullscreen mode

Now traffic sent to the Service can be routed to matching Pods.

This is the foundation of Kubernetes service discovery.

ConfigMaps

Applications often need configuration.

For example:

DATABASE_HOST
APP_ENV
LOG_LEVEL
API_URL
Enter fullscreen mode Exit fullscreen mode

Instead of hardcoding configuration directly into the container image, Kubernetes provides ConfigMaps for non-sensitive configuration.

Conceptually:

ConfigMap
   ↓
Application Pod
   ↓
Configuration
Enter fullscreen mode Exit fullscreen mode

This helps separate application code from environment-specific configuration.

Secrets

What about sensitive information?

For example:

Database Password
API Token
Credentials
Certificates
Enter fullscreen mode Exit fullscreen mode

Kubernetes provides Secrets as a mechanism for storing and supplying sensitive configuration data.

The important lesson is:

Don't put credentials directly into application source code or container images.

Also remember that Kubernetes Secrets aren't automatically equivalent to a complete secrets-management strategy; production environments may use dedicated secret-management systems and appropriate encryption/access controls.

Health Checks

What happens if the application process is running but the application itself isn't actually working?

For example:

Container: Running
Application: Broken
Enter fullscreen mode Exit fullscreen mode

Kubernetes supports health probes.

Common concepts include:

Liveness Probe

Helps determine whether a container should be restarted.

Readiness Probe

Helps determine whether a container is ready to receive traffic.

Conceptually:

Application
    ↓
Health Check
    ↓
Healthy?
    │
 ┌──┴──┐
Yes    No
 ↓      ↓
Traffic  Remove/Restart
Enter fullscreen mode Exit fullscreen mode

This is extremely useful for reliable deployments.

Rolling Updates

Suppose you currently run:

Version 1
Enter fullscreen mode Exit fullscreen mode

And you want to deploy:

Version 2
Enter fullscreen mode Exit fullscreen mode

You don't necessarily want to shut down everything simultaneously.

Kubernetes Deployments can perform rolling updates.

Conceptually:

Version 1
Version 1
Version 1
     ↓
Version 2
Version 1
Version 1
     ↓
Version 2
Version 2
Version 1
     ↓
Version 2
Version 2
Version 2
Enter fullscreen mode Exit fullscreen mode

The exact behavior depends on the Deployment strategy and configuration, but the basic idea is controlled replacement.

This is one of the features that makes Kubernetes useful for continuous delivery.

Kubernetes Networking

Networking is where Kubernetes becomes much deeper.

You eventually need to understand:

  • Pod networking
  • Services
  • DNS
  • Network policies
  • Ingress
  • Load balancing

For example:

User
 ↓
Ingress
 ↓
Service
 ↓
Pods
Enter fullscreen mode Exit fullscreen mode

Internally, one service can discover another through Kubernetes DNS.

For example:

frontend
   ↓
backend-service
   ↓
Backend Pods
Enter fullscreen mode Exit fullscreen mode

This makes communication between services easier to manage.

Ingress

Suppose you have several applications:

example.com
api.example.com
shop.example.com
Enter fullscreen mode Exit fullscreen mode

You may want an entry point that routes traffic to different services.

Conceptually:

                    Internet
                       ↓
                    Ingress
                  /    |    \
                 /     |     \
             Frontend  API    Shop
                ↓       ↓       ↓
             Service Service Service
Enter fullscreen mode Exit fullscreen mode

Ingress is one way Kubernetes can model HTTP/HTTPS routing into cluster services.

Modern Kubernetes environments may also use the Gateway API for more advanced traffic-management scenarios.

Resource Requests and Limits

A common Kubernetes mistake is deploying applications without thinking about resource usage.

Imagine one Pod consumes:

CPU: 4 cores
Memory: 8 GB
Enter fullscreen mode Exit fullscreen mode

If you have dozens of Pods, resource consumption can become significant.

Kubernetes lets you define resource requests and limits.

For example:

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"
Enter fullscreen mode Exit fullscreen mode

This helps Kubernetes make scheduling decisions and place boundaries around container resource usage.

Kubernetes Is a Platform, Not Just a Command-Line Tool

This is perhaps the biggest lesson.

If your Kubernetes knowledge is:

kubectl get pods
kubectl delete pod
kubectl apply -f file.yaml
Enter fullscreen mode Exit fullscreen mode

you know some commands.

You don't necessarily understand Kubernetes yet.

Real understanding means knowing:

Control Plane
      ↓
API Server
      ↓
Controllers
      ↓
Scheduler
      ↓
Worker Nodes
      ↓
Pods
      ↓
Containers
Enter fullscreen mode Exit fullscreen mode

And then understanding how:

Deployments
Services
ConfigMaps
Secrets
Ingress
Volumes
Probes
Resources
Networking
Enter fullscreen mode Exit fullscreen mode

fit into that architecture.

A Practical Kubernetes Learning Roadmap

If you're starting Kubernetes, don't try to memorize everything.

Follow a progression.

Phase 1 — Foundations

Learn:

  • Linux
  • Networking
  • Containers
  • Docker
  • YAML
  • Basic Git

Phase 2 — Kubernetes Fundamentals

Learn:

  • Cluster architecture
  • Pods
  • Namespaces
  • Deployments
  • ReplicaSets
  • Services

Phase 3 — Configuration

Learn:

  • ConfigMaps
  • Secrets
  • Environment variables
  • Volumes

Phase 4 — Networking

Learn:

  • Services
  • DNS
  • Ingress
  • Network policies

Phase 5 — Reliability

Learn:

  • Liveness probes
  • Readiness probes
  • Resource requests
  • Resource limits
  • Scaling

Phase 6 — Operations

Learn:

  • Logs
  • Troubleshooting
  • Scheduling
  • RBAC
  • Cluster maintenance

Phase 7 — Advanced Kubernetes

Then move toward:

  • Helm
  • Operators
  • CRDs
  • GitOps
  • Observability
  • Security
  • Production architecture

Build Instead of Just Watching Tutorials

Here's a project I'd recommend.

Build a simple microservices application:

                User
                  ↓
               Ingress
                  ↓
              Frontend
                  ↓
              Backend
             /       \
            ↓         ↓
        Database    Redis
Enter fullscreen mode Exit fullscreen mode

Containerize everything.

Then deploy it to Kubernetes.

Add:

Deployment
Service
ConfigMap
Secret
Ingress
Persistent Volume
Health Probes
Resource Limits
Enter fullscreen mode Exit fullscreen mode

Then break things intentionally.

Delete a Pod.

Change a Service port.

Break a configuration value.

Use the wrong image tag.

Remove a required environment variable.

Then troubleshoot.

This is where Kubernetes knowledge becomes real.

The Troubleshooting Mindset

Suppose you run:

kubectl get pods
Enter fullscreen mode Exit fullscreen mode

And see:

NAME                     READY   STATUS
backend-7d8c9d4b-x7k2    0/1     CrashLoopBackOff
Enter fullscreen mode Exit fullscreen mode

Don't immediately copy a random command from the internet.

Start investigating.

kubectl describe pod backend-7d8c9d4b-x7k2
Enter fullscreen mode Exit fullscreen mode

Then:

kubectl logs backend-7d8c9d4b-x7k2
Enter fullscreen mode Exit fullscreen mode

Ask:

  • What changed?
  • Is the container starting?
  • Is the image correct?
  • Are environment variables present?
  • Can it connect to its dependencies?
  • Is the health probe failing?
  • Is the application crashing?

This is the difference between:

Knowing Kubernetes commands

and

Knowing how to operate Kubernetes.

Learn Kubernetes for a Reason

Don't learn Kubernetes just because every DevOps roadmap contains it.

Understand what problem it solves.

If you have:

Many containers
+
Frequent deployments
+
Scaling requirements
+
Service discovery
+
Self-healing requirements
+
Complex workloads
Enter fullscreen mode Exit fullscreen mode

an orchestration platform becomes valuable.

Kubernetes is one way to provide those capabilities.

My Kubernetes Book

If you're serious about learning Kubernetes and want a structured resource instead of jumping between random tutorials, I've created:

CKA Complete Study Guide — Certified Kubernetes Administrator

The goal is to take you from Kubernetes fundamentals toward practical cluster administration and CKA-oriented knowledge.

You can check it out here:

CKA Complete Study Guide — Certified Kubernetes Administrator

CKA Study Guid

The best way to use the book is simple:

Read
 ↓
Practice
 ↓
Build
 ↓
Break
 ↓
Troubleshoot
 ↓
Repeat
Enter fullscreen mode Exit fullscreen mode

Don't just memorize commands for an exam.

Understand what Kubernetes is doing underneath them.

Other DevOps Resources

If you're building a complete Cloud & DevOps skill set, you can also explore:

Docker Mastery

Docker Mastery Dca 2026

Terraform Associate (003) Exam Crash Course

TerraformAssociate

Git Mastery

Git Mastery

DevOps Complete Pack

Devopspack

Mastering Go

Mastering Go Complete

Final Thoughts

Kubernetes looks complicated because there are many moving parts.

But underneath all those YAML files and commands is a relatively simple idea:

Describe what you want, and Kubernetes continuously works to make the cluster match that desired state.

Once you understand that, many Kubernetes concepts start connecting:

Deployment
    ↓
ReplicaSet
    ↓
Pods
    ↓
Containers
Enter fullscreen mode Exit fullscreen mode

and:

Ingress
    ↓
Service
    ↓
Pods
Enter fullscreen mode Exit fullscreen mode

and:

ConfigMap / Secret
    ↓
Pod
    ↓
Application
Enter fullscreen mode Exit fullscreen mode

and:

API Server
    ↓
Controllers + Scheduler
    ↓
Worker Nodes
    ↓
Workloads
Enter fullscreen mode Exit fullscreen mode

That's the mental model you want.

Don't become someone who only knows:

kubectl get pods
Enter fullscreen mode Exit fullscreen mode

Become someone who can answer:

Why is this Pod running here?

Who created it?

How does traffic reach it?

Where does its configuration come from?

What happens when it crashes?

How does Kubernetes recover it?

How would I troubleshoot it?

That's when Kubernetes stops being a collection of commands and becomes a system you actually understand.

Learn the architecture. Build real clusters. Break things. Troubleshoot them. Then automate.

And if you're preparing for Kubernetes administration or the CKA, check out:

CKA Complete Study Guide — Certified Kubernetes Administrator

CKA Study Guide

Top comments (0)