ReviseAlgo Logo

Kubernetes Architecture

Why Kubernetes Exists — The Container Orchestration Problem

Moving beyond single-host container management.

Interview: Be ready to explain the transition from single-host container management (Docker Compose) to distributed systems. Interviewers look for architectural justification: service discovery across nodes, container rescheduling upon host failure, automated scaling, and rollout strategies.

Last Updated: June 15, 2026 • 15 min read

Introduction

Docker makes it trivial to package, ship, and run a single application container on your machine. But in production, you cannot run your application stack on a single server. If the server loses network connectivity or suffers a hardware crash, your system goes offline.

To achieve high availability, we must distribute container instances across a cluster of physical or virtual machines. This introduces the Container Orchestration Problem.

Why It Matters

At scale, manually logging into dozens of servers to restart crashed containers, coordinate network routes, and allocate port ranges is impossible. Container orchestration automates these operations, increasing uptime and reducing operational overhead.

Real-World Analogy

Running containers manually is like being a hotel manager who has to check in every guest individually, show them to their room, carry their bags, and make sure their lights work. Kubernetes is like a fully automated luxury hotel system. Guests book a room online (declarative request), and the system automatically assigns them an open room (scheduler), programs the keycard, monitors utility usage (cgroups), and calls maintenance if the lights go out (self-healing).

How It Works

Kubernetes aggregates a group of physical or virtual servers into a single unified resource pool:

  1. You submit a desired state configuration manifest (YAML) to the cluster gateway.
  2. The control plane identifies which worker nodes have the CPU and memory capacity to run the containers.
  3. The worker nodes pull the container images and launch the processes, constantly reporting their health status back to the control plane.

Internal Architecture

Kubernetes divides work between the Control Plane (which acts as the cluster brain) and Worker Nodes (which act as the cluster muscle). The control plane runs components like the API Server, etcd, Scheduler, and Controller Manager. The worker nodes run the kubelet agent, kube-proxy for routing, and the container executor (containerd).

Visual Explanation

Loading diagram…

Practical Example

Here is how to create a deployment representing a scalable, self-healing web server replica set:

Common Mistakes

1. Ignoring Node Resources: Deploying containers without configuring CPU/RAM request limits. If one container has a memory leak, it can consume the host node's entire physical memory, causing the operating system to terminate other critical cluster workloads.
2. Imperative Antipatterns: Running raw kubectl run commands to deploy apps. These commands do not produce version-controlled configuration files, violating GitOps patterns.

Quick Quiz

Q1: What is the primary role of a container orchestrator like Kubernetes?

A) Compile application source code into images.

B) Automate scheduling, scaling, and health management of containers across a cluster of hosts.

C) Run single-container databases on development machines.

Answer: B — Container orchestration focuses on managing container lifecycles across distributed systems at scale.

Scenario-Based Challenge

Scenario:

Your application has a traffic spike at 9:00 AM every morning. If you host it on single servers using Docker Compose, how does this compare to running it on a Kubernetes cluster?

View Solution

On Docker Compose, you must manually run CLI commands to scale instances, or configure external host-level autoscaling scripts which is highly complex. In Kubernetes, you can configure a Horizontal Pod Autoscaler (HPA) to monitor CPU metrics. When CPU exceeds 70%, K8s automatically spins up new Pod replicas and registers them to load balancers, then scales them back down when traffic subsides.

Debugging Exercise

Failure Case:

A physical worker node in your cluster loses power. In a standard Docker Compose setup, the containerized app goes offline. How does Kubernetes automatically handle this node failure?

Describe the automatic healing process.

View Solution

1. The control plane detects that the failed node has stopped sending health heartbeats.
2. The Node Controller marks the node status as NotReady.
3. The Deployment controller compares desired state (e.g. 3 replicas) with observed state (only 2 active on healthy nodes).
4. The Scheduler identifies a healthy node and binds the pending Pod to it. The local node agent (kubelet) pulls the image and starts the container, recovering the desired state without human intervention.

Interview Questions

1. What is the container orchestration problem and what challenges does it solve?

It is the challenge of managing container lifecycles across a pool of servers. It solves scheduling (where to run), self-healing (recovering from host failure), service discovery (routing), and automated rollouts.

2. Where did Kubernetes originate?

It was originally designed by Google engineers, drawing heavily from their internal container orchestration system called Borg, before being donated to the CNCF (Cloud Native Computing Foundation) in 2014.

Production Considerations

Do not host all your Kubernetes control plane nodes in the same availability zone. Always distribute them across physical zones to prevent single-datacenter outages from locking control plane administration.