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.

> 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.

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.

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.

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)

Does Kubernetes usage also require podman or docker?

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/cont...

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-interfa...

[2] https://github.com/kubernetes/cri-api

[3] https://kind.sigs.k8s.io/

[4] https://kubernetes.io/blog/2022/01/07/kubernetes-is-moving-o...

[5] https://www.mirantis.com/blog/mirantis-to-take-over-support-...

[6] https://github.com/Mirantis/cri-dockerd

Most modern Kubernetes implementations use either containerd or cri-o.

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.

Podman is only used for bootstrapping the cluster with the OpenShift installer. The cluster itself uses cri-o.

OpenShift uses cri-o as the runtime.

Kubernetes can use either

my understanding was that it was docker that doesnt need root or a daemon.

i always thought it seemed wrong that it needed either of those to start with.

in most other respects i think it's a drop in replacement.

What you said is true. Other than those podman:

- does not mess with your iptables unlike docker. Because of this docker can bypass firewall rules set by ufw

- does not creates bridged networks

If you use K8s or some other production container runtime, those are enormous benefits.

From a security perspective, a daemon is a nightmare. It makes so much more sense to inherit the permissions from the process it’s launched from, and as such I’m a big proponent of podman (or rkt in a distant past).

there is more to it.

If you are running kubernetes there are k8s daemons already possibly CRI-O containerd Otherwise the pod is started by systemd, which is another daemon

A Started from the command line using podman, is not a production pattern

Correct. We are not allowed any command line access to worker nodes or containers. If it isn't deployed using automation, it isn't deployed.

It depends on what you’re looking for. Most people use containerd as their backend to Kubernetes. Docker itself uses it. Podman uses a different engine. That may matter to some folks.

There are also a bunch of tools that talk directly to the docker socket.

There are a lot of varying use cases here.

Disclaimer, I started Rancher Desktop.

I think the most surprising coming from docker was that containerd can’t build images, just run them, thus nerdctl and things plus other userspace ways of building images too.. so many options..

Totally makes sense when you understand more but initial is surprising.

Podman can also be optionally be run as a system daemon that provides a docker socket, but still has/used to have quite a bit of compatibility isues.

It also has a couple of other handy features:

1. It can form up k8s-style pods for deploying tightly-coupled containers. 2. It can understand k8s YAML for deployment (although obviously it doesn't support everything k8s does), which makes it easier to do deployment config that will work locally with podman and then in a k8s deployment.

Docker can do 1. as well. Either via compose (network-mode: service:) or cli (--net=container).

you can also run static k8s pods with docker by just running the k8s kubelet which will watch /etc/kubernetes/manifests

Docker the CLI tool is made of a bunch of opensource components that Docker the company put under an opensource organization called moby: https://mobyproject.org/projects/

Poke around the different moby components like runc, containerd, buildkit, etc. and you'll start to see how they all form part of docker the CLI tool. For example runc runs a container image, and containerd is a service that can run and manage multiple containers at once (each using runc to run). Buildkit is a tool for building container images. All of these tools assume you're on a linux host, but there are tools like linuxkit, hyperkit to make linux VMs for mac and windows hosts that can then run all the other tools.

Tools like podman, rancher desktop, docker, etc. all more or less use those components and compose them in different ways or with different tweaks to support their view of a container workflow.

A bit part of it are the companies behind it. Docker is the original from the Docker company. Podman is an open source clone pushed by RH that has the advantage of not needing root access, but some apps that expect genuine Docker fail. Rancher is a simple Kubernetes implementation. LXC for a similar but different world.