Comparison
Container registryvsContainer runtime
Container registry
the deploy failed at three in the morning because the place you pull images from was rate-limiting you, and it is not your infrastructure.
The service that stores and serves images, addressed by repository, tag and digest. It is a hard dependency of every scale-up and every node replacement, which makes a public registry a single point of failure that your architecture diagram does not show. Teams reach for a pull-through cache or an internal mirror the first time a rate limit or an outage takes production capacity with it.
Full entry →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 →