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
---
EDIT: For more details, OCI (Open Container Initiative) defines a few things:
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:
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":
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.