Apache Mesos 1.11 介绍与核心概念

Apache Mesos 1.11 介绍与核心概念：剖析两级调度与资源邀约机制、Master/Agent/Framework 架构、Scheduler 与 Executor 接口、角色配额与高可用模型，全部基于 Ubuntu 22.04 源码与运行实测。

Apache MesosMesosApache集群分布式资源调度2026/10/15

Apache Mesos 1.11 介绍与核心概念

本文基于 Ubuntu 22.04 服务器（内核 5.15）对 Apache Mesos 1.11.0 源码（gcc 11.4.0 编译安装）与真实运行的 Master/Agent 实例进行实测后撰写，所有命令、回显与接口摘录均为真实执行结果。

一、项目概述

1.1 Mesos 是什么

Apache Mesos 是一个集群资源统一管理与两级调度系统（cluster resource manager and two-level scheduler），它把数据中心中所有机器的 CPU、内存、磁盘、端口等资源抽象为一个统一的资源池，按「邀约」（Offer）方式分发给上层的框架（Framework），由框架自行决定是否接受以及如何运行任务。

与「集中式调度器」（如 YARN 的 ResourceManager 统一决定所有任务的资源分配）不同，Mesos 采用两级调度：第一级由 Mesos Master 决定「把哪些机器的哪些资源份额提供给哪个框架」，第二级由框架自己的调度器决定「接受哪些邀约、在其中运行什么任务」。这种设计让多种异构负载（大数据作业、长驻服务、批处理任务）可以共存于同一个集群，各框架按自身语义做资源决策。

Mesos 官方源码包 README 对自己的定位描述如下（摘自 mesos-1.11.0 源码包，实测输出）：

Apache Mesos is a cluster manager that simplifies the complexity of running
applications on a shared pool of servers.

1.2 历史沿革

Mesos 起源于加州大学伯克利分校的 AMPLab 研究项目，论文《Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center》发表于 NSDI 2011，2010 年进入 Apache 孵化器，2013 年 6 月成为 Apache 顶级项目。它曾是 Twitter、Apple Siri 后端等大规模生产系统的底座，也是 Apache Spark、Aurora、Marathon、Chronos 等著名项目的原生调度平台。

理解 Mesos 的黄金期能帮助理解它的设计动机：当时数据中心里同时跑着 Hadoop（批处理）、Storm（流计算）、服务进程（长驻）等多类负载，各自带一套资源管理，利用率普遍低下。Mesos 的答案是「把资源分配和任务调度解耦」——平台只管把资源公平分出去，任务语义交给各框架自己决定。这个思想影响了后来的 Kubernetes 调度器设计（如多调度器与 Pod 优先级抢占的分工）。而它最终被 Kubernetes 时代取代的原因，同样值得记录：容器化应用模型统一了「任务」的抽象，Kubernetes 以声明式 API 与丰富的服务治理能力覆盖了 Mesos 加 Marathon 组合的大部分场景，且社区与厂商投入远胜。

关键时间节点如下：

  • 2013 年 6 月：成为 Apache 顶级项目；
  • 2016 年前后：Twitter 等标志性用户开始向 Kubernetes 迁移，社区动能转向；
  • 2019 年 5 月：Mesosphere 公司（Mesos 商业化主体）转向 Kubernetes 产品线并更名 D2iQ；
  • 2025 年 8 月：Mesos 项目管理委员会决议退役，社区停止开发；
  • 2025 年 10 月：项目整体迁移至 Apache Attic（ATTIC-245），仓库与发行包转为只读归档；
  • 站外由原社区成员维护的分支（clusterd 项目）不属于 Apache 官方维护范围。

1.3 退役状态与适用性声明

截至本文撰写时，Mesos 官网 mesos.apache.org 仍可访问，发行历史（含 1.11.0）保留在 Apache 归档站点，但项目已是 Apache Attic 中的退役项目：不再发布新版本、不再接受补丁与安全修复。本文及本专栏对 Mesos 的定位是：适合学习集群资源调度的设计思想、维护仍在运行 Mesos 的存量遗产系统，不建议新项目采用。若需新建集群资源管理系统，应评估 Kubernetes 等活跃维护的方案。

1.4 终版 1.11.0 概况

