4 ms·

Podman is for running containers on a single host. It's exactly like docker with a few additional features (like the ability to run rootless containers and run

Podman is for running containers on a single host. It's exactly like docker with a few additional features (like the ability to run rootless containers and run containers in something like a Kubernetes pod). Podman was developed by Red Hat to replace docker, the cli, because Docker, the company, didn't play very nice with the open source community. Rancher is a Kubernetes implementation that can run containers across multiple hosts. Rancher is more comparable to something like Red Hat OpenShift or Hashicorp Nomad than docker.

pkaye 5y ago
Does Kubernetes usage also require podman or docker?
- Bilal_io 5y ago
  Kubernetes can support multiple solutions if I am not mistaken. I know rancher requires Docker and is not compatible with Podman as of today. And I believe Red Hat uses Podman in Openshift, their implementation of kubernetes.
  - spicyusername 5y ago
    OpenShift uses cri-o as the runtime.
  - gbraad 5y ago
    Podman is only used for bootstrapping the cluster with the OpenShift installer. The cluster itself uses cri-o.
- dariusj18 5y ago
  Kubernetes can use either
- rektide 5y ago
  Kubernetes requires a tool which implements the Container Runtime Interface (CRI), a standardized API for starting & managing containers. This is from 2015-2016[1]. The CRI interface is defined by & owned by Kubernetes, and there's a lot of implementations: runc, crun, youki, dockershim and likely more. For a while Kubernetes has included something called the "dockershim", it's own implementation of a CRI interface that, under the hood, calls Docker or Podman, so Kubernetes "pods" run in Docker/Podman. There's also tools like Kind[3] ("kubernetes in docker") that go further- not just hosting Kubernetes worker containers in Docker, but hosting the main kubernetes daemons also in Docker. Kubernetes deprecated Dockershim, formally in December 2020, but is just throwing the switch now in the upcoming 1.24, expected mid-April[4]. A company Mirantis has pledged to take over support of Dockershim[5], and is calling the new effort "cri-dockerd"[6]. This should allow Kubernetes workers to continue to run via Docker or Podman. Kind is unaffected, since it runs the main Kubernetes controllers in Docker, which then launch their own opencontainerd (one off the main CRI implementations) inside that Docker container, nested like, so no dockership/cri-dockerd is needed). Worth re-noting that Podman includes tools to try to run Kubernetes pods directly, without running the rest of Kubernetes. [1] https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/ https://kubernetes.io/blog/2016/12/container-runtime-interfa... [2] https://github.com/kubernetes/cri-api https://github.com/kubernetes/cri-api [3] https://kind.sigs.k8s.io/ https://kind.sigs.k8s.io/ [4] https://kubernetes.io/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/ https://kubernetes.io/blog/2022/01/07/kubernetes-is-moving-o... [5] https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/ https://www.mirantis.com/blog/mirantis-to-take-over-support-... [6] https://github.com/Mirantis/cri-dockerd https://github.com/Mirantis/cri-dockerd
- qbasic_forever 5y ago
  Kubernetes needs a container runtime, of which docker is a supported type (but deprecated and replaced with containerd for most users): https://kubernetes.io/docs/setup/production-environment/container-runtimes/ https://kubernetes.io/docs/setup/production-environment/cont...
- spicyusername 5y ago
  Most modern Kubernetes implementations use either containerd or cri-o.
spion 5y ago
I think OP meant Rancher Desktop, which is meant to be a replacement of sorts for Docker Desktop (it does include a Kubernetes implementation though)
Kaytaro 5y ago
> Podman was developed by Red Hat Wow they should advertise that more. I had no idea and I'm pretty deep in the Red Hat ecosystem.
- spydum 5y ago
  Pretty sure they will once it's a bit more stable. They have presented at most of the kubecons for several years but it's always cautioned they will potentially break stuff.
- gbraad 5y ago
  Why should they? I work for Red Hat, help and contribute to podman but they like to remain as 'independent' as possible. We collaborate but the preference is that Podman is an upstream/community project first.

pkaye 5y ago

Does Kubernetes usage also require podman or docker?

Bilal_io 5y ago
Kubernetes can support multiple solutions if I am not mistaken. I know rancher requires Docker and is not compatible with Podman as of today. And I believe Red Hat uses Podman in Openshift, their implementation of kubernetes.
- spicyusername 5y ago
  OpenShift uses cri-o as the runtime.
- gbraad 5y ago
  Podman is only used for bootstrapping the cluster with the OpenShift installer. The cluster itself uses cri-o.
dariusj18 5y ago
Kubernetes can use either
rektide 5y ago
Kubernetes requires a tool which implements the Container Runtime Interface (CRI), a standardized API for starting & managing containers. This is from 2015-2016[1]. The CRI interface is defined by & owned by Kubernetes, and there's a lot of implementations: runc, crun, youki, dockershim and likely more. For a while Kubernetes has included something called the "dockershim", it's own implementation of a CRI interface that, under the hood, calls Docker or Podman, so Kubernetes "pods" run in Docker/Podman. There's also tools like Kind[3] ("kubernetes in docker") that go further- not just hosting Kubernetes worker containers in Docker, but hosting the main kubernetes daemons also in Docker. Kubernetes deprecated Dockershim, formally in December 2020, but is just throwing the switch now in the upcoming 1.24, expected mid-April[4]. A company Mirantis has pledged to take over support of Dockershim[5], and is calling the new effort "cri-dockerd"[6]. This should allow Kubernetes workers to continue to run via Docker or Podman. Kind is unaffected, since it runs the main Kubernetes controllers in Docker, which then launch their own opencontainerd (one off the main CRI implementations) inside that Docker container, nested like, so no dockership/cri-dockerd is needed). Worth re-noting that Podman includes tools to try to run Kubernetes pods directly, without running the rest of Kubernetes. [1] https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/ https://kubernetes.io/blog/2016/12/container-runtime-interfa... [2] https://github.com/kubernetes/cri-api https://github.com/kubernetes/cri-api [3] https://kind.sigs.k8s.io/ https://kind.sigs.k8s.io/ [4] https://kubernetes.io/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/ https://kubernetes.io/blog/2022/01/07/kubernetes-is-moving-o... [5] https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/ https://www.mirantis.com/blog/mirantis-to-take-over-support-... [6] https://github.com/Mirantis/cri-dockerd https://github.com/Mirantis/cri-dockerd
qbasic_forever 5y ago
Kubernetes needs a container runtime, of which docker is a supported type (but deprecated and replaced with containerd for most users): https://kubernetes.io/docs/setup/production-environment/container-runtimes/ https://kubernetes.io/docs/setup/production-environment/cont...
spicyusername 5y ago
Most modern Kubernetes implementations use either containerd or cri-o.

spion 5y ago

I think OP meant Rancher Desktop, which is meant to be a replacement of sorts for Docker Desktop (it does include a Kubernetes implementation though)

Kaytaro 5y ago

> Podman was developed by Red Hat Wow they should advertise that more. I had no idea and I'm pretty deep in the Red Hat ecosystem.

spydum 5y ago
Pretty sure they will once it's a bit more stable. They have presented at most of the kubecons for several years but it's always cautioned they will potentially break stuff.
gbraad 5y ago
Why should they? I work for Red Hat, help and contribute to podman but they like to remain as 'independent' as possible. We collaborate but the preference is that Podman is an upstream/community project first.