This is a question that pops up whenever I explain Apache Mesos and Mesosphere DC/OS to customers or at an event. I finally wanted to address this question in the form of a blog post.
TL;DR is: nope, they are not.
To understand why Kubernetes and DC/OS are friends, not foes, let's look at an analogy from the world of operating systems and web browsers. Think for a moment of a MacBook that comes pre-installed with MacOS and the Safari browser or a Windows machine that has Internet Explorer on it per default. Some people are happy to use the default browser on their machine, while others choose to install their favorite alternative like Firefox or Chrome and mainly use those browsers. Some people even install and regularly use multiple browsers simultaneously.
Browsers and operating systems provide a very strong analogy because there is an equivalent of this in DC/OS: we ship it with Marathon pre-installed and configured — which is also, by the way, used to launch long-running services in your cluster (like init or systemd on a Linux machine) — but it's up to you to decide if you want to use Marathon to build and deploy your applications. You may choose to go with Marathon or you may choose to use Kubernetes. Or, you might decide to use both: each for different workloads and use cases (yes, with DC/OS you can run Marathon and Kubernetes workloads on the same cluster at the same time without conflict, just like running multiple browsers on your laptop). The tools you use with DC/OS are based on your requirements and preferences, entirely.
Kubernetes is a first-class citizen (package as we call it) of DC/OS. Kubernetes is also a community project we heavily contribute to: we have a large team of people at Mesosphere working on Kubernetes, from the open source engineering to product and training.
Mesosphere customers have the choice of offering Kubernetes to their developers. They can also use the pre-installed Marathon. Or, they can use any number of other emerging development models, including many PaaS's that run on top of DC/OS. That is a key part of what it means to be a Datacenter Operating System. The DC/OS gives its users a way to adopt as many workload types and development models that work best for their uses. DC/OS is the only system that provides this kind of inherent flexibility and eliminates lock in. The DC/OS is also the only system that lets you run multiple services—not just Marathon and Kubernetes, but also services like Spark and Cassandra—all on the same cluster, sharing resources and automating operations.
We partnered with Google to leverage the extensibility of Kubernetes and build Kubernetes-Mesos, the open source project that integrates with the Kubernetes scheduling API and the Mesos scheduler runtime, as well as provides an executor component that integrates kubelet services and the Mesos executor runtime:
As the above diagram illustrates: Kubernetes is deeply integrated with Mesos and, by extension, into the DC/OS. It is simple to set up (a single command, dcos package install kubernetes does the trick) and you're good to go. So you can use Kubernetes on DC/OS right now. If you're prepared to go all-in and package 100% of your applications in containers—that is, you're comfortable to using Docker 100% of the time, then you have the choice between Kubernetes and Marathon. Which one you pick depends mainly on your preference for Kubernetes' pod/labels/services model or Marathon's apps/groups/dependency operating model. Last but not least a consideration, at least for the time being, is scalability—Marathon has been around a lot longer than Kuberentes and has been proven to scale to much larger clusters and much larger workloads—but we're working with the Kubernetes community to help Kubernetes catch up.
To sum up: we love and support Kubernetes, on an individual as well as a corporate level. We are founding members of the Cloud Native Computing Foundation and we believe that choice is king. With the DC/OS we support you in whatever orchestration tool you want to use, be it Kubernetes or Marathon — or some new model that has yet to be invented. Our yardstick is you being successful in writing distributed applications faster and operating them with as much automation and little hassle as possible.
This website places cookies on your computer or device to make the site work better and to help us understand how you use our site. Further use of this site (by clicking, navigating or scrolling) will be considered consent. Please visit our privacy and cookie notices for more information