1.11.0 是 Mesos 的最后一个常规版本（2020 年 12 月发布后，项目仅有 1.11.1/1.11.2 两个小维护版本，最终于 1.12.x 线之前进入退役流程）。实测从源码 configure.ac 读取的版本定义：

$ grep -m1 AC_INIT /opt/src/mesos-1.11.0/configure.ac
AC_INIT([mesos], [1.11.0])

本文实测环境编译安装后，/usr/local/sbin/mesos-master --version 输出 mesos 1.11.0；运行中的 Master 通过 HTTP 接口上报的版本信息同样为 "version": "1.11.0"。1.11 系列的主要能力包括：任务隔离运行支持（Mesos 自带隔离器与外部隔离器扩展机制并存）、CSI 存储接口支持、资源磁盘 XFS 等持久卷增强、HTTP API（v1 scheduler/executor 协议）与新的 Operator API。

需要澄清「终版」的准确边界：1.11.0 是最后一个包含新特性的常规版本，其后 1.11.1、1.11.2 仅做缺陷修复，1.11.2 就是全项目的最后一版。因此文档、教程与兼容性矩阵均应以 1.11.x 为准绳，网上标称「1.12」的资料不存在官方对应物，遇到时应当警惕。

二、核心特性

2.1 两级调度与资源邀约

Mesos 的资源分配模型是「资源邀约驱动」：Master 把每个 Agent 节点的可用资源打包成 Offer 发给框架调度器，框架调度器可以在 Offer 中声明式地启动任务，未使用的资源会被回收后重新邀约。两级调度的分工边界清晰：

  • Mesos 侧（第一级）：维护全局资源池，按角色的配额、权重决定「资源给谁、给多少」，不感知任务语义；
  • 框架侧（第二级）：感知自身任务的优先级、依赖与拓扑，决定「用不用这份资源、跑什么任务」。

第一级分配采用的默认策略是 DRF（Dominant Resource Fairness，主导资源公平）。其核心思想：多资源（CPU、内存、磁盘）场景下，「公平」不能只看单一资源，而要看每个框架的主导资源——即它消耗占比最高的那种资源。DRF 把所有框架的主导资源份额拉向相等，让各框架在其最紧张的维度上获得公平份额。用一个双框架例子走一遍计算：集群共 18 核 CPU、36GB 内存；框架 A 每个任务占 1 核 4GB（CPU 占比 5.6%，内存占比 11.1%），框架 B 每个任务占 3 核 1GB（CPU 占比 16.7%，内存占比 2.8%）。A 的主导资源是内存、B 的主导资源是 CPU，DRF 轮流满足两者的主导资源份额，最终收敛到 A 跑 2 个任务、B 跑 3 个任务时双方主导份额同为 33.3%。权重（Weight）即作用在这个份额比较上：权重 2 的角色每轮获得双倍的分配机会。

DRF 的取舍也要客观看：它最大化了「同时活跃框架数」，但牺牲了整体资源利用率的最优（占资源形态迥异的框架混部时可能出现碎片），且对「框架声明资源后不用」的囤积行为需要配额与邀约超时兜底。这也是后面 7.x 节与 Kubernetes 对比时的关键差异点之一。

2.2 多资源类型统一建模

资源在协议层统一建模为 Resource 消息（含 CPU、MEM、DISK、PORTS 等标量与范围类型），定义在协议描述文件 include/mesos/v1/mesos.proto 中（实测该文件 6 万余行，message Resource 起始于第 1269 行）。资源可按角色（Role）划分、可预留（Reservation）、可设置配额（Quota）与权重（Weights），实现多租户隔离。

2.3 任务隔离

Mesos Agent 通过隔离器（Containerizer）为每个任务创建相互隔离的运行实例：

  • Mesos 自带隔离器：以 cgroups/命名空间实现隔离，支持 POSIX 或 GPU 隔离器，可挂载 UCR（统一任务隔离层，Uniform Containerizer）管理的应用制品；
  • 外部隔离器：通过 --containerizer=external 或自定义 isolator 模块接入第三方隔离实现。

