Mesos

Mesos#

Apache Mesos is a two-level scheduler that came out of UC Berkeley and ran some of the largest container fleets on the planet (Twitter, Apple, Airbnb) before Kubernetes took the workload over. The Apache Software Foundation moved Mesos to the Attic in 2021; the operator will not stand up new clusters in 2026, but Mesos appears on long-lived data and HPC estates where the migration budget has not arrived.

Architecture#

        flowchart TB
  subgraph cp[Master quorum]
    M1[mesos-master 1]
    M2[mesos-master 2]
    M3[mesos-master 3]
    M1 --- M2 --- M3
    ZK[(ZooKeeper)]
    M1 --- ZK
    M2 --- ZK
    M3 --- ZK
  end
  subgraph fw[Frameworks]
    MAR[Marathon, long-running services]
    CHR[Chronos, batch / cron]
    SPK[Spark]
    AUR[Aurora]
  end
  subgraph ag[Agents]
    A1[mesos-agent + container runtime]
    A2[mesos-agent + container runtime]
    A3[mesos-agent + container runtime]
  end
  cp -->|resource offers| fw
  fw -->|accept / launch| cp
  cp --> ag

Concept

Detail

Master

Control plane. Tracks agents, offers their resources to frameworks, persists state in ZooKeeper.

Agent

Per-node daemon. Reports CPU / memory / disk / GPU; launches tasks under a container runtime (Mesos Containerizer, Docker, or Universal Container Runtime).

Framework

The workload-shaped scheduler. The master offers resources; the framework accepts or rejects and launches tasks. Marathon for services, Chronos for cron, Spark for Spark, Aurora for everything.

Two-level scheduling

Master makes offers; framework decides what to run. Different from Kubernetes’ single global scheduler.

ZooKeeper

Master quorum and leader election. Mesos’s etcd-equivalent.

Marathon#

Marathon is the framework most operators meet first. JSON-defined applications that look very much like Kubernetes Deployments:

{
  "id": "/web",
  "instances": 3,
  "cpus": 0.5,
  "mem": 512,
  "container": {
    "type": "DOCKER",
    "docker": { "image": "myorg/app:1.0", "network": "BRIDGE",
                "portMappings": [{ "containerPort": 8080, "hostPort": 0 }] }
  },
  "healthChecks": [{ "protocol": "HTTP", "path": "/healthz", "portIndex": 0 }],
  "labels": { "HAPROXY_GROUP": "external" }
}

$ curl -X POST http://marathon:8080/v2/apps -d @web.json -H 'content-type: application/json'

DC/OS#

Mesosphere’s commercial distribution bundled Mesos + Marathon + Chronos + a CLI + a UI + service discovery (Mesos-DNS) + an ingress (marathon-lb / HAProxy). D2iQ rebranded; the project ended; clusters still exist.

Migrating off#

The operator’s job on a Mesos estate in 2026 is almost always “move it to Kubernetes.” The standard path:

  • Inventory the Marathon apps; each maps cleanly to a Kubernetes Deployment.

  • Inventory the Chronos jobs; each maps to a CronJob.

  • Inventory custom frameworks; these are the hard part. Most are bespoke schedulers built before Kubernetes; their replacement is usually a Kubernetes operator or a workflow engine.

  • Move stateful workloads (Cassandra, Kafka, HDFS) deliberately; these were the original reason Mesos was picked, and the Kubernetes operator ecosystem now covers each of them.

When to pick Mesos#

For new work, never. The project is archived and the talent pool is shrinking.

When the operator inherits one#

  • Document the framework set in use; that determines the migration path.

  • Stand up monitoring on the masters; ZooKeeper quorum loss is the failure mode that takes a Mesos cluster down.

  • Plan the Kubernetes migration before a security CVE or a certificate expiry forces the timing.

References#

Contents