For those of us not into this space, does this replace docker or kubernetes or just some piece of the puzzle that could be bolted into both to replace some component?
Take a car, the engine is the OCI runtime, crun, containerd, etc.. The whole car is Docker, or Podman. Kubernetes is the city where the cars run.
---
EDIT: For more details, OCI (Open Container Initiative) defines a few things:
- an image format (how to create them)
- a runtime specification (how to run them)
- ...
A container runtime is an implementation of one of those things.
Docker is a set of tools hidden under a unified CLI which gives you the ability to:
- create images
- upload/download images to/from a registry
- run images with volumes, networking configuration, environment variables, ...
But Docker is only one host.
Kubernetes is an interface to abstract a cluster of hosts. Everything is described as a "resource" which goes through the "control loop":
1. the user uses the k8s REST API to create/read/update/delete the resource
2. the k8s api server will contact admission controllers (via webhook) to authorize (and/or mutate) the action
3. the action is persisted to a distributed database (usually, etcd)
4. then, controllers are notified of the change and will run the side effects
This is the simplified version. But what is stored in the distributed database is called the "desired" state, and controllers have the duty of observing the real state (the "observed" state) and make it converge towards the "desired" state.
So a "Pod" controller's job will be to observe Docker instances, to check what containers are running, and start/stop the containers based on what "Pod" resources exists in k8s's database.
A "Deployment" controller's job will be to observe the "Pod" resources in the k8s database and create/update/delete them based on what "Deployment" resources exists in k8s's database.
etc...
In theory, Kubernetes does not need docker. You could have a "proxmox" controller which would start/stop virtual machines instead.
Kubernetes provides a lot of tooling for storage management, secret management, networking, workload management, etc... so that you can manage it all with a unified REST API.
The very nature of the "control loop" makes it very extensible, allowing you to build layers of abstraction on top of layers of abstraction on top of layers of abstraction ... A real "onion cloud" if I dare say it.
kubernetes can use anything that conforms to the CRI interface, which in practice is either CRI-O (RedHat) or Containerd (Docker, Inc.). Podman and Docker are also consumers of both of those engines
It replaces `runc` which is used by most non-docker container runtimes to actually start the container. Thus the punny name.
When using kubernetes, the hierarchy is as follows:
1. kubernetes master tells kubelet what to do (sort of, not important here)
2. kubelet uses CRI-compatible runtime to start containers
3. containerd or CRI-O handle management of containers and start them using runc or crun
4. runc/crun are the applications that setup the final environment of application to run in container, using resources (mounts, devices, etc) provided to them by upper layers. They also handle things like sending stdout/stderr to logs, or setting up a pseudoterminal to talk to a program in container, etc.
