Live data from Hacker News

Kubernetes: The Future of Deployment

bashton.com

31–40 of 80 posts

Re: Kubernetes: The Future of Deployment

#31

I'd love for someone to explain how Kubernetes compares to Mesos. Every article I find on the subject says they are mutually beneficial, not competitors — that you would typically run Kubernetes as a Mesos framework — yet Kubernetes also seems like it duplicates much of Mesos' functionality on its own.

They are competitors, but life isn't simple. The reality is many frameworks currently only run on Mesos or YARN, and Kubernetes has not reached V1, so larger installations typically need multiple frameworks. Mesos is a proven way to run multiple frameworks side-by-side. Ebay's YARN on Mesos is another example. But where this all leads remains to be seen.

Re: Kubernetes: The Future of Deployment

#32
post #27

bundling with (unholy-ly immature) SDN is the most damning things for its adoption. It is thought to be needed for "live migration", but I don't see me needing that anytime soon because we run on virtual machines anyway? Iaas provider is not going away,paying for the cost of SDN now for features that doesn't even exists yet, is insane.

(kubernetes contributor here)

SDN isn't required for k8s, what is required is that each Pod (group of containers) get it's own IP address, and that the IP address is routeable in the cluster. In many cases, the easiest way to achieve this is via an SDN, but it is also achievable by programming traditional routers.

The reason for wanting an IP address per pod is that it eliminates the need for port mangling, which dramatically simplifies wiring applications together.

Re: Kubernetes: The Future of Deployment

#33
post #3

What's the deal with the name "Kubernetes"? Does it mean anything, or have some tech significance, or is it really just because it basically means "ruler" in Greek?

According to the IO 2014 talk about docker/kubernetes, it was chosen because it means something like pilot/helmsman.

Re: Kubernetes: The Future of Deployment

#34
post #30

Worth remembering, Kubernetes was built to Google's needs, and Google runs with a shared network space on any given VM and assigns an entire /24 to the VM running docker. Each container gets one of those addresses. [1] This probably won't work for everyone - be sure to read into the fine grained details before drinking the koolade. They're also at least two build versions behind Docker.[2] [1] https://github.com/Goog…

Google runs docker in a VM? Why would you do that? I understand you might want to play with it in a lab environment, but in production at scale (especially Google-scale) sounds very strange.

Users of the Google Cloud run Docker in VMs, since VMs are what the Google Cloud Platform sells.

(as does every public cloud provider [e.g. AWS])

For now, VMs are required to ensure a security barrier between different user's containers on the same physical machine. See some of Dan Walsh's posts on the subject (e.g. https://opensource.com/business/14/9/security-for-docker) for more context.

Re: Kubernetes: The Future of Deployment

#35
post #30

Worth remembering, Kubernetes was built to Google's needs, and Google runs with a shared network space on any given VM and assigns an entire /24 to the VM running docker. Each container gets one of those addresses. [1] This probably won't work for everyone - be sure to read into the fine grained details before drinking the koolade. They're also at least two build versions behind Docker.[2] [1] https://github.com/Goog…

Google runs docker in a VM? Why would you do that? I understand you might want to play with it in a lab environment, but in production at scale (especially Google-scale) sounds very strange.

Only on their public cloud. For internal workloads, they run everything in containers. Mostly cgroups containers.

Re: Kubernetes: The Future of Deployment

#36
post #3

What's the deal with the name "Kubernetes"? Does it mean anything, or have some tech significance, or is it really just because it basically means "ruler" in Greek?

Pretty sure it's due to it meaning in a literal sense, "Helmsman".

(disclosure: i work at Google and picked the name)

comments above are right -- we wanted to stick to the nautical theme that was emerging in containers and 'kubernetes' (or helmsmen is greek) seemed about right. the fact that the word has strong roots in modern control theory was nice also.

fun fact: we actually wanted to call it 'seven' after seven-of-nine (a more attractive borg) but for obvious reasons that didn't work out. :)

Re: Kubernetes: The Future of Deployment

#37
post #5

Earlier quoted context omitted.

Kubernetes (k8s) makes for an amazing developer story. Mesos is much more bare metal, but the scheduler scales a loooot better than the still relatively immature k8s scheduling component. One of the original authors of mesos wrote a paper on scheduling: https://www.cs.berkeley.edu/~alig/papers/drf.pdf . Mesos is one of the first "two level" schedulers. I very highly recommend that you also read this article for an id…

Thanks for the explanation. Sounds like Kubernetes should work just fine for small ( I'm still not quite understanding what utility Kubernetes brings to the table if you can also use it with Mesos. If you use Mesos, why involve Kubernetes at all, and not some Mesos-specific framework like Marathon or Aurora? Is Kubernetes simply a competitor to those frameworks? My concern about Mesos is mainly footprint and complexi…

Kubernetes supports 100 nodes with ease, and we expect to handle much more than that very quickly. We just had to pick some target to start with.

Re: Kubernetes: The Future of Deployment

#39

I'd love for someone to explain how Kubernetes compares to Mesos. Every article I find on the subject says they are mutually beneficial, not competitors — that you would typically run Kubernetes as a Mesos framework — yet Kubernetes also seems like it duplicates much of Mesos' functionality on its own.

(disclaimer: i work at Google and was one of the founders of the project)

when we were looking at building k8s our mission was to help the world move forwards to a more cloud native approach to development. by cloud native i mean container packaged, dynamically scheduled, micro-services oriented. we figured that in the end our data centers are going to be well suited to run cloud native apps, since they were designed from the ground up for this approach to management, and will offer performance and efficiency advantages over the alternatives. we also however recognized that no matter how cheap, fast and reliable the hosting offering is, most folks don't want to be locked into a single provider and Google in particular. we needed to do what we were doing in the open, and the thing that we built needed to be pattern compatible with our approach to management and quite frankly address some of the mistakes we had in previous frameworks (Borg mostly as a first system).

we looked really closely at Apache Mesos and liked a lot of what we saw, but there were a couple of things that stopped us just jumping on it. (1) it was written in C++ and the containers world was moving to Go -- we knew we planned to make a sustained and considerable investment in this and knew first hand that Go was more productive (2) we wanted something incredibly simple to showcase the critical constructs (pods, labels, label selectors, replication controllers, etc) and to build it directly with the communities support and mesos was pretty large and somewhat monolithic (3) we needed what Joe Beda dubbed 'over-modularity' because we wanted a whole ecosystem to emerge, (4) we wanted 'cluster environment' to be lightweight and something you could easily turn up or turn down, kinda like a VM; the systems integrators i knew who worked with mesos felt that it was powerful but heavy and hard to setup (though i will note our friends at Mesosphere are helping to change this).

so we figured doing something simple to create a first class cluster environment for native app management, 'but this time done right' as Tim Hockin likes to say everyday.

now we really like the guys at Mesosphere and we respect the fact that Mesos runs the vast majority of existing data processing frameworks. by adding k8s on mesos you get the next-generation cloud native scheduler and the ability to run existing workloads. by running k8s by itself you get a lightweight cluster environment for running next gen cloud native apps.

-- craig

Re: Kubernetes: The Future of Deployment

#40
post #38

An interesting sidenote. The Meteor development group is contributing to Kubernetes and will be using it to help scale Meteor with their upcoming paid service Galaxy.

This is great to see independent software companies like Meteor embrace Kubernetes as the platform on which to build their next-generation services [0].

[0] http://info.meteor.com/blog/meteor-and-a-galaxy-of-container...

Post reply on HN