Kubernetes in plain terms: why it exists and how a cluster works

One container on one server starts with one command. Trouble begins when there are dozens of containers, several servers, and the application must survive a machine failure and grow under load. Kubernetes takes over placing containers on servers, restarting failed ones, scaling and rolling out updates without downtime.

The key idea is desired state. Instead of a sequence of commands you describe the result: three replicas of a service with a given image version. The cluster constantly compares reality with the description and fixes the difference. That loop is called reconciliation.

A cluster splits into the control plane and the worker nodes. A node is a physical server, a virtual machine or a cloud instance. The smallest unit of deployment is a pod: a wrapper around one, sometimes several containers that share network and storage.

• API Server: the single entry point for every command and query.
• etcd: the distributed store that holds cluster state.
• Scheduler: picks a node for every new pod by resources and rules.
• Controllers: watch for drift between desired and actual state and trigger fixes.
• kubelet: the agent on each node that starts and monitors pods.
• Container runtime such as containerd: runs the containers themselves.

The same five steps repeat on every change. Knowing the chain helps read logs and see where a rollout is stuck.

• You send a manifest through kubectl to the API Server.
• The API Server stores the desired state in etcd.
• Controllers notice the pods do not exist yet and create their objects.
• The Scheduler assigns each pod to a node.
• The kubelet on that node starts the containers through the runtime and reports status.

Kubernetes pays off when there are many services, load varies and downtime is expensive: an online store with peaks, a product with several teams, a SaaS shipping several times a day. For a corporate website, a landing page or a small 1C-Bitrix store a cluster is overkill: one server with backups and monitoring is cheaper to run and easier for contractors to understand.

If in doubt, count the cost of ownership, not the cost of launch: who maintains the cluster, who is on call at night and how long training takes.

Kubernetes keeps an application in the state you described across a group of machines. The control plane decides, nodes execute, etcd remembers. Most small-business websites do not need it; products with constant releases and variable load treat it as the standard.