Kubernetes: The Future of Deployment • Hacker News Board

Re: Kubernetes: The Future of Deployment

#21

Post by fixermark » Wed, Jun 03, 2015, 5:27 PM UTC

irickt wrote: post #4

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 is also related to the source of the word "cybernetics".

Correct, which is how it slants to the "Borg cube" pun. Cybernetics was the term chosen by Norbert Wiener in the book "Cybernetics," and he traced the word's origin to the greek "kubernetes;" it related to his first example of a cybernetic system, the self-correcting steam-controlled rudder on a ship [http://en.wikipedia.org/wiki/Steering_engine].

(Why the pun? Kubernetes was heavily inspired / guided by Google's internal scheduling tool, which was named Borg (http://blog.kubernetes.io/2015/04/borg-predecessor-to-kubern...).)

Re: Kubernetes: The Future of Deployment

#22

Post by sciurus » Wed, Jun 03, 2015, 5:45 PM UTC

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…

This may not be the level of specificity that you're looking for, but http://research.google.com/pubs/pub43438.html and http://research.google.com/pubs/pub41684.html are what I know google has published about their cluster management systems.

Re: Kubernetes: The Future of Deployment

#23

Post by falcolas » Wed, Jun 03, 2015, 5:46 PM UTC

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/GoogleCloudPlatform/kubernetes/blob/maste...

[2] https://github.com/GoogleCloudPlatform/kubernetes/blob/maste...

Re: Kubernetes: The Future of Deployment

#24

Post by josephjacks » Wed, Jun 03, 2015, 5:48 PM UTC

jaytaylor wrote: post #8

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…

Thanks for sharing all that terrific information! The only thing I'll add is that k8s isn't targeting the same scale as Mesos. Their current goal is to support up to 400-500 nodes, max. Source: One of the core k8s developers I met at a CoreOS meetup in SF earlier this year. They said if I needed to go beyond 500 nodes that I should probably look at something else.

This is categorically incorrect. K8S will ultimately scale to N number of nodes. Within 2015, it will scale to 1K+ nodes, as per the roadmap. Being modeled after Google's Borg system, I encourage curious/interested folks to read at the recent Borg paper [0] which also outlines lessons learned in running Borg at Google for nearly 15 years and managing many millions of machines.

[0] http://research.google.com/pubs/pub43438.html

Disclaimer: I work for Kismatic.

Re: Kubernetes: The Future of Deployment

#25

Post by wyc » Wed, Jun 03, 2015, 5:56 PM UTC

falcolas wrote: post #23

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…

Agreed. I have more specifics of Google-centralism in my comment here:

https://news.ycombinator.com/item?id=9330049

Re: Kubernetes: The Future of Deployment

#26

Post by josephjacks » Wed, Jun 03, 2015, 6:03 PM UTC

falcolas wrote: post #23

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…

I see Docker 1.6 in your [2] link, where do you see they are two versions behind Docker?

Re: Kubernetes: The Future of Deployment

#27

Post by sunyc » Wed, Jun 03, 2015, 6:13 PM UTC

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.

Re: Kubernetes: The Future of Deployment

#28

Post by dordoka » Wed, Jun 03, 2015, 6:16 PM UTC

josephjacks wrote: post #26

falcolas wrote: post #23

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…

I see Docker 1.6 in your [2] link, where do you see they are two versions behind Docker?

Current is Docker 1.6.2, released about 20 days ago. There also was a 1.6.1. That makes it two versions. Also, v1.6.0 was released almost two months ago. [0]

[0] https://github.com/docker/docker/blob/master/CHANGELOG.md

Re: Kubernetes: The Future of Deployment

#29

Post by josephjacks » Wed, Jun 03, 2015, 6:24 PM UTC

dordoka wrote: post #28

josephjacks wrote: post #26

Earlier quoted context omitted.

I see Docker 1.6 in your [2] link, where do you see they are two versions behind Docker?

Current is Docker 1.6.2, released about 20 days ago. There also was a 1.6.1. That makes it two versions. Also, v1.6.0 was released almost two months ago. [0] [0] https://github.com/docker/docker/blob/master/CHANGELOG.md

Understood, I was referring to major point releases vs minor. Thanks for clarifying.

Re: Kubernetes: The Future of Deployment

#30

Post by xorcist » Wed, Jun 03, 2015, 6:35 PM UTC

falcolas wrote: post #23

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.