I'm looking for words that explain why containers are a great thing, why they are more simple than I thought, how they aren't bound to one specific operating system kernel, or something that tells me why they're good, what the upside is.

I want to hear the passionate beliefs of someone who loves them.

Without a bind mount, their state is explicitly contained. You can run one, delete it, and run it again, and know that your host system is unmodified inbetween, and that the state is coming up brand new the second time.

It's the reproducibility of a vm without the overhead of a whole 'nother OS/boot. You can keep all of the state in a single volume, and can back it up or move it to another machine and relaunch it with a minimum of fuss.

>> move it to another machine

Just any machine at all? I hear people say things like "move it to another machine" but I'm imagining a whole bunch of caveats are left out such as "move it to another machine wherein W,X,Y,Z must all be version foo and this thingy must match that thingy and in fact no you can't really move it to another machine without first replicating the underlying machines your moving from and to". You can hear my cynicism unfortunately.

A virtual machine runs a kernel on an virtualized CPU. Different CPU versions exist, but so long as they have the basic virtualization extensions, the hyperviser will be fine. From inside the VM, it looks like you own the CPU.

A container runs applications on a virtualized kernel (kinda). Different kernel version exist, but so long as they have the basic namespacing extensions, the container will be fine. From inside the container, it looks like you own the kernel.

It's like a chroot, but for everything. You have your own init, your own daemons, your own applications.

In practice, this isn't a problem. Any reasonably modern Linux kernel will do.

The container image will usually be based on a Linux distribution (so, Ubuntu if you want it, often something lightweight like Alpine). Most applications don't actually see the kernel: they see the system library (eg. glibc, musl) and it hides differences in system call versions, etc.

This is not a problem in general usage. A container will work on basically any Linux kernel.

As long as it's got the same vlans (or your sidecar container can hook it up to the appropriate service mesh/router or update a load balancer backend) then yup. The entire userspace is inside the container. The kernel version doesn't need to match, anything not ancient will be fine.

Think of it like a tar of a chroot, although that is an oversimplification.

This presumes you trust the workload in the container (which you might!).

Containers are not an adequate security boundary for untrusted workloads to assume they leave the host unchanged.