容器云厂商普遍难以满足的需求——容器云多租户及权限中心设计
作者：汪照辉 王作敬 中国银河证券股份有限公司 信息技术部IT研发中心
原题：《容器云多租户及权限中心设计》
容器云平台逐步进入到了企业生产环境，但容器云产品化才刚刚起步。很多功能的设计很不完善也很不合理。这篇文章从容器云多租户考虑，提出多租户可能的需求，从而设计出适用不同场景需求的多租户和多租户权限中心能力，更能灵活的满足不同租户的需求。
随着容器技术的火热，不能免俗，我们也尝试引入容器技术搭建私有容器云平台，然后在容器云的基础上逐步实现公司的PaaS平台，以提供给各团队应用托管、应用开发、应用运维的能力，同时希望实现开发测试环境一致性，实现互联网应用或类互联网应用的弹性伸缩，实现手机应用的灰度发布，实现持续集成持续交付的敏捷流程，实现运维自动化等能力。
我们前后接触了10多家容器云厂商，从交流过程中，随着理解的深入，也发现基本上所有的厂商都是基于开源社区版本的功能，很少有自己的想法，难以满足我们的需求，特别是多租户的设计，基本上都是开发人员一厢情愿的想法，没有理解多租户功能。所以这里我们就抛砖引玉讨论下如何看待多租户及多租户权限访问控制的设计实现。
多租户，顾名思义，就是很多人来租用容器云平台的资源来实现自己的应用托管运维需求。那么资源管理与分配就是我们首先需要面对的问题。那么容器云中什么是资源？资源该由谁来管理？如何分配？谁来运维这些资源？谁来使用这些资源？ 是不是一个admin就可以眉毛胡子一把抓，干所有事情？
资源概念很广，对于容器云平台来说，租户是不是一种资源？当然是。但这里我们讨论的只是容器云平台提供的基础资源：计算资源、存储资源、网络资源。
有了资源，那么谁来管理运维分配使用这些资源？目前几乎所有的容器厂商都是由一个容器平台管理员来做所有的事情，这很不合理！
多租户很重要的一点是资源隔离，安全。即便是私有云，也需要考虑相应的安全和业务隔离需求，特别做一个产品时。
从多租户的角度考虑，租户租用容器云平台的资源来托管、开发、部署运维自己的应用、服务。容器云平台需要提供、维护保障租户能正常使用这些资源，同时给租户托管的应用提供服务注册、服务发现、服务配置、日志、监控、预警告警、弹性伸缩、负载均衡、安全等能力。我们要明白的是租户只是租用这些能力，他并不运维这些能力。租户关注的是其托管的应用和服务，他需要做的是利用平台提供的这些能力来无缝的运维他们的应用和服务。
到此，我们就理解清楚了上面的几个问题。租户只是使用/租用资源；容器云平台管理运维这些资源。租户侧重于对自由的应用或服务进行运维。资源由租户申请，容器云平台来分配管理资源。
我们再来讨论下容器云中多租户的可能的案例需求：
■ 案例需求一
不同组织架构支持。租户可能是一个公司、一个部门、一个团队、一个项目组或者简单一个人等。一个公司可能有不同的部门，一个部门有子部门，一个团队可能有多个项目组，一个人可能属于不同的团队不同的项目组……有点头大，是不是？多租户中需要支持不同的组织架构形式，并且这个组织架构是租户自己定义管理的。
图表 1需要支持的租户的不同组织架构需求
■ 案例需求二
权限定义。容器云为租户提供不同的功能，不同功能组件可能面临着不同权限定义的问题。对于租户来说，可以完全控制其下的账户管理，账户管理可能有增删改查等权限；但对资源，只能申请、使用分配到的资源，或者再分配资源给其他用户或角色。而对租户自己的应用可能有查询、部署、运维（配置更新停止启动等）、删除等权限。
图表 2不同功能不同权限定义需求
■ 案例需求三
角色定义、授权。对于部署的应用A， 可能的需求是分配一个用户UserA仅 有应用A运维的角色，用户UserA只有运维应用A的权限。当然用户UserA需要有从镜像仓库更新对应的应用镜像的权限，需要有在日志中心查询应用A的日志的权限，在监控告警中心配置应用A监控告警规则的权限等。当然也可以不赋予用户A此权限。
图表 3角色定义，授权
■ 案例需求四
多租户用户登录。前面提到不同租户下可能有同名用户或同账号用户。同一用户/同一账号也可能属于不同的租户，那么登录的时候如何通过租户账号来区分？
■ 案例需求五
对应用不同资源需求的支持。租户开发的应用可能需要不同的资源类型来支撑，比如某应用B需要内存优化的资源，某应用C需要IO优化和高CPU计算的资源，应用D可能只通用资源就可以，应用E需要GPU资源，等等。这就需要根据不同的应用需求，提供不同的资源支撑。
■ 案例需求六
充分利用现有资源。我们知道容器不占用很多资源，那么为充分有效利用可用的资源，公司内可能有虚拟化资源，也可能有一些淘汰的物理机。是不是可以利用起来部署容器？这些设备配置各异，即便是新购买主机，不同批次配置也可能不一样，这些资源如何能更好的管理和使用？
■ 案例需求七
都把容器列到菜单最显著位置，生怕没人知道他们采用了容器技术。但对于租户来说关心的重点应该是应用，用不用容器，用什么容器，应用部署在哪台主机哪个集群都应该是透明的，都不重要。只要保证资源有效可用，在资源异常情况下能顺利实现应用迁移即可。
回到应用。这里的应用我们指业务应用。一个业务应用可以看作是一个系统，也可以是系统的一个模块，或者组件。一个业务应用可能由多个服务组成，这里就涉及到了服务的编排。每个服务可能需要部署一到多个服务实例，每个服务实例运行在Pods或容器中。Pods或容器和主机、存储、网络等资源相关，主机上有CPU、Memory等资源。我们希望我们运维一个应用时，不同层次的对象可以有效平滑的关联起来，就像一个人，有骨架，有血肉，是一个整体。而不是点这里一下，再点那里一下，跳来跳去。
图表 4应用管理
■ 案例需求八
同时业务服务涉及到镜像仓库、服务的注册发现、服务配置、服务部署策略、服务运行监控、服务弹性伸缩、服务负载均衡、异常迁移、自动恢复等。每个租户登录时可能只希望看到镜像仓库、日志、监控告警、配置等中自己相关的信息，不希望其他租户看到自己的信息。
■ 案例需求九
多租户还有重要的一点就是安全和资源隔离。租户用户不需要连接登录远程容器云资源主机或容器引擎。我们说了，容器资源由容器平台来运维，租户只是使用资源。不管私有云或公有云，理念要一致，不能随意而为。否则安全就无法保证。
基于上面提到的需求，我们看下怎么实现。看起来挺复杂，其实也很简单。只有想不到，没有做不到。
从目前国内各厂商的实现来看，没有能满足以上需求的， 也没有厂商认真考虑上面的问题。
多租户设计，需要考虑到租户的权限访问控制，这涉及到容器云平台整体的权限控制架构，所以这里我们提出了一个权限中心的概念，实现一个权限中心，由权限中心来实现对容器云各组件及各功能的动态控制，以适应灵活的不同的场景需求？
一、 组织结构的实现可采用类似论坛的层次结构方法，无论多少层多少级，只标注其父结点ID，树型结构遍历可以获得所有的结点。这也是我们下面权限访问控制实现的基础。
二、由于每项功能可以提供不同的操作，所以定义权限时很难用统一的权限名称来定义，这里可以借助Oracle数据库的权限定义，比如应用管理，有部署、查看、运维、删除等权限；租户资源管理，有申请、使用、再分配等权限。
三、角色定义，就需要基于用户及用户组织结构，权限和容器云提供给租户的功能列表来实现。可以采用Oracle 数据库的用户角色权限定义方式来定义。容器云平台初始化时可以预定义角色，比如租户管理员角色、应用管理员角色等。
四、用户登录我们借用Windows domain的概念，一个租户就是一个domain。租户账号就是domain name。 登录时指定domainName\useraccount的方式登录。根据定义的角色权限展示不同用户视图。以租户账号登录时，可以不用指定domain登录。 租户/用户账号是有效的Email Address。租户账号是超级用户账号。
五、资源管理需要容器云平台来支撑，简单的方式是通过标签来进行资源分类。 一方面可以方便的充分有效的利用公司内资源，另一方面也有针对性的对应用不同资源需求提供支持。再者也可以简单实现资源隔离。
这样组织结构可支持不同的需求变化，每用户（人员）有从属于租户（domain）下的自己的账号。租户可定义不同的角色，角色赋予用户，用户可有多种角色、角色权限可继承。用户使用资源重点关注应用的运维。
之所以把权限访问控制提取出来实现一个统一的权限中心组件，是因为整个容器云平台，各个组件都面临着权限访问控制需求。从云计算的理念来说，松耦合，插件式的组件或模块设计更灵活和适用快速变化的需求。对一个客户来说，一个组件可能需要也可能不需要，每个组件都可以以插拔的方式来控制，根据客户需求来部署相应的组件，实现相应的权限访问控制，将会更灵活和便利。
更多相关文章，请点击阅读原文
长按二维码关注公众号