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 appears at scale: an application with a dozen services, each needing multiple replicas for availability, spread across many machines, needing to survive machine failures, needing to find and talk to each other, and needing to be updated without downtime. Doing this by hand — SSHing into machines, manually restarting crashed containers, manually editing load balancer configs when an instance moves — doesn't scale past a handful of containers, and is fragile and slow even then.

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, without a human intervening.
• Service discovery and load balancing — containers get a stable way to find and talk to each other, even as individual instances are created and destroyed and move between nodes.
• Rolling updates and rollbacks — deploying a new version of an application gradually, replacing old instances with new ones, and automatically reverting if something goes wrong.
• Scaling — increasing or decreasing the number of running instances of an application, 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

Rather than 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") and 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 that 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 has dropped below 3 and schedules a replacement — without anyone needing 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 (manual scheduling, no self-healing, fragile networking, risky deploys) that existed before it, 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 in the system (Deployments, Services, PVCs) is just a different application of the same "describe what you want, a controller makes it true" pattern.