Let us look at some terms that people commonly use when describing or talking about Kubernetes.
Kubernetes is used to run containerised applications. But not just one container, it often runs a distributed system. Such a system which has a main control plane that runs and orchestrates several containers on Kubernetes becomes a kubernetes cluster. But before we go further, let me avoid having to type the full word Kubernetes every single time and stick to the abbreviation, k8s.
The name Kubernetes originates from the Greek κυβερνήτης (kubernḗtēs), meaning governor, ‘helmsman’ or ‘pilot’. Kubernetes is often abbreviated as K8s, counting the eight letters between the K and the s (a numeronym).
Container
Containers are a bundle of your application and its dependencies that can be repeatedly built and run on different cloud or Operating systems. Containers are composed of something called a Container Image. If you have written back-ups on your windows PC, you are probably familiar with the term an ISO image. This image is the binary data that encapsulates an application and all its software dependencies. This is what gets executed when the container is run. It contains application, code, runtime dependencies, system library, defaults for essential settings, etc. They are meant to be stateless and immutable.
Stateless
A stateless application is one that does not retain any data or state between different requests that it has to serve. Thus the application treats each request independent of one another with no knowledge of previous interactions.
Any state, persistent data of any kind, is to be stored outside of a container.
- You could store files in a file storage
- Session information in a cache technology like memcached or Redis
- blocks - for databases maybe, use an external disk attached to the container - mounted storage
This ensures that the container can be shutdown and destroyed anytime without fear of data loss. And whenever a container has to restart, it will pick the data from the external storage.
Immutable
Immutability in this context, is the concept that once a container is created and deployed, it should not be modified. If changes are needed, then a new container image is built and deployed instead of modifying the existing one. Fix it forward.
Ensuring immutability makes deployments safer and more repeatable. Let’s say you need to roll back, you redeploy the previous version of the container image. In order to ensure that the same container image can run in multiple environments, ensure that you externalise your configuration/environment variables/ externally loaded configuration files from a mounted path or so.
Container Runtime
Kubernetes does not run containers on its own. It uses something called a container runtime. This is a fundamental component of Kubernetes that is responsible for running containers. It manages the lifecycle and execution of containers inside a k8s environment.
Some of the container runtimes supported by k8s today are containerd, CRI-O (pronounced “cry-o”) and any implementation of k8s container runtime interface
Container runtime interface
This is the main protocol for communication between something called a kubelet and the container runtime. All communication between the node components and container runtime uses gRPC.
Container Registry
We talked about building images. So you might have thought about where do we store all these binaries. Typically, you’d create a container image and push it to a container registry owned by your organisation or project. This serves as a common source of images that members of your organisation or your project can pull images from to run or build other containers.