返回 登录
0

Mesos Implicit Roles介绍及实践

本文系作者根据自己在Mesos社区贡献的经验,主要讲解Mesos implicit roles这个新的特性,以及结合自身参与这个特性的设计,开发的过程,讲解这个新的特性在实际应用中应该注意的问题。

【编者按】Role是Mesos中的一个非常重要的概念,Mesos围绕它来定义资源在多个framework之间分配的策略。在Mesos 0.26之前,Mesos集群的操作员可以通过指定–roles这个参数来指定Mesos所支持的Roles,一个framework只能通过Mesos支持的role来加入到Mesos的集群进而接收Mesos所发送的Resource Offer。如果后来有一个新的framework需要加入,集群操作员需要为它新增一个新的role的时候,他就必须重启所有的Mesos Master节点来修改–roles这个参数,这在实际的生产环境上实际上是不可取的,为了解决这一问题,Mesos在0.27版本中引入了Implicit Roles这个新的特性来解决这一问题。

Mesos Roles

在介绍Implicit Roles之前,我们先来大概的了解一下Role在Mesos中的作用。在Mesos中,role主要是用来在各个framework组之间进行资源的配置,也就是说role提供了多个租户之间的资源隔离,使用同一个role来注册的frameworks属于一个租户。在Mesos中和role相关的case主要有以下几种:

1.资源的静态分配。它是在Mesos agent启动的时候你可以把部分资源分配给某些role,或者一次性把所有的资源分配给某一个role。然后Mesos Allocator将会把这个agent上的资源根据DRF算法分配给这个role下注册的所有frameworks。

2.资源的动态分配。在Mesos运行期,集群的操作员可以通过HTTP endpoint为某些role分配一些资源。

3.Quota配置。比如集群操作员可以通过为某个role配置quota来限制这个role下注册的所有framework使用资源的数量,也可以通过配置quota来保证注册在某个role下的所有framework至少有多少资源可以使用。

4.Weight的配置。可以为不同的role来设置不同的weight来修改它们之间资源分配的优先级。

5.配置磁盘组。可以为某个role创建一个persistent volumes,这样就可以隔离不属于这个role的framework来使用这块存储资源。

Implicit Roles前世今生

在介绍Implicit Roles之前,我们先来了解以下它的背景。为了支持在Mesos数据中心运行期间动态配置role这一问题,社区开始的想法是引入一个新的endpoint来支撑dynamic roles,让集群操作员可以在运行时动态的配置roles。本文的作者作为这个proposal owner来简单介绍一下大概的设计:

这个endpoint是这样的:

$ curl -d JsonMessageBodyX POST http://<master-ip>:<port>/roles

例如,如果我们要为新加入的framework新增一个role,则我们可以使用如下的

JsonMessageBody:
{
         "name" : "sales",
         "weight" : 2.0
}

weight参数是可选的,它表示role1的资源分配的优先级,如果在以上的HTTP请求中不指定的话,系统将采用默认值(1.0).在后续的章节中我们将会对weight相关的特性进行介绍,这里不多说明。

后来社区没有采用这个设计的一个主要的原因,是它引入的一个新的endpoint,对集群操作员来说操作过于繁琐,没有Implicit Roles的设计简洁。如果哪位读者对Dynamic Roles有兴趣的话,你可以参考这个proposal的详细设计:
https://docs.google.com/document/d/1OIgceqpsjV3-_LGF83IMAFnrh1Ea3Zc16w9kWWPpUj4/edit#

Implicit Role从字面意思上来看,就是隐含的role,它主要的思想就是Mesos集群操作员将不需要为Mesos集群配置一个合法的role list,所有可能的role(在role所支持的字符集,长度的范围内)都是容许的。因此一个新的framework能不能使用这个role(例如sales)来注册,将主要取决与Mesos ACLs的配置,Mesos将不会额外验证这个role是不是合法的。也就是说如果一个Mesos 集群没有配置任何的ACLs,那么framework可以使用任意的(注:但必须是role所支持的字符集,以及长度)role来注册。

Implicit Roles实践问题归纳

从上边的简介,我想大家已经对Implicit Roles有一个大致的了解,但也会有不少的问题,从我个人的理解,如果你要在实际中使用这个新的特性,你需要注意一下问题:
兼容性问题
作为一个不断快速演进中的开源产品,虽然Mesos到现在仍然没有达到一个比较稳定的版本(V1.0),但它已经应用与很多企业的生产环境(比如国外的twitter,airbnb,苹果的siri等,国内的爱奇艺,豆瓣等),因此在对一个重要特性做大的改进的时候,我们需要考虑兼容性问题。

上边介绍过,在Implicit Roles实现之前,Mesos集群的操作员是通过–roles这个参数来在Mesos Master启动时配置所支持的role list,上层的framework只能使用这些role来注册Mesos。Implicit Roles的设计为了兼顾向后的兼容性问题,它时分了两个阶段来实施的:

1.第一阶段,也就是在Mesos 0.27版本,Implicit Roles只有在Mesos集群操作员在启动Mesos Master时没有指定–roles时生效。也就是说,这个新的特性在0.27版本中,它仅仅改变了–roles这个参数没有指定时的Mesos的行为,如果一个静态的role list在Mesos Master启动时被指定,那么Mesos集群仍然维持原有的行为。为了进一步理解举个例子:

如果你现在安装了0.27版本,但你在启动Mesos Master时指定了–roles:

