Kubernetes (often abbreviated K8s) is an open-source platform for running and managing containerized applications across many machines. It was created at Google and is now a Cloud Native Computing Foundation project. This guide explains the problems it exists to solve and the handful of terms the rest of this series builds on.

Containers are the easy part

A container packages an application together with the libraries it needs, so it runs the same way on a laptop, a test server, and production. Containers start quickly, are cheap to replace, and you scale by running more copies of them. That fits microservice architectures well, where an application is split into many small services, each in its own container.

What breaks without orchestration

Now run those containers yourself on a single virtual machine and watch what happens:

• The host fills up. Once the machine has no spare CPU or memory, you have to start new containers somewhere else and connect them to the rest by hand.
• Containers die and nobody notices. Containers are disposable by design. Restarting a crashed one is something you must script or do manually.
• The host itself fails. Every container on it goes down together, and nothing brings them back.

You can write scripts for each of these, but once an application is hundreds of containers across several environments, that homegrown tooling becomes a project of its own.

What an orchestrator provides

Kubernetes takes over those jobs:

• High availability. Run several copies of a workload on different machines so users don’t notice when one fails.
• Scaling. Increase or decrease the number of copies as load changes, by hand or automatically.
• Self-healing. Restart failed containers and reschedule workloads from failed machines onto healthy ones.
• Recoverable state. The cluster’s configuration and state live in a datastore (etcd) that you can back up and restore.

The building blocks: pods, nodes, and clusters

Three terms cover most of the vocabulary:

• A Pod is the smallest thing Kubernetes runs. It wraps one or more containers that share networking and storage. Most Pods hold one main container, occasionally with a helper alongside. Kubernetes manages Pods, not bare containers.
• A node is a machine, virtual or physical, that runs Pods.
• A cluster is a set of nodes managed as one pool of CPU and memory. Some nodes form the control plane that manages the cluster, and the rest are worker nodes that run your applications. The next guide covers how they work.

The declarative model

You don’t tell Kubernetes which steps to take. You describe the state you want, usually in YAML (“three replicas of this image, exposed on this port”), and send it to the cluster’s API. Controllers inside Kubernetes then continuously compare what exists with what you asked for and act on the difference. That is why a Pod you delete comes back when a Deployment says three should exist, and it is the foundation for everything else in this series.

What Kubernetes doesn’t do for you

Kubernetes is a platform, not a complete solution:

• It doesn’t build your images or test your code. That’s still CI’s job.
• It doesn’t back up your application’s data. Persistent storage and backups are your responsibility.
• It doesn’t encrypt Secrets by default, and its default settings aren’t hardened for production.
• It is a large system with a real learning curve, so practice on a local cluster first, which is what the next guides do.