These particular storage drivers are slowly becoming a favorite for Docker installations. They are very similar to aufs but are much faster and simpler implementation. Like aufs, both overlay and overlay2 require a kernel overlay module included and loaded, which in general should be available on kernels 3.18 and higher. Also, both can run only on top of ext4 or xfs filesystems. The difference between overlay and overlay2 is that the newer version has improvements that were added in kernel 4.0 to reduce inode usage, but the older one has a longer track record in the field. If you have any doubt, overlay2 is a rock-solid choice in almost any circumstance.
If you have not worked with inodes before, note that they contain the metadata about each individual file on the filesystem and the maximum count allowed is in most cases hardcoded when the filesystem is created. While this hardcoded maximum is fine for most general usages, there are edge cases where you may run out of them, in which case the filesystem will give you errors on any new file creation even though you will have available space to store the file. If you want to learn more about these structures, you can visit http://www.linfo.org/inode.html for more information.
Both overlay and overlay2 backing storage driver have been known to cause heavy inode usage due to how they handle file copies internally. While overlay2 is advertised not to have these issues, I have personally run into inode problems numerous times, with large Docker volumes built with default inode maximums. If you ever use these drivers and notice that the disk is full with messages but you still have space on the device, check your inodes for exhaustion with df -i to ensure it is not the docker storage that is causing issues.