41–50 of 79 posts
We're running on Azure and have spent quite a bit of time and engineering on k8s. We're trying out DCOS for frameworks like Spark. We'd prefer not to run two container infrastructures if possible.
I looked at kubernetes-mesos, its installation wasn't as simple as "dcos package kubernetes" so I'm wondering if I'm going down a path of high resistance.
Nothing could be further from the truth. Google has been doing "containers" since before dotcloud was even a company.
The argument is usually around mesos' two level scheduling paradigm with which i'm familiar, but still don't see it's practical advantages over simple master scheduler.
Does someone have any insight on this topic? (assume docker containers will be used anyway and that a single application/framework will work on the cluster)
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.
>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.
BTW - the more I dove into Marathon the more I discovered how thin wrapper it is above mesos, that does most of the work including - container runtime, pulling resources, starting tasks, handling registries, and now even health checks!
I would like to share my personal experience running Meoss. I have been using Pure Mesos setup, without DC/OS for 2.5 years. We have the following infra features.: - 120 micro-services running using marathon. - 10 batch jobs running using Chronos. - So far, everything is reliable and no downtime. - We have Ip-Per-Task enabled with Project Calico. - We have Public, Private, and IP Access-list enabled per container usi…
May I ask, any further details on the use cases or plain use of the networking landscape on your setup?
- to deploy on demand staging or QA environment including its dependencies.
- allow service/infra devs to try services quickly without the need to use Terraform or to buy expensive instances in the first stage of the development.
Also, learning different orchestrators is a lot of work. Sure, maybe Mesos does more than just schedule containers, but that doesn't matter because a standardized orchestration platform is the main thing developers need right now - For orchestration to become truly standardized, there needs to be a single big majority winner.
It reminds me of the Minix vs Linux debate in the early days of operating systems; Minix was modular (microkernel) while Linux was monolithic. The reason why Linux won is because it provided a single consistent standard platform on which to build and configure applications. I think the same is going to happen here and I think that Kubernetes or Swarm are better placed in that regard.