有容云：容器驱动的PaaS平台实现方案（上）

Posted 2020-08-02 有容云

编者注:

本文基于上海容器大会现场演讲内容，立足于实战跟大家分享了新一代PaaS平台构建中遇到的问题、当下主流PaaS平台解析、企业交付经验及心得体会等。文章较长，分为上、下两个部分，本文为上篇。

 

嘉宾介绍：

马洪喜，有容云联合创始人兼首席架构师。此前担任Rancher Labs中国区技术负责人、Citrix公司资深架构师、Oracle公司虚拟化产品开发经理等职务，在容器云、IaaS云、桌面云建设方面拥有较为丰富的经验。

本次大会的大部分朋友都是以用户身份分享了自己家的故事和经验，我作为厂商代表之一，首先是想从一个大的面上跟大家交流下各方面的知识点，另外也给大家分享下我们遇到的别人家的故事，相信对大家有一定借鉴的意义。

 

下面我们进入主题。早上梁博士（编者：指Rancher Labs CEO梁胜博士）也说了，PaaS是一个老的概念了，发展到现在有老一代PaaS也有新一代PaaS，其中新一代我管它叫容器驱动的轻量级PaaS。当下业界我们能看到的一种趋势，大家都在逐渐摈弃老的PaaS技术而拥抱容器驱动的新一代轻量级PaaS。就拿一个我们华南地区的金融客户来说，他们想做一个比DevOps范畴还大的开发运维系统，他们请来了传统PaaS厂商，但是需求始终没能得到满足。后来我跟他们负责人聊的时候就介绍了容器驱动的新一代的轻量级PaaS，或者说是CaaS，然后发现跟他们的需求就配套了。这是一个非常典型的代表。还有一家位于北京的全国性商业银行，跟他们聊的时候他们也在犹豫是采用老一代的PaaS技术还是直接用容器，后来交流了容器驱动的轻量级PaaS技术之后他们就没再邀请传统PaaS厂商来测试了，所有入围测试的都是基于Docker容器技术的厂商。这是一些客户的情况。那么为什么会出现这种情况呢？

通过这张胶片大家可以看到，老一代PaaS技术下的产品有一个特点就是非常重，封闭性比较强。当然，这之中有开源版本也有商业版本，但是如果选择商业版本的的话你不得不等待它的版本和组件发布步调，比如等待一个新版本的Redis组件，程序员都不太喜欢封闭性的东西。而新一代的容器技术无论是基于Kubernetes还是Mesos还是其它技术，它的一个特点就是更轻量，更开放，而程序员会感觉自己在里面可以有贡献，有一种参与感，这是他们的一个区别。所以我们看到，现在的客户有很多都有这种新一代PaaS的需求，很多企业在选择的时候都会考虑以容器为基础的PaaS。有趣的是有些企业可能前两年已经采购了传统PaaS产品，但是今年他们还是会去看看新一代采用容器技术的PaaS到底能给他带来哪些便利。大家都相信未来是采用容器技术实现PaaS的方向，那大家在选择这种容器的PaaS方案或厂商时会重点关注哪些问题呢？我可以给大家稍微分享一下。

某世界500强保险集团

 

1. 开源方案，简单易用 - 这其实也是业界一种共识。你可以是纯粹的开源，也可以是商业开源。所谓商业开源，就是说你可以不是Apache或GPL协议发布，但是你承诺向客户开放所有源代码等，这也是一种开源的形式。

 

2. 需求匹配度高，API丰富，可定制化 – 他们的另外一个要求就是你一定要有非常丰富的API接口。我不一定会用你的portal，但可能我需要做一些功能非常丰富的集成，所有你界面上有的功能API一定都要能实现，甚至说有些隐藏的功能是界面上没有，但是API里一定要有。

 

3. 服务团队能力强 - 服务团队的交付能力不仅仅是厂商或是服务供应商，也包括客户自有团队或者说自有团队跟厂商之间形成的合作和默契。

 

 某全国性股份制商业银行

 

1. 容器管理能力强 - 构建在容器上的PaaS平台，需要容器的管理能力非常强，容器调度、编排策略需求比较丰富。

 

2. PaaS能力快速上线 - 最好客户团队自己就可以快速开发出构建在基于容器之上的PaaS能力模块，不需要依赖于厂商的发布周期。

 

3. 应用配置管理功能丰富 - 我的应用配置，比如说我的CI、CD部署参数并非都一样，在开发、测试、生产等环境不也各有不同。所以我的应用有大量的定制化需求，客户希望平台可以提供灵活的应用配置参数，哪怕是Java栈的内存参数也好，总之应用程序的参数一定要可定制化。

 

