Open Standards, and the Role of containerd in Kubernetes Orchestration
What Could Have Gone Wrong Before containerd
Docker was already the de facto standard when Kubernetes adoption was starting to begin, but Docker was backing its own alternative, the Swarm orchestrator. The need for an industry standard for container runtime was apparent. This lead to the creation and subsequent graduation in February of containerd within the Cloud Native Computing Foundation, joining the ranks of Kubernetes, Prometheus, Envoy and CoreDNS.
“It’s containerd not just being created but its donation to the CNCF was part of answering that call for kind of a stable boring core runtime that would stay underneath Kubernetes and have the right lifecycle support — to not cause those frictions between Kubernetes just wanting a stable layer that just runs containers without anything else,” Phil Estes, a distinguished engineer and chief technology officer for Container and Linux OS Architecture Strategy for the IBM Watson and Cloud Platform division.
Estes shared his thoughts said during the latest episode of The New Stack Makers podcast hosted by Alex Williams, founder and editor-in-chief of The New Stack recorded during the Open Source Leadership Summit.
Indeed, the discussions leading up to the creation of containerd were ultimately constructive, while the debate was lively. In that way, “contentions brought containerd,” Estes said.
“A lot of smart people from all over the industry played a role in that to kind of say, ‘hey, let’s have a level-headed direction from here that includes something, a base that allows Docker to continue innovating,’” Estes said. “There were lots of meetings that happened in those days that were not necessarily public but were important in getting the right people together to agree.”
The idea was to “not lose our cool here,” Estes said. “We decided the best path forward was “open, covered well, that provided the base on which a lot of different vendors can build so we didn’t end up in a world where my container doesn’t run on your product because you know, we all went in different directions in 2016,” Estes said.
Thanks to the Open Container Initiative’s (OCI) standardization efforts “containerd, cri-o, Docker and Kubernetes “can all live in that world that we can all collaborate and have interoperability,” Estes said. “Otherwise, that would have been, I think, a death knell of containers if there wasn’t true interoperability among all these implementations,” Estes said.
Underneath the hood, the OCI “is really that standardization layer of what’s a container image, what’s a container run time, and runC is the implementation that now, years later, everyone is really using and based on,” Estes said. In this way, containerd sets one layer above in the stack and manages containers that are being run by runC in order that commands such as “start,” “stop,” and “list” can operate against runC-executed containers, Estes said.
Docker also continues to be the de facto standard for containers, and yet, controversy remains. “Even today, you know, there can be some voices that say, ‘OCI seems to be just a rubber stamp of Docker’s style of image format runtime capabilities. “But standards often come out of a pragmatic place. You know, ‘this is what people are using, let’s standardize around that,’” Estes said. “And so you know, I think, in the end, the OCI was a good choice to be pragmatic and accept what was being used and was done and codifying that into a standard.”
CNCF is a sponsor of The New Stack.
Feature image via Pixabay.
