containerd vs Jenkins

Yes. It is an open-source CNCF graduated project with no licence fee.

When the build needs something hosted runners cannot give you: physical hardware, an air-gapped network, a node-locked commercial tool licence, or an unusual platform. If none of those apply, hosted CI is usually less work to own.

You already have it. Docker uses containerd underneath to run containers; it is not an alternative you install separately.

Not in the open source distribution, which runs a single active controller. High availability and active-active controllers are features of CloudBees' commercial products. Open source deployments mitigate it with fast restores and, sometimes, multiple independent controllers.

Kubernetes talks to runtimes through the Container Runtime Interface. Docker did not speak CRI natively and needed a shim, so Kubernetes removed the shim and talks to containerd directly, which Docker was already using anyway.

This is the main operational risk. Many plugins have a single volunteer maintainer, and Jenkins publishes security advisories for unmaintained plugins where no fix exists. Auditing which plugins you depend on and who maintains them should be a periodic task, not a one-off.

No. Image building is deliberately out of scope. Tools such as Buildah, BuildKit or Docker handle that.

For declarative pipelines you can go a long way without it. Anything involving shared libraries, conditional logic or custom steps is Groovy, and it runs in a sandboxed, transformed environment where standard Groovy idioms sometimes behave unexpectedly.

The software is free under the MIT licence. The cost is infrastructure and staff time to run controllers, agents and upgrades, plus a CloudBees subscription if you want high availability, support or centralised management of many controllers.