5 ms·

(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

by 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
Kubernetes manages many types of containers, Docker containers just happen to be the most popular (or at least I'd venture to guess). But Kubernetes for a while has supported a few container runtimes (: Here's some k8s docs on a few: https://kubernetes.io/docs/setup/production-environment/container-runtimes/ https://kubernetes.io/docs/setup/production-environment/cont...
scrappyjoe 6y ago
Kubernetes orchestrates containers, but Docker is just one way of running containers. It wraps all the underlying Linux into a nice set of of easy to use commands. Kubernetes is deprecating interacting with the underlying Linux via the Docker wrapper.
bitdivision 6y ago
It will still run docker containers, they're just deprecating the Docker runtime, which is more of an implementation detail
astuyvenberg 6y ago
Simply put, Docker includes a bunch of UX components that Kubernetes doesn't need. Kubernetes is currently relying on a shim to interact with the parts that it _does_ need. This change is to simplify the abstraction. You can still use docker to build images deployed via Kubernetes. Here's an explanation I found helpful: https://twitter.com/Dixie3Flatline/status/1334188913724850177 https://twitter.com/Dixie3Flatline/status/133418891372485017...
- Patrick_Devine 6y ago
  Former Docker employee here. We've been busy writing a way to allow you to build OCI images with your Kubernetes cluster using kubectl. This let's you get rid of `docker build` and replace it with `kubectl build`. You can check out the project here: https://github.com/vmware-tanzu/buildkit-cli-for-kubectl https://github.com/vmware-tanzu/buildkit-cli-for-kubectl
  - jrockway 6y ago
    That is a really good idea! Does this just schedule a one-off pod, then have that do the build?
    - Patrick_Devine 6y ago
      Not quite a one-off pod, but very close to that. It will automatically create a builder pod for you if you don't already have one, or you can specify one with whichever runtime that you want (containerd or docker). It uses buildkit to do the builds and has a syntax which is compatible with `docker build`. There are also some pretty cool features. It supports building multi-arch images, so you can do things like create x86_64 and ARM images. It can also do build layer caching to a local registry for all of your builders, so it's possible to scale up your pod and then share each of the layers for really efficient builds.
  - rcarmo 6y ago
    That’s pretty nice. One of the things I am curious about is how Kubernetes will deal with private “insecure” in-cluster registries (which are a major pain to set up TLS for when you’re doing edge deployments or stuff that is inherently offline).
jcastro 6y ago
Kubernetes will just use containerd directly, most end users will just continue to use docker on their laptop or whatever. Or you can use something else like podman, it's all OCI: https://opencontainers.org/ https://opencontainers.org/
geerlingguy 6y ago
It's a situation where 'Docker' has become eponymous with 'container'. But 'Docker' in this case refers to the runtime that Kubernetes uses to run container images on servers ('nodes') where the UI/UX features of Docker (like it's CLI, image building capabilities, etc.) are not needed. Container images nowadays can be built by a variety of tools, and run by a variety of tools, with Docker likely being the most popular end-user tool with the most history and name recognition. Others like Podman/Buildah are differently-architected replacements. As long as a container meets the open container specs, it can be built with whatever tool and run on whatever tool that also follows the specs.
- fulafel 6y ago
  This holds for OCI style containers, but not all container systems are of the Docker/OCI variety. For example LXD.
jsmith45 6y ago
"docker containers" are more accurately called OCI containers, and have been standardized so that various container runtimes can use exactly the same container images. Kubernetes can use docker runtime (dockerd) to run OCI containers, but Docker Inc strongly discourages the docker runtime being used directly for infrastructure. Docker runtime imposes a lot of opinionated defaults on containers that are often unwanted by infrastructure projects. (For example docker will automatically edit the /etc/hosts file in containers, in a way that makes little sense for Kubernetes, so Kubernetes has to implement a silly work around to avoid this.) Instead Docker Inc recommends using containerd as the runtime. containerd implements downloading, unpacking, creating CRI manifests, and running the resulting containers all without implementing docker's opinionated defaults on top. Docker itself uses containerd to actually run the containers, and plans to remove it downloading code in favor of using the one from containerd too. The only advantage to using docker proper for infrastructure projects is that you can use the docker cli for introspection and debugging. Kubernetes has created its own very similar cli that works with all supported backend runtimes, and also can include relevant Kubernetes specific information in outputs.
- nextaccountic 6y ago
  Why do you spell containerd as "ContainerD"? You wrote dockerd without caps.
  - kordlessagain 6y ago
    MANY THINGS IGNORE CAPS.
  - tylersmith 6y ago
    dockerd is the literal name of a binary while containerd is the name of a project. As far as I can tell containerd stylizes its name in all lowercase but more than half the time I still see it written like a standard name, ContainerD, exactly like this.
    - cpuguy83 6y ago
      Being nitpicky here, but the canonical representation of "containerd" is all lowercase, as in the logo.
mfer 6y ago
In basic terms... this is a technical detail that isn't going to impact Kubernetes users (a mass majority of them). Those who are concerned with running their workloads in Kubernetes, anyway. The part of Kubernetes that runs containers has had a shim for docker along with an interface for runtimes to use. It's called the Container Runtime Interface (CRI). The docker shim that worked alongside CRI is being deprecated and now all runtimes (including Docker) will need to use the CRI interface. These days there are numerous container runtimes one can use. containerd and cri-o are two of them. Container images built with Docker can be run with either of these without anyone noticing.

by 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

Kubernetes manages many types of containers, Docker containers just happen to be the most popular (or at least I'd venture to guess). But Kubernetes for a while has supported a few container runtimes (: Here's some k8s docs on a few: https://kubernetes.io/docs/setup/production-environment/container-runtimes/ https://kubernetes.io/docs/setup/production-environment/cont...

scrappyjoe 6y ago

Kubernetes orchestrates containers, but Docker is just one way of running containers. It wraps all the underlying Linux into a nice set of of easy to use commands. Kubernetes is deprecating interacting with the underlying Linux via the Docker wrapper.

bitdivision 6y ago

It will still run docker containers, they're just deprecating the Docker runtime, which is more of an implementation detail

astuyvenberg 6y ago

Simply put, Docker includes a bunch of UX components that Kubernetes doesn't need. Kubernetes is currently relying on a shim to interact with the parts that it _does_ need. This change is to simplify the abstraction. You can still use docker to build images deployed via Kubernetes. Here's an explanation I found helpful: https://twitter.com/Dixie3Flatline/status/1334188913724850177 https://twitter.com/Dixie3Flatline/status/133418891372485017...

Patrick_Devine 6y ago
Former Docker employee here. We've been busy writing a way to allow you to build OCI images with your Kubernetes cluster using kubectl. This let's you get rid of `docker build` and replace it with `kubectl build`. You can check out the project here: https://github.com/vmware-tanzu/buildkit-cli-for-kubectl https://github.com/vmware-tanzu/buildkit-cli-for-kubectl
- jrockway 6y ago
  That is a really good idea! Does this just schedule a one-off pod, then have that do the build?
  - Patrick_Devine 6y ago
    Not quite a one-off pod, but very close to that. It will automatically create a builder pod for you if you don't already have one, or you can specify one with whichever runtime that you want (containerd or docker). It uses buildkit to do the builds and has a syntax which is compatible with `docker build`. There are also some pretty cool features. It supports building multi-arch images, so you can do things like create x86_64 and ARM images. It can also do build layer caching to a local registry for all of your builders, so it's possible to scale up your pod and then share each of the layers for really efficient builds.
- rcarmo 6y ago
  That’s pretty nice. One of the things I am curious about is how Kubernetes will deal with private “insecure” in-cluster registries (which are a major pain to set up TLS for when you’re doing edge deployments or stuff that is inherently offline).

jcastro 6y ago

Kubernetes will just use containerd directly, most end users will just continue to use docker on their laptop or whatever. Or you can use something else like podman, it's all OCI: https://opencontainers.org/ https://opencontainers.org/

geerlingguy 6y ago

It's a situation where 'Docker' has become eponymous with 'container'. But 'Docker' in this case refers to the runtime that Kubernetes uses to run container images on servers ('nodes') where the UI/UX features of Docker (like it's CLI, image building capabilities, etc.) are not needed. Container images nowadays can be built by a variety of tools, and run by a variety of tools, with Docker likely being the most popular end-user tool with the most history and name recognition. Others like Podman/Buildah are differently-architected replacements. As long as a container meets the open container specs, it can be built with whatever tool and run on whatever tool that also follows the specs.

fulafel 6y ago
This holds for OCI style containers, but not all container systems are of the Docker/OCI variety. For example LXD.

jsmith45 6y ago

"docker containers" are more accurately called OCI containers, and have been standardized so that various container runtimes can use exactly the same container images. Kubernetes can use docker runtime (dockerd) to run OCI containers, but Docker Inc strongly discourages the docker runtime being used directly for infrastructure. Docker runtime imposes a lot of opinionated defaults on containers that are often unwanted by infrastructure projects. (For example docker will automatically edit the /etc/hosts file in containers, in a way that makes little sense for Kubernetes, so Kubernetes has to implement a silly work around to avoid this.) Instead Docker Inc recommends using containerd as the runtime. containerd implements downloading, unpacking, creating CRI manifests, and running the resulting containers all without implementing docker's opinionated defaults on top. Docker itself uses containerd to actually run the containers, and plans to remove it downloading code in favor of using the one from containerd too. The only advantage to using docker proper for infrastructure projects is that you can use the docker cli for introspection and debugging. Kubernetes has created its own very similar cli that works with all supported backend runtimes, and also can include relevant Kubernetes specific information in outputs.

nextaccountic 6y ago
Why do you spell containerd as "ContainerD"? You wrote dockerd without caps.
- kordlessagain 6y ago
  MANY THINGS IGNORE CAPS.
- tylersmith 6y ago
  dockerd is the literal name of a binary while containerd is the name of a project. As far as I can tell containerd stylizes its name in all lowercase but more than half the time I still see it written like a standard name, ContainerD, exactly like this.
  - cpuguy83 6y ago
    Being nitpicky here, but the canonical representation of "containerd" is all lowercase, as in the logo.

mfer 6y ago

In basic terms... this is a technical detail that isn't going to impact Kubernetes users (a mass majority of them). Those who are concerned with running their workloads in Kubernetes, anyway. The part of Kubernetes that runs containers has had a shim for docker along with an interface for runtimes to use. It's called the Container Runtime Interface (CRI). The docker shim that worked alongside CRI is being deprecated and now all runtimes (including Docker) will need to use the CRI interface. These days there are numerous container runtimes one can use. containerd and cri-o are two of them. Container images built with Docker can be run with either of these without anyone noticing.