用户致容器云厂商：我们需要这样的容器云平台应用管理

原题：《容器云之应用管理》

作者：汪照辉 王作敬 中国银河证券股份有限公司 信息技术部IT研发中心

在跟厂商交流的时候我们强调过，对于容器云平台，我们关注的是业务应用管理和安全。其实前面我们也讨论过，对于我们这样的最终用户，是不关心容器云平台是用什么实现的（除了我们几个技术人员），无论Kubernetes、Mesos、Docker Swarm或其他都是透明的。最终用户关注的是容器云平台提供了哪些功能，这些功能是否是他们期望的。在这些功能中，业务应用管理是重中之重。因为用户关心的是其业务，容器云平台只是提供一个工具而已。

要说清楚容器云平台应用管理，不得不重提租户。应用部署运维管理等应该是租户角色下的职责，云计算平台多租户的特性不能在容器云平台就不用它了，前面我们也讨论了使用多租户策略来实现应用隔离、访问控制、服务治理、安全机制等。应用管理也应该是基于租户的，不管私有云或公有云，应用的管理不应该是平台管理员的职责，而应该交给相应的租户。

所以容器云平台初始化时，只需要初始化平台管理员账号，其拥有创建租户和管理资源、分配资源以及平台监控运维的能力。至于说其他虚拟集群管理员、项目管理员、二级管理员什么的，那都是不同的场景、不同的单位可能的角色，不是所有企业都需要的，所以不要总是做一些一厢情愿、画蛇添足的事。让用户自己去定义自己需要的角色最简单最合理，让用户去管理自己的应用，不要什么事都大包大揽给容器云平台管理员。容器云平台管理员要做的事，是维护资源、管理资源、分配资源、创建租户账号、监控平台运行，租户的应用就不要插手了，虽然是私有容器云，但职责也需要划分清晰，界线、范围要明确。不仅是安全管理的需要，也是化繁为简的需要。你想想，一个人管理100个业务服务或业务应用，和10个人各管理10个服务或应用是什么样的差别。如果量再增加呢？量变会导致质变。

所以我们在多租户权限管理设计一文中也讨论过，云计算平台一定要把云计算的特性用起来。平台管理员就让他只做平台管理和平台运维，应用管理员只是使用资源来运维应用。各负其责、各尽其职。应用管理员角色是租户下的角色，这样每个租户独立维护自己的业务服务和应用。平台管理员无需知道租户部署了什么应用、多少应用，只需要关心租户使用了多少资源。

在这样的考虑之下，以业务应用管理为中心，我们觉得容器云平台主界面应该分为平台管理员界面和租户界面。容器云安装初始化之后只有平台管理员，平台管理员登录容器云平台，维护容器集群、节点、网络、存储、租户账户，监控统计资源使用、分租户监控统计资源使用、定义资源动态调整分配规则等。所以，平台管理员界面看起来像这样：

1、DashBoard：平台资源使用情况（总的资源、已使用、可用；多集群或多虚拟集群分集群列示；包括但不限于节点、CPU、Memory、存储、网络等）；以及资源使用最多的top 10租户及使用明细；平台节点情况：节点配置、资源使用，Pods或容器数，资源紧张的予以不同色彩提示；平台Pods/Containers运行情况：Pods量、状态、异常；平台组件使用的Pods和租户应用使用的Pods，两者要分开，不要混在一起。公共镜像统计；平台组件运行状况等；这是管理员登录之后展示的内容，这里没有租户应用的信息。对平台管理员来说，他不应该关心租户应用。

2、基础设施资源中心：这是平台管理员的工作核心。包括集群的维护、配置详情，组件、namesapce、节点、CPU、内存、存储、网络等资源运维。比如namespace创建、节点增删、存储挂载、网络策略配置（支持Calico、Weave Net、Romana网络）等。

3、租户管理中心：平台管理员创建、维护租户账号，为租户分配资源，重置密码等操作。租户账号一经创建不可删除，但可以disable。

