Mesos 实战之 Constraints

Posted 2021-04-24 小米运维

本篇文章介绍了 Marathon/Mesos 的 Constraints 如何使用，并通过一些实例来深入了解 Constraints 具体的约束策略和可能遇到的坑。

回顾上篇文章： 

概念

Mesos 是什么？

Mesos 是一个集群管理平台。 可以理解为是一种分布式系统的 kernel， 负责集群资源的分配， 这里的资源指的是 CPU 资源， 内存资源， 存储资源， 网络资源等。

在 Mesos 可以运行 Spark， Storm， Hadoop， Marathon 等多种 Framework（框架）。

Marathon 是什么？

Marathon 是一个 Mesos 框架，能够支持运行长服务，比如 Web 应用等。它是集群的分布式 init.d 能够原样运行任何 Linux 二进制发布版本，如 Tomcat、Play 等等。

它也是一种私有的 PaaS，实现服务的发现，为部署提供 REST API 服务，有授权和 SSL、配置约束，通过 HaProxy 实现服务发现和负载平衡。

Marathon 如何支持不同的应用部署策略？

Marathon 通过为应用设置约束来决定应用实例的部署策略，比如把某个应用的实例分散创建到不同的机器或者机架上来提供高容错性，或者把应用的所有实例集中部署到同一类型的机器上。

Marathon 的约束的定义分为三个部分：约束名，操作符和一个可选的约束的值：

约束名可以是 hostname（表示 Mesos Agent 的机器名）或者 Mesos Agent 的一个属性（Mesos Agent 的属性通过–attributes 在启动 Mesos Agent 的时候指定）的名称。

操作符

UNIQUE

UNIQUE 告诉 Marathon 把这个应用的每一个实例部署到属性值不同的机器上，也就是说属性的值相同的机器上只能运行一个这个应用的实例。

比如为某个应用定义如下约束的时候，表示每一个机器上只能运行一个这个应用的实例。

$ curl -X POST -H "Content-type: application/json"
localhost:8080/v2/apps -d '{ "id":"sleep-unique", "cmd":"sleep 60", "instances": 3, "constraints": [["hostname","UNIQUE"]] }'

CLUSTER

CLUSTER 告诉 Marathon 把这个应用的所有实例部署到一组具有相同属性的机器上。

比如某个应用的实例只能跑到某些硬件平台上或者把这些应用实例部署到同一个机架或者地域。比如把某个应用的所有实例部署到 rack-1 上

$ curl -X POST -H "Content-type: application/json"
localhost:8080/v2/apps -d '{ "id":"sleep-cluster", "cmd":"sleep 60", "instances": 3, "constraints": [["rack_id","CLUSTER","rack-1"]] }'

GROUP_BY

GROUP_BY 告诉 Marathon 把某个应用的实例均匀的创建到属性值不同的机器上。

比如为了应用的高可用，你可以通过这个操作符把应用的实例均匀的分散部署到不同的机架或者数据中心。

比如把应用的实例均匀分散部署到不同的机架上

$ curl -X POST -H "Content-type: application/json"
localhost:8080/v2/apps -d '{ "id":"sleep-group-by", "cmd":"sleep 60", "instances": 3, "constraints": [["rack_id","GROUP_BY"]] }'

LIKE
LIKE 接受一个正则表达式作为参数，允许在 slave 节点运行你的任务，这个些节点是正则表达式匹配的节点。

下面的例子是应用在机架 rack-1 到 rack-3 上运行，并均匀分布。

$ curl -X POST -H "Content-type: application/json"
localhost:8080/v2/apps -d '{ "id":"sleep-group-by", "cmd":"sleep 60", "instances": 3, "constraints": [["rack_id","LIKE","rack-[1-3]"]] }'

UNLIKE

和 LIKE 相似，任务只能运行在和正则表达式不匹配的 slave 节点上。

下面的例子是应用不在机架 rack-7 到 rack-9 上运行。

$ curl -X POST -H "Content-type: application/json"
localhost:8080/v2/apps -d '{ "id":"sleep-group-by", "cmd":"sleep 60", "instances": 3, "constraints": [["rack_id","UNLIKE","rack-[7-9]"]] }'

实战

集群背景：

Mesos 集群，拥有 8 个 slave 节点，每个 slave 拥有 32 个 cpu。

接下来我们结合实战，来介绍下 UNIQUE 与 GROUP_BY

先来看一个 unique 的例子

$ curl -X POST -H "Content-type: application/json"
localhost:8080/v2/apps -d '{ "id":"sleep-unique", "cmd":"sleep 60", "instances": 8, "constraints": [["hostname","UNIQUE"]] }'

结果：

由于我们申请了 8 个实例，而我们 Mesos 集群节点下有 8 个 slave，我们可以看到在 marathon 管理界面上每个 slave 只运行了一个实例，符合预期。

如果我们申请的实例数大于我们节点的数量将如何，我们再来看一个例子：

$ curl -X POST -H "Content-type: application/json"
localhost:8080/v2/apps -d '{ "id":"sleep-unique", "cmd":"sleep 60", "instances": 9, "constraints": [["hostname","UNIQUE"]] }'

结果：

由于我们申请了 9 个实例，而我们 Mesos 集群节点下有 8 个 slave，我们可以看到在 marathon 管理界面上状态为 wating，在实际的业务场景中，我们的集群 slave 节点数量是随时发生变化的，而申请的实例数量也是随着业务的需求不断修改的，所以 UNIQUE 是不满足我们的需求的。

我们再来看一个 group_by 的例子

$ curl -X POST -H "Content-type: application/json"
localhost:8080/v2/apps -d '{ "id":"sleep-group-by", "cmd":"sleep 60", "instances": 9, "constraints": [["hostname","GROUP_BY"]] }'

结果：

我们申请的 9 个实例被均匀的分布在这 8 个 slave 节点中，符合预期。

如果我们集群资源比较紧张时 group_by 还能否发布成功并将实例均匀打散，我们先将一台 slave 资源欲占用使其只能分配一个实例，我们再来看一个例子

$ curl -X POST -H "Content-type: application/json"
localhost:8080/v2/apps -d '{ "id":"sleep-group-by", "cmd":"sleep 60", "instances": 16, "constraints": [["hostname","GROUP_BY"]] }'

结果：

我们可以看到在 marathon 管理界面上状态为 wating，由于资源不足导致无法正常发布成功。

总结

为了保证实例可以均匀分布在集群 slave 节点下，我们优先考虑使用 group_by；

但在集群资源紧张，且实例数较大的情况下，即便集群整体资源情况是可以分配所有实例，但由于 group_by 的分配策略还是会出现 waiting 的情况；

需要根据集群规模的大小、剩余资源、期望实例大小、期望的资源等情况综合考虑用哪种分配策略，仅供参考。

长按指纹，一键关注“小米运维”