containerd 1.1 supports *all* Kubernetes features

Kubernetes containerd integration is now generally available

Gabriela Motroc
© Shutterstock /WikaGraphic

The alpha version of the Kubernetes containerd integration was introduced in November 2017 and now a very important milestone has been achieved: the integration with containerd is generally available. Let’s have a look at what this means for us!

The biggest milestone of them all: the Kubernetes containerd integration is now generally available.

According to the blog post announcing the good news, containerd 1.1 can now be the container runtime for production Kubernetes clusters!

Containerd 1.1 works with Kubernetes 1.10 and above, and supports all Kubernetes features. The test coverage of containerd integration on Google Cloud Platform in Kubernetes test infrastructure is now equivalent to the Docker integration.

What does this mean for us?

We’re talking about a double evolution. For the previous version (1.0), a daemon called cri-containerd was needed to operate between Kubelet and containerd. In short, this daemon “handled the Container Runtime Interface (CRI) service requests from Kubelet and used containerd to manage containers and container images correspondingly. However, cri-containerd and containerd 1.0 were still 2 different daemons which interacted via grpc.”

All the problems went away when containerd 1.1 was introduced; the cri-containerd daemon is now refactored to be a containerd CRI plugin. Since the plugin is built into 1.1 and enabled by default, you don’t need the cri-containerd daemon anymore.

SEE ALSO: containerd reaches its 1.0 milestone

See the complete list of highlights here and the release notes here

Oh, and last but not least, you should know that since the next release of Docker Community Edition (Docker CE) will use containerd 1.1, the CRI plugin will be built-in and enabled by default. Therefore, you can either continue using Docker Engine for other purposes typical for Docker users or you can also “configure Kubernetes to use the underlying containerd that came with and is simultaneously being used by Docker Engine on the same node.”

Since containerd is being used by both Kubelet and Docker Engine, if you choose the containerd integration, you get new Kubernetes features, performance, and stability improvements, as well as the option of keeping Docker Engine around for other use cases.

containerd 1.1: Summary

  • Containerd 1.1 natively supports CRI. It can be used directly by Kubernetes.
  • Containerd 1.1 is production ready.
  • Containerd 1.1 has good performance in terms of pod startup latency and system resource utilization.
  • crictl is the CLI tool to talk with containerd 1.1 and other CRI-conformant container runtimes for node troubleshooting.
  • The next stable release of Docker CE will include containerd 1.1. Users have the option to continue using Docker for use cases not specific to Kubernetes, and configure Kubernetes to use the same underlying containerd that comes with Docker.

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.

Chanwit Kaewkasi


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.

Kendrick Coleman


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.

Adrian Mouat


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.

John Zaccone


Gabriela Motroc
Gabriela Motroc was editor of and JAX Magazine. Before working at Software & Support Media Group, she studied International Communication Management at the Hague University of Applied Sciences.

Inline Feedbacks
View all comments