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

Docker vs. Kubernetes vs. Mesos

mesosphere.com

Post reply on HN
Print view View original

51–60 of 79 posts

Re: Docker vs. Kubernetes vs. Mesos

#51

Post by k2xl »

jondubois wrote: post #50

I do think it's a fight to the death for container orchestrators. The configuration files required to run complex auto-scaling systems can add up (and require DEEP understanding of all the systems involved and how they interact with each other) - Most developers don't want to have to do it for more than one orchestrator; especially since there is no straightforward migration path from one orchestrator to another. Als…

I'm not sure if I agree. There are many frameworks in the devops space with each having their own DSLs that had various learning curves. For example, I see companies split between Puppet, Chef, Salt, Ansible, etc...

It sucks, don't get me wrong, that there one hasn't come away from the pack, but I don't think it's likely that any of these orchestration frameworks will go away. Each of them have a pretty dedicated following with lots of developers behind it.

Re: Docker vs. Kubernetes vs. Mesos

#52

Post by gtaylor »

sandGorgon wrote: post #7
raarts wrote: post #2

It feels downplayed in this article, so I would like to state for the record here, I am a happy user of Docker Swarm. Swarm has been shown to scale to tens of thousands of hosts, but I found it easy to start with, especially with the Gitlab CI support, which natively brings a Docker container registry. So I commit, CI builds my containers, stores them in my private registry, and automatically deploys from there to th…

I'm also a user of Docker Swarm - and I love it! I have extensively played with k8s and feel it has a lot of upfront complexity (especially ingress). I feel people who are beginning to scale from one machine to 10 will love Docker Swarm (and stick with it). While those who have about 100 machines will start with Mesos/K8s.

There's no direct migration path from Swarm to Kubernetes, so we chose to start out at a small scale with the latter. It was enough of a leap to fundamentally change how we were building and deploying things. We didn't want to do it twice!

You can dodge much of the operational complexity in standing a cluster up by starting with Google Container Engine or a provisioner like kops. Once you have enough comfort, you can get more fancy and build something more customized to your cases.

Re: Docker vs. Kubernetes vs. Mesos

#54

Post by fen4o »

tbcj wrote: post #37
fen4o wrote: post #36

Earlier quoted context omitted.

Exactly. The frameworks that the article describes know how to run say Cassandra or Spark, but you can do the same thing in Kubernetes using TPRs or CRDs with operators: [0] https://github.com/coreos/prometheus-operator [1] https://github.com/coreos/etcd-operator [2] https://github.com/huawei-cloudfederation/redis-operator [3] https://github.com/CrunchyData/postgres-operator [4] https://github.com/krallistic/kafka-op…

There doesn't appear to be anything at #2 - https://github.com/huawei-cloudfederation/redis-operator .

From what I've seen, Huawei will upload it soon™

Re: Docker vs. Kubernetes vs. Mesos

#55

Post by tyingq »

jondubois wrote: post #50

I do think it's a fight to the death for container orchestrators. The configuration files required to run complex auto-scaling systems can add up (and require DEEP understanding of all the systems involved and how they interact with each other) - Most developers don't want to have to do it for more than one orchestrator; especially since there is no straightforward migration path from one orchestrator to another. Als…

>The reason why Linux won is because it provided a single consistent standard platform

I suspect there were many reasons. One reason it might have won vs minix was broader driver support for various video, network, sound cards, etc.

Re: Docker vs. Kubernetes vs. Mesos

#56

Post by coding123 »

lucaspiller wrote: post #8
raarts wrote: post #2

It feels downplayed in this article, so I would like to state for the record here, I am a happy user of Docker Swarm. Swarm has been shown to scale to tens of thousands of hosts, but I found it easy to start with, especially with the Gitlab CI support, which natively brings a Docker container registry. So I commit, CI builds my containers, stores them in my private registry, and automatically deploys from there to th…

How do you automate the updating of images on Docker Swarm?

I do this:

    docker build -t $APPNAME:$timestamp .
    OUTPUT="$(docker service inspect -f '{{.Spec.Name}}' sv-$APPNAME || true)"
    if [ "$OUTPUT" == "" ]; then
      # Service does not exist
      echo "Creating service"
      docker service create --update-delay 5s \
        --publish $PUBPORT:8080 --replicas 2 \
        --mount type=bind,source=$(cd ../images; pwd),target=/images,readonly=true \
        --mount type=bind,source=$(cd ../processed_images; pwd),target=/app/images \
        --mount type=bind,source=$(cd ..; pwd)/config.json,target=/config.json,readonly=true \
        --mount type=bind,source=$(cd ~/.aws; pwd),target=/root/.aws,readonly=true \
        --name sv-$APPNAME $APPNAME:$timestamp
    else
      # Service exists
      echo "Updating service"
      docker service update --image $APPNAME:$timestamp sv-$APPNAME
I haven't looked in a while, but it would be nice if they had some kind of "upstall" (update/install) kinda like upsert (update/insert) in CRUD land.

Re: Docker vs. Kubernetes vs. Mesos

#58

Post by acejam »

lucaspiller wrote: post #8
raarts wrote: post #2

It feels downplayed in this article, so I would like to state for the record here, I am a happy user of Docker Swarm. Swarm has been shown to scale to tens of thousands of hosts, but I found it easy to start with, especially with the Gitlab CI support, which natively brings a Docker container registry. So I commit, CI builds my containers, stores them in my private registry, and automatically deploys from there to th…

How do you automate the updating of images on Docker Swarm?

This is the easiest part, you just call:

  docker service update --image $image_name:$new_sha $service_name
and Swarm handles the rest. You can even pass in rolling update options, so the container updates are staggered. Put this into a simple bash script that only runs when the current branch is master. (Because your CI is building every branch to give you fast feedback, right?) In the case of CircleCI or TravisCI, that can be done with something like:

  if [ "${CIRCLE_BRANCH}" == "master" ]; then

Re: Docker vs. Kubernetes vs. Mesos

#59

Post by kyrias »

user5994461 wrote: post #57

Too bad reviewers always forget Nomad from Hashicorp. https://www.nomadproject.io/ The only cluster management system that doesn't take 3 years to understand and doesn't depend on 42 other complicated software.

Nomad is mentioned in the article, so they hardly forgot about it.

Re: Docker vs. Kubernetes vs. Mesos

#60

Post by tbrock »

timhwang21 wrote: post #47
tbrock wrote: post #44

This article hilariously makes it seem as though Google hadn't thought about using Linux cgroups and namespaces to manage processes before dotcloud conceived of Docker. Nothing could be further from the truth. Google has been doing "containers" since before dotcloud was even a company.

This is addressed: >Google had tremendous experience with containers (they introduced cgroups in Linux) but existing internal container and distributed computing tools like Borg were directly coupled to their infrastructure.

Ah I missed that, touché
Post reply on HN