containerd reaches its 1.0 milestone
© Shutterstock / Kosmayer
containerd, an industry-standard runtime for building container solutions, has just reached its 1.0 milestone — that’s one year after Docker open-sourced it to make sure it receives the attention it deserves. Some of the performance improvements include the creation of a stress testing system, improvements in garbage collection and shim memory usage.
containerd: The story so far
Life is beautiful when tech giants like AWS, IBM, Google, Microsoft and Alibaba promise to maintain and contribute to the development of containerd, an industry-standard runtime for building container solutions. Solomon Hykes, founder and CTO of Docker, announced in a blog post last year that containerd is “the latest chapter in a multi-year effort to break up the Docker platform into a more modular architecture of loosely coupled components.”
A lot has happened since Docker decided to open-source containerd last December; the core container runtime was later donated to the Cloud Native Computing Foundation (CNCF) in order to “unlock a whole new phase of innovation and growth across the entire container ecosystem,” the first containerd Summit was held one month later and last month a new milestone was reached: Kubernetes 1.8 has the ability to use containerd as base runtime. And now, containerd has reached its 1.0 milestone.
containerd 1.0: Overview
Patrick Chanezon of Docker wrote in a blog post announcing the new milestone that “additional work has been done to add even more powerful capabilities to containerd including”:
- Complete storage and distribution system that supports both OCI and Docker image formats and
- Robust events system
- More sophisticated snapshot model to manage container filesystems
These changes helped the team build out a smaller interface for the snapshotters, while still fulfilling the requirements needed from things like a builder. It also reduces the amount of code needed, making it much easier to maintain in the long run.
Some of the performance improvements include the creation of a stress testing system, improvements in garbage collection and shim memory usage.
containerd is everywhere:
- It is already being used by Kubernetes for its cri-containerd project — users can run Kubernetes clusters using containerd as the underlying runtime.
- It is an essential upstream component of the Docker platform
- It exposes an API using gRPC and exposes metrics in the Prometheus format
- It fully leverages the Open Container Initiative (OCI) runtime, image format specifications and OCI reference implementation (runC), and will pursue OCI certification when it is available.
Find out more about it here.
Let’s see what Docker Captains say about containerd
Not long ago, we launched an interview series with Docker Captains to hear more about their love stories with Docker, their likes and dislikes, their battle scars and more.
We also asked them what they think of Docker’s decision to donate containerd runtime to CNCF and here are their answers:
It’s a great and cool move. Containerd is basically the real engine behind Docker. The standardized container runtime benefits everyone in the community.
As I said, Docker’s technical value is not in container runtime, which is not a huge engineering effort to replicate. But for ecosystem health they need to ensure confidence and interoperability, so an open standard and a reference implementation is a must have.
As a Java developer, I’m used with such approach to have a standard to document API and reference implementation, which doesn’t prevent alternate implementations or innovation. Docker does the same with a distinct approach: it proves things can work, then extracts an open source component and makes sure it becomes part of the standardized container ecosystem driven by OCI.
Nicolas De Loof
Docker’s decision to move containerd to CNCF and make a split between Moby is an attempt to keep their feet buried in the sand. Let’s not sugarcoat it. This is a really hot space with competition brewing and lots of leapfrogging.
Docker doesn’t want to be replaced as the container runtime of choice. containerd and Project Moby are attempts to allow new container packaging tools emerge but still share the underlying base functionality. This keeps Docker relevant because everyone will see the tool they created isn’t as simple as it sounds. This gives anyone the freedom to try and realize that Docker is the route of least resistance and to continue using their tool in lieu of something else, including rkt.
I firmly believe that every decision thought leaders make based on what the community needs should be respected as they are the only horse power for future innovation.This is good for the container market as a whole. To me, it is full of excitement as we are going to see Docker containerd competing with CRI-O without affecting Docker’s business.
Ajeet Singh Raina
It’s a big move forward. My understanding — and please note the following is my own personal opinion — is that Docker Inc. has a vision to build a complete platform for building, deploying and managing software systems – a distributed cloud OS for lack of a better name. To this end, I would expect to see more Docker tooling that integrates with their own services like Docker Cloud and the Docker Store to provide useful features. This tooling will be built on top of the open source components that are part of the OCI and Moby project, but will also include components that are entirely owned by Docker and designed to interact with their own commercial offerings.
It is crucial for Docker to be the industry-wide accepted standard — to maintain the power position they currently have within the market they carved out. Companies such as Google have built on the work of Docker with their container orchestration frameworks such as Kubernetes (which CoreOS and RedHat built on to create OpenShift and Tectonic respectively). Within these frameworks (which have gained a lot of market traction, more so than Docker’s own orchestration solution), every component has very clearly defined roles and responsibilities.
If these players are no longer happy with the implementation Docker provides (due to Docker’s fast iteration, adopting roles it shouldn’t, or other concerns with Docker’s governance of the technology), more and more competing implementations (such as rkt from CoreOS) have emerged and matured as potential replacements.
Docker themselves iterated on many of the core implementations within Kubernetes to re-work their clustering offering called Swarm in last year’s introduction of Docker 1.12’s new “Swarm mode”. This creates an interesting dynamic where each improves on the weaknesses of the other offerings — driving every solution to become a complete offering. (Docker has since also separated their company’s products —Docker CE / EE— from the core technology by creating the Moby project at April’s DockerCon).
Vincent De Smet
The ecosystem moves faster than any single company. If Docker wasn’t open and willing to give back to the community, they will find that they would become a siloed center of hype that dies after a few years. By trying to get the community involved, it allows the conversation to continue and evolve with drive from many parties in the industry. Contributing the containerd runtime is just one example of Docker’s principle of developing in the open.
Don’t miss our Docker Captains interview series
- “Docker doesn’t want to be replaced as the container runtime of choice”
- Docker vs. VM: What’s the difference?
- Solving Docker confusions one by one — Docker Captains share their tricks
- “It is crucial for Docker to be the industry-wide accepted standard”
- Docker Captains speak bluntly: “Containerd is basically the real engine behind Docker”
- “Making containers usable with nice tooling was the only thing missing — Docker provided that”
- “Data persistence is the most misunderstood element by Docker users”