Kubernetes terms - a topological approach
An introduction to the basic Kubernetes terms - one new term at the time.
This post was first published on Øysteins personal blog blixhavn.dev
Coming from plain old Docker, it's confusing to navigate all the different terms used in Kubernetes - especially because a lot of them already have different meanings in other contexts. Here's an attempt to introduce the basic Kubernetes terms one at the time. I will try to keep all definitions based on terms already introduced, but sometimes there might be a reference to one being explained just below.
Terms will be highlighted when referring to its definition within the Kubernetes context. If not highlighted, think of what it would usually mean.
When running docker containers, a container runtime is needed (similar to JVM for Java and .NET for C#). Docker uses
containerd, but there are several other alternatives, such as
The smallest and simplest Kubernetes object (apart from containers). It is an abstraction over the Docker container, disconnecting the rest of Kubernetes from the container runtime. If there is more than one container in a pod, it's usually with one main container and one or more sidecar containers (e.g. webserver and log handler).
Because pods are often considered ephemeral and may die for no/any reason, it is very inconvenient to have explicit connections to the pods IP address. Therefore, services act as a grouping of pods, and will forward and load balance any communication to the pods in the service. There are different kinds of services, each with their own use cases.
A type of service that manages external access to the cluster. It can handle incoming HTTP and HTTPS traffic, SSL/TLS termination and act as a load balancer.
A collection of different services (e.g. Node web application, MongoDB and Redis). Managed by one or more deployment recipes. Not strictly a Kubernetes term, but used for example in Google Kubernetes Engine.
A recipe describing a collection of pods and services. For availability and performance reasons, it's possible run pods with replicas, for example two or more instances of the Node web application. In these cases, services will serve as load balancers. For stateful services (e.g. databases), a specific type of deployment called StatefulSets is needed.
Node (worker node)
A virtual/physical machine connected to a cluster. A cluster can distribute its applications over several nodes - both for availability and performance reasons. Maybe you want one node to be dedicated to one specific application.
A process running on each node that starts and manages containers on that node.
A process running on each node that routes requests intelligently between pods - keeping requests within the same node if possible, but is able to connect to any service and pod in the cluster. Can be replaced by other networking applications (e.g. GKE Dataplane V2 uses eBPF)
The overarching, top level entity in Kubernetes. Consists of control plane services and one or more worker nodes.
Used to manage the Kubernetes cluster. Consists of four components listed below. These components may run on dedicated machines, on the same machines as one or more of your nodes, or somewhere in the cloud (as with for all cloud kubernetes providers). They may also be replicated for availability and performance reasons.
API Server (kube-apiserver)
The REST API used to manage your cluster.
Makes sure that pods are matched to nodes so that kubelet can run them.
Controller Manager (kube-controller-manager)
Control process that regulates the state of your cluster, initiating changes when the current state is not identical to the desired state (e.g. new applications are added, or replication number of pods have changed). Communicates with the kubelets of the different nodes to do changes.
The configuration store for the cluster. A conceptually simple key-value store that is immediately available to all entities in the cluster. Used to store and maintain the state of the cluster.
Official CLI tool for managing your cluster. Uses the API Server.