【问题标题】:Limitations in Mesos and Marathon Regarding DockerMesos 和 Marathon 关于 Docker 的限制
【发布时间】:2015-08-24 15:39:30
【问题描述】:

我们有这种情况。

我们有 3/3 的 Mesos 主/从拱门。

每个套筒都是相同的,4GB RAM 和 4 核 CPU。

我们已经启动了 10 个具有 1 核 CPU 和 1GB RAM 的马拉松应用程序。我们启动了容器,但没有使用它们,因为系统说 97% 的 CPU 是空闲的。

现在,我们正在尝试启动另一个具有 3Core CPU 和 2GB RAM 的容器。

不幸的是,我们无法启动容器,根据 Mesos 日志,它说 marathon 拒绝了这个提议,但是所有从节点都没有做任何事情。 Marathon 应用程序本身保持在 Deployment 状态。

如果 mesos 无法为马拉松应用分配资源(如果容器没有利用资源),那么这里的 Docker 集成有什么用。

据我了解:

一旦 marathon 应用程序接受了一个提议,即使 docker 没有使用该资源,mesos 也会认为该资源已经被该应用程序使用了。但是如果容器没有使用任何资源,mesos 需要收集可用资源并分配给下一个马拉松应用程序。

Mesos 会从总资源中减去分配的资源。

我们没有充分利用 Mesos/Marathon 中的 Docker 功能。

如果有任何建议和答案,请告诉我。

谢谢

【问题讨论】:

    标签: docker containers mesos mesosphere marathon


    【解决方案1】:

    Mesos 跟踪“分配”而不是实际使用情况。如果您的应用程序没有做任何事情,这并不意味着它不会在下一刻做任何事情。这意味着,如果您的应用请求 1 个 CPU,则该 CPU 将保留给该应用。

    现在,如果您不想精确估计您的应用正在使用的资源,您可能需要查看oversubscription in Mesos。但您必须记住,一旦应用程序请求了超额订阅的资源,并且这些资源已分配给这些资源,使用超额订阅资源的应用程序可能会被终止。

    【讨论】:

      【解决方案2】:

      Mesos/Marathon 实际上会考虑分配的 10*(1GB + 1CPU),因为这是您的应用程序允许使用的最大值。 所以是的,你的理解是正确的。

      在我看来,你至少有两个选择

      1. 为您的任务分配更少的资源。
      2. 实际上有一个有趣的新功能似乎适合您的用例:oversubscription,它基本上试图利用分配的资源和实际使用的资源之间的这种差异。

      【讨论】:

      • 1.我们在这里遇到了 Marathon 的问题,我们在容器内运行 WordPress 站点,如果我们分配的资源较少,当我们达到最大 RAM 使用量(基于分配)时,容器开始使用 SWAP,这个场景容器需要很长时间回复。我们配置了健康检查,由于容器响应慢,Marathon 正在杀死旧容器并创建新容器。 @js84
      • 2. @rukletsov @js84 如果我们尝试使用超额订阅,我们无法创建所有应用程序,使用超额订阅,他们明确提到如果If any resource used by a task or executor is revocable, the whole container is treated as a revocable container and can therefore be killed or throttled by the QoS Controller.
      • 对,超额订阅是为了尽力而为的任务。如果我正确理解您的情况,您的容器可能会使用所有分配的内存。如果是这种情况,您将无法真正提高利用率,因为您的任务最终需要集群中的所有可用资源。有意义吗?
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2014-03-25
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多