Yes, this is a real problem. As discussed with regard to Mesos, having multiple applications/frameworks sharing the same cluster resources can be very important in today's world where nearly all applications at a company like Google need to run on a scale that requires large numbers of nodes.
The main idea is to run each application within a container, which are grouped together into pods (which are scheduled together on the same machine) to enable e.g. local resource sharing. Developers can also use labels to group pods/containers into subsets of an application, e.g. different builds, different jobs, etc. This model allows applications to be scheduled and run independently of each other (even if they may be on the same machine) while also giving developers flexibility to control colocation when desirable.
This isn't that different from previous work, and seems mainly an evolution of previous systems. Containers like Docker provide some of the same ideas, and Google's previous system, Borg, seems to have very similar ideas in a less configurable and flexible manner.
There will always be a trade-off in terms of complexity of the containering system (e.g. how much protection it provides) and how much overhead it causes. Google's blog post does not make it clear what kind of overhead Kubernetes imposes, so it is difficult to gauge where it falls on the spectrum.
I am tempted to say that it might be influential in 10 years only for the fact that is a large project coming out of Google that is being open sourced, and Google has enough clout that generally large software projects it throws resources behind do well. It will remain to see, however, if Kubernetes will gain traction when Mesos and YARN already integrate nicely with the hugely popular Hadoop ecosystem and provide some similar features, though Kubernetes does seem to provide some higher level constructs which may be useful.
No comments:
Post a Comment