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

Kubernetes V1 Released

googlecloudplatform.blogspot.com

Post reply on HN
Print view View original

71–80 of 110 posts

Re: Kubernetes V1 Released

#71

Post by bkeroack »

davidooo wrote: post #69
bkeroack wrote: post #65

Earlier quoted context omitted.

Nowhere in the pod spec is there a way to specify resource constraints or even hints ( https://github.com/GoogleCloudPlatform/kubernetes/blob/maste... ). So even if the scheduler is vaguely resource-aware (I'm not convinced that's true) it would be entirely static, based on things like container count.

Currently resource requirements are specified only on containers, not Pods. The requirements for the Pod are computed by adding up the requirements of the containers within the Pod. To be more concrete: Within the PodSpec type that you linked to, there is a field of type []Container. Within the Container type there is a field called Resources which is of type ResourceRequirements. ResourceRequirements lets you specif…

Fair enough! :) I overlooked that aspect of the Container type, obviously.

Re: Kubernetes V1 Released

#72

Post by bcbroussard »

bkeroack wrote: post #65
davidooo wrote: post #58

Earlier quoted context omitted.

The Kubernetes scheduler also does resource-aware scheduling. You're correct that it tries to spread replicas across nodes, but it only spreads them across the nodes that have enough free resources for the container (more precisely, Pod) that it's scheduling.

