{"id":21910,"date":"2020-12-04T01:03:59","date_gmt":"2020-12-04T01:03:59","guid":{"rendered":"https:\/\/rbsitsoftwaresolution.com\/blog\/kubernetes-dropping-docker-is-not-that-big-of-a-deal.html"},"modified":"2020-12-04T01:03:59","modified_gmt":"2020-12-04T01:03:59","slug":"kubernetes-dropping-docker-is-not-that-big-of-a-deal","status":"publish","type":"post","link":"https:\/\/www.rbsitsoftwaresolution.in\/blog\/kubernetes-dropping-docker-is-not-that-big-of-a-deal.html","title":{"rendered":"Kubernetes dropping Docker is not that big of a deal"},"content":{"rendered":"

It all started so quietly. Deep in the forthcoming Kubernetes 1.20 release notes<\/a>, Kubernetes<\/a>, everyone’s favorite container orchestrator, developers announced: “Docker support in the kubelet is now deprecated<\/a> and will be removed in a future release.” You’d thought from the uproar that someone just kicked your puppy. Relax.<\/p>\n

\n\t\tRead this<\/span>
\n\t<\/h3>\n


\n <\/span><\/p>\n

<\/a><\/p>\n

\n
\n What is Docker and why is it so darn popular?
\n <\/a>\n <\/p>\n

Docker is hotter than hot because it makes it possible to get far more apps running on the same old servers and it also makes it very easy to package and ship programs. Here’s what you need to know about it.<\/p>\n

\n Read More<\/a>\n <\/p>\n

Yes, the kubelet the “dockershim” module, which implemented Container Runtime Interface (CRI) <\/a>\u00a0support for Docker<\/a>, will soon be history. So what? It’s not that big a deal.\u00a0<\/p>\n

Docker, you see, is many things.\u00a0<\/p>\n

As Kelsey Hightower, Google Cloud Platform staff developer advocate and best-known teacher of all things Kubernetes, tweeted: “Docker != Containers<\/a>. There are container images. Docker can build them. There are container registries. Docker can push and pull from them. There are container runtimes. Docker is one of them. There are container processes. Docker can create them but Linux is still the boss.”\u00a0<\/p>\n

As the developers explained in their well-named “Don’t Panic: Kubernetes and Docker<\/a>” blog post, all that’s happening is that Kubernetes is deprecating Docker as a container runtime after v1.20. You can still build containers, use them in registries, and push and pull. All that’s happened is Docker as an underlying runtime is being deprecated in favor of CRI runtimes. Docker-produced images will continue to work in your cluster just as they always have.<\/p>\n

In short, it’s not — I repeat — not a big deal.\u00a0<\/p>\n

Part of the confusion stems from people using “Docker” to mean a great many different things. Inside your Kubernetes cluster, the container runtime’s job is pulling and running your container images. Docker is a popular choice for that runtime, but Docker was not designed to be embedded inside Kubernetes, and that causes problems.<\/p>\n

\n<\/section>\n

As the programmers observed, “The thing we call ‘Docker’ isn’t actually one thing — it’s an entire tech stack.” Docker includes many user enhancements for programmers, but Kubernetes doesn’t need any of that. Dockershim’s job is to extract only the runtime. The rest is only so much unneeded and unwelcome code, which opens a bigger attack surface and requires maintenance.\u00a0<\/p>\n

In addition, Docker isn’t compliant with CRI. “If it were, we wouldn’t need the shim, and this wouldn’t be a thing.” But it’s not the end of the world. Developers just need to change their container runtime from Docker to a supported container runtime. It’s not that hard.\u00a0<\/p>\n

This change for the Docker runtime has been coming for some time now. Today, the debate for which runtime to use is between containerd<\/a> and CRI-O<\/a>. In fact, under the hood of both containerd and CRI-O, you’ll find Docker’s own open runtime, runc.<\/a>\u00a0\u00a0<\/p>\n

As Hightower said in a later post, “Nothing changes. Keep using Docker. Kubernetes only leverages a fraction of what Docker is capable of at runtime. In fact, both can leverage containerd and runc to manage the underlying processes. The container image is portable. How you build and run them is up to you.”<\/p>\n

Docker agrees. In a post, Dieu Cao, Docker’s senior director of product management, explained, “If you’re using Docker, you’re already using containerd<\/a>.” In fact, “Docker created the containerd project, along with Google and IBM, in 2016, with the goal of this transition in mind. The deprecation of docker-shim (and Docker Engine as runtime) marks the completion of a long-term commitment to provide a modern runtime for Kubernetes.”<\/p>\n

Cao continued, “Container images you build using Docker tools will continue to run on Kubernetes. Buildkit<\/a>, our next generation build infrastructure, has a flexible architecture so that while it can be used as the builder with Docker, it can also talk directly to containerd or runc instead for use in infrastructure where Docker might not be available.”<\/p>\n

Got that? Relax. Breath. You can still use Docker to create containers for Kubernetes. The one and only thing that changes if you’re be using containerd or CRI-O to run them in Kubernetes. Odds are decent you’re already doing that and you just didn’t realize it.<\/p>\n

In any case, you’re going to have lots of time to figure it out. As the Dockershim Deprecation FAQ<\/a> says, “The only thing changing in 1.20 is a single warning log printed at kubelet<\/a> startup if using Docker as the runtime.”<\/p>\n

Dockershim will stick around until the release of Kubernetes 1.23 in late 2021. The Kubernetes crew will work closely with everyone to make sure we’re all on the same page and that dockershim won’t be put out to pasture until everyone is ready for the change.<\/p>\n

Related Stories:<\/strong><\/h3>\n