Hacker News new | past | comments | ask | show | jobs | submit login

I think that the title of this is a bit misleading.

Kubernetes is removing the "dockershim", which is special in-process support the kubelet has for docker.

However, the kubelet still has the CRI (container runtime interface) to support arbitrary runtimes. containerd is currently supported via the CRI, as is every runtime except docker. Docker is being moved from having special-case support to being the same in terms of support as other runtimes.

Does that mean using docker as your runtime is deprecated? I don't think so. You just have to use docker via a CRI layer instead of via the in-process dockershim layer. Since there hasn't been a need until now for an out-of-process cri->docker-api translation layer, there isn't a well supported one I don't think, but now that they've announced the intent to remove dockershim, I have no doubt that there will be a supported cri -> docker layer before long.

Maybe the docker project will add built-in support for exposing a CRI interface and save us an extra daemon (as containerd did).

In short, the title's misleading from my understanding. The Kubelet is removing the special-cased dockershim, but k8s distributions that ship with docker as the runtime should be able to run a cri->docker layer to retain docker support.

For more info on this, see the discussion on this pr: https://github.com/kubernetes/kubernetes/pull/94624




Also, people probably don't understand the difference between the container runtime and container build environment. You can build your container with Docker still and it can run in a different environment.


You can, but buildah exists.


What's the advantage of using buildah?


It's docker without the dockerfile which, from what I can tell, is the biggest feature of docker most engineers like.

I've personally switched to bazel for building most of my containers but that's a far departure from what the majority of people are doing I suspect.


My company uses bazel to build containers and the distroless images that Google provides, it's a really nice setup IMO


I love the experience and performance. If more adoption happens it'll just get better as more languages are supported.


Can you point to any sources using bazel for this?



Is containerd CRI compliant? Kubelet still interacts with cri-containerd which inturn calls containerd. Isn't cri-containerd the dockershim of containerd?

Maybe I'm mixing up things, pls correct me wherever needed.


containerd can serve CRI requests itself. This has been the case since the containerd v1.1.0 release[0], which included the cri "plugin" as an in-process part of the containerd binary. For a while, to keep up the plugin idea, it was in a separate github repo too, but these days it's in the main containerd repo directly[1].

[0]: https://github.com/containerd/containerd/releases/tag/v1.1.0

[1]: https://github.com/containerd/containerd/tree/9561d9389d/pkg...


Thanks for explaining.

I suspect this will nuke a huge amount of tutorials out there though & frustrate newbies.


This is deep in the internals of Kubernetes, nothing about `docker build/push` or `kubectl apply` will change.


This changes nothing for 99.9% of Kubernetes users.


For what it's worth, there are a few cases where docker vs some other runtime does make a difference.

One difference is that if you 'docker build' or 'docker load' an image on a node, with docker as a runtime a pod could be started using that image, but if containerd is the runtime it would have had to be 'ctr image import'ed instead.

I know that minikube, at some point, suggested people use 'DOCKER_HOST=..' + 'docker build' to make images available to that minikube node, which this would cause to not work.

It would be nice if k8s had its own container image store so you could 'kubectl image load' in a runtime agnostic way, but unfortunately managing the fetching of container images has ended up as something the runtime does, and k8s has no awareness of above the runtime.

Oh, and for production clusters, a distribution moving from dockerd to containerd could break a few things, like random gunk in the ecosystem that tries to find kubernetes pods by querying the docker api and checking labels. I think there's some monitoring and logging tools that do that.

If distributions move from docker to docker-via-a-cri-shim, that won't break either of those use cases of course.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: