<p><em>Foreword:</em> My question is somewhat related to <a href="https://stackoverflow.com/questions/26705201/whats-the-difference-between-apaches-mesos-and-googles-kubernetes">this one</a>, but I'd like to go deeper on the particular aspect of scheduling.</p>

<p>Apart from the fact that Kubernetes's scheduling is <em>centralized</em> and Mesos's scheduling is <em>decentralized</em>, following a two-step process, what are the differences between the scheduling algorithms of both projects? </p>

<p>I've been using Kubernetes for half a year now, and I've never used Mesos in practice. I understand the concept of <em>resource offerings</em> but I cannot establish a comparison between Mesos and Kubernetes scheduling algorithms, mainly because I don't have deep knowledge of both tools' implementations.</p>

<p>I'm not sure if this is comparable. Kubernetes can be run as a Mesos framework. Its scheduler is described <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/scheduler_algorithm.md" rel="nofollow noreferrer">here</a>. It base on filtering and ranking the nodes.</p>
<p>Mesos two step scheduling is more depend on framework algorithm.</p>
<ol>
<li>Mesos presents the offers to the framework based on <a href="https://cs.stanford.edu/%7Ematei/papers/2011/nsdi_drf.pdf" rel="nofollow noreferrer">DRF algorithm</a>. Frameworks could be prioritized as well by using roles and weights.</li>
<li>Frameworks decide which task to run based on give offer. Every framework can implement its own algorithm for matching task with offer. <a href="https://stackoverflow.com/a/43448790/1387612">This is a NP hard problem</a></li>
</ol>
<p><strong>Appendix</strong> Quote from <a href="https://medium.com/@ArmandGrillet/comparison-of-container-schedulers-c427f4f7421" rel="nofollow noreferrer">https://medium.com/@ArmandGrillet/comparison-of-container-schedulers-c427f4f7421</a></p>
<p><a href="https://i.stack.imgur.com/JZiRp.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/JZiRp.png" alt="enter image description here" /></a></p>
<blockquote>
<p><strong>Monolithic scheduling</strong></p>
<p>Monolithic schedulers are composed of a single
scheduling agent handling all the requests, they are commonly used in
high-performance computing. A monolithic scheduler generally applies a
single-algorithm implementation for all incoming jobs thus running
different scheduling logic depending on job types is difficult. Apache
Hadoop YARN [55], a popular architecture for Hadoop that delegates
many scheduling functions to per-application components, is a
monolithic scheduler architecture due to the fact that the resource
requests from application masters have to be sent to a single global
scheduler in the resource master.</p>
<p><strong>Two-level scheduling</strong></p>
<p>A two-level
scheduler adjusts the allocation of resources to each scheduler
dynamically using a central coordinator to decide how many resources
each sub-cluster can have, it is used in Mesos [50] and was used for
Hadoop-on-Demand (now replaced by YARN). With this architecture, the
allocator avoids conflicts by offering a given resource to only one
framework at a time and attempts to achieve dominant resource fairness
by choosing the order and the sizes of the resources it offers. Only
one framework is examining a resource at a time thus the concurrency
control is called pessimistic, a strategy that is less error-prone but
slower compared to an optimistic concurrency control offering a
resource to many frameworks at the same time.</p>
<p><strong>Shared-state scheduling</strong></p>
<p>Omega grants each scheduler full access to the entire cluster,
allowing them to compete in a free-for-all manner. There is no central
resource allocator as all of the resource-allocation decisions take
place in the schedulers. There is no central policy-enforcement
engine, individual schedulers are taking decisions in this variant of
the two-level scheme. By supporting independent scheduler
implementations and exposing the entire allocation state of the
schedulers, Omega can scale to many schedulers and works with
different workloads with their own scheduling policies [54].</p>
</blockquote>
