Why Kubernetes?

The conceptual foundation: what problems Kubernetes solves and why it dominates container orchestration. Part of the CKA Certification journey.

The Problem: Containers at Scale

Docker revolutionized application packaging, but running containers in production exposes critical gaps when operating at enterprise scale:

Problem	Description	Business Impact
No Auto-Healing	Container crashes stay down until manual restart	Downtime, SLA breaches
No Auto-Scaling	Traffic spikes overwhelm fixed container counts	Performance degradation, lost revenue
No Load Balancing	No native traffic distribution across instances	Uneven load, hot spots
Manual Deployments	Updates require stop/remove/run steps	Human error, downtime
No Service Discovery	Dynamic IPs make inter-service communication brittle	Broken integrations
Host-Bound	Containers tied to specific machines	No fault tolerance, hard migrations

How Kubernetes Solves These Problems

Kubernetes Capability	What It Does
Self-Healing	Automatically restarts failed containers, replaces unresponsive pods, reschedules on healthy nodes via ReplicaSet and Deployment controllers
Horizontal Auto-Scaling	HPA adds/removes pod replicas based on CPU, memory, or custom metrics
Load Balancing	Service abstraction distributes traffic across pod replicas automatically
Rolling Updates & Rollbacks	Zero-downtime deployments with automatic rollback if health checks fail
Service Discovery	DNS-based naming (my-service.default.svc.cluster.local) decouples clients from pod IPs via Kubernetes Services
Intelligent Scheduling	Places workloads on optimal nodes based on resources, constraints, and policies
Namespace Isolation	Logical partitioning for multi-tenancy, resource quotas, and RBAC per team/environment via Namespaces

What Is Kubernetes?

Kubernetes (K8s) is an open-source container orchestration platform originally designed by Google (based on their internal Borg system), now maintained by the Cloud Native Computing Foundation (CNCF).

• Abstraction Layer: Treats a cluster of machines as a single unified compute resource.
• Declarative Model: You describe the desired state (e.g., “run 3 replicas of my app”), and Kubernetes continuously reconciles actual state to match.
• Extensible: Pluggable networking (CNI), storage (CSI), and authentication/authorization.

Kubernetes vs. Docker

Aspect	Docker	Kubernetes
Scope	Single-host container runtime	Multi-host container orchestration
Scaling	Manual (docker run more instances)	Automatic (HPA, VPA, Cluster Autoscaler)
Resilience	None built-in	Self-healing, replication, rescheduling
Networking	Basic bridge/overlay networks	Advanced CNI plugins, ingress, service mesh
Deployment	Imperative commands	Declarative YAML, rolling updates
Use Case	Local development, single-host apps	Production, distributed, multi-node systems

When Kubernetes Is NOT the Right Choice

Scenario	Better Alternative	Reason
Single small app on one server	Docker Compose, systemd	Operational overhead exceeds benefit
One-off batch jobs	Cron, AWS Lambda, Cloud Run	Ephemeral; doesn’t need orchestration
Team lacks DevOps expertise	Managed PaaS (Heroku, App Engine)	Steep learning curve; misconfiguration risks
Edge/IoT with tight resources	K3s, Nomad, Docker Swarm	Full K8s is too heavy for constrained devices
Simple static websites	CDN + S3, Netlify, Vercel	Overkill; no container benefits needed

The Big Picture

┌─────────────────────────────────────────────┐
│              Kubernetes Cluster               │
│                                               │
│   ┌─────────────────────────────────────┐     │
│   │         Control Plane (Brain)        │     │
│   │  ┌─────────┐ ┌─────────┐ ┌────────┐ │     │
│   │  │ API     │ │ etcd    │ │ Sched- │ │     │
│   │  │ Server  │ │ (Store) │ │ uler   │ │     │
│   │  └─────────┘ └─────────┘ └────────┘ │     │
│   │  ┌─────────┐ ┌─────────────────┐    │     │
│   │  │ Control │ │ Cloud Controller│    │     │
│   │  │ Manager │ │ Manager         │    │     │
│   │  └─────────┘ └─────────────────┘    │     │
│   └─────────────────────────────────────┘     │
│                    │                          │
│   ┌─────────────────────────────────────┐     │
│   │         Worker Nodes (Muscle)        │     │
│   │  ┌─────────┐ ┌─────────┐ ┌────────┐ │     │
│   │  │ kubelet │ │kube-proxy│ │Container││     │
│   │  │ (Agent) │ │(Network)│ │Runtime ││     │
│   │  └─────────┘ └─────────┘ └────────┘ │     │
│   └─────────────────────────────────────┘     │
│                                               │
│   You declare: "I want 3 replicas"            │
│   Kubernetes does: Schedule → Heal → Scale    │
│                    → Update → Balance         │
└─────────────────────────────────────────────┘

Sources

• CKA Day 4: Why Kubernetes Is Used

Practical Practice

Conceptual and architecture-oriented tasks to solidify your understanding of why Kubernetes works the way it does. These are not hands-on CLI drills — they test your mental model.

Task 1: Identify the Right Abstraction A team is running 5 containers on a single VM using Docker Compose. They experience downtime every time the VM reboots and cannot scale beyond one machine. You are asked to recommend the smallest set of Kubernetes primitives that solve auto-healing, scaling, and load balancing. Requirements: Name the minimum resources needed (Namespace, Deployment, Service) and explain why each is necessary. Verification: A written explanation checked against the page’s “How Kubernetes Solves These Problems” table. Solution:

1. Namespace — isolate the team's workloads
2. Deployment + ReplicaSet — self-healing (restarts crashed containers) and scaling (replica count)
3. Service — stable endpoint and load balancing across Pod replicas
4. Optional: HPA for automatic scaling based on CPU/memory

Task 2: Kubernetes vs. Docker Decision A startup runs a single-node prototype with 3 containers (web, API, database). They ask whether they need Kubernetes now or can stay on Docker Compose until they have 10+ nodes. You are asked to list the specific signals that justify moving to Kubernetes. Requirements: List 3 concrete operational signals (not just “scale”). Verification: Your answer should reference at least three items from the “Problems at Scale” table. Solution:

Signals that justify Kubernetes:
1. Need for auto-healing (containers crash and must restart automatically)
2. Multiple nodes required (horizontal scaling beyond one VM)
3. Rolling updates needed (zero-downtime deployments)
4. Service discovery across services (dynamic IPs make hardcoded addresses brittle)

Task 3: Architecture Flow Walkthrough You are asked to trace the path of a kubectl apply -f deployment.yaml command through the Kubernetes architecture. List every component that touches the request, in order. Requirements: Start from kubectl and end at the container runtime creating the Pod. Verification: Compare your flow against the Architecture page’s request-flow diagram. Solution:

kubectl → kube-apiserver → etcd (persist desired state) 
→ controller-manager (Deployment controller creates ReplicaSet) 
→ scheduler (assigns node) → kubelet (on assigned node) 
→ container runtime (creates containers) → CNI (assigns Pod IP)

Related Pages

• Kubernetes Architecture
• Kubernetes Services — How K8s provides stable networking for dynamic Pods
• Kubernetes Namespaces — Multi-tenancy and resource governance
• Kubernetes CNI — Pluggable networking: the CNI specification and plugin ecosystem
• CKA Certification
• CKA Study Roadmap
• Docker Fundamentals

---

Tags: kubernetes container-orchestration devops cka cloud-native why-k8s