How to check for docker specific code and APIs in an application for later migration to containerd?

Question

So I have a couple of Java RESTful microservices, and since the past few years I have basically been using Docker to build them and deploy them over to a Kubernetes cluster.

Our team is upgrading Kubernetes versions, and it was brought to attention that latest versions of Kubernetes don't support dockerd, and has moved over to using containerd runtime.

Not really sure on how to move forward with this docker -> containerd migration. And hence I have a couple of questions :

• What are some basic hurdles and problems I should look out for while moving from docker to containerd?
• What are some basic docker APIs a Java project can use that I might need to find alternatives to for moving over to containerd?
• How can I streamline the process for other app teams to make the migration process easier?

Projects are RESTful microservices, that use Docker containers at the moment for running on all K8s clusters we have, and are built on Grizzly web server. Supporting microservices to these for other teams use Node.js, Ubuntu and Alpine Linux docker images.

Answer 1

Newer docker engine uses containerd.

What are some basic hurdles and problems I should look out for while moving from docker to containerd?

Perhaps none ? Images build via newer docker engine should also run on containerd. If you are concerned about developers having to learn containerd CLI you could use something like nerdctl. Since kubernetes API is still the same you should barely notice any difference.

What are some basic docker APIs a Java project can use that I might need to find alternatives to for moving over to containerd?

From the question it does not seen any of the services you build directly interfaces with docker. They use docker as a runtime host.

However your CI/CD service scripts might have to be updated to use containerd instead of docker, hence, the devops team might need to study containerd.

How can I streamline the process for other app teams to make the migration process easier?

This is a context dependent question. The generic advise would be to have an org wide devops repository with re-usable tools and scripts that leverage containerd.