某通讯解决方案提供商

 

还有某通讯解决方案提供商，看看他们的关注点：

 

容器网络、存储，灰度发布等 - 他们要求比较细节，首先一点容器网络要求比较高，其次在容器的场景上构建PaaS时我存储的问题怎样解决？还有一个是灰度发布，也是比较领先的课题，包括另外一个某银行客户，他们也提出了这个要求，他们希望应用到的是什么场景呢？比如我想把最新的版本只发送给深圳的IP，而其他地区IP访问还是旧版本，或者是想把新版本只给IT中的某个部门访问，但是其他部门访问的还是旧版本。所以也讨论到是否可以采用比如来源IP，或者用访问标签来做标识和区分。其实对厂商来讲我们可以在不同客户那里听到很多新的的需求，而这些需求可以不断融入到我们产品中来。

 

某省科技厅医疗大数据项目

 

另外这是某省科技厅医疗大数据项目的关注点。我们可以想象，把所有医院血液的大数据都聚集在一起，做一个健康大数据系统，做一些肿瘤早期的预测，某些疾病的筛查等，这是非常有意义的。他们不仅仅是要构建一个PaaS的大数据平台，他们也希望基于容器技术搭建，他们有什么需求呢？

 

1. 混合云能力构建-他们想借力类似国内阿里、腾讯这样的公有云来运作他们的大数据分析系统；

 

2. 容器数据存储，大数据与容器结合-他们希望这个PaaS平台在大数据方面有比较大建树，具备大数据分析能力比较强的特点；

 

3. 本地交付团队-便于随时交流和提供技术支持。

 

以上是我列举的不同行业客户对构建PaaS平台的需求。那我们的理解是什么呢？

我们通过大量的客户交流、客户交付做了一个总结：项目能成功的因素至少有这两点，首先是基于一个优良的框架或者是产品去做你的事情，大部分用户不可能说是完全白手起家，基于Docker就去做，另一方面是比较强的服务交付团队，无论是自己的还是邀请合作伙伴协作的团队，至少这两点都是不可或缺.

 

大家知道，对于Docker来说，它本身只是几十兆的几个安装包，本身只提供了一个命令行的方式，当然现在也提供了Docker Swarm可以实现集群管理 ,但是在生产中还是需要一个容器的管理平台。这样我们通过一个Docker核心的Engine加上一个容器管理平台就构成了完整的容器服务。Container as a Services只是容器应用场景的一部分而已，他并不等于一个完整的PaaS平台,PaaS的范畴比它要大很多。在我们的定义中，一个完整的PaaS应该包括一个很好的容器管理平台作为坚实的基础，上层有部署流水线、大数据、中间件等PaaS能力插件，这我们称之为构建PaaS的基础，但其实这距离企业完整的PaaS需求还不够，还需要一个交付团队去补充。

 

我们到一家客户去聊的时候他们就表示，你上头搞的portal我并不关心，上面所有的东西我都需要跟我的系统做一些对接，所以你们要保证你们产品内件有比较好的机制，丰富的API接口，团队要有能力，能跟我们一起构建符合我们需求的PaaS平台。大家知道，开箱即用的PaaS平台可能并不能满足每个企业的个性化需求，所以构建PaaS有很多个性的需求。

今天我们也看到，很多朋友基于Swarm，Kubernetes、Mesos做了PaaS技术分享，也有一些基于Rancher或者是我们有容云AppSoar的PaaS技术分享。我列出这张图来并非做一个优劣的对比，而是做一个比喻。最著名的三剑客Swarm、Mesos、Kubernetes，它们好比发动机的引擎技术，而Rancher、AppSoar、OpenShift等他们是基于引擎技术之上构建的范围更广的产品或者说平台。可能有些用户会说，ok，我不想花更多的心思去组装发动机、轮子、方向盘，我只是想买一辆直接就能开的车；也有一些用户会说我想要有一些灵活的定制化，我希望配置出来的是一个我最喜欢的性能状态，比如底盘调试等各种都是按照我的意愿来组装的。所以我们这张图就是告诉大家，在选择的时候存在这样两种趋势。

 

我花点时间跟大家谈下我对三种框架的一个粗浅认识。之前也跟梁博士有过交流，这三种技术短时间内暂时还不会出现谁干掉谁的局面，但是就我个人的观点来看，大家选择Kubernetes，或者Docker  Swarm的时候，至少这两种是一个完全的不同的路线，并不是从技术层面来说，而是非技术角度。圈里人都听过，不管是Kubernetes社区还是Docker社区，两者之间是一种PK的关系，包括对网络栈的支持。很有意思的一个故事， Kubernetes之前发了一篇文章说为什么我们不支持Docker的CNM结构而支持CNI，未来会有更多Docker已有的功能 Kubernetes没有，但是Kubernetes会拿另外一种东西来做补充。这就是两个社区背后相关利益既得者，他们的想法不一样。

 