UCR 的架构值得多说两句：它是 1.0 之后的统一隔离层，任务以「镜像/制品 + 执行器」的方式描述，Agent 通过 Provisioner（如 overlayfs/aufs 后端）准备根文件系统，再由 isolator 组（filesystem/linux、namespaces/pid、cgroups/cpu、cgroups/mem、network/port_mapping 等，可按需组合）施加隔离与限制。与旧版「Mesos 隔离器和外部隔离器二选一」的模型相比，UCR 把隔离能力做成了可插拔的细粒度组合，这也是 1.11 的 --isolation 参数可以传一长串 isolator 名单的原因。

此外 Mesos 提供持久卷（Persistent Volume）、动态预留、任务组（Task Group）、健康检查（Health Check）与任务清理（Task Kill 策略）等面向生产的能力。健康检查分为三类：命令式（在任务沙箱内执行检查命令）、HTTP 式（探测端口路径）与 TCP 式（仅探连通性），延迟与超时在 TaskInfo 中声明，失败达到阈值后 Agent 自动向框架上报失败状态——长驻服务框架（如 Marathon）正是基于此实现自动重启。

2.4 高可用

Master 通过 ZooKeeper 选举实现主备切换，框架调度器通过 FrameworkID 在 Master 故障转移后重新注册（reregistered 回调）。任务状态通过 HTTP API 持久上报，Agent 也能通过 Registry 恢复运行中任务的隔离状态（--recover 标志）。

高可用模型的两个关键参数需要区分清楚。一是 Master 侧的 --quorum：多 Master 经 ZK 选举，quorum 是「选出主所需的票数」，生产取「Master 数量的一半加一」；注册表（replicated log 形态持久化于 work_dir，实测为 LevelDB 结构）随选主复制，是 Agent 与框架信息恢复的根据。二是框架侧的 failover_timeout：框架断线后，Master 保留其 FrameworkID 与已运行任务的最长时间。超时前重新注册，任务原样保留（调度器收到 reconnect）；超时后，Master 认为框架已死，会拆除其全部任务并释放资源。这一参数是「调度器崩溃恢复」语义的核心，缺失或不合理都会导致 Master 切换时把本该存活的长驻任务清光。

框架故障转移的行为链路可以用 mesos-execute 直接观察：其默认 failover_timeout 为 0，命令行退出即框架被注销、关联任务被终止；若在命令中显式调大该值并断开进程，任务会继续运行直至超时——这是理解 failover 语义最直观的实验（实测见本系列 CLI 篇）。

三、体系架构

3.1 四类角色

一个 Mesos 集群由四类角色构成：

  1. Master：全局管理者，负责 Agent 生命周期、资源邀约分配、框架注册与故障检测（生产形态为多 Master + ZooKeeper）；
  2. Agent：每台工作节点运行一个，负责任务隔离、任务执行、资源上报（默认端口 5051）；
  3. Framework：由 Scheduler（调度逻辑）+ Executor（执行器）组成，通过注册获得 FrameworkID；
  4. 用户任务：由 Executor 在隔离实例中启动的具体进程。

Master 提供 WebUI（默认端口 5050）与 HTTP API；Agent 提供 HTTP API（5051）。本文实测单 Master + 单 Agent 集群，/state 接口返回的集群摘要（实测节选）：

"version": "1.11.0",
"elected_time": 1792016726.78514,
"activated_slaves": 1,
"slaves": [{"id": "S0", "pid": "slave(1)@172.17.0.2:5051", ...}]

把 /state 的顶层键完整枚举一次（实测），可以直接当作集群状态速查表使用：activated_slaves、capabilities、build_date/build_time/build_user（构建元信息）、completed_frameworks（历史框架，审计用）、deactivated_slaves、elected_time（本届 Master 上任时间，选主后排查的第一线索）、flags、frameworks、git_sha/git_tag、hostname、id、leader 与 leader_info（当前主与选举协议信息）、orphan_tasks（无框架归属的遗留任务）、pid、recovered_slaves、slaves、start_time、unregistered_frameworks、unreachable_slaves、version。其中 orphan_tasks 与 unreachable_slaves 两个键在日常运维里最容易被忽视：前者意味着 Agent 上还有 Master 已不认为有框架归属的残留任务，后者则是网络分区排查的起点。

3.2 资源邀约生命周期

