There is nothing extraordinary, profound or even innovative in so-called Containerization, Orchestration and other silly memes.
It is a way to tightly pack applications into a data-center to extract more "value" from hardware, or simply put - to make more money by selling slices of servers with per-hour basis.
All other blah-blah about benefits of containers is nonsense. The more complex system you make, the more inefficient and fault-prone it becomes, compared to running the same service on a dedicated hardware.
The reasoning is quite simple. Suppose you have some Java pile of crap, which is, basically, a java.exe process which uses sockets for communication and, probably, some remote storage, which is also communicated via IP protocol. This kind of crappy app could be run in a chroot-based environment under some hypervisor. So, one isolates it into a "container" which is could be think of as a FS snapshot. You could isolate a Rails app, for sure, or some REST-ful service at a cost of losing I/O efficiency - basically, you are running in an emulator with para-virtualization (Xen, KVM+qemu).
This exactly what FreeBSD Jails has been designed for. The ideas came from IBM Mainframes.
Docker gives you way to describe in a declarative way (which is good) your images. Kubernets is a cluster management. It is all clever and saturated with a lots of sophisticated blah-blah full of long words, so the crowd is very excited.
But this does not solve any fundamental problems, it just squeezes a few more profit-driven middle-men between your code and hardware. The claims that it eliminates the costs of system administration is nonsense. Unless you are running a guest-book with a few html-forms Rails example, everything will become even more messy. Think what would happen when a some replications (Redis or MySQL or whatever) will fail. Or, my favorite example, your java.exe crashes, leaving your data in inconsistent state and cause a data lose.
But, of course, all this it is very cool. Especially to isolate these Apache Spark nodes, which are utilizing literally hundreds of thousands of lines of code, consuming gigabytes of memory to hold mutable, locked data to perform map-reduce operations on read-only, pre-sorted, partitioned data, which could be done in a few thousand of lines of Erlang or Common Lisp or even Scheme.