金融行业容器云PaaS平台建设实践.docx

《金融行业容器云PaaS平台建设实践.docx》由会员分享，可在线阅读，更多相关《金融行业容器云PaaS平台建设实践.docx（23页珍藏版）》请在优知文库上搜索。

1、A刖百国内保险业客户向线上迁徙，对于保险产品和服务形式的期望集中在简单、便捷、透明、个性化以及社交化，开始深耕大健康领域，加快为客户打造全场景、全覆盖的保险服务生态圈.作为一家全球大型保睑金融服务集团，打造保险+医疗养老”生态闭环，引领服务业和供给侧改革，助力民生发展，服务经济社会.伴随互联网、大数据，以及人工智能等技术的发展，新业务形态、新业务需求乃至新业务创新都对现有IT提出了新的挑战.这就带来了对IT基础设施的敏捷化需求,计箕资源从物理机,到虚拟化,再到IaaS;新一代企业云建设的变点由IaaS来到了PaaS,作为云计算市场的制高点，成了众人追逐的对象.与已经趋向成熟的IaaS和SaaS

2、相比,PaaS仍处于持续演进的过程中，从OPenStaCk和VMware的产品技术动向来看,IaaS与PaaS正快速融合.如今，随着技术和社区的成熟，容器、Kubernetes,微服务等新事物不再只是概念，已在很多企业落地并发挥了生产力，对容器和PaaS的需求也从试探性转向规模化推广和纵深探索，建设企业级容器PaaS平台成为必然趋势.背景技术方面：1 .容器-量变引发质变，形成PaaS平台新契机容器是2016年软件行业七大趋势之首以Docker为代表的容器技术是一种轻量级虚拟化.（隔离）技术实现应用封装标准化，形成混合云部署标准Container虚拟机VS容器2 .微服务架构引领企业软件架构的

3、变革微服务是一种将应用分割成一系列细粒度服务的应用架构模式微服务与容器成就企业应用开发、部罟和性能伸缩的敏捷，围绕企业的业务的关联性拆分微服务，使IT敏捷带动业务敏捷3 .Kubernetes成为容器编排技术标准为PaaS技术演进，PaaS与IaaS淞合提供基础云原生为企业生产环境运行容器应用而设计企业方面：PaaSApplications企业业务应用系统分层ApplicationsNetworking企业管理黄昌理传统IT微服务和云原生对PaaS的需求越发强烈，必须要用全新的视角建设容器云PaaS平台；PaaS带来的不只是技术的变化，还有开发模式和运维模式的转变,以及IT资源生命周期的管理等

4、,容器云PaaS的建设目标容器云PaaS平台是企业IT集中化建设的基础设施平台，目标一定是结合业务使用场景实际需求，而不是追求大而全，要杜绝技术上的投机主义，做到技术和成本的权衡；构建容器PaaS基础设施，；在容器云PaaS框架下，扩展提供软件定义网络、软件定义存储、权限管理、企业级镜像仓库、统一入口路由.CI/CD.统一管理控制台、监控日志等功能，形成覆盖整个软件生命周期的解决方案，并用套建设DeVoPS工具链、微服务管理平台、IT运营/监控平台.企业需要怎样的一个PaaS平台，首先要认识到云计算技术的豆杂性，比如OpenStack,Kubernetes和Ceph,代表了开源云技术领域的三个

5、典型，企业想用好并不容易，其所涉及到技术栈几乎覆盖全部的计算领域知识，又处于数据中心的底座，牵一发而动全身，企业之大事，存亡之道，不可不察也。不可盲目得追求大而全得功能，花哨的功能，做加法容易，做减法难，PaaS建设的核心需求是数据中心技术底座，健壮、可运维性强、长生命周期支持是根本.建设原则技术先进性和成熟性互联网和开源带来了新技术的迅猛发展，大厂积极参与社区，一定要立足高起点，积极吸收社区的养分，把握技术的方向，选择先进性和成熟度鼬合较好的技术，在保障平台稳定性的基础上，考虑到技术折旧，满足3-5年的技术需求即可.开发性和标准化平台总体设计上一定不能偏离业界标准和实践，充分利用开源社区，例

