What Kubernetes is, and what a cluster is made of
Why containers need something to run them in production, and the two halves of every cluster, the control plane that decides and the worker nodes that do the work.
This is the first post in a series that starts at the basics of Kubernetes and goes as far as the three Kubernetes certifications: CKA (Certified Kubernetes Administrator), CKAD (Certified Kubernetes Application Developer) and CKS (Certified Kubernetes Security Specialist).
Why Kubernetes exists
Say you have built an application and packaged it as a container, using something like Docker. That makes it portable and consistent. But running it on your laptop is not the same as running it in production, where it has to be available around the clock, handle a lot of traffic and be easy to update.
Kubernetes is an open-source platform that automates running containerized applications. It is often shortened to K8s, for the eight letters between the K and the s. The usual comparison is a conductor: it tells each container where to run and what to do, and keeps them all working together.
Kubernetes restarts containers that fail. If a whole server goes down, it moves that server's containers onto healthy ones. This is called self-healing, and it is a large part of why a cluster stays available.
Scaling is automatic. When traffic rises, Kubernetes can start more copies of a container to handle the load, and when traffic falls it removes them again, so you stop paying for capacity you no longer need.
Updates go out gradually. A rolling update replaces containers one at a time, so a new version ships with zero downtime. If something goes wrong, you can roll back to the previous version.
None of this ties you to one provider. Kubernetes runs on AWS, Azure and Google Cloud, and on your own servers, so you can run your applications wherever you want.
How a cluster is laid out
A Kubernetes cluster has two parts: the control plane, which makes the decisions, and the worker nodes, which run your applications.
The control plane
The control plane decides what runs where and keeps the cluster in the state you asked for. It has four main components.
The API server, kube-apiserver, is the front door to the cluster. Everything talks to it: you,
through the kubectl command, and the worker nodes too.
etcd is the cluster's database. It stores the cluster's state, such as which applications are running and where.
The scheduler, kube-scheduler, picks the best worker node for each new application you ask to
run.
The controller manager, kube-controller-manager, runs a set of controllers whose job is to keep
the cluster in the correct state. If one copy of an application dies, for example, a controller
notices and starts a replacement.
Worker nodes
Worker nodes are the machines, virtual or physical, that run your applications. Each one runs three components.
The kubelet is an agent that talks to the control plane. It makes sure the containers that are supposed to run on its node are running.
kube-proxy is a network proxy. It keeps the network rules on the node that let your containers talk to each other and to the outside world.
The container runtime is the software that runs the containers. Docker is the name most people know, but containerd is now the usual default in Kubernetes distributions, and CRI-O is another option.
The next post puts this into practice by starting a cluster on your own machine: Your first Kubernetes cluster.