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 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.
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.
Think of it like a tar of a chroot, although that is an oversimplification.
Containers are not an adequate security boundary for untrusted workloads to assume they leave the host unchanged.
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.