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

101–110 of 110 posts

Re: Kubernetes V1 Released

#101

Post by azernik »

andybak wrote: post #89
andybak wrote: post #64

Earlier quoted context omitted.

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

(this would be more readable if Markdown was less idiotic)

The problem isn't that Markdown is idiotic; the problem is that Hacker News doesn't use Markdown at all.

GitHub and Reddit have conditioned us to think that any halfway decent discussion system must use it :-P

Re: Kubernetes V1 Released

#102

Post by juliangregorian »

rsync wrote: post #68
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…

"you have more work than can fit into one server" Many, many people believe this is true for them. Most of them are wrong.

I know being the edgy you-don't-have-big-data guy is all the rage right now, but seriously? Most people can fit all of their work on one server? What kind of mom-and-pop shops are you working for?

Re: Kubernetes V1 Released

#103

Post by SEJeff »

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…

Actually that isn't entirely true. mesos-execute will run any shell command and it shows up as a framework in the framework api/ui tab on the mesos master.

Re: Kubernetes V1 Released

#104

Post by SEJeff »

bkeroack wrote: post #84
SEJeff wrote: post #79

Earlier quoted context omitted.

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

> 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 On AWS that has not been my experience. Nodes can be brought up dynamically and they register themselves with the master.

Can't speak for the cloud. When running on bare metal, in high availability mode, you need to edit the controller manager config, /etc/kubernetes/controller-manager, and update a line called KUBELET_ADDRESSES. If you don't, they won't be in the output of:

kubectl get minions

Or usable at all. Really frustrating to me.

Re: Kubernetes V1 Released

#105

Post by juliangregorian »

sarnowski wrote: post #60
gtaylor wrote: post #51

Earlier quoted context omitted.

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?

Kubernetes Cluster Federation (proposal) "Ubernetes" "Today, each Kubernetes cluster is a relatively self-contained unit, which typically runs in a single "on-premise" data centre or single availability zone of a cloud provider (Google's GCE, Amazon's AWS, etc)." https://github.com/GoogleCloudPlatform/kubernetes/blob/relea...

While cute, that name would make Kubernetes appear to be the KDE version of Ubernetes.

Re: Kubernetes V1 Released

#106

Post by nickbauman »

jacques_chester wrote: post #94
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…

I've worked on what is ostensibly a Heroku competitor (Cloud Foundry). I don't see where the limits on languages, frameworks or data stores comes in. Languages are extensible in buildpacks, data stores are ordinary services. Heroku pioneered the 12-factor app model, Cloud Foundry lets people run it themselves.

The "limitation" comes from the notion that you code to a particular implementation with Heroku (or Cloud Foundry). If you want to change implementations, you must code to that new implementation. With a true aPaaS, the implementation can change, but your code goes against the same fabric-like API.

Re: Kubernetes V1 Released

#107

Post by TheIronYuppie »

boundlessdreamz wrote: post #98
miles932 wrote: post #86

Earlier quoted context omitted.

Any suggestions for incentive systems that would be motivational for you? We want to help! Full Disclosure: I work at Google on da Cloudz

There should be several types of free trials 1. Current type for new customers. Here's $500. Do whatever you want 2. For old customers who haven't ever used a free trial, give credit without limits (same as new customers) 3. For old customers who have used a free trial give credit only for services they haven't used

It's an interesting problem - the issue is that our trials are both money & time based ($300 for 60 days). So technically you've "used" your trial even if you do nothing for 2 months.

We do appreciate the feedback and are looking hard at the right next way to solve this. If it wasn't for bitcoin miners and/or bot nets, this would all be a lot easier :(

Full disclosure: I work at Google on Kubernetes.

Re: Kubernetes V1 Released

#108

Post by jacques_chester »

nickbauman wrote: post #106
jacques_chester wrote: post #94

Earlier quoted context omitted.

I've worked on what is ostensibly a Heroku competitor (Cloud Foundry). I don't see where the limits on languages, frameworks or data stores comes in. Languages are extensible in buildpacks, data stores are ordinary services. Heroku pioneered the 12-factor app model, Cloud Foundry lets people run it themselves.

The "limitation" comes from the notion that you code to a particular implementation with Heroku (or Cloud Foundry). If you want to change implementations, you must code to that new implementation. With a true aPaaS, the implementation can change, but your code goes against the same fabric-like API.

Can you give an example?

Because I am just not seeing your point. The whole point of a PaaS is to not code to an API. You throw a 12-factor app at one and it Just Works.

Re: Kubernetes V1 Released

#109

Post by teraflop »

TheIronYuppie wrote: post #107
boundlessdreamz wrote: post #98

Earlier quoted context omitted.

There should be several types of free trials 1. Current type for new customers. Here's $500. Do whatever you want 2. For old customers who haven't ever used a free trial, give credit without limits (same as new customers) 3. For old customers who have used a free trial give credit only for services they haven't used

It's an interesting problem - the issue is that our trials are both money & time based ($300 for 60 days). So technically you've "used" your trial even if you do nothing for 2 months. We do appreciate the feedback and are looking hard at the right next way to solve this. If it wasn't for bitcoin miners and/or bot nets, this would all be a lot easier :( Full disclosure: I work at Google on Kubernetes.

Ah, interesting -- I thought it was for a year. Then I don't feel like I'm missing out quite so much, because I would have a hard time spending that much credit in 2 months anyway :)

Re: Kubernetes V1 Released

#110

Post by rsync »

juliangregorian wrote: post #102
rsync wrote: post #68

Earlier quoted context omitted.

"you have more work than can fit into one server" Many, many people believe this is true for them. Most of them are wrong.

I know being the edgy you-don't-have-big-data guy is all the rage right now, but seriously? Most people can fit all of their work on one server? What kind of mom-and-pop shops are you working for?

I started JohnCompanies in summer/fall 2001, which was the first VPS provider. This was a fairly significant financial gamble that most people can fit all their work on even less than one server.

That bet paid off.

I have no idea what "is all the rage right now".

Post reply on HN