Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kubernetes: The Future of Deployment

bashton.com

Post reply on HN
Print view View original

11–20 of 80 posts

Re: Kubernetes: The Future of Deployment

#11

Post by rco8786 »

SEJeff wrote: post #5
lobster_johnson wrote: post #2

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.

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…

> mesos and apache aurora

ohh i bet we're in the same building right now

Re: Kubernetes: The Future of Deployment

#12

Post by philip1209 »

NotOscarWilde wrote: post #6

A slightly off-topic comment, but being an early-stage PhD in theoretical CS with my thesis topic on approximation algorithms for scheduling, I would like to know whether there are some theoretical problems related to these VM schedulers used in practice. If there is somebody knowledgeable about what is theoretically open (unknown tight approximation ratio, for instance) AND very useful to people building Kubernetes…

It was more of an amusement, but I used integer programming at a company hackathon to build a better image scheduler:

https://engineering.opendns.com/2015/05/06/docker-container-...

With a large, fairly homogenous environment it didn't outperform random assignment that well, though. It worked best with small, inhomogeneous loads.

Re: Kubernetes: The Future of Deployment

#13

Post by lobster_johnson »

SEJeff wrote: post #5
lobster_johnson wrote: post #2

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.

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 complexity. You need to run ZooKeeper, the master, the slaves, and then each framework. Only Mesos itself is written in C++, everything else is JVM, which is a pretty significant memory hog. By installing Mesos you just increased the complexity of the deployment/ops stack by a huge margin; you reap many benefits, of course, but Mesos is a lot more opaque and complex than a few daemons and some SSH-based scripts.

Re: Kubernetes: The Future of Deployment

#14

Post by lobster_johnson »

SEJeff wrote: post #5
lobster_johnson wrote: post #2

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.

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 complexity. You need to run ZooKeeper, the master, the slaves, and then each framework. Only Mesos itself is written in C++, everything else is JVM, which is a pretty significant memory hog. (Kubernetes, by comparison, is written in Go and would presumably be more lightweight; its only dependencies are etcd and Docker.) By installing Mesos you just increased the complexity of the deployment/ops stack by a huge margin; you reap many benefits, of course, but Mesos is a lot more opaque and complex than a few daemons and some SSH-based scripts.

Re: Kubernetes: The Future of Deployment

#15

Post by mmccaff »

iyn wrote: post #9
SEJeff wrote: 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…

Can you suggest best resources (text/video) for learning about Kubernetes & Mesos? I use Docker & CoreOS all the time (love it) and I'm always trying to improve/learn something new. Can you tell how do you use Apache Aurora? What other interesting projects are worth learning about?

I recently spent some time playing with Mesos, Marathon (the web ui + api for scheduling long-running jobs / services) and Chronos (the web ui + api for scheduling cron / batch jobs).

I did this on my Macbook, using Virtualbox, Vagrant, and this:

https://github.com/mesosphere/playa-mesos

^ I started with that, and then installed Chronos with apt-get in addition.

Specifically, for launching Docker containers, this was useful:

https://docs.mesosphere.com/tutorials/launch-docker-containe...

I didn't try Aurora but it seems it'd be an alternative to Marathon + Chronos (Mesos calls all of these "frameworks").

Re: Kubernetes: The Future of Deployment

#16

Post by thebeardisred »

dchuk wrote: 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?

It means "Helmsman" in ancient Greek. Similarly it's related to the word "Governor"

e.g: "kubernan" in ancient greek means to steer "kubernetes" is helmsman

"gubernare" means to steer or to govern in Latin "gubernator" is "governor" in Latin

Which then leads into the modern word "Gubernatorial", et al.

Re: Kubernetes: The Future of Deployment

#17

Post by seanp2k2 »

philip1209 wrote: post #12
NotOscarWilde wrote: post #6

A slightly off-topic comment, but being an early-stage PhD in theoretical CS with my thesis topic on approximation algorithms for scheduling, I would like to know whether there are some theoretical problems related to these VM schedulers used in practice. If there is somebody knowledgeable about what is theoretically open (unknown tight approximation ratio, for instance) AND very useful to people building Kubernetes…

It was more of an amusement, but I used integer programming at a company hackathon to build a better image scheduler: https://engineering.opendns.com/2015/05/06/docker-container-... With a large, fairly homogenous environment it didn't outperform random assignment that well, though. It worked best with small, inhomogeneous loads.

Interesting, I didn't know "inhomogeneous" was a word: http://english.stackexchange.com/questions/194906/heterogene...

Re: Kubernetes: The Future of Deployment

#19

Post by NotOscarWilde »

philip1209 wrote: post #12
NotOscarWilde wrote: post #6

A slightly off-topic comment, but being an early-stage PhD in theoretical CS with my thesis topic on approximation algorithms for scheduling, I would like to know whether there are some theoretical problems related to these VM schedulers used in practice. If there is somebody knowledgeable about what is theoretically open (unknown tight approximation ratio, for instance) AND very useful to people building Kubernetes…

It was more of an amusement, but I used integer programming at a company hackathon to build a better image scheduler: https://engineering.opendns.com/2015/05/06/docker-container-... With a large, fairly homogenous environment it didn't outperform random assignment that well, though. It worked best with small, inhomogeneous loads.

Right, ILP is a great tool for solving NP-complete problems relatively fast (depending on the solver, but there are some very good ones out there). However, as a theoretical tool it probably is not that exciting unless you're ready to tackle P vs. NP this way. (Unless you move to semidefinite programming and the SDP hierarchies, where the progress is very exciting but not yet that applicable to scheduling, to the best of my knowledge.)

> With a large, fairly homogenous environment it didn't outperform random assignment that well, though. It worked best with small, inhomogeneous loads.

Yes, that's probably a piece of the puzzle that I don't have yet -- to know a theoretical model that is both useful in practice and at the same time greedy/randomized assignment is not "good enough" for practical uses.

Re: Kubernetes: The Future of Deployment

#20

Post by henrikschroder »

thebeardisred wrote: post #16
dchuk wrote: 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?

It means "Helmsman" in ancient Greek. Similarly it's related to the word "Governor" e.g: "kubernan" in ancient greek means to steer "kubernetes" is helmsman "gubernare" means to steer or to govern in Latin "gubernator" is "governor" in Latin Which then leads into the modern word "Gubernatorial", et al.

It's also a pun on Borg Cubes.
Post reply on HN