Nowhere in the pod spec is there a way to specify resource constraints or even hints ( https://github.com/GoogleCloudPlatform/kubernetes/blob/maste... ). So even if the scheduler is vaguely resource-aware (I'm not convinced that's true) it would be entirely static, based on things like container count.

Here's the doc for resource constraints, called "limits" in Kubernetes. https://github.com/GoogleCloudPlatform/kubernetes/blob/maste...

The Kubernetes scheduler looks at "fit" and "resource availability" to determine the node a pod will run on. Nodes can also have labels like "high-mem" or "ssd", so you can request a particular type of server (via the the nodeSelector field). More details are in the link above.

Re: Kubernetes V1 Released

#73

Post by teraflop »

TheIronYuppie wrote: post #61
teraflop wrote: post #53

Earlier quoted context omitted.

Except: "Sorry, you aren't eligible for a free trial at this time. The free trial is for new customers only." Apparently, the fact that I've been curious enough to experiment with other Google developer products in the past means I'm not part of the target audience.

Sorry about that! Free trials have a timeout :( Can you submit a support request and we'll see what we can do? Also, spinning up a cluster should be incredibly cheap if you just want to mess around for a little bit - we do billing by the minute :) Full disclosure: I work on Google on Kubernetes

Yeah, sorry if that came off as snarky; I appreciate the suggestion.

I guess I can understand the cost-cutting mentality that drives Google, AWS, etc. to limit these kinds of offers to "new customers" only. Just remember to consider what kind of incentives you're creating. By effectively punishing developers for being early adopters/experimenters, you're making them wary of signing up early for whatever new and interesting stuff you announce in the future.

Re: Kubernetes V1 Released

#74

Post by merb »

bkeroack wrote: post #39
StevePerkins wrote: post #3

Can anyone recommend a good "Consultant's", "Solutions Architect's", or "Top-Right Quadrant on a Silly Gardner Chart" overview of how Kubernetes competes or cooperates with Mesos? It feels like there's quite a bit of dense conceptual reading you have to plow through before you can even start to talk about what these things do.

To add to the others, in a nutshell: - Mesos is a generalized, low level framework for distributing workloads over multiple nodes. It provides mechanism not policy. Therefore it requires quite a bit of up-front work to build something usable for any given application. - Kubernetes is an opinionated cluster execution tool. It provides tools and a curated workflow for running distributed containerized applications. It'…

What you forgot is that it's not only easy to get started, you could also start REALLY REALLY small which doesn't work with ALL the other solutions. Kubernetes Master could run on a node with 512mb memory and it still works great. Your cluster doesn't die if the master dies it won't reschedule etc but thats ok mostly. the only thing what you need is enough etcd nodes to keep it up and running.

Re: Kubernetes V1 Released

#75

Post by merb »

TheIronYuppie wrote: post #47
throwaway1979 wrote: post #22

Earlier quoted context omitted.

I've been playing with Swarm and like what I've seen so far. WRT Kubernetes, on a platform other than GCE, is Flannel required for networking?

Networking on AWS works fine with no additional networking as well. Overlay networking is not required if you're running within a bunch of nodes that can see each other. Only if you get more complex will you require something, and there are quite a few solutions (Flannel, Weave, Calico, etc) Full disclosure: I work at Google on Kubernetes

But most of them suck, and they suck even more when you configured them badly (badly in terms of you used an option which comes by default). However with the bigger vxlan adoption most performance issues are fixed, still, could have some improvmenents. I also think that IPv6 could fix a lot of these things...

Re: Kubernetes V1 Released

#76

Post by smegel »

> containers scheduled That seems awfully slow for a fancy chroot. I use KVM to bring up WinXP snapshot VMs in around 2s to a running state...maybe they mean 5ms?

Re: Kubernetes V1 Released

#77

Post by davidooo »

bcbroussard wrote: post #72
bkeroack wrote: post #65

Earlier quoted context omitted.

Nowhere in the pod spec is there a way to specify resource constraints or even hints ( https://github.com/GoogleCloudPlatform/kubernetes/blob/maste... ). So even if the scheduler is vaguely resource-aware (I'm not convinced that's true) it would be entirely static, based on things like container count.

Here's the doc for resource constraints, called "limits" in Kubernetes. https://github.com/GoogleCloudPlatform/kubernetes/blob/maste... The Kubernetes scheduler looks at "fit" and "resource availability" to determine the node a pod will run on. Nodes can also have labels like "high-mem" or "ssd", so you can request a particular type of server (via the the nodeSelector field). More details are in the link above.

The page you linked to describes a slightly different feature, namely the ability to restrict and override the resource requirements of Pods at the time they are submitted to the system. So it's part of the admission control system, not part of the scheduling.

The documentation on resource-based scheduling is at https://github.com/GoogleCloudPlatform/kubernetes/blob/maste...

Re: Kubernetes V1 Released

#78

Post by davidooo »

nzoschke wrote: post #55
puja108 wrote: post #9

Earlier quoted context omitted.

ManagedVMs don't use k8s under the covers afaik. However there's GKE (Google Container Engine), which goes on top of (at least 3) MVMs and that one does use k8s. While it is true that going with a PaaS(-like) solution like AppEngine or Heroku is easy in the beginning it can get pretty expensive pretty fast and it limits you in the choice of languages, frameworks, and data stores you can use. This can in some instance…

In the Container-as-a-Service there's also EC2 Container Service (ECS). AWS just did a nice technical deep dive on how their orchestration works: http://www.allthingsdistributed.com/2015/07/under-the-hood-o...

There's also a hosted version of Kubernetes, called Google Container Engine: https://cloud.google.com/container-engine/

Re: Kubernetes V1 Released

#79

Post by SEJeff »

bkeroack wrote: post #39
StevePerkins wrote: post #3

Can anyone recommend a good "Consultant's", "Solutions Architect's", or "Top-Right Quadrant on a Silly Gardner Chart" overview of how Kubernetes competes or cooperates with Mesos? It feels like there's quite a bit of dense conceptual reading you have to plow through before you can even start to talk about what these things do.

To add to the others, in a nutshell: - Mesos is a generalized, low level framework for distributing workloads over multiple nodes. It provides mechanism not policy. Therefore it requires quite a bit of up-front work to build something usable for any given application. - Kubernetes is an opinionated cluster execution tool. It provides tools and a curated workflow for running distributed containerized applications. It'…

Mesosphere is a company, not a piece of software. I think you're referring to Mesosphere's dcos[1].

DCOS is some really nice packaging for marathon, chronos, etc, with a nice cli tool for downloading and installing new frameworks onto mesos. Personally, I find using Aurora a lot nicer.

That being said, I do think the kubernetes-mesos gives you far and above the best of both worlds. You get the developer story of kubernetes, with the ops story of mesos.

From an ops perspective, k8s is a bit clunky. I was actually shocked when I found out after bringing a new kubelet (worker node) online, you have to also update a service on the master. This was in a power training class on Kubernetes at this year's Redhat Summit in Boston. Really underwhelmed with the complexity of k8s compared to mesos, but they aren't an apples to apples comparison.

[1] https://mesosphere.com/product/

Re: Kubernetes V1 Released

#80

Post by SEJeff »

tlrobinson wrote: post #50
ninkendo wrote: post #42

Earlier quoted context omitted.

I'm afraid answers like this actually make the confusion problem worse (nothing against your comment, just an observation in general.) If you're confused about the differences between similar-sounding products X and Y, the fact that "X runs on Y" or "Y supports X" has never made the situation any better, it only makes the line between X and Y even more blurred. I think this is especially true of Mesos, because people…

"X runs on Y" at least implies Y is "lower level" than X. As I understand it, Mesos is analogous to an operating system kernel for your cluster, while Kubernetes is a CaaS (containers-as-a-service) layer on top.

This, this so much. You just nailed it.
Post reply on HN