6、如kubernetes为了保证社区不分裂，推出了一致性认证计划，产品要和主流的技术栈如DevOps工具链、CI/CD,微服务框架保持较好的兼容，松般合+标准化.易于调整，可较好的适应企业现有技术栈和基础环境，可灵活组合，这样也可最大程度的利用已有技术，降低成本.可靠性与安全性安全和可鬼是整个系统建设的基础，豆杂的容器云PaaS平台更是如此，平台需提供良好的可靠性工具，可运维性强、可观测(监控)、可全方位容错、备份恢复与自诊断、良好的debug与故障诊断，确保系统数据的准确性、正确性.合理的技术演进路线考虑到容器云PaaS的技术成熟度，哪些应用要上容器云，数据库要不要上，现在不上何时上，上的话需

7、要具备哪些条件，都需要有合理的规划，采取正确的实施策略，分为一期二期三期甚至更多来实现，正确准确得迈出第一步很关键.风险与应对措施1、容器技术的弱隔离性容器(container),并不是一种虚拟化(virtualization)技术，而是一种进程隔离(isolation)技术，从内核空间、资源和安全等方面对进程做隔离，其不具备和虚拟机以及沙盒(sanbox)一样的隔寓能力，目前以kata为代表的轻量级Vm容器技术还不能成为主流，目前只能选择DoCker(Containerd)作为容器引擎,所以要从业务所使用的技术栈来考虑是否适合容器化，切忌一刀切.2、企业多租户隔离多租户隔离在容器云PaaS主

8、要分为考虑网络上的隰离性，主要分为弱隔离和强隔渤。弱隔离的场景适合同一个组织多个租户使用同一个集群，能达到在遂辑上隔离的目的；强隔离的技术需求通过一个集群很难解决，最好采用多集群的方案，容器云在上层做统一纳管即可；3、配套的DevOps工具链和CI/CD流水线容器的应用交付完全不同于Vm时代，其模糊了开发和运维的边界，需要通过DevOps去解决,需要建设配套的工具链如Helm、JenkinS、统一镜像仓库、CMDB、代码托管仓库、Dockerfile编写等都需要去解决，涉及到的工具很多，配套跟不上,企业内部的采购流程一般又较长，善于利用开源工具去解决这个问题；4、应用的容器化改造应用要上容器云

9、PaaS,比如进行无状态化改造，日志的标准化输出、监控埋点.C1/CD自动化等；产品/技术选型我司从2016年还是对容器技术进行试验性研究，不像现在的Kubernetes一统江湖，当时的COntainer领域docker一家独大，容器编徘领域SWarm、mesos.kubernetes上演三国演义，Mesos定位数据中心技术底座，天然吸引大型企业，kubernetes戴若谷歌的光环，swarm是Docker自家产品，各怀千秋；国内的容器技术创业公司也雨后春笋般出现，可见其火热程度，炙手可热.一圈下来，编排发现落地太难，不知道从何处下手，尚不敢做容器PaaS的假设.就这样时间到了2017年，容器

10、编排领域技术一下失去悬念，Kubernetes脱颖而出；上半年我们就迅速确定了kubernetes作为容器PaaS的技术核心，视线开始转向产品解决方案，建设目标也逐渐清晰起来；作为一个技术底座，容器PaaS的底屣技术健壮性的再要不言而喻，虽然kubernetes已成编排领域事实标准，但kubernetes本身只专注于编排领域，其余的上下游技术栈都由社区提供，怎样良好的集成就成了摆在眼前的难题；经过研究和试用，我们最终把视角投向了OpenshiftjOpenShift是一个私有的基于Kubernetes的企业级PaaS(Platform-as-a-Service)解决方案，基于DOCker和KU