一次完整的任务运行流程（本文用 mesos-execute 实测通过）：

  1. Agent 启动后向 Master 注册，上报本机资源（如 cpus:8、mem:30937）；
  2. Master 按 Allocation Policy 生成 Offer 发给框架；
  3. 框架调度器在 resourceOffers 回调中决定启动任务，调用 driver.launchTasks；
  4. Master 把任务下发到对应 Agent，Agent 为其创建隔离实例并启动 Executor；
  5. 任务状态沿 Executor → Agent → Master → Scheduler 回调链路流转（TASK_RUNNING → TASK_FINISHED）；
  6. 任务结束后资源回收，进入下一轮邀约。

第 5 步的状态流转值得展开成完整状态机（实测 mesos-execute 全程可见）：TASK_STAGING（已分配尚未在 Agent 上开始）→ TASK_STARTING → TASK_RUNNING → 终态之一。命令任务可实测到三种典型终态：正常结束 TASK_FINISHED；命令不存在时 TASK_FAILED（message 为 Command exited with status 127，实测）；被主动终止时经历 TASK_KILLING（收到终止请求、正在拆除）→ TASK_KILLED（message 为 Command terminated with signal Terminated，实测）。中间态 TASK_KILLING 的存在是为了区分「请求已发」与「已结束」，框架调度器据此决定是否重试终止。此外 TASK_LOST 用于 Agent 失联等异常场景，TASK_GONE/UNREACHABLE 是 1.x 后期引入的更精确的 Agent 状态细分。状态机不是纸面概念：排障时 statusUpdate 的 message 字段（退出码、信号名）就是第一手证据。

3.3 协议与接口层次

Mesos 1.11 同时提供两套 API：

  • 旧版（无版本前缀）：include/mesos/scheduler.hpp 等头文件定义的 C++ 驱动 API，本文实测该文件共 572 行；
  • v1 版 HTTP API：include/mesos/v1/ 下的 proto 协议（scheduler、executor、master、agent 四类），语言无关，官方 Python/Java/Go/C++ 客户端均基于它。

v1 协议的传输形态有两种：JSON 与 Protobuf over HTTP，调度器与 Master 之间以持久 HTTP 连接上的事件流（Subscribe 长连接）交互。这一设计的深远影响是：任何语言都能实现框架调度器，不再依赖 C++ 驱动库，Marathon、自定义调度器、各类 Operator 工具因此得以繁荣。另外两套 API 在概念上有一一对应的字段模型（如 v1 的 FrameworkInfo 对应旧版同名消息），源码阅读时以 include/mesos/v1/ 下的 proto 为「最新事实」，旧版头文件可视为其 C++ 便捷封装。

四类 proto 的分工（实测源码目录）：mesos.proto 定义资源、任务、框架等数据模型；scheduler.proto 定义框架调度器与 Master 之间的 Call/Event；executor.proto 定义 Executor 与 Agent 之间通道；master.proto 与 agent.proto 则是运维面 Operator API 的调用定义（读写状态、drain Agent、查询配额等）。本文 CLI 篇用到的 mesos-execute、mesos-log 等工具正是 Operator API 的命令行化。

四、核心接口：Scheduler 与 Executor

4.1 Scheduler 回调接口

框架调度器实现 Scheduler 接口的回调方法，由 MesosSchedulerDriver 驱动。实测摘录源码头文件 include/mesos/scheduler.hpp 第 80 行附近的三个核心回调（含官方注释）：

  virtual void registered(
      SchedulerDriver* driver,
      const FrameworkID& frameworkId,
      const MasterInfo& masterInfo) = 0;

  // Invoked when the scheduler reregisters with a newly elected
  // Mesos master. This is only called when the scheduler has
  // previously been registered. MasterInfo containing the updated
  // information about the elected master is provided as an argument.
  virtual void reregistered(
      SchedulerDriver* driver,
      const MasterInfo& masterInfo) = 0;

  // Invoked when the scheduler becomes "disconnected" from the master
  // (e.g., the master fails and another is taking over).
  virtual void disconnected(SchedulerDriver* driver) = 0;

registered 回调返回的 FrameworkID 是框架在集群中的永久身份，高可用调度器必须持久保存它，Master 故障转移后凭该 ID 重新注册。其余重要回调包括 resourceOffers（接收邀约）、statusUpdate（任务状态变更）、offerRescinded（邀约被收回）与 slaveLost（Agent 失联）。

