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

1–10 of 110 posts

Re: Kubernetes V1 Released

#3

Post by StevePerkins »

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.

Re: Kubernetes V1 Released

#4

Post by kordless »

Wercker has a post on continous integration for containers to Kubernetes which Micha, their CEO, did back in June: http://blog.wercker.com/2015/06/23/Deploying-minimal-contain..., which uses Google's Container Registry for pushing images.

If anyone is interested, I just wrapped up a similar post for deploying containers to Giant Swarm from Wercker, no Docker required: I just got done doing a continuos integration post for containers using Wercker and Giant Swarm: https://github.com/giantswarm/swarm-wercker.

Re: Kubernetes V1 Released

#5

Post by ghshephard »

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

Re: Kubernetes V1 Released

#7

Post by nickbauman »

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 use raw Kubernetes and Docker. And you will spend a lot of time getting it right.

Re: Kubernetes V1 Released

#8

Post by WestCoastJustin »

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], Aurora [4], or Hadoop [5]. Then Marathon/Aurora/Hadoop/etc tells Mesos to farm out compute jobs to these end client nodes (aka schedules). Complexity can quickly go up depending on your hosting environment, scale, and HA requirements. There is actually a really good high-level overview diagram of what a mesos/hadoop/zookeeper setup looks like here [6].

The stack looks something like this for Kubernetes/Mesos (top down):

  - Kubernetes and Mesos (client/server packages depending on node type)
  - Docker (container engine)
  - OS (Ubuntu/RHEL/etc)
What are some use-cases?

  - you have more work than can fit into one server
  - need to distribute load across N+ nodes
  - Google heavily uses containers (not k8s, but that inspired these patterns)
    - Gmail/Search/etc all run in containers [7]
  - Apple, Twitter, and Airbnb are running Mesos today [8, 9]
There are a bunch of revolving services, like:

  - distributed key/values stores (etcd/zookeeper)
  - load balancers
  - image registries
  - user interfaces
  - cli tools
  - logging/monitoring/alerting
  - etc
But, to answer your question, the main difference between Kubernetes and Mesos, is that Kubernetes offers an opinionated workflow, built-in scheduler, and patterns for how containers are deployed into this cluster of compute notes. The pattern is baked in from the start via Pods, Labels, Services, and Replication Controllers. It also helps to know that Kubernetes comes from Google, where they have been running containers in-house, so much of this workflow (pods, services, replication controllers, etc), comes from their internal use-cases. That's the 10,000 foot view.

[1] https://github.com/GoogleCloudPlatform/kubernetes

[2] http://mesos.apache.org/

[3] https://mesosphere.github.io/marathon/

[4] http://aurora.apache.org/

[5] https://hadoop.apache.org/

[6] http://mesos.apache.org/assets/img/documentation/architectur...

[7] http://www.wired.com/2013/03/google-borg-twitter-mesos/

[8] http://www.infoq.com/news/2015/05/mesos-powers-apple-siri

[9] https://www.youtube.com/watch?v=E4lxX6epM_U

Re: Kubernetes V1 Released

#9

Post by puja108 »

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 instances bring technical debt with it that will pose a hurdle when growing. Actually, using Docker combined with an orchestration layer like k8s is supposed to give the the ease-of-use of PaaS with the flexibility of IaaS (or MVMs), however, managing sth like k8s by yourself is not that easy and you will need quite a bunch of other tools on top, i.e. for monitoring and stuff, which paves the way for Container-as-a-Service solutions, like RancherOS, tutum, or Giant Swarm (disclaimer, I'm part of the latter company)
Post reply on HN