4、公共镜像仓库：公共镜像仓库提供公用的中间件镜像（比如Kafka、Spark、Tomcat、MySQL、redis等），所有的租户都可以使用来部署中间件服务。

5、集中日志中心：链接跳转到集中日志中心比如ELK，传递当前管理员账号参数，可以查看平台和组件产生的日志。

6、监控告警中心：链接跳转到监控告警中心比如Prometheus，传递当前管理员账号，可以查看平台和组件的详细运行情况、异常信息等。

7、审计计费：如果有需要可以实现审计计费能力。

8、平台设置：平台的可调配置项管理，以及管理员角色、权限、人员管理。也可能需要实现统一认证、单点登录等设置。比如多个集群可能想一人管理一个集群，那么就可以考虑配置单集群管理员。这些集群管理员的信息由平台管理员来维护。容器云平台不同的组件实现统一认证，一次登录，全平台可用，不用容器云平台登录一遍，日志中心登录一遍，监控中心登录一遍，配置中心再登录一遍等。

平台管理员界面以资源管理为中心，那么租户界面则是以应用管理为核心。首先也是需要一个Dashboard，主要用来展示业务应用/服务的部署运行情况，以及应用的资源使用情况。

1、DashBoard：展示当前租户或用户下主要业务应用或资源使用最多的若干业务应用的运行状况。比如应用的负载、响应时间、并发量、异常请求数；最近5分钟、30分钟、1小时、4小时、8小时、24小时、48小时等运行情况统计；业务应用下服务实例的数量（Pods/容器数量）、运行情况、异常次数，处理请求数、平均响应时间、最大响应时间等；展示业务应用使用的资源情况等，比如历史资源使用，总的和分应用图形展示等。

2、应用管理：应用管理是我们工作中的重中之重，容器云平台只是工具，目的就是为了更好的管理运维我们的业务应用。所以在应用管理界面首先应该展示所有当前租户或用户下部署的业务应用，数量多的话需要分页展示应用列表。

1)应用列表：应用列表列出所有当前租户或用户下的业务应用。包括但不限于应用的名称、运行状态、描述、资源配置和使用、部署时间、部署人员等。通过名称的链接打开应用详情页面。

应用详情：应用详情展示业务应用所能采集的详细信息、统计信息、业务应用的业务服务列表等（业务应用由业务服务编排而成）。

服务列表：服务列表展示当前应用用到的服务情况，一个业务应用至少由一个业务服务编排而成，大部分业务应用都会涉及多个业务微服务，这些业务微服务在服务列表中列出，包括但不限于服务的名称、运行状态、服务描述、资源配置和使用、部署时间等，通过服务名称的链接打开服务的详情页面。

服务详情：服务详情展示当前业务微服务所能采集到的详细信息、统计信息、服务实例列表等（每个服务可能部署1到多个服务实例），弹性伸缩在服务这层实现。

服务实例详情：服务实例详情展示服务实例部署的Pods/容器详细信息、所在节点主机信息、使用的存储信息、使用的网络信息、namespace信息等，Pod/容器、节点、存储、网络、namespace等都可通过名称链接跳转到Pod/容器详情、节点详情、存储详情、网络详情、namespace详情等页面。

3、应用模板：在某些情况下，可能希望使用已经配置好的应用存储为模板，基于模板稍作调整或不作调整直接快速部署为新的应用。

1)服务模板 ：和应用模板类似，只不过是对于业务微服务来说的。

4、服务注册发现中心：服务注册发现是服务治理的基本内容。服务部署之后自动注册到服务注册中心，容器云平台根据采用技术的不同有不同的注册中心实现方式，需要根据具体情况进行选择。我们这里要讨论的是服务注册发现中心要向服务配置中心等提供注册的服务列表信息。