\# ./bin/mesos-master.sh --ip=127.0.0.1 --work_dir=/var/lib/mesos --roles="sales,enginers"

那么Implicit Roles就被disabled,上层的framework仍然只能使用sales,enginers或者默认的role(*)来注册到Mesos集群,这时和role相关的行为和0.26之前的行为一致,比如集群操作员仍然不能为Mesos中不支持的role(也就是sales和enginers之外的role)reserve资源,配置quota等。

2.第二阶段:也就是大概在一个贬值周期之后,Mesos的贬值周期一般大概为6个月,按照Mesos release的周期来算,大概在Mesos 0.33版本,–roles这个参数将会被废弃掉,如果那时在启动Mesos master时指定了这个参数,Mesos master将会启动失败,告诉你不支持这个参数。

综上所述:也就是在Mesos 0.27版本之后,Mesos不再推荐在启动Mesos master的时候使用–roles参数,建议使用Implicit roles这个新特性。

资源分配的公平性问题

在看了上边对Implicit Roles的详细解释后, 我想大家一个直接的问题就是如果允许framework用任意的role来注册Mesos,那会不会影响Mesos对资源分配的公平性?会不会出现一个不良公民通过注册多个role来恶意使用更多的资源?了解Mesos资源分配的人可能知道,Mesos默认采用的是DRF allocator,它以一个相对公平的原则在各个role之间分配资源,如果有新的role加入,那它势必会影响已有的资源分配格局。Implicit Roles的这个问题它是通过Mesos 的Authentication和Authorization来解决的。

Mesos集群的操作员可以通过配置Authentication,来保证只有信任的framework可以访问Mesos集群。现在的Authentication主要用在以下三个方面:

1.要求farmeworks注册时进行认证。
2.要求计算节点slaves在注册时进行认证。
3.要求集群操作员在使用某些HTTP endpoints访问Mesos集群时进行认证。

Authentication默认情况下是不被激活的,操作员可以在启动Mesos Master的时候通过指定–authenticate,–authenticate_http 和–credentials参数来激活Authentication。这样Mesos集群就可以避免非法的framework来注册Mesos集群。–credentials指定的是一个JSON格式的文件,例如:


{    
  "credentials": [                             
    {                               
      "principals": "swarm",
      "secret": "passw0rd"
    }
  ]
}

另外Mesos集群操作员可以通过配置Authorization来阻止framework以一个非法的role来注册。Mesos Authorization是通过ACLs(Access Control List)来实现的,每一个ACL通过指定一个主题(Subject)来表示它可以对某些对象(Object)做哪些操作(Action)。它是一个JSON格式的配置文件,例如:

{    
  "register_frameworks":  [                             
    {                               
      "principals": {                                 
         "values": ["swarm"]                               
       },  
       "roles":  {
          "values": ["docker-compose", "docker-client"]  
       }
    }
  ]
} 

上文的配置表示只有principal为swarm这个framework才可以注册Mesos集群,并且它只能使用docker-compose和docker-client作为它的role。这样就可以杜绝上层的framework使用非法的role来注册。

综上所述,其实在实际的生产环境,Implicit Roles这个特性必须要和Mesos的Authentication和Authorization结合来使用。

Implicit Roles对其他endpoints的影响

按照对传统设计的理解,既然role作为Mesos的一个重要的实体,Mesos
围绕它来定义各个framework之间共享resource的规则,因此作为Mesos集群的操作员,他/她应该首先在Mesos集群中创建这个role,然后为这个role配置weight,static/dynamic reservation, quota, create persist volume等,然后framework可以使用这个role以及按照对它所定义的规则来使用集群的resources。

Implicit Roles的设计它打破了这一个传统,也就是它不强调上边的操作顺序。也就是说集群的操作员可以为一个不存在的role设置weight,reserve资源,设置quota等。在Mesos 0.26之前,如果你要操作一个不存的role, 则会失败。这种行为的改变影响的endpoints有:

•/master/create-volumes //为Role创建persistent volume.
•/master/quota //为Role配置quota
•/master/reserve //为Role reserve资源
•/master/weights //为一个Role配置weight,这个feature将在Mesos 0.28 release。

未来展望

Mesos到现在的0.27版本,其实对很多的配置都是不支持在运行时进行修改的,比如:Authentication,Authorization,Framework的Meta信息,Agent的配置信息等。从长期来看,作为下一代的数据中心的操作系统,Mesos必须要对Master和Agent节点同时支持在运行时的动态配置,如:可以在Master/Agent运行时,动态的修改Master/Agent的命令行参数; 可以在Framework运行时,修改它的Meta信息等。请大家关注今年的Mesos Conference,将会有专门的topic来介绍Mesos的动态配置。

IBM Platform DCOS Team作为Mesos社区的主要贡献组织,结合自身在资源调度方面丰富的实践应验,通过将自己的资源调度组件EGO与Mesos集成,为Mesos上层framework提供了更多的调度策略,以及一个集中式的资源调度策略配置界面,Mesos集群的操作员可以通过这个界面配置Global Resource Plan.提升了终端用户使用Mesos的体验。

作者简介:

王勇桥(Wechat:gradyYQwang),80后的IT攻城狮,供职于IBM多年,主要从事云计算领域相关的工作,Mesos和Swarm社区的贡献者。平时喜欢在业余时间研究DevOps相关的应用, 对容器化技术,自动化部署,持续集成,资源调度有较深的研究。

评论