11、berneteS构建,具有Kubernetes的全部优点，又针对Kubernetes的弱项又做了多方面的功能补充，以满足企业在业务应用、开发及运维用户在生产效率上的诉求.OpenshiftVSKubernetesOPenShift项目和KUberneteS项目的定位不同，属于不同层次的创新.Kubernetes项目目的是为了提供一个通用的容器部署和编排平台恻电于提供基础技术支持应用在容器集群环境中的快速部署和运行管理.OpenShift项目的关注点在于为用户提供一个可用的基于容器的应用云平台的解决方案(PIatform-as-a-Service).这个方案包含具体的SDN.日志、储存、高可用、

12、编程框架、U1.自动化等开箱即用的方案。作为基础技术，Kubernetes提供尽可能广泛地支持各种技术和提供最大的可能性.作为接近用户恻的解决方案，OPenShift倾向于从众多的可能性中实现某一种或多种具体的方案.OpenShiftvsKubernetesux、工具、自动化、集成编程平台、中间件Kubernetes容器编排容器引整Wffi.tt（hH志,度胡、高M用、通过OPenShift,企业可以快速搭建瑁定、安全、高效的容器应用平台.在这个平台上：1、可以构建企业内部的容器应用市场，为开发人员快速提供应用开发所依赖的中间件、数据库等服务.2、通过OPenShift,用户可以贯通从应用开发

13、到测试，再到上线的全流程，开发、测试和运维等不同的角色可以在一个平台上进行协作，可以有效地帮助企业推进DevOps,提高资源利用率，提升生产效率。3、支持1.DAP用户权限管理，支持细粒度的权限资源管理。4 .良好的开源社区支持.5、强大的厂商支持和长生命周期管理.6.支持软件自定义网络（SDN）.通过OPenVSWitCh,为用户提供了灵活强健的软件定义网络,可实现监主机共享网络及多租户隔离网络模式；此外，Openshift还支持与红帽认证过的第三方软件定义网络产品进行集成，例如：CiscoContiv,JuniperContraikNokiaNuage,TigeraCalico.VMwar

14、eNSX-T.7、支持性能监控及日志管理.OPenShift提供了开箱可用的性能监控及日志管理组件.能快速获取业务的运行状态指标，对业务日志进行收集及分析.8、支持多用户接口.可以通过友好的Web用户界面、命令行工具及RESTfuIAPl放访问和使用OPenShfit提供的各项功能。9、支持自动化集群部署及管理.OPenShift通过AnSible实现了集群的自动化部署，为集群的自动化扩容提供了接口.架构方案主机：虚拟机方案：双方各有千秋，虚拟机部署优点是灵活部署与死置,节点扩容方便，可借助已有IaaS展的能力.迁移灵活，虚世机使用户能够使用image轻松地在主机之间移动工作负载，回滚方便。从

15、平台健壮性上考虑，相当于上了2道保险：虚拟化层和PaaS展；缺点：多了一层虚拟化，从复杂度上讲，整体可靠性会下降；裸金属方案：高性能，无虚拟化层的性能开销，根据性能测试，在裸机上运行Kubernetes和容器，实现了显着降低的延迟-比在虚拟机上运行KUberneteS低大约3倍.社区和厂商也在探索Container-nativeVirtualization,比如kbevirt;从成本上看,虚拟化和容器都是弹性计算的方案，从license成本上考虑，作为用户没必要同时为2个技术买单，因为容器解决了问综合和长远上看,推荐私有云环境下直接上裸金属部署；(备注：本次主要讨论裸金属方案)高可用：对于OP

16、enShift集群来说，有两种类型的高可用.一种是集群自身不同组件的高可用，另一种是运行在集群内部的应用的高可用.OPenShift从设计之初就考虑了这两种不同类型的高可用.对于集群组件高可用来说，OPenShift有多种类型的组件，包括master,etcd,node,router,registry等，每个组件都默认支持高可用的部署.OPenShift的router组件可以通过OCSCaIe命令随时进行扩展，最多可以达到集群node的数量.对于运行在集群内部的应用来说，OPenShift可以将应用的多个实例分散在不同的物理拓扑的domain概念上，比如node,机架,机房等，这样尽可能的保证应用的实例不会再同一时间发生故障。Op