Kubernetes The Hard Way has leveraged multiple container runtimes over the years. The original guide used Docker, the only fully supported runtime back then, rkt from CoreOS was a work in progress, but "rktnetes" was a thing. coreos.com/rkt/docs/lates…
Kubernetes later introduced the CRI which standardized how Kubernetes interacts with lower level container runtimes. KTHW was updated to use a shim, the dockershim, which implemented the CRI on top of Docker, instead of Docker directly. kubernetes.io/blog/2016/12/c…
The CRI opened the door to new container runtimes optimized for Kubernetes. Less features; tighter integration. Red Hat built CRI-O, and about a year later, KTHW was updated to use CRI-O instead of Docker, via the dockershim, and almost no one noticed. redhat.com/en/blog/introd…
What's often missed in these conversions is that Docker, Google, IBM, and many others were hard at work breaking Docker up into reusable components. It's a long story, but we ended up with containerd, which implements the CRI. containerd.io
containerd reached a level of maturity that enabled Docker to leverage it as an embedded component, which makes sense because the majority of containerd comes directly from Docker. It was more like a big refactor than a rewrite.
Following in Docker's footsteps, Kubernetes The Hard Way was updated to use containerd, and the rest is history.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