5、服务配置中心：服务配置是我们一直强调的重点，特别采用微服务架构，必须考虑实现服务配置中心。因为微服务实例数量可能会很多，靠人来运维微服务将是一个耗费极大精力的事情。服务配置中心支持微服务运行时配置参数的动态更新，服务配置中心自身的配置可以通过容器云平台来设置，服务配置中心客户端则需要一个配置文件，能够连接到配置中心并从服务配置中心获取和接收服务配置数据。服务配置中心的服务列表信息可以通过容器云平台的注册发现中心来获取，在用户打开服务配置中心时，可以看到其部署的服务，选择服务进入服务参数配置页面。服务的配置参数在服务打包镜像时，按照相应的格式通过配置文件打包进镜像，部署后配置中心自动获取服务的配置参数在配置中心服务参数配置页面列示。参数可以配置默认值。这样，服务从编码、打包、部署、注册、自动发现、参数配置就可以串联起来，更好的实现自动化运维管理。

6、服务网关：服务网关也是服务/微服务治理的重要组件，是服务安全的访问控制的重要屏障。在服务配置完成之后，正式发布之前，往往需要通过服务网关来实现访问控制、转换、路由、过滤、限流等规则。也包括API和OpenAPI管理、负载均衡等机制。

7、权限中心：容器云权限中心设计我们前面也已讨论过，权限中心主要是对角色、用户和权限的维护，也为了支持不同的公司、部门、团队、组等，采用灵活的组织架构设计。一组权限定义一个角色，角色赋予用户，用户可以有多个角色、权限叠加合并继承；组织架构被赋予某个角色，其下的所有用户继承其角色权限，其下的组织架构则不继承其角色权限。这里角色、组织架构的定义完全交给租户自己去定义，不要总是插一杠，想当然的替用户定义一些没用的角色。只要保证容器云平台能够支持不同的需求不同的场景就可以了。

8、基础设施资源中心：这里是租户分配的资源和已经在使用的资源的详细情况。和我们前面应用管理应用服务用到的资源是一体两面，这里从资源的角度来展示，应用管理中通过资源链接也可能会跳转到这里。比如节点信息、Pods信息、网络信息等。基础设施资源包括网络/网络策略、存储/存储卷、节点、namespace、Pods/容器等。Pods/容器和服务实例关联，节点上运行的Pods/容器可以展示出来，存储卷由哪些应用在用，网络的使用情况等从资源的角度可以关联到业务服务实例、业务服务、业务应用。

9、镜像仓库：这里连接到租户私有镜像仓库（主要是业务服务镜像），同时可以访问容器云公共镜像仓库（主要是中间件镜像）。私有镜像仓库由租户自己维护，公共镜像仓库中的镜像只可访问，不可更改（只读权限）。也就是说租户可以使用公共镜像仓库中的镜像部署中间件服务，用于业务应用/业务服务的部署。

10、集中日志中心：从租户角度来看，租户下的用户访问日志中心只能看到该租户的应用/服务的日志，不可以看平台和其它租户的应用/服务日志。租户用户的权限是由权限中心设置的。租户部署的服务在权限中心可以分配给用户基于角色的查看、更新、删除等操作权限。

11、监控告警中心：从租户的角度为租户业务应用/业务服务提供监控告警能力。同样，在监控告警中心也应该实现租户/用户隔离，一个租户不能看到其它租户的业务应用/业务服务的监控数据。

12、调度中心：实现定时、不定时、批量任务的调度。

13、审计计费：用户租户资源使用的统计、计费等。

14、其它可能需要实现的能力。

总的来说所有的功能都是围绕容器云的应用管理来设计和实现的。是以应用/服务为中心，这是我们作为最终用户所关心的地方。容器云平台不是说非要把“容器”二字显示在界面上，而是基于容器技术实现的应用/服务管理运维平台。

扩展阅读：

本文作者更多相关文章：

更多相关内容，请点击阅读原文

长按二维码关注公众号