News for hackers. Stuff that matters.
Re:Convergence to Kubernetes by gnur on Monday June 25, 2018 @02:41AM (#17390366)
Having used both DC/OS (mesos & marathon) and kubernetes in production.

The one thing DC/OS had absolutely nailed was the web interface and bootstrap. The DC/OS interface is brilliant as it allows you to explore all the possibilities and actually have a overview of what is happening.

Also, it was a lot easier to reason about because everything is contained in a single marathon job. No need to split everything up in deployments / services / ingresses. A single JSON file is all you need for DC/OS. Less to think about.

The downside of all this is that DC/OS feels like a solution for a theoretical problem, while kubernetes is the solution to practical problems.

Re:Convergence to Kubernetes by amazingman on Monday June 25, 2018 @03:11AM (#17390483)
It seems to me that running Kubernetes as a service on DC/OS might be a decent path to take. Mesosphere seem to be pushing this pretty hard, too.

What did you think of DC/OS as a base platform? From an ops perspective, I’m finding a lot to like at least conceptually. Especially the idea of managing one “kind” of cluster that then manages many additional kinds for you. But I have yet to actually use it.

Re:Convergence to Kubernetes by gnur on Monday June 25, 2018 @04:28AM (#17390813)
It sounds great, but I've always found the DC/OS marketplace not really flexible enough. I've looked at many services, but in most cases the requirements for running a service from the marketplace were for extremely high throughput situations. I wanted to experiment with arrongoDB but it required a total of 16GB memory (IIRC).

Practically, I think kubernetes with helm charts gets will get you at least 90% of what DC/OS offers.

Also, running Kubernetes itself is complicated enough, running it on a different scheduler will just expose you to the pains of both schedulers.

Re:Convergence to Kubernetes by chrisgaun on Monday June 25, 2018 @11:42AM (#17393262)
Mesos means "middle" and it was designed to handle the declarative infrastructure provisioning for different schedulers... container orchestration schedulers: Aurora (Youtube/Twitter), Titus (Netflix), Marathon and Kubernetes (DC/OS).... analytics schedulers: Spark, Tensorflow, etc.

The idea was always that you should manage this infrastructure just like they are managing containers.

discloser: I am the PM of Kubernetes on DC/OS.

Re:Convergence to Kubernetes by bfrydl on Monday June 25, 2018 @04:44AM (#17390869)
FWIW, while the resources themselves are still split up, you can combine any number of resource definitions into a single YAML file for Kubernetes. Just separate each with ---