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

11–20 of 110 posts

Re: Kubernetes V1 Released

#11

Post by dlor »

puja108 wrote: post #9
nickbauman wrote: post #7

I've found that Kubernetes is a big hammer. If your problem can be backed by a web app, you should start with AppEngine. If you need specialty library support or wider computational space per instance, you can move your AppEngine app to ManagedVMs (which uses Kubernetes under the covers). If you need special, "grid-like" services where you need exquisite control over the entire stack, only then does it make sense to…

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…

Correct, MVMs does not use Kubernetes today. We're looking at rebasing onto GKE now that they've hit 1.0, but nothing is set in stone yet.

Disclaimer: I'm a tech lead on Managed VMs/App Engine at Google

Re: Kubernetes V1 Released

#12

Post by DannoHung »

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…

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 large collections of compute nodes, this is reputedly a good choice (though I don't have any personal experience to back that assessment up).

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

Re: Kubernetes V1 Released

#13

Post by alooPotato »

dlor wrote: post #11
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…

Correct, MVMs does not use Kubernetes today. We're looking at rebasing onto GKE now that they've hit 1.0, but nothing is set in stone yet. Disclaimer: I'm a tech lead on Managed VMs/App Engine at Google

Since you're already here, any chance you can talk a little bit more about upcoming plans for managed vms? I hear there is a lot of investment in that area, but what will that mean technically going forward? How are things going to change so we can plan better?

Re: Kubernetes V1 Released

#14

Post by [deleted] »

dlor wrote: post #11
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…

Correct, MVMs does not use Kubernetes today. We're looking at rebasing onto GKE now that they've hit 1.0, but nothing is set in stone yet. Disclaimer: I'm a tech lead on Managed VMs/App Engine at Google

[deleted]

Re: Kubernetes V1 Released

#15

Post by WestCoastJustin »

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…

Oh, thanks. Will check that out.

Re: Kubernetes V1 Released

#16

Post by nickbauman »

puja108 wrote: post #9
nickbauman wrote: post #7

I've found that Kubernetes is a big hammer. If your problem can be backed by a web app, you should start with AppEngine. If you need specialty library support or wider computational space per instance, you can move your AppEngine app to ManagedVMs (which uses Kubernetes under the covers). If you need special, "grid-like" services where you need exquisite control over the entire stack, only then does it make sense to…

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 found Heroku to be about 10x the cost of AppEngine for the same kinds of apps and users. I don't even want to imagine what it would cost to create my own ec2 sprawl to do what AppEngine can do out of the box. As far as languages go, I've gone to production with AppEngine apps written in Python and Clojure. I've diddled with Go. Unless what you want is something like Node.js, which has its own limitations, I don't see this as a big problem. As far as Datastore is concerned, you can substitute the implementation of it using technologies like AppScale: Cassandra, Hypertable, etc. But I've never seen another structured storage solution in a fabric form that works as well as Datastore for 90% of my problems AT SCALE. YMMV.

Re: Kubernetes V1 Released

#18

Post by nickbauman »

dlor wrote: post #11
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…

Correct, MVMs does not use Kubernetes today. We're looking at rebasing onto GKE now that they've hit 1.0, but nothing is set in stone yet. Disclaimer: I'm a tech lead on Managed VMs/App Engine at Google

I could swear I saw "kubernetes" in the URL when I spun up a ManagedVM not to long ago. Thanks for the correction.

Re: Kubernetes V1 Released

#19

Post by mml »

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.

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...

Re: Kubernetes V1 Released

#20

Post by waffle_ss »

ghshephard wrote: post #5
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.

Add to that, how does this relate to Docker-Swarm & Core-OS Fleet. StackOverflow has at least one quick briefer, but wow, this field is growing quickly: http://stackoverflow.com/questions/27640633/docker-swarm-kub...

A couple things I've found when evaluating these:

Docker Swarm seems to be the only one that supports one-off interactive containers that bind a TTY, like a Rails console (i.e. does the cluster support `docker run -it --rm busybox sh`). But its scheduling strategies[1] aren't as sophisticated as the others.

Marathon doesn't support linked containers[2], so if you're using Mesos and need linked containers, you probably will want to run Kubernetes on it and use pods.

[1]: https://github.com/docker/swarm/tree/b2182d080956040730cc76c...

[2]: https://support.mesosphere.com/hc/en-us/articles/205006415-H...

Post reply on HN