4.2 Executor 接口

执行器实现 Executor 接口（同一头文件树 include/mesos/executor.hpp），核心回调为 registered、launchTask、killTask 与 frameworkMessage。Executor 与 Agent 之间通过本地 HTTP/Protobuf 通信，任务进程的 stdout/stderr 被沙箱（Sandbox）目录收集。

4.3 实测：用 mesos-execute 走通全链路

mesos-execute 是官方自带的「单任务框架」调试工具，把上述接口封装为命令行。本文实测在单 Master 单 Agent 集群运行命令任务：

$ /usr/local/bin/mesos-execute --master=127.0.0.1:5050 \
    --name=hello-test --command="echo hello-mesos-task && uname -m"
I1014 ... Using framework with id: <framework-id>
Subscribed with id ...
task hello-test launched ...
TASK_STARTING ... TASK_RUNNING ... TASK_FINISHED (Status update: TASK_FINISHED)

任务沙箱中的标准输出（实测读取 Agent 工作目录下的 stdout 文件）：

hello-mesos-task
x86_64

从邀约到任务完成的全链路真实可用。

五、安装形态与组件清单

5.1 源码构建产物

Mesos 1.11.0 在 Ubuntu 22.04 上以 configure + make 构建（详见本系列安装篇）。make install 后的命令清单（实测 /usr/local/sbin 与 /usr/local/bin 目录）：

mesos-agent  mesos-daemon.sh  mesos-master  mesos-slave
mesos-start-agents.sh  mesos-start-cluster.sh  mesos-start-masters.sh
mesos-stop-agents.sh  mesos-stop-cluster.sh  mesos-stop-masters.sh
mesos-execute  mesos-log  mesos-resolve  mesos-tcp-logger ...

其中 mesos-master 与 mesos-agent 是核心守护进程，mesos-start-cluster.sh 用于批量启停（配合 --master 列表），mesos-execute 面向单任务调试。核心动态库 libmesos.so 与全套 C++ 头文件安装到 /usr/local/lib 与 /usr/local/include/mesos。

5.2 关键启动参数

实测最常用的最小参数集：

  • Master：--ip（监听地址）、--work_dir（注册表与日志目录）、--zk（多 Master 选举串）、--quorum（选举法定人数）；
  • Agent：--master（Master 地址）、--work_dir（沙箱与本地运行时目录）、--attributes、--resources（自定义资源）。

一个对新手非常重要的实测细节：在新版 Linux 发行版上 Agent 默认尝试挂接 systemd cgroup 层级，若系统没有 /sys/fs/cgroup/systemd 层级（典型于非 systemd 托管环境），Agent 会启动失败并报 Failed to initialize systemd: Failed to locate systemd cgroups hierarchy，此时需显式加 --systemd_enable_support=false 才能正常启动（本文实测即遇到并以此解决）。

5.3 观测接口

Master 与 Agent 均暴露 HTTP 端点（实测均返回 200）：

  • /state：集群/节点完整状态（含资源、任务、框架清单）；
  • /flags：进程当前生效的全部启动参数；
  • /metrics/snapshot：Prometheus 文本格式的指标快照；
  • Master 的 /（WebUI）与 Agent 的 /api/v1（Operator API）。

/metrics/snapshot 的指标量相当大（单机实测上百项），按前缀分组理解最有效。资源视角（实测单机环境节选）：

allocator/mesos/resources/cpus/total = 12.0
allocator/mesos/resources/mem/total = 31026.0
allocator/mesos/resources/cpus/offered_or_allocated = 0.0
master/cpus_percent = 0.0
master/mem_percent = 0.0

分配器（allocator）前缀反映 DRF 引擎的资源账本（总量与已分配量），master/cpus_percent、mem_percent 正是 2.1 节 DRF 讨论的主导资源份额在系统里的直接观测点；框架行为视角是另一组：master/frameworks/active、master/messages_*（各类内部消息计数，选主与注册异常时看消息是否中断）、以及 v1 API 调用计数（实测框架的 calls 处理指标如 frameworks_subscribe、frameworks_accept_calls、frameworks_acknowledge_calls 等，可精确观察每个框架的订阅与响应节奏）。把这几组指标接进监控系统，即可覆盖「资源水位、调度健康度、框架行为」三个层面。

