A container registry is not a file server for images — it is a content-addressable object store that implements a specific HTTP API standardised by the OCI Distribution Specification. Understanding the registry's internal architecture determines how you approach image layer deduplication, multi-architecture image distribution, rate limit management, and the security implications of mutable tags. When a developer runs `docker pull nginx:latest`, Docker does not download a file named `nginx:latest` — it resolves the mutable tag `latest` to an immutable SHA-256 manifest digest, reads the manifest to discover the list of layer digests, and downloads only the layers whose content hashes are not already present in the local content store. Knowing this pull sequence explains why pulling a new image that shares layers with an existing image is fast, why tagging and pushing the same image content to a different name costs zero additional storage, and why a tag that was present yesterday may silently point to a different image today without any visible notification.
25 minintermediate
Registry architecture — OCI Distribution Spec, manifests and pull-through caches
Analogy🏏Cricket
🏏 Think of it like cricket: The Pod-ReplicaSet-Deployment hierarchy maps precisely onto the three levels of IPL franchise team management. A Pod is a single player on the field at a given moment — the smallest unit of participation, carrying its own identity and fulfilling a specific role in the current game. A ReplicaSet is the franchise's match-day playing XI contract — it specifies that exactly eleven players matching a specific profile must always be on the field; if one is injured and leaves, the team management immediately sends a substitute of the same profile to restore the count. A Deployment is the franchise's season-long team strategy — it manages how the playing XI evolves between matches: when a new batting approach is adopted, the Deployment replaces the old XI with the new one in a controlled rolling substitution rather than swapping all eleven players simultaneously and disrupting team cohesion. Just as the franchise director does not manage individual players directly — the playing XI contract (ReplicaSet) handles the count and the season strategy (Deployment) handles the transitions — you never manage Pods directly in production; the Deployment manages the transition and the ReplicaSet maintains the count. This reveals why the three-level hierarchy exists rather than one omnibus 'workload' object: each level solves one specific problem, and composing three focused abstractions produces better separation of concerns than one object that conflates scheduling, scaling, and update management.
Lesson 3 of 33
0% complete