Ivan Velichko
Ivan Velichko

@iximiuz

8 tweets 54 reads Oct 01, 2023
From VMs to Containers to Pods ๐Ÿงต
Containers are (just) Linux processes.
A helpful approximation to "get it." But at some point it might start limiting oneโ€™s understanding of the tech, hence the abilities.
Containers are a lightweight VM replacement.
Another good approximation. Helps to see the problem from a slightly different angle. But the thing is that some containers are actually VMs (Kata Containers, for example).
Containers simplify running applications.
Not quite. Containers (via images) solved app packaging and distribution problems. Containers also improved portability - running a container is (almost) the same on Linux, Windows, and macOS now. But an app is bigger than a container.
Docker Swarm was an attempt to solve (distributed) application runtime problem.
For some reason, it didnโ€™t become the industry standard (unlike the Docker-shaped) containers. The standard multi-server runtime is Kubernetes now.
Kubernetes doesnโ€™t run containers. Instead, it uses Pods.
A (typical) Pod is a group of semi-fuzed Linux containers.
A Pod is a much closer abstraction to a VM than a single container. But again, the implementation of Pods can vary between container runtimes.
Kubernetes runs Pods (groups of containers) on multiple servers (Nodes).
A group of Nodes is called a Cluster.
From the app developerโ€™s standpoint, Kubernetes is serverless.
Every Pod has an IP address. Multiple Pods can be grouped in a Service. A Service uniquely names (DNS) its group of Pods.
Pods are replicated and distributed over the Nodes via Deployments.
In the end of the day, running an app in a Kubernetes Cluster is not much different from running a service (in a traditional meaning) on fleet of VMs.
Itโ€™s still a bunch of IP-addressable instances, each running the main app and potentially a few helper processes (sidecars).

Report this thread