It has been a while since I started working with Docker, also I have been planning to learn Kubernetes but noticed that it will be removing the dockershim component that enables Docker as a Kubernetes container runtime in version 1.23.

I just wanted to understand should I start learning Kubernetes on version 1.22 using docker and dockershim, or wait until the end of dockershim support and start following the new learning path?

I am actually worried because some of my projects use the docker socket docker.sock to collect containers data.

All answers and comments would be appreciated.

CodePudding user response：

The "Kubernetes is removing Docker support" is actually a pretty low-level detail. Unless you're actually administering the cluster, you won't notice or care. If your project needs to run with multiple replicas distributed across several systems, learning Kubernetes could make sense, and there's no particular reason to wait until this internal change completes. You'll still need to know details like how to build Docker images and push them to a repository to effectively develop an application that runs on Kubernetes.

some of my projects use the docker socket docker.sock

That doesn't work on Kubernetes. In general, Kubernetes has much stronger security controls than Docker does. On the one hand this means you can configure a ServiceAccount to have permissions to create a new Pod in a specific Namespace, without also giving it permissions to read Secrets anywhere. On the other, it also means containers will generally be prohibited from things that could compromise the host. (I understand it to not be uncommon to ban hostPath volumes entirely, for example.) Even if your Kubernetes is running Docker underneath, you may not be able to access the Docker socket, and if you can, you'll see many Kubernetes internals and they'll only be what's running on the current Node.

You should revisit whether your application actually needs access to the Docker socket. For many cases, a job queue like RabbitMQ can replace the need to dynamically launch containers. You mention a monitoring need, and it's possible there are off-the-shelf projects that could fill that. In the worst case you might need to update your application to support both the Docker and Kubernetes APIs, depending on where it's running.