What is Kubernetes, and what problem does it solve?

The problem before orchestration

Running a single container on a single machine is easy — docker run and you're done. The problem shows up at scale. An application with a dozen services, each needing multiple replicas for availability, spread across many machines, needs to survive machine failures, find and talk to its own parts, and update without downtime. Doing this by hand — SSHing into machines, manually restarting crashed containers, editing load balancer configs when an instance moves — doesn't scale past a handful of containers. It's fragile and slow even at that scale.

What Kubernetes actually automates

• Scheduling — deciding which machine (node) in the cluster should run each container, based on available resources and constraints.
• Self-healing — if a container crashes or a node dies, Kubernetes notices and starts replacement containers elsewhere, with no human involved.
• Service discovery and load balancing — containers get a stable way to find and talk to each other, even as individual instances are created, destroyed, and moved between nodes.
• Rolling updates and rollbacks — deploying a new version gradually, replacing old instances with new ones, and automatically reverting if something goes wrong.
• Scaling — increasing or decreasing the number of running instances, manually or automatically based on load.
• Configuration and secret management — injecting configuration and sensitive values into applications without baking them into container images.

The core idea: declarative desired state

Instead of issuing imperative commands ("start this container on that machine"), you describe the desired state of your system in configuration: "I want 3 replicas of this application running." Kubernetes continuously works to make the actual state match it. This reconciliation-loop model, covered in depth in a later question, is the central idea everything else in Kubernetes builds on.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3          # desired state: always keep 3 running
  template:
    spec:
      containers:
        - name: web
          image: myapp:1.4.0

If a node hosting one of these pods dies, Kubernetes notices the actual count dropped below 3 and schedules a replacement — no one needs to notice the failure or take manual action.

Why this matters for interviews

A strong answer doesn't just define Kubernetes as "a container orchestrator." It connects that definition to the concrete operational pain that existed before it — manual scheduling, no self-healing, fragile networking, risky deploys — and names the reconciliation/desired-state model as the mechanism that makes the automation possible. This framing sets up nearly every other Kubernetes topic, since almost every object type (Deployments, Services, PVCs) is just a different application of the same "describe what you want, a controller makes it true" pattern.