六、多租户与资源管理

6.1 角色（Role）与预留

资源按 Role 划分。框架注册时声明消费的角色，Master 只把属于该角色的资源邀约给它。静态预留通过 Agent 的 --resources 参数声明（如 cpus(*):2;mem(*):2048;cpus(prod):4），动态预留通过 Reserve 操作在运行期完成。

把预留机制放进一个典型拓扑：Agent 总资源 12 核 30GB，静态预留 prod 角色 4 核；prod 的框架拿满这 4 核后，剩余 8 核默认归角色 *（无角色框架可消费）；若临时需要给 prod 加 2 核，用 Reserve 操作把 * 的 2 核转为 prod 专属（动态预留），不用改 Agent 配置重启；峰值过后再 Unreserve 释放。1.4 引入的**预留细化（Reservation Refinement）**能力（实测 mesos-execute 的帮助信息里标注 RESERVATION_REFINEMENT 与 TASK_KILLING_STATE 两个能力始终启用）进一步支持层层嵌套的预留链，适配复杂的多级租户树。

6.2 配额（Quota）与权重（Weight）

Quota 保证某角色至少获得指定资源量（Master 在分配时优先满足），Weight 控制各角色之间的相对分配比例（DRF 算法按权重加权主导资源公平性）。二者组合即可实现「保障 + 溢出共享」的多租户资源模型。

二者的优先级关系要记牢：Quota 是「先扣留」——满足全部配额后才进入 DRF 溢出分配；Weight 只影响溢出部分的公平比较。因此把稀缺资源全部塞进配额会饿死共享池，规划时通常按「保底走 Quota、弹性走 Weight」分层。

6.3 持久卷与磁盘资源

磁盘资源可声明为 root/PATH/MOUNT 三种类型：root 磁盘与 Agent 工作目录共用文件系统；PATH 磁盘是预留目录下的配额切分；MOUNT 磁盘独占一个挂载点（块设备），是三种中最强的隔离形态。Persistent Volume 以磁盘资源为底座创建，随任务生命周期存在，配合动态预留可实现有状态框架（如数据库类框架）的存储诉求。持久卷的创建与销毁都是框架通过 Operator/Scheduler API 显式管理的资源操作（CreateVolumes/DestroyVolumes），TaskInfo 中以「磁盘资源 + volume 引用」组合声明，任务重建时只要资源还在、数据就还在——这正是 Mesos 当年支撑有状态服务的机制基础，也是评估遗产系统存储方案时必须理解的一层。

七、适用场景与局限

7.1 曾经的典型场景

Mesos 适合的场景在其黄金期被反复验证：多框架共享的统一大数据集群（Spark/Hadoop/Storm 共池）、长驻服务与批处理混部（Marathon + Chronos）、GPU 集群调度等。判断一个场景「当年为什么选 Mesos」，本质是三个条件的组合：负载异构到需要一个中立的资源仲裁者、每个负载都自带调度智能（框架模式适用）、需要多租户的细粒度资源治理（角色/配额/权重）。

7.2 与 Kubernetes 的能力对照

以今天的视角做一次冷静对照，比空谈优劣更有价值：

  • 抽象模型：Mesos 是「资源池 + 框架自治」的库模式，Kubernetes 是「声明式 API + 控制器」的平台模式。前者灵活但要自建调度器与状态管理，后者开箱即用但定制成本高；
  • 调度粒度：Mesos 的 DRF 面向多资源公平共享，Kubernetes 的调度器面向单任务放置（打分选节点），公平性靠多队列与调度器扩展实现——两者哲学不同，迁移时不能机械换算；
  • 服务治理：Mesos 只到「任务跑起来」为止，服务发现、发布、回滚要靠 Marathon 等上层组件拼装；Kubernetes 原生覆盖 Service/Ingress/滚动发布，这是它胜出的主因；
  • 生态：Mesos 生态组件（Marathon、Aurora、Chronos）均已停更，Kubernetes 生态仍在快速演进。存量 Mesos 系统评估迁移方案时，Marathon 应用清单到 Deployment 的映射与持久卷的搬移是两大主要工作量。

