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

A刖百国内保险业客户向线上迁徙，对于保险产品和服务形式的期望集中在简单、便捷、透明、个性化以及社交化，开始深耕大健康领域，加快为客户打造全场景、全覆盖的保险服务生态圈.作为一家全球大型保睑金融服务集团，打造"保险+医疗养老”生态闭环，引领服务业和供给侧改革，助力民生发展，服务经济社会.伴随互联网、大数据，以及人工智能等技术的发展，新业务形态、新业务需求乃至新业务创新都对现有IT提出了新的挑战.这就带来了对IT基础设施的敏捷化需求,计箕资源从物理机,到虚拟化,再到IaaS;新一代企业云建设的变点由IaaS来到了PaaS,作为云计算市场的制高点，成了众人追逐的对象.与已经趋向成熟的IaaS和SaaS相比,PaaS仍处于持续演进的过程中，从OPenStaCk和VMware的产品技术动向来看,IaaS与PaaS正快速融合.如今，随着技术和社区的成熟，容器、Kubernetes,微服务等新事物不再只是概念，已在很多企业落地并发挥了生产力，对容器和PaaS的需求也从试探性转向规模化推广和纵深探索，建设企业级容器PaaS平台成为必然趋势.背景技术方面：1 .容器-量变引发质变，形成PaaS平台新契机容器是2016年软件行业七大趋势之首以Docker为代表的容器技术是一种轻量级"虚拟化.（隔离）技术实现应用封装标准化，形成混合云部署标准Container虚拟机VS容器2 .微服务架构引领企业软件架构的变革微服务是一种将应用分割成一系列细粒度服务的应用架构模式微服务与容器成就企业应用开发、部罟和性能伸缩的敏捷，围绕企业的业务的关联性拆分微服务，使IT敏捷带动业务敏捷3 .Kubernetes成为容器编排技术标准为PaaS技术演进，PaaS与IaaS淞合提供基础云原生为企业生产环境运行容器应用而设计企业方面：PaaSApplications企业业务应用系统分层ApplicationsNetworking企业管理黄昌理传统IT微服务和云原生对PaaS的需求越发强烈，必须要用全新的视角建设容器云PaaS平台；PaaS带来的不只是技术的变化，还有开发模式和运维模式的转变,以及IT资源生命周期的管理等,容器云PaaS的建设目标容器云PaaS平台是企业IT集中化建设的基础设施平台，目标一定是结合业务使用场景实际需求，而不是追求大而全，要杜绝技术上的投机主义，做到技术和成本的权衡；构建容器PaaS基础设施，；在容器云PaaS框架下，扩展提供软件定义网络、软件定义存储、权限管理、企业级镜像仓库、统一入口路由.CI/CD.统一管理控制台、监控日志等功能，形成覆盖整个软件生命周期的解决方案，并用套建设DeVoPS工具链、微服务管理平台、IT运营/监控平台.企业需要怎样的一个PaaS平台，首先要认识到云计算技术的豆杂性，比如OpenStack,Kubernetes和Ceph,代表了开源云技术领域的三个典型，企业想用好并不容易，其所涉及到技术栈几乎覆盖全部的计算领域知识，又处于数据中心的底座，牵一发而动全身，企业之大事，存亡之道，不可不察也。不可盲目得追求大而全得功能，花哨的功能，做加法容易，做减法难，PaaS建设的核心需求是数据中心技术底座，健壮、可运维性强、长生命周期支持是根本.建设原则技术先进性和成熟性互联网和开源带来了新技术的迅猛发展，大厂积极参与社区，一定要立足高起点，积极吸收社区的养分，把握技术的方向，选择先进性和成熟度鼬合较好的技术，在保障平台稳定性的基础上，考虑到技术折旧，满足3-5年的技术需求即可.开发性和标准化平台总体设计上一定不能偏离业界标准和实践，充分利用开源社区，例如kubernetes为了保证社区不分裂，推出了一致性认证计划，产品要和主流的技术栈如DevOps工具链、CI/CD,微服务框架保持较好的兼容，松般合+标准化.易于调整，可较好的适应企业现有技术栈和基础环境，可灵活组合，这样也可最大程度的利用已有技术，降低成本.可靠性与安全性安全和可鬼是整个系统建设的基础，豆杂的容器云PaaS平台更是如此，平台需提供良好的可靠性工具，可运维性强、可观测(监控)、可全方位容错、备份恢复与自诊断、良好的debug与故障诊断，确保系统数据的准确性、正确性.合理的技术演进路线考虑到容器云PaaS的技术成熟度，哪些应用要上容器云，数据库要不要上，现在不上何时上，上的话需要具备哪些条件，都需要有合理的规划，采取正确的实施策略，分为一期二期三期甚至更多来实现，正确准确得迈出第一步很关键.风险与应对措施1、容器技术的弱隔离性容器(container),并不是一种虚拟化(virtualization)技术，而是一种进程隔离(isolation)技术，从内核空间、资源和安全等方面对进程做隔离，其不具备和虚拟机以及沙盒(sanbox)一样的隔寓能力，目前以kata为代表的轻量级Vm容器技术还不能成为主流，目前只能选择DoCker(Containerd)作为容器引擎,所以要从业务所使用的技术栈来考虑是否适合容器化，切忌一刀切.2、企业多租户隔离多租户隔离在容器云PaaS主要分为考虑网络上的隰离性，主要分为弱隔离和强隔渤。弱隔离的场景适合同一个组织多个租户使用同一个集群，能达到在遂辑上隔离的目的；强隔离的技术需求通过一个集群很难解决，最好采用多集群的方案，容器云在上层做统一纳管即可；3、配套的DevOps工具链和CI/CD流水线容器的应用交付完全不同于Vm时代，其模糊了开发和运维的边界，需要通过DevOps去解决,需要建设配套的工具链如Helm、JenkinS、统一镜像仓库、CMDB、代码托管仓库、Dockerfile编写等都需要去解决，涉及到的工具很多，配套跟不上,企业内部的采购流程一般又较长，善于利用开源工具去解决这个问题；4、应用的容器化改造应用要上容器云PaaS,比如进行无状态化改造，日志的标准化输出、监控埋点.C1/CD自动化等；产品/技术选型我司从2016年还是对容器技术进行试验性研究，不像现在的Kubernetes一统江湖，当时的COntainer领域docker一家独大，容器编徘领域SWarm、mesos.kubernetes上演三国演义，Mesos定位数据中心技术底座，天然吸引大型企业，kubernetes戴若谷歌的光环，swarm是Docker自家产品，各怀千秋；国内的容器技术创业公司也雨后春笋般出现，可见其火热程度，炙手可热.一圈下来，编排发现落地太难，不知道从何处下手，尚不敢做容器PaaS的假设.就这样时间到了2017年，容器编排领域技术一下失去悬念，Kubernetes脱颖而出；上半年我们就迅速确定了kubernetes作为容器PaaS的技术核心，视线开始转向产品解决方案，建设目标也逐渐清晰起来；作为一个技术底座，容器PaaS的底屣技术健壮性的再要不言而喻，虽然kubernetes已成编排领域事实标准，但kubernetes本身只专注于编排领域，其余的上下游技术栈都由社区提供，怎样良好的集成就成了摆在眼前的难题；经过研究和试用，我们最终把视角投向了OpenshiftjOpenShift是一个私有的基于Kubernetes的企业级PaaS(Platform-as-a-Service)解决方案，基于DOCker和KUberneteS构建,具有Kubernetes的全部优点，又针对Kubernetes的弱项又做了多方面的功能补充，以满足企业在业务应用、开发及运维用户在生产效率上的诉求.OpenshiftVSKubernetesOPenShift项目和KUberneteS项目的定位不同，属于不同层次的创新.Kubernetes项目目的是为了提供一个通用的容器部署和编排平台恻电于提供基础技术支持应用在容器集群环境中的快速部署和运行管理.OpenShift项目的关注点在于为用户提供一个可用的基于容器的应用云平台的解决方案(PIatform-as-a-Service).这个方案包含具体的SDN.日志、储存、高可用、编程框架、U1.自动化等开箱即用的方案。作为基础技术，Kubernetes提供尽可能广泛地支持各种技术和提供最大的可能性.作为接近用户恻的解决方案，OPenShift倾向于从众多的可能性中实现某一种或多种具体的方案.OpenShiftvsKubernetesux、工具、自动化、集成编程平台、中间件Kubernetes容器编排容器引整Wffi.tt（hH志,度胡、高M用、通过OPenShift,企业可以快速搭建瑁定、安全、高效的容器应用平台.在这个平台上：1、可以构建企业内部的容器应用市场，为开发人员快速提供应用开发所依赖的中间件、数据库等服务.2、通过OPenShift,用户可以贯通从应用开发到测试，再到上线的全流程，开发、测试和运维等不同的角色可以在一个平台上进行协作，可以有效地帮助企业推进DevOps,提高资源利用率，提升生产效率。3、支持1.DAP用户权限管理，支持细粒度的权限资源管理。4 .良好的开源社区支持.5、强大的厂商支持和长生命周期管理.6.支持软件自定义网络（SDN）.通过OPenVSWitCh,为用户提供了灵活强健的软件定义网络,可实现监主机共享网络及多租户隔离网络模式；此外，Openshift还支持与红帽认证过的第三方软件定义网络产品进行集成，例如：CiscoContiv,JuniperContraikNokiaNuage,TigeraCalico.VMwareNSX-T.7、支持性能监控及日志管理.OPenShift提供了开箱可用的性能监控及日志管理组件.能快速获取业务的运行状态指标，对业务日志进行收集及分析.8、支持多用户接口.可以通过友好的Web用户界面、命令行工具及RESTfuIAPl放访问和使用OPenShfit提供的各项功能。9、支持自动化集群部署及管理.OPenShift通过AnSible实现了集群的自动化部署，为集群的自动化扩容提供了接口.架构方案主机：虚拟机方案：双方各有千秋，虚拟机部署优点是灵活部署与死置,节点扩容方便，可借助已有IaaS展的能力.迁移灵活，虚世机使用户能够使用image轻松地在主机之间移动工作负载，回滚方便。从平台健壮性上考虑，相当于上了2道保险：虚拟化层和PaaS展；缺点：多了一层虚拟化，从复杂度上讲，整体可靠性会下降；裸金属方案：高性能，无虚拟化层的性能开销，根据性能测试，在裸机上运行Kubernetes和容器，实现了显着降低的延迟-比在虚拟机上运行KUberneteS低大约3倍.社区和厂商也在探索Container-nativeVirtualization,比如kbevirt;从成本上看,虚拟化和容器都是弹性计算的方案，从license成本上考虑，作为用户没必要同时为2个技术买单，因为容器解决了问综合和长远上看,推荐私有云环境下直接上裸金属部署；(备注：本次主要讨论裸金属方案)高可用：对于OPenShift集群来说，有两种类型的高可用.一种是集群自身不同组件的高可用，另一种是运行在集群内部的应用的高可用.OPenShift从设计之初就考虑了这两种不同类型的高可用.对于集群组件高可用来说，OPenShift有多种类型的组件，包括master,etcd,node,router,registry等，每个组件都默认支持高可用的部署.OPenShift的router组件可以通过OCSCaIe命令随时进行扩展，最多可以达到集群node的数量.对于运行在集群内部的应用来说，OPenShift可以将应用的多个实例分散在不同的物理拓扑的domain概念上，比如node,机架,机房等，这样尽可能的保证应用的实例不会再同一时间发生故障。Openshift可以提供对于应用实例运行情况的键康检直探针，当OPenShift发现某个实例异常时，它会在其他的node上重新启动一个新的实例来代替故障的实例，并保证集群内部的应用总实例数量和管理人员配爸的是一致的.OPenShift节点主要分为主控节点(MaSter)和受控节点(NOde),受控节点根据用途又分为基础节点Qnfra)和计算节点(COmPUte),Master*3+Infra*2+Infra*n,具体角色硬件配置配置示例（企业可根据自己情况进行定制）：MaSter控制节点*3Infra-node节点*2Compute-node节点*n角色Srfwr6154Procrswr0U±2S6G2480GSSD5e900GIOKSASkRAm2GWRE吞Mrd1A0)210Gb1*M部署架构图网络架构图网络Openshift使用软件定义网络(SDN)提供集群内部统一的网络环境，可以使集群内部不同节点之间的Pod进行通讯。Openshift的SDN框架是非常灵活的，可以通过配JS切换不同的SDN实现.当前版本的OPenShift使用的是基于OPenVSwitch的VX1.AN方案.该方案为用户提供了两种不同类型的选择,Ovs-SUbnet可以提供一个整体连通的平面网络，所有集群中的Pod默认都是可以直接通讯的;。vs-multitenant提供了PrOjeCt相互隔般的方式，每个ProjeCt有一个独特的VirtualNetworkID(VNID),Project内部的资源可以互通,但是不同Project之间的PodS和服务是无法相互访问的,管理人员可以手动的打通ProjeCt之间的网络，使其可以相互访问.此方案对企业既有网络无侵入性，可快速部若；多租户支持：每个用户项目分配一个惟一的虚拟网络ID(VNiD)防止交叉项目沟通；项目VNIDS可以合并以允许通信；VNID0预留给管理服务，不受限制；节点内的SDN流量1MlPm)OvE10M.MlIsY3r<0utf<M(*5t卬f*M*A*4M<M>>存储持久化存储分为平台内置组件的持久化存储和应用的持久化存储.平台的持久化存储可根据企业已有的存储平台确定，OPenShift本身支持NFS、GIusterFS.CindervCeph等存储.应用系统需要使用持久化数据的，优先建议使用对象存情，其次是使用nas.监控和日志推荐和企业已有的统一监控和日志平台。监控推荐直接使用内置的Prometheus,可定制多层次丰富的告警策略，node节点的基础监控可使用ZabbiX之类的工具作为平台带外监控工具补充，除此还需圣点关注OCP内部基础组件的监控，如etcd、ovs-sdn,router等监控，另外还要增加syslog关堆字监控用来探百平台整体的监控状况，提前处理.平台调度Openshift从APIServer接收到创建Pod的请求以后，会为其安排一个可以运行的节点.在调度的过程中首先会选取所有满足Pod要求的节点，然后根据不同的第法为所有的节点进行打分，最后将Pod调度到合适的节点上.结合Nodelabels和NodeSeIector的使用，可以实现豆杂的pod调度策略.管理员可以为基础设施打上多级标签(比如region=rl,zone=zl,rack=sl),部署应用时可以通过1.abel指定该应用需要运行的基础设施.部署人员可以指定Pod之间的亲和关系(Affinity),将互相访问频繁的Pod同时部署在网络距离短的节点上(比如同一个节点、机架).也可以指定服务的反亲和属性，使同一个服务的多个Pod尽可能的在集群上分散部署(不同的节点、机架、机房)，这样也就提高了服务的高可用性.权限和多租户管理租户是指多组不同的应用或者用户同时运行在一个基础资源池之上，实现软件、硬件资源的共享，为了安全需求，平台需要提供资源隔离的能力.在OCP中，project是一个进行租户隔渤的概念，它来源于kubernetes的namespace,并对其进行了功能的扩展.利用Project,OCP平台从多个层面提供了多租户的支持.1 .权限控制2 .网络陶离3 .Router隔离4 .物理资源池隔商5 .对接外部1.DAP,可实现细粒度的权限控制；6 .根据要求定制个性化SCC角色；负我均衡router本身可做平台层内部的多层次的7层控制,外部还需增加一个负载均衡层,对接企业已有的F5、1.VS.NginX等负载均衡设备,建议新增一层7层控制，分为内网负载均衡器和外网负载均衡器。https证书也JS于这一层，这样router直接启用http的80服务即可.团队组织架构应用系统上云方案上容器云流程开发测试环境流程生产环境流程应用上容器云评估（架构梳理）1 .了解目前项目的架构，确定哪些组件采用容器化方案2 .目前数据库采用传统架构，部署到物理机或虚机3 .微服务架构，单体应用4 .主流微服务框架(SPringaOud、dubb。)的kubernetes方案;混合云下的交付Jenkins+Helm,这里不做展开应用容器化改造过程中应注意的几个问题应用的无状态化，日志输出1、jdk版本是否要升级参考：java开发时企业应用的主力，相信java类开发上容器云是第一要务，jdkll提供原生容器(Containerd)支持，另外JaVa8ul31及以上版本开始支持了Docker的CPU和memory限制.如果应用不能升级jdkll,那就升级到JaVa8ul31.cpulimit即如果没有显式指定-XX:ParameIGCThreadS或者-XX:CIComPilerCoUnt,那么JVM使用docker的CPU限制.如果docker有指定CPUlimitJvm参数也有指定-XX:ParaIlIeIGCThreadS或者-XX:ClComPilerCOUnt,那么以指定的参数为准.memorylimit在java8ul31+及java9,需要力上-XX:+UnIoCkEXPerimentalVMoPtiOnS-XX:+UsecGroupMemory1.imitForHeap才能使得Xmx感知docker的memorylimit.2、Debug工具：不建议将基础镜像搞大，添加过多的dubug工具，BusyBox是一个集成了三百多个最常用1.inUX命令和工具的软件.BusyBox包含了一些简单的工具例如Is、Cat和echo等等，还包含了一些更大、更发杂的工具,例grep、find、mount以及telnet,有些人将BusyBox称为IinUX工具里的瑞士军刀。简单的说BusyBox就好像是个大工具箱，它集成压缩了1.inux的许多工具和命令,也包含了Android系统的自带的SheiI.平台运维过程的几点问题1、一次Node节点hang死的处理记录查看系统syslog发现一下关键日志：rpcerror:code=2desc=ociruntimeerror:execfailed:container_linux.go:247:startingcontainerprocesscaused"openprocselftask124250attrexec:toomanyopenfilesinsystem"更改文件数解决(rootnode0i-)uliait-acorefilesize(blocks,-C)0dataSegsize(kbytes,-d)unliitedschedulingpriority(-e)。filesize(blocks,-f)unliitedpendingsignals(1)1547Q28Mxlocked(evory(kbyte,-D64maxeorysize(kbytes,-)unliaitdopenfiles(-n)2655)5pipesize(S12bytes,-p)8POSIXessagequeues(bytes,q)81920realtirpriority(-r)Ostacksize(kbytes,s)8192cputiae(seconds,-t)unliaitdMxuserprocesses(«)1547028virtualBMK)Ty(kbyt4,.v)UnUaltrdfilelocks()unliaited2,扩容计算节点，新节点的pod报"dialUpJookup.nosuchhost"错误经强,是新塔节点的dnsmasq信息未同步到其他节点上，需串启其他节点的dnsmsq服务；3、扩容新节点后，新节点报错；atomic-openshift-node2588:E070119:02:26.5479942588SUmmary.go:IO2Failedtogetsystemcontainerstatsfor7system.sliceatomic-openshift-node.service,:failedtogetcgroupstatsfor7system.sliceatomic-openshift-node.service,:failedtogetcontainerinfofor*system.sliceatomic-openshift-node.service,:unknowncontainer"system.sliceatomic-openshift-node.service"经iS此为OPenShift的一个bug,参考改如下，ManagerDefaultcPUAccounting=yesDefaUItMemOryACCOUnting=yes# systemdv230ornewer*DefaultIOAccounting=yes# Deprecated,removeinfutureDefaultBlockIOAccounting=yes最后，需重启主机；4,平台升级应用迁移的一些脚本：# 1.全员导出项目# #切换projectocproject<projectName># 新建SprojectNamemkdirVPrOjeCtName-export#导出死置forobjectiningressrouteconfigmapservicerolebindingsserviceaccountssecretsimagestreamtagspodpresetCmSegressnetworkpoliciesrolebindingrestrictionslimitrangesresourcequotaspvcstemplatescronjobsStatefulsetshpasdeploymentsreplicasetspoddisruptionbudgetendpointsderoledoocget-oyaml-export$object>$object.yamldone# #2.豆制到新系群环境下scp.# #3.导入新集群# 切换projectocproject<projectName># 导入配置forobjectiningressrouteconfigmapservicerolebindingsserviceaccountssecretsimagestreamtagspodpresetCmSegressnetworkpoliciesrolebindIngrestrictionslimitrangesresourcequotaspvcstemplatescronjobsStatefulsetshpasdeploymentsreplicasetspoddisruptionbudgetendpointsderoledooccreate-fSobject.yamldone总结企业要想落地容器云平台，人是第一位的,需要数据中心团队、架构团队、开发团队及项目管理团队的密切配合，容器云PaaS上线后，数据中心的运维交付模式发生了变化，逐渐向服务中心和价值中心转变，在计算资源利用率上得到了显著提升，经评估，开发资源池的资源利用率相比虚拟化提升5倍以上；部署上通过helm+Jenkins的交付真正可以做到了一键式交付，GitOps威力逐渐显现；k8s+springboot对微服务的支持可以直接替换负载的springcloud架构，微服务治理的压力得到了极大释放。上云一时爽，一直上云一直爽.