陈春润
OpsWorld金牌讲师
平安云产品负责人
2016年12月3日，在深圳圣淘沙酒店，运维帮、云技术、Linux中国三大社区联合主办主办了运维世界大会OpsWorld，演讲内容全程无广告，只谈技术，受到了广大观众的一直好评。本文根据刘天斯老师演讲内容整理而成。
【主持人】：接下来给我们带来分享的是中国平安云的产品负责人陈春润，陈春润是中国平安科技云平台事业部分总经理，云产品负责人，目前具体负责平安云整体产品规划和运营，同时负责自动化运营平台和容器服务，华中科技大学计算机专业本科，先后从事过软件开发等科研工作，2007年加入平安后，在技术团队系统架构师团队中任职系统工程师，2013年牵头发起平安云项目，负责云管平台和研发工作，陈春润给我们带来的演讲是容器服务与运维平台的对接，有请陈总。
【陈春润】：刚才肖总把我的介绍在大会念出来了，感觉很不好意思，文本总结和个人总结还是有点不一样，既然已经讲了，我就不再多讲。这个礼堂很有意思，因为我们公司在上上周也是在这几个厅组织了一个平安集团内的交流，我也是在这个地方讲另外一个课题，今天很荣幸能够在运维世界大会的首届场合，跟大家再次分享。
因为我介绍了我是2007年加入平安，加入的时候有两个职业的原则，一个是开发工程师，一个是系统工程师，我相信在座的基本上也是在开发运维这几个岗位工作的同事，运维这个概念本身是很大的，在每个公司承担的任务也不一样，因为平安整个运维团队也有几百人，所以每个不同的人员和岗位所负责的事情不一样，大家的关注点也不一样。我今天是代表平安云的产品和运维团队跟大家讲一下我们在构建服务和考虑服务的运维时，我们是怎么去想的，当然有很多观点跟大家有不一样的地方，这个都没关系，我觉得今天是一个聊天，不是给大家宣导什么，所以有什么讲得不对的地方，欢迎大家一起探讨和指正。
我们做运维或者做一个平台，首先要了解我们解决什么问题或者我们在一个公司什么样的组织架构和什么期望下做这个事情。我们讲平安云及容器服务，首先想到平安这么一个金融企业，为什么想要去做这样一个云平台？为什么会做容器服务？想把这个东西做成什么样的平台，解决什么问题，先给大家简单介绍一下。
今天我会从三个方面介绍整个内容，第一个是背景，这个平台是干什么的，有些什么样的约束，我们是怎么把它做出来的。第二是我们在构建一个平台的时候想怎么运维好它，否则在可靠性方面就很难做到理性的状况。同样的道理，虽然我们是做产品，做运维的产品，但是这个运维的产品本身也会运维，也会交给其他的团队做运维，也是整个开发团队眼中的运维团队所做的事情，所以我会把这几个方面糅合到一起，我会讲平安云在构建的时候如何考虑运维的，把它推给用户的时候，是怎么把它跟运维的过程结合到一起，是这样一个内容。
这个图是给大家认识一下平安云在解决什么问题，这个问题很好回答，目前市面上大家做的尤其是金融企业做的无非两种，一种是基础设施的云服务，一种是各种各样的Paas服务，每个企业的规模不一样，构建的难度和复杂度也不一样，因为平安集团有几十家专业公司做一个内部客户，所以我们在构建一个云的时候，不是一个简单的私有云，是一个企业内部的公有云，对集团其他专业公司来讲我们是一个公有云，但是对集团外的客户来讲是私有云。所以我们在构建的时候，从产品形态、交付的模式、收费的模式基本上会参照公有云的做法，我们第一个学习对象就是亚马逊，包括我们所有产品的购买过程和我们产品的属性，第一个老师是亚马逊，第二个老师是阿里云，我们也会参照他们的做法去做，参照他们做法做出来的产品，第一个就是云主机，现在已经有上万台的云主机在运行，第二个是云磁盘，这是云主机的扩充，还有VPC的服务，也是在私有云比较难的地方，构建内部虚拟的私有云。还有对象存储，数据库服务团队，也在努力把传统的数据库做一些云化的工作，这些事情不是一天就能做成的，我们从2013年到现在，虽然我们花了很多的人力物力，包括各个兄弟单位一起支持，但是整个产品还是成长期，还没有完全成熟，但是已经在企业内部有一些成果。
紧接着就讲容器服务，容器在这几年有很大的热度，每个企业都在尝试，开发经理和CTO们也在想我们公司能不能用容器来解决包括架构的问题、交付的问题，平安也一样，我们也有很多人提出平安容器服务。之前有好多人在做平安容器服务，也在解决具体的问题，效果也都还OK，在平安云的框架下我们做的容器服务也有一个老师，还是亚马逊的容器服务。为什么我们想做这样一个容器服务，而不是通常讲的K8S模式呢？跟亚马逊遇到的问题是一样的，我们已经有一个Iaas的问题，这个解决了存储和网络的问题，我们现在要解决的是容器问题，现在基本上是默认Iaas平台上，我们会优先放在Iaas平台上，这样就有了物理机、虚拟机加容器这样的计算三剑客。这三剑客解决各类金融企业里面对IT基础设施的要求，因为我们有很多包括保险还有银行、证券，所有这些不同的业务模块对计算的要求是完全不一样的，所以我们提出这样一个方式，我们不只是提供虚拟机、物理机，还有提供容器服务，容器服务的目的就是为了解决用户快速交付、做微服务的支撑。
我们的容器服务也会有自己的特色，我觉得每一个云基本上不是公有云还是私有云，没有一个公司做的云和其他公司一样，我们也不会特别强调我们的编排怎么做的，我们支持多么复杂的基础设施，没有这样的场景，我们的场景很简单，就是把它归结为两块，一个是我做自助服务，做好之后开发团队想用这个容器来做应用，可以自主的完成，就像亚马逊穿一个ESS一样，拿到这个容器一样，可以很高级的用它也可以很低级的用它，都没关系，这是第一块。
第二块是我们也想支持流水线，刚才跟其他同事也交流了，我们同事在做一个开发过程的优化项目，就是希望通过流水线来实现整个开发环节的自动化，我们在环境交付这一块就是想实现一键交付，这个一键交付是开发人员直接去交付一整套的环境，点一个键，提交一个版本，后台编译、打包、验证所有搭建的有效性，一步到位。在没有完全实现广义上的一键交付，但是在某些特定场景，我们也实现了一键交付，正在向不同的开发团队推广，这是我们做容器平台要支持的第二个场景，就是支持开发到运维流程的打通，这是我们给容器服务定义的两个最大的场景。
接到这个题目的时候我一直在想，这是运维的大会，我们团队里面大部分都是开发人员，开发各种各样的云产品。不知道大家是否认可一个观点，运维这个团队最大的价值就是交付，就是把你的服务、把你的产品，以可靠的、有效的方式快速交付出去，其实我们做云产品也一样，我做云网络的产品，就是要把云网络交付出去，这个交付就隐含着从无到有做出来和高效的交给用户，还要持续保证服务的可用性，因此可以说，云平台团队除了销售人员之外，其他人员都可以认为是运维人员或者交付人员，因为他们都是在做相互相同的目标。因此我们在构建的时候，我们也在学习SRE的理念，但是我们没有这样一个岗位，我们是对所有产品岗位负责人是这样要求的，你产品设计的时候，必须从产品的生命周期，创建、规划、构建、交付、运维的几个环节来把运维的事情考虑进去。
刚才那两个是大的场景，做自助服务和流水线，从产品的形态和用户在用的场景，我们做了简化，包括一些共有的容器云也好，功能很多，大家会把整个开发的过程全部都考虑进去了。在平安做容器服务还是站在运维角度看的，所以我们把客户的场景做了几个归类，第一个是我们是多租户管理，所以首先会有租户管理，这个租户是针对整个Iaas平台也好，都会涉及到租户的管理。有租户的容器云和没有租户的容器云，或者构建多租户的Iaas的容器云有个特点，我们是要求租户主动地去启用容器服务，不是每个租户在平安云上一创建，就用到容器服务的，不是这样的，我们认为容器服务在目前阶段还是高级产品，也不是一个刚需产品，是一个需要用户主动去申请的服务。申请的过程在我们这边设计是管理员可以划定它的区域，把Iaas的资源池作为一个环境，在这个环境下构建一个独有容器的平台，跟一般做法不一样，我们并没有在一个大的容器平台上划租户，而是在Iaas平台上划租户，Iaas平台给容器平台，这样单租户就OK了，因为底下资源已经划分了。好处就是这个容器的用户可以有自己独立的网络和独立的资源池，不需要跟别的用户混在一起。等下也会看到这种方式给别的平台，给运维也带来了好处。
第二是环境管理，我有一个租户建了一个容器平台之后，他是需要划分它的环境，至少会有开发环境和生产环境，他可以去创建这个环境，每个环境又有独立的资源池和网络，也可以在这个环境设置相应的权限。
第三个是应用管理，这个应用管理对应了企业内部的一些应用或者系统，在平安叫做子系统的管理，它需要部署，这里面就是一个应用，在云平台或者容器服务里就是一个应用，这个应用需要一个人来统筹管理，也是对整个编排来讲，一个应用也是一个编排的单位，我也搭一套一个企业的网站或者门户网站，所有这些都会在容器的应用管理里去设置。
应用的下一层就是服务，每一个集群都对应了一个服务，服务下面就是容器，相应有多个容器。还有一个容器特有的就是镜像管理，也是跟非容器的做法管理不一样。这是我们把它对接为五个，基本上把这五个步骤放在类似于一条生产线上，你可以一步一步往前做，不同角色可以看到不同功能，完成你自己的那一块，具备你相应的权限。
我们做了这样一个产品规划之后，接下来就要落地实现，实现的时候也会把刚才说的一些架构约束带进来，例如容器服务要同时支持物理机和虚拟机，也支持动态的添加资源，我不是买二十台服务器在那里给大家用，我们是把容器的资源池当做动态的资源池，就是利用Iaas的弹性动态来使用，而且我们需要在多个中心，如果用户想多中心部署，我们就在多中心给他创建这样一个容器服务。我们还要解决一些容器搞不定的问题，比如容器服务也好主机也好，肯定会跑到某个网络区里，跟网络区是有边界的，边界的防火墙不在容器范围内，包括还有一些运维系统也不在这个范围内，还有一些外围的数据库服务也不在这个范围内。这些服务也需要统筹进来，所以我们也有一个编排的框架，把容器当成一个产品，如果需要搭建容器的，我就调容器的接口，如果需要开墙我就调网络服务的接口。
因为容器平台做出来之后是要投产的，不投产平台就没有意义了，所以我们在创建这个平台的时候走得比较慢，我们一定要让它能够生产投产的规格，才能让它投产，所以我们兼容原有的ITIL平台。还有一个就是容器的网络，之前有一个容器网络做得不是很好，实际上我们绕过了这个问题，我们用最简单的网络方案来实现，借用底层的网络来做连通性的支持。这个图就展现了我们在多中心多租户的架构上，我们是怎么构建的。原理上很简单，因为多中心已经是多平台，通过一个集中的入口，对所有的平台进行管控，所以我们自己做了一个容器服务，底下对接一个编排的框架，来共同完成这样一个服务。底下有一个图，这个是租户环境，这个环境可以有多个主机，底下的编排就会把容器对应起来，也会跟镜像对应起来。
这是把其中的一块抽出来，中间是一个Caas的Portal，会有自己的数据库，这里写的平安云是平安的Iaas的接口，还有我们公司的资源管理平台，用来做资源的记录和查询，还有Ansible是做远程执行的，执行一些脚本和处理化的动作，还有一些远程登录的代理、镜像的拉取，这些动作都是通过Ansible去控制。中间我们是用registry做编排，因为我们做这个平台体系上已经够复杂了，所以编码这一块我们希望更简单，不需要引入更多的概念，大多数都是围绕刚才的产品定义和场景完成，只要这个编排框架够稳定够轻量，能够把容器编排在相应主机上，管理好镜像就可以了。目的就是不管编排框架怎么演变，我们的产品形态或者我们要实现的功能都是不变的，因为我们主体的功能和策略都在上层去做。还有一个是镜像，也是一个层次结构，不是单独的，这是架构，根据刚才的分解之后的架构。
刚才讲了产品规划我们做完了，产品设计也做完了，第三个是最重要的，是我们要把产品交付出去，交付服务也分为几个步骤，第一个是启动容器服务，但这是很难做的事情，为什么我们叫Caas，是把容器服务当做一个服务了，不是一个容器服务给更多人用，是为每个人或者每个租户建立自己的容器平台，他有自己的编排，有自己的编排体系，有自己的主机，有自己的权限，所以它的可用性是不会影响另外一个租户的，不会在容器管理平面上多个租户干扰，所以当用户在平安云的容器上启动服务，我们会有一系列的过程，当他把容器平台全新搭好。
第二个是创建容器环境，有了容器服务之后，你有你的编排，你可以存镜像，可以管理一些节点，有了这些基础东西，你还没有资源池，接下来就会启用这个环境，有资源池，为这个生产环境添加100台的主机，就可以在某个网站里把这100台的云主机创建好，再做初始化，初始化之后就在主机上安装一个跑起来，接下来你就可以像普通容器用户一样，创建你自己的应用，添加你的服务，管理你的容器。
第三个场景就是编排，因为用容器最简单的方式就是我在主机上命令好拉一个镜像出来，跑起来，这样作用很小，而且基本上要学习，对于要做到自动化交付的产品，我们肯定是要把编排作为最主要的功能，因为平安的交付环节里有架构设计和环境交付，在架构设计的产出，实际上就已经具备了编排的雏形，已经定义了每个组建的非功能性的要求和属性，把它作为一个编排的入口结合起来。
还有新建应用和服务，因为现在面向开发环境在做这个事情，基本上大家来的都知道，每个人来了以后新建一个应用，这个应用可以关联到管理体系的子系统，你创建好应用之后就可以添加，添加好之后构架了应用，应用构建完之后也会产生应用的编排文件。
接下来是服务管理，容器最擅长的是快速扩容，所以在服务里面，最开始就只有一个容器，可以把它变成两个三个，设置相应的策略，启停的策略和镜像的基本设置，所有的设置在这个服务管理。
最后是镜像仓库，这也是对运维团队来讲大家以前不是很关注的，但是我们希望把镜像仓库做成什么服务呢？就是做成普通的公有镜像和私有镜像的管理再加上商城的效果，平安的开发系统太多了，大的系统有一千多个，我们有很多产品是非常不错的，这些产品如果做得好的话，以前没有那么好的团队和方式销售出去，我们也可以组建一个销售团队，现在也有销售团队可以向潜在用户推我们平安的平台，要不要到你们公司落地一下，这当然很好，如果把商城就放在这里，这跟阿里的软件商城一样，把平安的软件改在上面，如果用户想要可以直接用这个商城或者镜像的方式直接交付出去，这是我们在服务交付这一块主要的环节。
这个图是现在已经实现的，刚才讲的那六个步骤，包括启用服务、镜像管理、应用管理编排所有都在这里。
讲到产品是怎么构建、怎么设计的，架构怎么构建的，也讲了交付的这几个环节，我们在不同环节交付不同的产品和功能。接下来讲从运维角度，我们怎么把这个平台，或者我们为了做好这个服务，维护好这个平台，我们需要做的事情。
