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

61–70 of 110 posts

Re: Kubernetes V1 Released

#61

Post by TheIronYuppie »

teraflop wrote: post #53
TheIronYuppie wrote: post #44

Earlier quoted context omitted.

I definitely don't want this to come off as a sales pitch, but you can get started in one click using Google Container Engine (and $300 in free credit) as well. Full disclosure: I work at Google on Kubernetes

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

Re: Kubernetes V1 Released

#62

Post by alex-mohr »

gtaylor wrote: post #51
TheIronYuppie wrote: post #44

Earlier quoted context omitted.

I definitely don't want this to come off as a sales pitch, but you can get started in one click using Google Container Engine (and $300 in free credit) as well. Full disclosure: I work at Google on Kubernetes

We were looking at this, but noticed that you have to one run cluster per availability zone. Any plans for being able to run a cluster across an entire region within GCE?

Yes, we've heard from a number of people who want that and will improve regional support.

Current ideas are either a single regional cluster or via federation of multiple zonal clusters.

See eg https://github.com/GoogleCloudPlatform/kubernetes/blob/maste... for an proposal on the latter.

Re: Kubernetes V1 Released

#63

Post by presspot »

ninkendo wrote: post #42
mml wrote: post #19

Earlier quoted context omitted.

Kubernetes can run on Mesos as a Mesos service. Thereby giving you a more opinionated layout for your compute cluster, while running other peer Mesos services, such as Hadoop, Chronos And Marathon. https://github.com/GoogleCloudPlatform/kubernetes/blob/maste...

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…

>>> Mesos is more of an SDK than anything, giving you the tools to write an orchestration system

This is why Mesosphere built their DCOS; it recognizes that Mesos is a sharp-edged distributed systems kernel and needs to be packaged with convenience layers like Marathon and Chronos and "userland" tools (CLI, graphical UI, packaging system, etc) that make it a complete OS.

Re: Kubernetes V1 Released

#64

Post by andybak »

pestaa wrote: post #59
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.

Or they assume your wallet is already open.

Then they are wrong.

I actually find this a common issue with a presumed sales pipeline I encounter.

They think:

1. He finds us. 2. He's interested and signs up for a trial 3. We hopefully convert before the trial is over

What actually tends to happen

1. I find something that looks interesting 2. I sign up 3. Real work intervenes 4. Several months later I have some time to look again but my trial has expired.

To be fair most companies respond to a quick email but they could be proactive and do the following:

1. If no activity is detected after the first day pause the trial 2. Some time later send an email saying "We've paused your trial. Please choose either: 1. to reactivate it, 2. be reminded in another x weeks or 3. never hear from us again.

Re: Kubernetes V1 Released

#65

Post by bkeroack »

davidooo wrote: post #58
bkeroack wrote: post #39

Earlier quoted context omitted.

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'…

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.

Re: Kubernetes V1 Released

#66

Post by kiyoto »

WestCoastJustin wrote: post #8
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.

At their most basic level, Kubernetes [1] and Mesos [2] both use a client/server type architecture, where you install a client on many compute nodes, then the server part farms out jobs (in the form of containers) to these client compute nodes. Mesos does not do scheduling, and is pretty low-level in terms of interfaces, so you would typically run some type of software which talks to it via API, like Marathon [3], Au…

>- logging/monitoring/alerting

As a maintainer of Fluentd [1], an open source log collector now integrated with Kubernetes [2] and Docker [3], happy to see this out =)

[1] https://www.fluentd.org [2] http://blog.raintown.org/2014/11/logging-kubernetes-pods-usi... [3] http://blog.treasuredata.com/blog/2015/07/07/collecting-dock...

Re: Kubernetes V1 Released

#67

Post by presspot »

DannoHung wrote: post #12
WestCoastJustin wrote: post #8

Earlier quoted context omitted.

At their most basic level, Kubernetes [1] and Mesos [2] both use a client/server type architecture, where you install a client on many compute nodes, then the server part farms out jobs (in the form of containers) to these client compute nodes. Mesos does not do scheduling, and is pretty low-level in terms of interfaces, so you would typically run some type of software which talks to it via API, like Marathon [3], Au…

One small correction: Mesos is a scheduler. It doesn't natively ship with any end-user framework to access the scheduling though (you are supposed to write your own framework which uses the Mesos API). Marathon is a generic end-user framework for accessing those functions and runs on top of Mesos. I think it's also interesting to note that Mesos can be used as the Kubernetes minion scheduler backend. And for very lar…

In the parlance of Mesos, the Mesos kernel is an "allocator" (in that it assembles and allocates all of the compute resources) and the frameworks are the "schedulers" in that they request and consume "resource offers" (made by the allocator) and then schedule tasks to be run on those accepted resources.

Re: Kubernetes V1 Released

#68

Post by rsync »

WestCoastJustin wrote: post #8
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.

At their most basic level, Kubernetes [1] and Mesos [2] both use a client/server type architecture, where you install a client on many compute nodes, then the server part farms out jobs (in the form of containers) to these client compute nodes. Mesos does not do scheduling, and is pretty low-level in terms of interfaces, so you would typically run some type of software which talks to it via API, like Marathon [3], Au…

"you have more work than can fit into one server"

Many, many people believe this is true for them.

Most of them are wrong.

Re: Kubernetes V1 Released

#69

Post by davidooo »

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.

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 specify resource requirements of the container. The resource requirements of the Pod are computed by adding up the resource requirements of the containers that run within the Pod.

In addition to resource-based scheduling, we also support "label selectors" which allows you to label nodes with key/value pairs and then say that a Pod should only run on nodes with particular labels. That's specified in the NodeSelector field of the PodSpec (which you linked to).

Re: Kubernetes V1 Released

#70

Post by [deleted] »

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.

[deleted]
Post reply on HN