What is Kubernetes?

You can run one container on your laptop with a single docker run command. But what happens when you need to run hundreds of containers across dozens of machines, keep them healthy, route traffic between them, and update them without downtime? That's the problem Kubernetes solves. It takes the manual, error-prone work of managing containers at scale and automates it.

The Container Problem

Containers changed how we package and ship software. Instead of installing dependencies directly on a server and hoping they don't conflict, you bundle your application and everything it needs into a single, portable image. Docker made this mainstream around 2013, and suddenly deploying software became reproducible.

But containers alone only solve the packaging problem. They don't answer the harder operational questions:

• Where does each container run? If you have 20 servers and 150 containers, which containers go on which servers?
• What happens when a container crashes? Who restarts it? How fast?
• How does traffic reach the right container? If you're running 5 copies of your API, how does a request get routed to one of them?
• How do you update without downtime? You can't stop everything, deploy, and start again — users are active.

These are orchestration problems. Containers are the building blocks; orchestration is the construction plan.

What Kubernetes Actually Does

Kubernetes (often abbreviated K8s — the 8 stands for the eight letters between 'K' and 's') is a container orchestration platform. You tell it what you want your system to look like, and it continuously works to make that happen.

Here's the core idea: you write a desired state declaration like "I want 3 copies of my API running, each with 512MB of memory, accessible on port 80." Kubernetes reads that declaration and figures out which machines to place them on, starts the containers, monitors their health, and replaces any that fail.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-api
  template:
    metadata:
      labels:
        app: my-api
    spec:
      containers:
        - name: api
          image: my-api:1.2.0
          resources:
            limits:
              memory: "512Mi"
          ports:
            - containerPort: 8080

This YAML file is a Deployment manifest. You apply it with kubectl apply -f deployment.yaml, and Kubernetes does the rest. You don't SSH into servers. You don't manually start processes. You declare intent.

Declarative vs. Imperative

This distinction matters. In an imperative model, you issue commands step by step: "SSH into server-3, pull the latest image, stop the old container, start a new one." If any step fails, you're in a partially-updated state and you have to figure out what went wrong.

In a declarative model, you describe the end state: "3 replicas of version 1.2.0." Kubernetes compares the desired state to the current state and takes whatever actions are needed to converge. If a container dies, K8s doesn't need you to notice — it sees the discrepancy and fixes it automatically.

This is the reconciliation loop: observe the current state, compare it to the desired state, take action to close the gap. This loop runs continuously, which is why Kubernetes is self-healing by default.

A Brief History: From Borg to Kubernetes

Kubernetes didn't appear out of nowhere. Google had been running containers at massive scale since the early 2000s using internal systems called Borg and later Omega. These systems managed everything from Google Search to Gmail, scheduling billions of containers per week.

In 2014, Google open-sourced the ideas behind Borg as Kubernetes. The key engineers — Joe Beda, Brendan Burns, and Craig McLuckie — built it from scratch in Go, incorporating lessons from a decade of production experience. In 2015, Google donated the project to the newly formed Cloud Native Computing Foundation (CNCF), making it vendor-neutral.

Today, Kubernetes is the de facto standard for container orchestration. Every major cloud provider offers a managed K8s service (EKS on AWS, GKE on Google Cloud, AKS on Azure), and it has the largest open-source community after Linux.

What Kubernetes Is Not

A few common misconceptions worth clearing up early:

• It's not a PaaS. Kubernetes doesn't deploy your code directly. It deploys containers. You still need to build and push container images.
• It's not simple. K8s has a steep learning curve. The operational complexity is real, which is why managed services exist.
• It's not always the right choice. If you're running a single service with predictable traffic, a simpler setup (a VM with a process manager, or a serverless function) might be the right call. Kubernetes shines when you have multiple services, need autoscaling, and want consistent deployment patterns across teams.

Why This Matters

Understanding Kubernetes starts with understanding the problem it solves. Before diving into API servers, etcd, and pod networking, you need this mental model: Kubernetes is a system that takes a declarative description of your infrastructure and continuously works to make reality match that description. Everything else — every component, every concept — exists in service of that reconciliation loop.

Key Takeaways

• Containers solve packaging; orchestration solves running them at scale.
• Kubernetes automates scheduling, health monitoring, scaling, and updates across a cluster of machines.
• The declarative model (desired state → reconciliation) is the core design principle.
• K8s evolved from Google's internal Borg system and is now the industry standard under the CNCF.
• It's powerful but complex — use it when your operational needs justify the overhead.

Next up: Kubernetes Architecture — the Control Plane and Worker Nodes that make all of this work.