7.3 退役后的现实约束

必须如实说明：项目已进入 Attic，官方不再修复缺陷与漏洞；其生态组件（Marathon、Aurora 等）多数也已停止维护；对新的硬件与内核特性（如 cgroup v2）不再有官方适配——本文实测中 Agent 在 cgroup 层级探测上的失败即是一例。因此对存量系统：可继续运行并按需自行修补；对新建系统：不建议采用。

八、实测环境摘要

本文所有实测均在以下环境完成：

  • 操作系统：Ubuntu 22.04（64 位），内核 5.15；
  • 工具链：gcc 11.4.0、GNU Make 4.3、JDK 8（仅编译期需要 configure 探测）；
  • 源码：mesos-1.11.0.tar.gz（Apache 归档站点），configure 选项 --disable-java --disable-python --disable-werror；
  • 运行形态：单 Master（127.0.0.1:5050）+ 单 Agent（--systemd_enable_support=false）；
  • 实测任务：mesos-execute 命令任务 TASK_FINISHED，沙箱 stdout 输出正确；
  • 相关命令与排障细节见本系列《Ubuntu 22.04 编译安装 Apache Mesos 1.11.0 指南》与《Apache Mesos 1.11 CLI 命令与集群实战详解》。

九、FAQ

Q1：Mesos 与 YARN 同为资源管理系统，两级调度的差异体现在哪？ YARN 的 ResourceManager 集中决定「资源分给哪个 ApplicationMaster、跑在哪」，调度语义内聚在平台里；Mesos 只把 Offer 抛给框架，接受与放置决策在框架手里。结果就是 YARN 换调度策略要动平台，Mesos 换调度语义只需换框架——这也是异构负载混部年代 Mesos 被偏爱的原因。

Q2：Offer 收到了但不使用会怎样？ Offer 不会永久占用：调度器必须显式 decline 或超时未响应，Master 会回收并重新邀约。框架若长期「拿了不用」会拖慢其他框架的分配节奏，生产上应实现 decline 逻辑（并可用 filters 短期内过滤不合适的 Offer 减少空转）。

Q3：FrameworkID 丢了会怎样？ 调度器重启后若不携带原 FrameworkID，Master 会当作新框架注册，旧框架名下任务在 failover_timeout 到期后被全部终止。所以 FrameworkID 必须与集群状态一起持久化在调度器侧，这是实现高可用框架的第一原则。

Q4：单机学习环境需要 ZooKeeper 吗？ 不需要。Master 以 --work_dir 单机模式运行时内置选举即可工作，Agent 与客户端直接指向 Master 地址即可。只有搭建多 Master 高可用集群才必须引入 ZK（--zk 与 --quorum）。本文实测即采用无 ZK 单机形态。

Q5：mesos-execute 的任务在命令行退出后还活着吗？ 不。mesos-execute 默认 failover_timeout 为 0，进程退出即框架注销，运行中的任务随之被终止。想让任务脱离命令行存续，需要显式设置 failover 超时并理解其语义（实测见 CLI 篇），长驻业务应使用真正的框架而非该调试工具。

Q6：Agent 启动报 Failed to locate systemd cgroups hierarchy 怎么处理？ Agent 默认探测 systemd 管理的 cgroup 层级，非 systemd 环境（手工运行、部分嵌入形态）探测失败即拒绝启动。加 --systemd_enable_support=false 关闭该集成即可，本文实测即如此解决；生产 systemd 环境则应保留默认以获得 cgroup 层级托管。

Q7：如何观察某个框架到底占了多少资源？ 三个观测点互相印证：/state 里 frameworks 节点下该框架的 resources 字段（声明量）；/metrics/snapshot 里 allocator 前缀的资源账本（总量与已分配）；master/cpus_percent、mem_percent（主导资源份额）。跨多 Agent 的框架资源是各节点声明量之和。

Q8：现在还要不要学 Mesos？ 分两个目的：以「建集群跑业务」为目的，直接学 Kubernetes，性价比高得多；以「理解两级调度、DRF、多租户资源治理」为目的，Mesos 源码与文档依然是极佳教材——它规模适中、概念完备，且本文实测证明 1.11.0 在 Ubuntu 22.04 上仍可完整编译运行，学习价值不减。