比如说Kubernetes，他们想做的事是未来大家只要用Kubernetes就好，至于底层你采用的Engine、到底是Rocket 还是Docker，你不用关心，你只需要知道Kubernetes就好。对Docker来说，主要的优势是他们有大量用户基础。所罗门曾在一次技术采访被问到面对谷歌这样强大的竞争对手是否有压力时，所罗门的回答是我们并不惧怕任何困难和挑战，因为90%以上的容器用户只用Docker。大家也可以看到，Docker马上就会有自己的生态系统，它会逐步壮大起来。虽然今天的Swarm还相对弱小，但是大家会看到他会逐渐强大起来，所以说对于Rancher也好，对于我们有容云自己也好，我们的选择都是不选边不站队，都支持。

下面我们来谈下整个CaaS框架的示例。本示例虽然是基于我们自有的产品，但是我会用一种通用的方式来告诉大家是什么意思。简单来说，我想用这幅图来告诉大家一个完整的容器管理系统他应该包含哪些方面的功能。首先一点就是对底层多主机的管理。可能有人会说，大部分平台都支持多主机管理，但我相信有一天，我们需要的是一个混合云的状态，我们希望企业在应对我们业务的时候，可以像流水一样把我们的业务任意在企业私有云、或者租用的公有云之间漂移。

 

比如平时我的业务都部署在私有云上，遇到特殊活动比如双十一双十二，充红包、促销等时候我们扩展出来的业务可以自动迁移到公有云上，而且迁移的流量入口也可以从公有云那里进来。未来如果企业要想达成这些能力，Docker是一个非常好的技术组件去完成这件事，但是我们一定要选择一个合适的平台，在未来或者说今天可以很好的管理混合云业务场景的模型。

 

在这基础之上我们有不同方式会对租户或者说业务场景的切割，例如测试、生产等环境的资源等进行切割，实现类似于“多租户”的管理。之前听了一些朋友关于存储、网络的介绍，都讲得非常好，大家也意识到，容器时代我们面临的来自存储、网络的挑战跟虚拟机时代是一样的。并不能说，虚拟机时代我们踩过的坑比如说在VMware上的标准交换机、分布式交换机已经做得很好，自然在容器时代就这些问题都得到了解决。其实在虚拟机上遇到的问题我们在容器上还要再解决一遍，这是IT的现实，甚至说以前虚拟机没遇到的一些新的问题和挑战，也需要容器来解决。

 

就比如虚拟机时代，他们还没有很强的模板和镜像管理功能，但是容器靠近应用，有很多新的玩法，比如你要考虑的应用配置的管理、企业私有镜像的管理等，这些问题你都需要去解决。可能有很多人都在用比较传统的Registry版本一版本二的命令行的方式在做，也可能有另外一些朋友在采取Portus、Harbor这样的开源项目在做，我们有容云有一款产品AppHouse，企业级私有镜像仓库，正是针对这类需求开发的，大家可以去试用下。

 

再往上可能会涉及到更靠近应用方面的功能。比如说应用的调度和编排，就像刚才提到的发动机之说。我想跟大家分享的是：发动机本身非常好，但是我们不应该把所有精力都放在发动机上，因为还要大的全景图需要我们去关注，从大的趋势来说我们的Kubernetes、Mesos、Swarm都只是其中的组件，它的地位很核心，但并不代表你选择Kubernetes就能马上把容器跑起来，你选择一个发动机不能马上就能把车开走。

 

更深入交流的时候有用户甚至提出来，我的ITSM系统，我的像CMDB这样的系统、要怎么样跟PaaS平台做一个对接，这些可能未来都是大家需要考虑的问题。再往上来说就是应用商店了，对于我们今天的主题来说，其实我更想把它叫做一个PaaS Offering 的Layer。这是一个统一管理的门户，也是我认为在一个完整的CaaS中不可或缺的部分。因为我们的PaaS还有很多能力组件在此基础上建立起来。这张图就是为了给大家展示一个完整的CaaS应该包括的能力。

 

（上篇完，下篇更新中。。。）

温馨提示

对Docker容器技术或容器生产实施感兴趣的朋友欢迎加群454565480讨论。我们汇集了Docker容器技术落地实施团队精英及业内技术派高人，在线为您分享Docker技术干货。我们的宗旨是为了大家拥有更专业的平台交流Docker实战技术，我们将定期邀请嘉宾做各类话题分享及回顾，共同实践研究Docker容器生态圈。