I talk a lot about containerd. I write blog posts about it, speak at conferences about it, give introductory presentations internally at IBM about it and tweet (maybe too much) about it. Due to my role at IBM, I’ve helped IBM’s public cloud Kubernetes service, IKS, start a migration to use containerd as the CRI runtime in recent releases and similarly helped IBM Cloud Private (our on-premises cloud offering) offer containerd as a tech preview in the past two releases. Given that backdrop of activity and the communities I participate in, I obviously hear a lot of chatter about replacing Docker with {fill in the blank}. Given my containerd resume, you might assume that I always think replacing Docker is the right step for anyone working with container runtimes.
Replace Docker!? or “Choose The Right Tool For The Job”
Maybe due to historic frustrations and/or differences of opinion across the container runtime space, some have failed to see that picking the right tool for the job is just as valuable in this context as it is in any other. There have definitely been “party lines” drawn in some circles based on vendor-affiliation, or some basing decisions off the latest arguments on HackerNews. But, let’s ignore that (which, I’ll admit, is good advice generally!) and look at what we are talking about when we compare the Docker toolset to any of rkt,cri-o,containerd, or any other runtime alternative.
Read more at Tigera
