Comparison
Container runtimevsOpen Container Initiative
Container runtime
something on the node unpacks the image, sets up the namespaces and cgroups, and starts the process — and it is not the orchestrator.
The component on each node that actually creates containers: pulling images, preparing the filesystem, applying isolation and supervising the process. Orchestrators talk to it through an interface rather than implementing it, which is why the runtime under your cluster can be swapped without any workload noticing. You meet it by name during upgrades and when a node-level failure — an image that will not unpack, a wedged process — is clearly below the orchestrator's abstraction.
Full entry →Open Container Initiative
an image built by one tool runs under a different runtime on someone else's cluster, and nobody had to agree on a vendor.
The specifications that define what a container image, a runtime and a distribution registry are, independently of any product. It is why 'Docker image' and 'container image' have become the same thing in practice, and why the build tool, the registry and the runtime in your stack are probably three different projects. It matters most when it is absent — a format outside the spec is a lock-in you find out about at migration time.
Full entry →