17 ms·

Kubernetes is deprecating Docker runtime support

457 points by GordonS 6y ago

Gravityloss 6y ago
> Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community. We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available. (#94624, @dims) [SIG Node]
GordonS 6y ago
Read about this over on Twitter: https://twitter.com/Dixie3Flatline/status/1334188913724850177?s=19 https://twitter.com/Dixie3Flatline/status/133418891372485017... The only "official" notice about it so far seems to be in the linked changelog.
- boberoni 6y ago
  This was very useful. Thanks for sharing. It seems that Docker images will still run fine on k8s. The main change is that they're moving away from the "Docker runtime", which is supposed to be installed on each of the nodes in your cluster. More details about k8s container runtimes here: https://kubernetes.io/docs/setup/production-environment/container-runtimes/ https://kubernetes.io/docs/setup/production-environment/cont...
  - jsmith45 6y ago
    Right. The simplest option is to use containerd, as the runtime. Installing docker will also install containerd (because docker uses it internally), so nothing much needs to change except a configuration option. docker and k8s can run side by side sharing the same containerd instance, in case you need to do something like build containers inside your k8s cluster. You lose out on things that require access to the docker daemon socket, but ideally any such software should be replaced with something that talks with the kubernetes API instead. (exception is building containers in cluster. If you need that, run docker side by side with the kubelet, or use buildkit with containerd integration). You also lose the ability to interact with containers with the docker cli tool. Use crictl instead, which has most of the same commands, but also includes certain k8s relevant information in output tables.
  - ccmcarey 6y ago
    Yep, they're not really "Docker" images. A while ago the image/container formats were standardized through the OCI.
- fhrow4484 6y ago
  The twitter thread has way more details about the change, which is why I submitted it here: https://news.ycombinator.com/item?id=25279424 https://news.ycombinator.com/item?id=25279424 https://twitter.com/IanColdwater/status/1334149283449352200 https://twitter.com/IanColdwater/status/1334149283449352200 also has some details
- shuuji3 6y ago
  There are several official responses now to help us understand this deprecation. K8sContributors on Twitter: "#Kubernetes 1.20 introduces an important change to the kubelet - the deprecation of #Docker as a container runtime option. What does this mean and why is it happening? You can learn more in our blog post! https://t.co/lzPPzwXUNM https://t.co/lzPPzwXUNM" / Twitter - https://twitter.com/K8sContributors/status/1334301732830990336 https://twitter.com/K8sContributors/status/13343017328309903... Don't Panic: Kubernetes and Docker | Kubernetes - https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/ https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-... Dockershim Deprecation FAQ | Kubernetes - https://kubernetes.io/blog/2020/12/02/dockershim-faq/ https://kubernetes.io/blog/2020/12/02/dockershim-faq/
GordonS 6y ago
@mods, would appreciate if someone could change the title to "Kubernetes is deprecating Docker runtime support" (I accidentally missed the word "runtime" when submitting).
- andyjohnson0 6y ago
  You can edit the title for two hours after submitting the article.
  - asah 6y ago
    even better: deprecating non-essential Docker components (or something to that effect). Currently, this is clickbait.
  - Supermancho 6y ago
    > You can edit the title for two hours after submitting the article. The submitter can. This kind of misses the point anyway. The title is misleading.
    - deleted 6y ago
      [deleted]
    - andyjohnson0 6y ago
      I was replying to the submitter.
    - GordonS 6y ago
      I am the submitter, I just didn't know I could edit the title after 7 years of using HN! Gone ahead and done it now.
- alpb 6y ago
  Your post is entirely clickbait. Docker runtime support doesn't really matter since most people already have moved onto other runtimes like containerd/runc.
djsumdog 6y ago
containerd will still run images build by Docker. Google can talk about how Docker is missing CRI support, but I feel like this is just Google wanting to cut out Docker entirely. I seems like containerd is maintained by The Linux Foundation, a group of people who mostly don't even run Linux (most of their releases and media material is made on Macs) I dunno. I don't like the direction things are going in the open source world right now.
- cogman10 6y ago
  Probably to get around the recent docker registry throttling would be my guess. They are likely looking at building out their own container ecosystem.
  - jacques_chester 6y ago
    Changing the runtime doesn't change the registry.
- chucky_z 6y ago
  i 100% agree with you. open source feels really, really bad especially in the last year. to others reading this -- simplified, but, docker uses containerd to build/run images. all docker images are valid containerd images. you can run images through containerd straight off the docker hub.
  - shadowgovt 6y ago
    It depends on what one means by "open source." Open source is fine; there's a ton of available code out there, to mix and match for whatever goals you need. Open services were never a thing, and what we're observing is that the SAAS model is eating the entire marketplace because tying services together to solve tasks is far easier (and depending on scale, more maintainable) than tying software together to solve tasks on hardware you own and operate exclusively. Owning and operating the hardware in addition to owning and operating the software that does the thing you want to do doesn't scale as flexibly as letting someone else maintain the hardware and provide service-level guarantees, for a wide variety of applications. But the software driving those services is generally closed-source. If by "open source" you mean "Free (as in freedom) software," the ship has kind of sailed. The GNU-style four essential freedoms break down philosophically in the case of SAAS, because the underlying assumption is "It's my hardware and I should have the right to control it" and that assumption breaks down when it's not my hardware. There may be an analogous assumption for "It's my data and..." but nobody's crystallized what that looks like in the way GNU crystallized the Four Freedoms.
qz2 6y ago
Can someone explain how logging is supposed to work after this change? I’m complete bloody lost. Actually I’m nearly always lost with kubernetes. It’s either broken or changing.
- throwaway201103 6y ago
  > I’m nearly always lost with kubernetes. It’s either broken or changing. Glad I'm not the only one. I'm sure I'm not the smartest engineer/sysadmin in the world, but I'm also not the dumbest and I have never gotten an on-premises Kubernetes installation to work. The way I manage containers is lxc and shell scripts. I understand it, and it works.
  - freedomben 6y ago
    I work for Red Hat as an OpenShift Consultant, so I'm on the bleeding edge of change and am constantly pushing boundaries. Don't tell the boss or the customers, but most of the time when release notes for a new version come out, I look at them and go "WTF, why do we need that, I better do some research." It's fast changing, complex as hell, and absolutely brutal. That said most things are there for a reason and once I dig in I usually see the need. That said I do love it despite its warts. There's no doubt some Stockholm Syndrome at play here, but I love the API (which is pretty curlable btw, a mark of a great API IMHO) and the principles (declarative, everything's a YAML/JSON object in etcd, etc). I see it the same way I did C++ (which I also loved). It gives you great power which you can use to build an elegant, robust system, or you can create an unmaintainable, complex, monster of a nightmare. It's up to you.
    - jacques_chester 6y ago
      The full-time job of keeping up with Kubernetes was published in February 2018[0] and things have only gotten faster since then. [0] https://goteleport.com/blog/kubernetes-release-cycle/ https://goteleport.com/blog/kubernetes-release-cycle/ , HN discussion: https://news.ycombinator.com/item?id=16285192 https://news.ycombinator.com/item?id=16285192
  - 6y ago
deleted 6y ago
[deleted]
dgrin91 6y ago
I'm kind of confused by this. It sounds like its removing just some parts of docker (like the UI stuff), but not others? Can I still run my docker-built images on K8?
- jacques_chester 6y ago
  > Can I still run my docker-built images on K8? Yes.
- deadmik3 6y ago
  yes it's just the underlying container runtime. so this is really only applicable to sysadmins managing their own k8s installation
st1x7 6y ago
(Super naive layman question, I don't work in this space.) What does this mean? I thought that Kubernetes manages Docker containers which makes the title kind of confusing.
- lucideer 6y ago
  Sibling comments cover the details but to put it simply: there are two definitions of the work "Docker": 1. [common, informal] "An OCI container". 2. [pedantic, strictly accurate] "A set of tools for building & interacting with OCI containers". This article is talking about the latter definition.
  - ghaff 6y ago
    It's actually even more confusing than that. There's also Docker, Inc. the company and there used to be the Docker Enterprise product (although I believe newer versions are now Mirantis Enterprise which bought that part of the business). Docker is pretty much the a textbook example of why you probably shouldn't use the same word for a lot of different things.
    - oblio 6y ago
      Java :-) Better yet, .Net.
      - ghaff 6y ago
        Heh. I can't tell you, especially going back a few years, the number of people who claimed to hate Java with a passion because as far as they were concerned it was that security-shredding dialog box that would pop up demanding to be updated. (OK, there are probably other reasons to dislike Java as well but I agree it's a lot of different things.)
    - gjlawran 6y ago
      MS Teams
- joeskyyy 6y ago
tannhaeuser 6y ago
As much as I love Docker as an excellent freelance developer tool for juggling customer environments, I just never understood the urge to run entire enterprises on containers. It certainly doesn't make things easier, faster, more secure, or cheaper; all it ever did was isolating shared library dependencies (a self-inflicted problem created due to overuse of shared libraries in F/OSS, since static linking has done just the same thing since the dawn of times; of course, in neither case do you get automatic security or stability updates which was the entire point of shared libs). Now they're removing Docker altogether from the k8s stack? So much for Docker's perceived "isolation" I guess.
- yahyaheee 6y ago
  It makes things reproducible, and k8s is still containers just not docker
- dbmikus 6y ago
  Kubernetes still uses containers, just not Docker. From the release notes: > We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI...
- deadmik3 6y ago
  k8s runs containers, docker is just one implementation of containers.
- bird_monster 6y ago
  From your post, I think you might fundamentally misunderstand Docker's use/value. From a value-add standpoint, Docker doesn't really care about "isolating shared library dependencies", but instead, compartmentalizing an entire application, dependencies and all. The value in this, of course, is that you no longer have to care about version conflicts between resources that are sharing a machine. As an added bonus, it means your deployment process can stay the same regardless of the type of container you're deploying. Before, if you had to deploy a Ruby app as well as a Python app, those required fundamentally different processes, as they each require their own package managers and interpreters. With a container, you compile each of those tools _into the container_, and then your deployment process is just "Create container image, send it somewhere". Hell, even if you wrote an application with 0 dependencies, you're still on the hook for installing the correct version of its compiler, the correct version of your deployment tool, and the correct version/OS of your VM. These are still dependencies, even if they're not dev dependencies. > It certainly doesn't make things easier, faster, more secure, or cheaper; If you don't think being able to reuse software makes your workflow easier, faster and at the very least cheaper, I'm not sure what you could possibly think would do those things.
renewiltord 6y ago
Ah I see. You need a runtime in k8s that actually runs the containers that are in pods. So you can use Docker to run those containers, or containerd or whatever. Each of your k8s nodes has to have this program running to run the containers. So they don't want to support that first one. Not a big deal. It's some backend stuff that's not interesting to people who use managed k8s. Cool cool.
- freedomben 6y ago
  Yep, NBD. OpenShift removed Docker a while ago and replaced it with CRI-O. 99% of people never noticed, and the ones that did just like to know how things work on the inside.
darknessmonk 6y ago
So... What's the better runtime alternatives?
- q3k 6y ago
  The 'standard' one is containerd.
- johnaoss 6y ago
  I've heard good things about https://containerd.io https://containerd.io Kubernetes documentation has a setup guide (for containerd, as well as CRI-O here: https://kubernetes.io/docs/setup/production-environment/container-runtimes/#containerd https://kubernetes.io/docs/setup/production-environment/cont...
bobbyi_settv 6y ago
> We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available. So Docker is deprecated, but no replacement is yet available?
- geerlingguy 6y ago
  I believe at least containerd and CRI-0 are actively available and in use quite a bit. (There are some others I've seen, too.) It's just saying if you use something else, it must follow at least the v1alpha1 or v1 CRI runtime standard.
- dodobirdlord 6y ago
  The recommended runtime to use is containerd, which Docker itself is using under the hood. This is just about removing Docker as a piece of middleware.
littlemerman 6y ago
Might make sense to update the link to point to the language exactly: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation https://github.com/kubernetes/kubernetes/blob/master/CHANGEL... "Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community. We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available. (#94624, @dims) [SIG Node]"
justicezyx 6y ago
This is inevitable one way or another. Docker lost any leverage after 2015, when they still had some chance of making sure container as they invented can still be monetized in the same way of VMware.
deleted 6y ago
[deleted]
brundolf 6y ago
It's funny, and telling, how many commenters here are using K8s without really knowing how it works (and what this change therefore means). I'm in that group myself. Is this a testament to, or an indictment of, how abstracted our systems have become?
- jrochkind1 6y ago
  If it works it's fine. I took an Operating Systems class decades ago in school in which I wrote a toy OS, but at this point I couldn't tell you much about how operating systems really work, but I deploy software to them everyday. That is fine, it is the nature of computers, they are basically abstraction machines. And OS's are pretty mature and stable, I don't really ever need to debug the OS itself in order to deploy software to one, for the kind of software I write. (Others might need to know more). But personally I still haven't figured out how to use K8, heh.
- symlinkk 6y ago
  The purpose of every piece of software is to be usable without knowing how it works.
  - Spivak 6y ago
    I feel like “how something works” and “implementation details” aren’t synonymous and are really context dependent. As a user you should know the different types of namespacing that affect containers without necessarily knowing that/how your runtime calls clone() to do it. And as a sysadmin you had better know how all the components fit together and their failure modes because you’re the one supporting them. Different people have different views of any technology so someone’s necessary understanding as a user of managed k8s can be different than a sysadmin who is a user of k8s code itself.
- pm90 6y ago
  Would you say you know the intricacies of how VMs work before using them to deploy apps? There is nothing “un abstract” about running applications on VMs or machines. We’re just evolving the abstractions that we work with. Before it was VMs, then containers and now containers + orchestrators. In the future it will be some other abstraction. Every step of the way, we’ve made this transition for compelling reasons. And it will happen again.
crizzlenizzle 6y ago
About time. Coincidentally, today I watched three presentations about burning Kubernetes clusters and all of them had Docker daemon issues in the mix. I’ve been using Docker for over five years myself and I’ve been using Kubernetes for almost two years now. The most pain I encountered was with Docker or its own ecosystem. In the last two years it always had some weird racy situations where it damaged its IPAM or simply couldn’t start containers after a restart anymore. Also its IPv6 support is just a joke. Sorry, I had to rant and I hope that this announcement will fuel the development of Docker alternatives even more.
tannhaeuser 6y ago
Just another case where an idea originally created for developer convenience turned into an enterprise thing and instrument for mass control. Reminds me of Java build tools having long forgotten that they're there to make developer's lives easier rather than appeal to enterprise control freak desires. Now have fun developing k8s-compatible containers to enslave us in "the cloud" with developer workflow an afterthought.
- mplewis 6y ago
  The 12-factor app has been around since at least 2014. Why do you think "containers" are "enslaving" you?
sbisson 6y ago
It gets less confusing when you realise that the original specification for containerd came from Docker (the company) and the current implementation of docker (the application) use containerd as their runtime. By using containerd (or podman) in K8s, you're getting rid of a lot of unnecessary overhead and so should get more containers per host...
flowerlad 6y ago
This is misleading. If you're using Docker to build images and using Kubernetes to manage containers nothing changes. The deprecation mentioned is internal to Kubernetes and does not impact people who use Kubernetes to manage containers built using Docker.
polskibus 6y ago
What does that mean for people working with Dockerfiles for local/small scale development that would like to be able to use kubernetes at some point? Will they not be able to use their Dockerfiles at all?
- freeone3000 6y ago
  No change for this workflow. Developers can still use docker to build OCI images as they always have, and containerd can run them as previously.
euank 6y ago
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 https://github.com/kubernetes/kubernetes/pull/94624
- Havoc 6y ago
  Thanks for explaining. I suspect this will nuke a huge amount of tutorials out there though & frustrate newbies.
  - ZiiS 6y ago
    This is deep in the internals of Kubernetes, nothing about `docker build/push` or `kubectl apply` will change.
  - manigandham 6y ago
    This changes nothing for 99.9% of Kubernetes users.
    - euank 6y ago
      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.
pietromenna 6y ago
I found the title just a reminder to invest learning concepts and topics that can last a life time. Tools come and go, and it is healthy to change from time to time. Containers as a concept is an important learning, but the implementation for today may not be the same as the one in 5 years from now.
npiit 6y ago
Did anybody make a test to compare CRI-O vs Docker especially when it comes to overall node memory usage for let's say 30-50 containers per node? I guess CRI-O would save a lot of memory but I don't have numbers.
mikesabbagh 6y ago
Docker has networking and other layers too. Docker runs as a daemon too, so it is not very secure. GKE uses containerd (u can use others) What is nice about containerd is that it only runs the container and you can write plugins to it. So much lighter than docker.
zapita 6y ago
Here’s what this means for real-world kubernetes deployments: - 99% of Kubernetes deployments use dockerd as a runtime - 99% of dockerd deployments use containerd as a runtime - containerd can be called directly by kubernetes via cri-containerd - Therefore most Kubernetes deployments can, and should, be simplified by calling containerd directly. - This deprecation notice will make this transition happen sooner. This is the natural consequence of Docker itself splitting out its runtime into containerd.
dataplayer 6y ago
You can spin up test Kubernetes clusters with different underlying container runtimes using Minikube. If you want to play around with a cluster running containerd instead of the docker container runtime use: minikube start --container-runtime=containerd Use this to convince yourself that all your current docker images will still deploy and work as usual.
blinkingled 6y ago
This link has a more thorough detail on what is actually happening and when - https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1985-remove-dockershim https://github.com/kubernetes/enhancements/tree/master/keps/... Bottom line I think is that using docker as a container runtime with K8S is going to be harder unless cri-dockerd becomes production grade but even then, from the Cons section it looks like it will not be a good option - cri-dockerd will vendor kubernetes/kubernetes, that may be tough. cri-dockerd as an independent software running on node should be allocated enough resource to guarantee its availability.
fomine3 6y ago
Say it many times: we miss Docker Swarm

457 points by GordonS 6y ago

> Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community. We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available. (#94624, @dims) [SIG Node]

GordonS 6y ago

Read about this over on Twitter: https://twitter.com/Dixie3Flatline/status/1334188913724850177?s=19 https://twitter.com/Dixie3Flatline/status/133418891372485017... The only "official" notice about it so far seems to be in the linked changelog.

boberoni 6y ago
This was very useful. Thanks for sharing. It seems that Docker images will still run fine on k8s. The main change is that they're moving away from the "Docker runtime", which is supposed to be installed on each of the nodes in your cluster. More details about k8s container runtimes here: https://kubernetes.io/docs/setup/production-environment/container-runtimes/ https://kubernetes.io/docs/setup/production-environment/cont...
- jsmith45 6y ago
  Right. The simplest option is to use containerd, as the runtime. Installing docker will also install containerd (because docker uses it internally), so nothing much needs to change except a configuration option. docker and k8s can run side by side sharing the same containerd instance, in case you need to do something like build containers inside your k8s cluster. You lose out on things that require access to the docker daemon socket, but ideally any such software should be replaced with something that talks with the kubernetes API instead. (exception is building containers in cluster. If you need that, run docker side by side with the kubelet, or use buildkit with containerd integration). You also lose the ability to interact with containers with the docker cli tool. Use crictl instead, which has most of the same commands, but also includes certain k8s relevant information in output tables.
- ccmcarey 6y ago
  Yep, they're not really "Docker" images. A while ago the image/container formats were standardized through the OCI.
fhrow4484 6y ago
The twitter thread has way more details about the change, which is why I submitted it here: https://news.ycombinator.com/item?id=25279424 https://news.ycombinator.com/item?id=25279424 https://twitter.com/IanColdwater/status/1334149283449352200 https://twitter.com/IanColdwater/status/1334149283449352200 also has some details
shuuji3 6y ago
There are several official responses now to help us understand this deprecation. K8sContributors on Twitter: "#Kubernetes 1.20 introduces an important change to the kubelet - the deprecation of #Docker as a container runtime option. What does this mean and why is it happening? You can learn more in our blog post! https://t.co/lzPPzwXUNM https://t.co/lzPPzwXUNM" / Twitter - https://twitter.com/K8sContributors/status/1334301732830990336 https://twitter.com/K8sContributors/status/13343017328309903... Don't Panic: Kubernetes and Docker | Kubernetes - https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/ https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-... Dockershim Deprecation FAQ | Kubernetes - https://kubernetes.io/blog/2020/12/02/dockershim-faq/ https://kubernetes.io/blog/2020/12/02/dockershim-faq/

GordonS 6y ago

@mods, would appreciate if someone could change the title to "Kubernetes is deprecating Docker runtime support" (I accidentally missed the word "runtime" when submitting).

andyjohnson0 6y ago
You can edit the title for two hours after submitting the article.
- asah 6y ago
  even better: deprecating non-essential Docker components (or something to that effect). Currently, this is clickbait.
- Supermancho 6y ago
  > You can edit the title for two hours after submitting the article. The submitter can. This kind of misses the point anyway. The title is misleading.
  - deleted 6y ago
    [deleted]
  - andyjohnson0 6y ago
    I was replying to the submitter.
  - GordonS 6y ago
    I am the submitter, I just didn't know I could edit the title after 7 years of using HN! Gone ahead and done it now.
alpb 6y ago
Your post is entirely clickbait. Docker runtime support doesn't really matter since most people already have moved onto other runtimes like containerd/runc.

djsumdog 6y ago

containerd will still run images build by Docker. Google can talk about how Docker is missing CRI support, but I feel like this is just Google wanting to cut out Docker entirely. I seems like containerd is maintained by The Linux Foundation, a group of people who mostly don't even run Linux (most of their releases and media material is made on Macs) I dunno. I don't like the direction things are going in the open source world right now.

cogman10 6y ago
Probably to get around the recent docker registry throttling would be my guess. They are likely looking at building out their own container ecosystem.
- jacques_chester 6y ago
  Changing the runtime doesn't change the registry.
chucky_z 6y ago
i 100% agree with you. open source feels really, really bad especially in the last year. to others reading this -- simplified, but, docker uses containerd to build/run images. all docker images are valid containerd images. you can run images through containerd straight off the docker hub.
- shadowgovt 6y ago
  It depends on what one means by "open source." Open source is fine; there's a ton of available code out there, to mix and match for whatever goals you need. Open services were never a thing, and what we're observing is that the SAAS model is eating the entire marketplace because tying services together to solve tasks is far easier (and depending on scale, more maintainable) than tying software together to solve tasks on hardware you own and operate exclusively. Owning and operating the hardware in addition to owning and operating the software that does the thing you want to do doesn't scale as flexibly as letting someone else maintain the hardware and provide service-level guarantees, for a wide variety of applications. But the software driving those services is generally closed-source. If by "open source" you mean "Free (as in freedom) software," the ship has kind of sailed. The GNU-style four essential freedoms break down philosophically in the case of SAAS, because the underlying assumption is "It's my hardware and I should have the right to control it" and that assumption breaks down when it's not my hardware. There may be an analogous assumption for "It's my data and..." but nobody's crystallized what that looks like in the way GNU crystallized the Four Freedoms.

qz2 6y ago

Can someone explain how logging is supposed to work after this change? I’m complete bloody lost. Actually I’m nearly always lost with kubernetes. It’s either broken or changing.

throwaway201103 6y ago
> I’m nearly always lost with kubernetes. It’s either broken or changing. Glad I'm not the only one. I'm sure I'm not the smartest engineer/sysadmin in the world, but I'm also not the dumbest and I have never gotten an on-premises Kubernetes installation to work. The way I manage containers is lxc and shell scripts. I understand it, and it works.
- freedomben 6y ago
  I work for Red Hat as an OpenShift Consultant, so I'm on the bleeding edge of change and am constantly pushing boundaries. Don't tell the boss or the customers, but most of the time when release notes for a new version come out, I look at them and go "WTF, why do we need that, I better do some research." It's fast changing, complex as hell, and absolutely brutal. That said most things are there for a reason and once I dig in I usually see the need. That said I do love it despite its warts. There's no doubt some Stockholm Syndrome at play here, but I love the API (which is pretty curlable btw, a mark of a great API IMHO) and the principles (declarative, everything's a YAML/JSON object in etcd, etc). I see it the same way I did C++ (which I also loved). It gives you great power which you can use to build an elegant, robust system, or you can create an unmaintainable, complex, monster of a nightmare. It's up to you.
  - jacques_chester 6y ago
    The full-time job of keeping up with Kubernetes was published in February 2018[0] and things have only gotten faster since then. [0] https://goteleport.com/blog/kubernetes-release-cycle/ https://goteleport.com/blog/kubernetes-release-cycle/ , HN discussion: https://news.ycombinator.com/item?id=16285192 https://news.ycombinator.com/item?id=16285192
- 6y ago

deleted 6y ago

[deleted]

dgrin91 6y ago

I'm kind of confused by this. It sounds like its removing just some parts of docker (like the UI stuff), but not others? Can I still run my docker-built images on K8?

jacques_chester 6y ago
> Can I still run my docker-built images on K8? Yes.
deadmik3 6y ago
yes it's just the underlying container runtime. so this is really only applicable to sysadmins managing their own k8s installation

st1x7 6y ago

(Super naive layman question, I don't work in this space.) What does this mean? I thought that Kubernetes manages Docker containers which makes the title kind of confusing.

lucideer 6y ago
Sibling comments cover the details but to put it simply: there are two definitions of the work "Docker": 1. [common, informal] "An OCI container". 2. [pedantic, strictly accurate] "A set of tools for building & interacting with OCI containers". This article is talking about the latter definition.
- ghaff 6y ago
  It's actually even more confusing than that. There's also Docker, Inc. the company and there used to be the Docker Enterprise product (although I believe newer versions are now Mirantis Enterprise which bought that part of the business). Docker is pretty much the a textbook example of why you probably shouldn't use the same word for a lot of different things.
  - oblio 6y ago
    Java :-) Better yet, .Net.
    - ghaff 6y ago
      Heh. I can't tell you, especially going back a few years, the number of people who claimed to hate Java with a passion because as far as they were concerned it was that security-shredding dialog box that would pop up demanding to be updated. (OK, there are probably other reasons to dislike Java as well but I agree it's a lot of different things.)
  - gjlawran 6y ago
    MS Teams
joeskyyy 6y ago

tannhaeuser 6y ago

As much as I love Docker as an excellent freelance developer tool for juggling customer environments, I just never understood the urge to run entire enterprises on containers. It certainly doesn't make things easier, faster, more secure, or cheaper; all it ever did was isolating shared library dependencies (a self-inflicted problem created due to overuse of shared libraries in F/OSS, since static linking has done just the same thing since the dawn of times; of course, in neither case do you get automatic security or stability updates which was the entire point of shared libs). Now they're removing Docker altogether from the k8s stack? So much for Docker's perceived "isolation" I guess.

yahyaheee 6y ago
It makes things reproducible, and k8s is still containers just not docker
dbmikus 6y ago
Kubernetes still uses containers, just not Docker. From the release notes: > We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI...
deadmik3 6y ago
k8s runs containers, docker is just one implementation of containers.
bird_monster 6y ago
From your post, I think you might fundamentally misunderstand Docker's use/value. From a value-add standpoint, Docker doesn't really care about "isolating shared library dependencies", but instead, compartmentalizing an entire application, dependencies and all. The value in this, of course, is that you no longer have to care about version conflicts between resources that are sharing a machine. As an added bonus, it means your deployment process can stay the same regardless of the type of container you're deploying. Before, if you had to deploy a Ruby app as well as a Python app, those required fundamentally different processes, as they each require their own package managers and interpreters. With a container, you compile each of those tools _into the container_, and then your deployment process is just "Create container image, send it somewhere". Hell, even if you wrote an application with 0 dependencies, you're still on the hook for installing the correct version of its compiler, the correct version of your deployment tool, and the correct version/OS of your VM. These are still dependencies, even if they're not dev dependencies. > It certainly doesn't make things easier, faster, more secure, or cheaper; If you don't think being able to reuse software makes your workflow easier, faster and at the very least cheaper, I'm not sure what you could possibly think would do those things.

renewiltord 6y ago

Ah I see. You need a runtime in k8s that actually runs the containers that are in pods. So you can use Docker to run those containers, or containerd or whatever. Each of your k8s nodes has to have this program running to run the containers. So they don't want to support that first one. Not a big deal. It's some backend stuff that's not interesting to people who use managed k8s. Cool cool.

freedomben 6y ago
Yep, NBD. OpenShift removed Docker a while ago and replaced it with CRI-O. 99% of people never noticed, and the ones that did just like to know how things work on the inside.

darknessmonk 6y ago

So... What's the better runtime alternatives?

q3k 6y ago
The 'standard' one is containerd.
johnaoss 6y ago
I've heard good things about https://containerd.io https://containerd.io Kubernetes documentation has a setup guide (for containerd, as well as CRI-O here: https://kubernetes.io/docs/setup/production-environment/container-runtimes/#containerd https://kubernetes.io/docs/setup/production-environment/cont...

bobbyi_settv 6y ago

> We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available. So Docker is deprecated, but no replacement is yet available?

geerlingguy 6y ago
I believe at least containerd and CRI-0 are actively available and in use quite a bit. (There are some others I've seen, too.) It's just saying if you use something else, it must follow at least the v1alpha1 or v1 CRI runtime standard.
dodobirdlord 6y ago
The recommended runtime to use is containerd, which Docker itself is using under the hood. This is just about removing Docker as a piece of middleware.

littlemerman 6y ago

Might make sense to update the link to point to the language exactly: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation https://github.com/kubernetes/kubernetes/blob/master/CHANGEL... "Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community. We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available. (#94624, @dims) [SIG Node]"

justicezyx 6y ago

This is inevitable one way or another. Docker lost any leverage after 2015, when they still had some chance of making sure container as they invented can still be monetized in the same way of VMware.

deleted 6y ago

[deleted]

brundolf 6y ago

It's funny, and telling, how many commenters here are using K8s without really knowing how it works (and what this change therefore means). I'm in that group myself. Is this a testament to, or an indictment of, how abstracted our systems have become?

jrochkind1 6y ago
If it works it's fine. I took an Operating Systems class decades ago in school in which I wrote a toy OS, but at this point I couldn't tell you much about how operating systems really work, but I deploy software to them everyday. That is fine, it is the nature of computers, they are basically abstraction machines. And OS's are pretty mature and stable, I don't really ever need to debug the OS itself in order to deploy software to one, for the kind of software I write. (Others might need to know more). But personally I still haven't figured out how to use K8, heh.
symlinkk 6y ago
The purpose of every piece of software is to be usable without knowing how it works.
- Spivak 6y ago
  I feel like “how something works” and “implementation details” aren’t synonymous and are really context dependent. As a user you should know the different types of namespacing that affect containers without necessarily knowing that/how your runtime calls clone() to do it. And as a sysadmin you had better know how all the components fit together and their failure modes because you’re the one supporting them. Different people have different views of any technology so someone’s necessary understanding as a user of managed k8s can be different than a sysadmin who is a user of k8s code itself.
pm90 6y ago
Would you say you know the intricacies of how VMs work before using them to deploy apps? There is nothing “un abstract” about running applications on VMs or machines. We’re just evolving the abstractions that we work with. Before it was VMs, then containers and now containers + orchestrators. In the future it will be some other abstraction. Every step of the way, we’ve made this transition for compelling reasons. And it will happen again.

crizzlenizzle 6y ago

About time. Coincidentally, today I watched three presentations about burning Kubernetes clusters and all of them had Docker daemon issues in the mix. I’ve been using Docker for over five years myself and I’ve been using Kubernetes for almost two years now. The most pain I encountered was with Docker or its own ecosystem. In the last two years it always had some weird racy situations where it damaged its IPAM or simply couldn’t start containers after a restart anymore. Also its IPv6 support is just a joke. Sorry, I had to rant and I hope that this announcement will fuel the development of Docker alternatives even more.

tannhaeuser 6y ago

Just another case where an idea originally created for developer convenience turned into an enterprise thing and instrument for mass control. Reminds me of Java build tools having long forgotten that they're there to make developer's lives easier rather than appeal to enterprise control freak desires. Now have fun developing k8s-compatible containers to enslave us in "the cloud" with developer workflow an afterthought.

mplewis 6y ago
The 12-factor app has been around since at least 2014. Why do you think "containers" are "enslaving" you?

sbisson 6y ago

It gets less confusing when you realise that the original specification for containerd came from Docker (the company) and the current implementation of docker (the application) use containerd as their runtime. By using containerd (or podman) in K8s, you're getting rid of a lot of unnecessary overhead and so should get more containers per host...

flowerlad 6y ago

This is misleading. If you're using Docker to build images and using Kubernetes to manage containers nothing changes. The deprecation mentioned is internal to Kubernetes and does not impact people who use Kubernetes to manage containers built using Docker.

polskibus 6y ago

What does that mean for people working with Dockerfiles for local/small scale development that would like to be able to use kubernetes at some point? Will they not be able to use their Dockerfiles at all?

freeone3000 6y ago
No change for this workflow. Developers can still use docker to build OCI images as they always have, and containerd can run them as previously.

euank 6y ago

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 https://github.com/kubernetes/kubernetes/pull/94624

Havoc 6y ago
Thanks for explaining. I suspect this will nuke a huge amount of tutorials out there though & frustrate newbies.
- ZiiS 6y ago
  This is deep in the internals of Kubernetes, nothing about `docker build/push` or `kubectl apply` will change.
- manigandham 6y ago
  This changes nothing for 99.9% of Kubernetes users.
  - euank 6y ago
    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.

pietromenna 6y ago

I found the title just a reminder to invest learning concepts and topics that can last a life time. Tools come and go, and it is healthy to change from time to time. Containers as a concept is an important learning, but the implementation for today may not be the same as the one in 5 years from now.

npiit 6y ago

Did anybody make a test to compare CRI-O vs Docker especially when it comes to overall node memory usage for let's say 30-50 containers per node? I guess CRI-O would save a lot of memory but I don't have numbers.

mikesabbagh 6y ago

Docker has networking and other layers too. Docker runs as a daemon too, so it is not very secure. GKE uses containerd (u can use others) What is nice about containerd is that it only runs the container and you can write plugins to it. So much lighter than docker.

zapita 6y ago

Here’s what this means for real-world kubernetes deployments: - 99% of Kubernetes deployments use dockerd as a runtime - 99% of dockerd deployments use containerd as a runtime - containerd can be called directly by kubernetes via cri-containerd - Therefore most Kubernetes deployments can, and should, be simplified by calling containerd directly. - This deprecation notice will make this transition happen sooner. This is the natural consequence of Docker itself splitting out its runtime into containerd.

dataplayer 6y ago

You can spin up test Kubernetes clusters with different underlying container runtimes using Minikube. If you want to play around with a cluster running containerd instead of the docker container runtime use: minikube start --container-runtime=containerd Use this to convince yourself that all your current docker images will still deploy and work as usual.

blinkingled 6y ago

This link has a more thorough detail on what is actually happening and when - https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1985-remove-dockershim https://github.com/kubernetes/enhancements/tree/master/keps/... Bottom line I think is that using docker as a container runtime with K8S is going to be harder unless cri-dockerd becomes production grade but even then, from the Cons section it looks like it will not be a good option - cri-dockerd will vendor kubernetes/kubernetes, that may be tough. cri-dockerd as an independent software running on node should be allocated enough resource to guarantee its availability.

fomine3 6y ago

Say it many times: we miss Docker Swarm