"OS running like a VM" is a wrong summary. Containers are collection of namespaces. Docker manages (starts , stops etc) these containers. It also provides an easy gateway into readymade container images.
If you're a programmer, you most probably have heard about OSes and VMs before, one way or another. Then, the analogy is a bit easier for the beginner to understand. Hence the "slightly wrong but somehow still manages to be a bit informative"-summary Waterluvian gave can teach the beginner the first steps.
Maybe it's just me. I love teaching and learning by starting with a common but wrong model and learning piece by piece what's different until its an evolved, more accurate model.
Truly understanding the Linux kernel namespacing features that Docker is built on certainly takes more effort to learn, but I disagree that it's irrelevant to anyone not working at Docker. Understanding your tools makes you a better developer, and allows you to understand what is and isn't possible.
I think it is a fair summary, because the implications of running in Docker are often the same as running a real VM.
To exemplify, a common mistake is to run a server as the entrypoint of the docker container. The server will then run as PID 1, with all the implications and responsibilities an init process has. This causes a lot of subtile and annoying problems.
Unless you are writing kernel drivers or you need to tweak certain kernel parameters, running in a Docker container is very much as running in a VM. With the same responsibilities, e.g., setting up an init process.
Not really, no. Software in a container directly talks to the kernel of the host using the normal APIs the kernel provides. A container does not contain a kernel!
Running an Ubuntu user land on top of some generic other Linux kernel will for almost all practical purposes feel the same as running real Ubuntu.
That kernel is what is shared between different containers. You can have 5 copies of Ubuntu (or Debian, or Mint) in separate containers, but they're all using the same kernel. This is what makes containers much more efficient than multiple full VMs.
They are just applications running on top of the very same kernel you would run any application from.
The kernel just provides enough layers of separation on the necessary structures.
There's plenty of material on it; if interested I'd suggest to start to study by kernel namespaces as @mav3rik pointed out.