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

刖百

国内保险业客户向线上迁徙，对于保险产品和服务形式的期望集中在简单、便捷、

透明、个性化以及社交化，开始深耕大健康领域，加快为客户打造全场景、全覆

盖的保险服务生态圈。作为一家全球大型保险金融服务集团，打造"保险+医疗

养老”生态闭环，引领服务业和供给侧改革，助力民生发展，服务经济社会。伴

随互联网、大数据，以及人工智能等技术的发展，新业务形态、新业务需求乃至

新业务创新都对现有IT提出了新的挑战。

这就带来了对IT基础设施的敏捷化需求，计算资源从物理机，到虚拟化，再到laaS;

新一代企业云建设的重点由laaS来到了PaaS，作为云计算市场的制高点，成了

众人追逐的对象。与已经趋向成熟的laaS和SaaS相比，PaaS仍处于持续演进

的过程中，从Openstack和VMware的产品技术动向来看，laaS与PaaS正快

速融合。如今，随着技术和社区的成熟，容器、Kubernetes、微服务等新事物不

再只是概念，已在很多企业落地并发挥了生产力，对容器和PaaS的需求也从试

探性转向规模化推广和纵深探索，建设企业级容器PaaS平台成为必然趋势。

背景

技术方面：

1.容器・量变引发质变，形成PaaS平台新契机

容器是2016年软件行业七大趋势之首

以Docker为代表的容器技术是一种

轻量级"虚拟化"（隔离）技术

实现应用封装标准化，形成混合云部署标准

VM

A

pD

po

c

ContainerBk

、e

r

虚拟机VS容器

2.微服务架构引领企业软件架构的变革

微服务是一种将应用分割成一系列细粒度服务的应用架构模式

微服务与容器成就企业应用开发、部署和性能伸缩的敏捷,

围绕企业的业务的关联性拆分微服务，使IT敏捷带动业务敏捷

3.Kubernetes成为容器编排技术标准

为PaaS技术演进，PaaS与laaS融合提供基础

云原生为企业生产环境运行容器应用而设计

企业方面：

aaS

传统ITPaaS

企

业

企ApplicationsApplications

管

业

理

管RuntimeRuntime

企

理

业

MiddlewareMiddleware

管

理

尝0/S

唇

VirtualizationVirtualization

理

子

口Server

管

理Storage

Networking

企业业务应用系统分层

微服务和云原生对PaaS的需求越发强烈，必须要用全新的视角建设容器云PaaS

平台；PaaS带来的不只是技术的变化，还有开发模式和运维模式的转变，以及IT

资源生命周期的管理等。

容器云PaaS的建设目标

容器云PaaS平台是企业IT集中化建设的基础设施平台，目标一定是结合业务使

用场景实际需求，而不是追求大而全，要杜绝技术上的投机主义，做到技术和成

本的权衡；构建容器PaaS基础设施，；在容器云PaaS框架下，扩展提供软件定

义网络、软件定义存储、权限管理、企业级镜像仓库、统一入口路由、CI/CD.

统一管理控制台、监控日志等功能，形成覆盖整个软件生命周期的解决方案，并

配套建设DevOps工具链、微服务管理平台、IT运营/监控平台。

企业需要怎样的一个PaaS平台，首先要认识到云计算技术的复杂性，比如

OpenStack,Kubernetes和Ceph，代表了开源云技术领域的三个典型，企业

想用好并不容易，其所涉及到技术栈几乎覆盖全部的计算领域知识，又处于数据

中心的底座，牵一发而动全身，企业之大事，存亡之道，不可不察也。不可盲目

得追求人而全得功能，花哨的功能，做加法容易，做减法难，PaaS建设的核心需

求是数据中心技术底座，健壮、可运维性强、长生命周期支持是根本。

建设原则

技术先进性和成熟性

互联网和开源带来了新技术的迅猛发展，大厂积极参与社区，一定要立足高起点，

积极吸收社区的养分，把握技术的方向，选择先进性和成熟度融合较好的技术，

在保障平台稳定性的基础上，考虑到技术折旧,满足3-5年的技术需求即可。

开发性和标准化

平台总体设计上一定不能偏离业界标准和实践，充分利用开源社区，例如

kubernetes为了保证社区不分裂，推出了一致性认证计划，产品要和主流的技术

栈如DevOps工具链、Q/CD、微服务框架保持较好的兼容，松耦合+标准化，

易于调整，可较好的适应企业现有技术栈和基础环境，可灵活组合，这样也可最

大程度的利用已有技术，降低成本。

可靠性与安全性

安全和可靠是整个系统建设的基础，复杂的容器云PaaS平台更是如此，平台需

提供良好的可靠性工具，可运维性强、可观测(监控)、可全方位容错、备份恢复与

自诊断、良好的debug与故障诊断，确保系统数据的准确性、正确性。

合理的技术演进路线

考虑到容器云PaaS的技术成熟度，哪些应用要上容器云,数据库要不要上，现

在不上何时上，上的话需要具备哪些条件，都需要有合理的规划，采取正确的实

施策略，分为一期二期三期甚至更多来实现，正确准确得迈出第一步很关键。

风险与应对措施

1、容器技术的弱隔离性

容器(container),并不是一种虚拟化(virtualization)技术，而是一种进程

隔离(isolation)技术，从内核空间、资源和安全等方面对进程做隔离，其不具

备和虚拟机以及沙盒(sanbox)一样的隔离能力，目前以kata为代表的轻量级

vm容器技术还不能成为主流，目前只能选择Docker(Containerd)作为容器引擎，

所以耍从业务所使用的技术栈来考虑是否适合容器化，切忌一刀切。

2、企业多租户隔离

多租户隔离在容器云PaaS主要分为考虑网络上的隔离性，主要分为弱隔离和强

隔离。弱隔离的场景适合同一个组织多个租户使用同一个集群，能达到在逻辑上

隔离的目的；强隔离的技术需求通过一个集群很难解决，最好采用多集群的方案，

容器云在上层做统一纳管即可；

3、配套的DevOps工具链和CI/CD流水线

容器的应用交付完全不同于vm时代，其模糊了开发和运维的边界，需要通过

DevOps去解决，需要建设配套的工具链如HelmJenkins、统一镜像仓库、CMDB、

代码托管仓库、Dockerfile编写等都需要去解决，涉及到的工具很多，配套跟不

上，企业内部的采购流程一般又较长，善于利用开源工具去解决这个问题；

4、应用的容器化改造

应用要上容器云PaaS,比如进行无状态化改造，日志的标准化输出、监控埋点、

CI/CD自动化等；

产品/技术选型

我司从2016年还是对容器技术进行试验性研究，不像现在的Kubernetes一统

江湖，当时的领域一家独大，容器编排领域、

containerdockerswarmmesosx

kubernetes上演三国演义，Mesos定位数据中心技术底座，天然吸引大型企业，

kubernetes戴着谷歌的光环，swarm是Docker自家产品，各怀千秋；国内的

容器技术创业公司也雨后春笋般出现，可见其火热程度，炙手可热。一圈下来，

编排发现落地太难，不知道从何处下手，尚不敢做容器PaaS的假设。

就这样时间到了2017年，容器编排领域技术一下失去悬念，Kubernetes脱颖而

出；上半年我们就迅速确定了kubernetes作为容器PaaS的技术核心，视线开始

转向产品解决方案，建设目标也逐渐清晰起来；作为一个技术底座，容器PaaS

的底层技术健壮性的重要不言而喻，虽然kubernetes已成编排领域事实标准，

但kubernetes本身只专注于编排领域，其余的上下游技术栈都由社区提供，怎

样良好的集成就成了摆在眼前的难题；经过研究和试用，我们最终把视角投向了

Openshi代，OpenShift是一个私有的基于Kubernetes的企业级PaaS

(Platform-as-a-Service)解决方案，基于Docker和Kubernetes构建,具有

Kubernetes的全部优点，又针对Kubernetes的弱项又做了多方面的功能补充,

以满足企业在业务应用、开发及运维用户在生产效率上的诉求。

OpenshiftVSKubernetes

OpenShi代项目和Kubernetes项目的定位不同，属于不同层次的创新。

Kubernetes项目目的是为了提供一个通用的容器部署和编排平台侧重于提供基

础技术支持应用在容器集群环境中的快速部署和运行管理。

OpenShift项目的关注点在于为用户提供一个可用的基于容器的应用云平台的解

决方案(Platform-as-a-Service)。这个方案包含具体的SDN、日志、储存、

高可用、编程框架、UI、自动化等开箱即用的方案。

作为基础技术,Kubernetes提供尽可能广泛地支持各种技术和提供最大的可能性。

作为接近用户侧的解决方案，OpenShift倾向于从众多的可能性中实现某一种或

多种具体的方案。

OpenShiftvsKubernetes

ux、工具、自动化、集成…

编程平台、中间件

容器编排-OpenShift

Kubernetes

容器引擎

网络、储存、日志、度依、而可用、部耳…

通过OpenShift,企业可以快速搭建稳定、安全、高效的容器应用平台。在这个

平台上：

1、可以构建企业内部的容器应用市场，为开发人员快速提供应用开发所依赖的

中间件、数据库等服务。

2、通过OpenShi代，用户可以贯通从应用开发到测试，再到上线的全流程,开

发、测试和运维等不同的角色可以在一个平台上进行协作，可以有效地帮助企业

推进DevOps,提高资源利用率，提升生产效率。

3、支持LDAP用户权限管理,支持细粒度的权限资源管理。

4、良好的开源社区支持。

5、强大的厂商支持和长生命周期管理。

6、支持软件自定义网络（SDN）。通过OpenVSwitch,为用户提供了灵活强

健的软件定义网络。可实现跨主机共享网络及多租户隔离网络模式；此外，

Openshift还支持与红帽认证过的第三方软件定义网络产品进行集成，例

如:

CiscoContiv,JuniperContrail.NokiaNuagexTigeraCalico.VMware

NSX-T。

7、支持性能监控及日志管理。Openshi代提供了开箱可用的性能监控及日志管

理组件。能快速获取业务的运行状态指标，对业务日志进行收集及分析。

8、支持多用户接口。可以通过友好的Web用户界面、命令行工具及RESTfulAPI

放访问和使用Openshfit提供的各项功能。

9、支持自动化集群部署及管理。Openshi代通过Ansible实现了集群的自动化

部署，为集群的自动化扩容提供了接口。

架构方案

主机：

虚拟机方案：

双方各有千秋，虚拟机部署优点是灵活部署与配置，节点扩容方便，可借助三有

laaS层的能力。迁移灵活，虚拟机使用户能够使用image轻松地在主机之间移动

工作负载，回滚方便。从平台健壮性上考虑，相当于上了2道保险：虚拟化层和

paas层；缺点：多了一层虚拟化，从复杂度上讲，整体可靠性会下降；

裸金属方案：

高性能，无虚拟化层的性能开销，根据性能测试，在裸机上运行Kubernetes和

容器,实现了显着降低的延迟・比在虚拟机上运行Kubernetes低大约3倍。社

区和厂商也在探索Container-nativeVirtualization，比如kubevirt;从成本上

看，虚拟化和容器都是弹性计算的方案，从license成本上考虑，作为用户没必

要同时为2个技术买单，因为容器解决了问题。综合和长远上看，推荐私有云环

境下直接上裸金属部署；(备注：本次主要讨论裸金属方案)

高可用：

对于openshift集群来说，有两种类型的高可用。一种是集群自身不同组件的高

可用，另一种是运行在集群内部的应用的高可用。Openshi代从设计之初就考虑

了这两种不同类型的高可用。

对于集群组件高可用来说，openshi代有多种类型的组件，包括master,etcd,

node,router,registry等，每个组件都默认支持高可用的部署。Openshift的

router组件可以通过ocscale命令随时进行扩展，最多可以达到集群node的数

量。

对于运行在集群内部的应用来说，openshift可以将应用的多个实例分散在不同

的物理拓扑的domain概念上，比如node，机架,机房等，这样尽可能的保证

应用的实例不会再同一时间发生故障。Openshift可以提供对于应用实例运行情

况的健康检查探针，当openshi代发现某个实例异常时，它会在其他的node上

重新启动一个新的实例来代替故障的实例，并保证集群内部的应用总实例数量和

管理人员配置的是一致的。Openshift节点主要分为主控节点(Master井口受控节

点(Node),受控节点根据用途又分为基础节点(Infra)和计算节点(Compute),

Master*3+Infra*2+Infra*n,具体角色

OCPI

nfraNodex2

Router

R»gto*y

硬件配置配置示例（企业可根据自己情况进行定制）：

Master控制节点*3

Infra-node节点*2

Compute-node节点*n

■低于容

角色CPUKB■V1兄•:.«££■

敷・

两《l

2,480GSSD

IntdXeon

5,900G10KSAS;2,10Gb

ASilver61545ft

2S€GRAIO^2GBWWme（支挎1,IPMI

Processor

r*d1/5/50）

部署架构图

负载均衢

KM

Openshift

区域

EM

网络架构图

Internet

Intranet

I-一一

网络

Openshi代使用软件定义网络(SDN)提供集群内部统一的网络环境，可以使集

群内部不同节点之间的Pod进行通讯。Openshift的SDN框架是非常灵活的，

可以通过配置切换不同的SDN实现。当前版本的Openshift使用的是基于Open

vSwitch的VXLAN方案。该方案为用户提供了两种不同类型的选择Qvs-subnet

可以提供一个整体连通的平面网络,所有集群中的Pod默认都是可以直接通讯

的;ovs-multitenant提供了Project相互隔离的方■式，每个Project有一个独特

的VirtualNetworkID(VNID)Project内部的资源可以互通，但是不同Project

之间的Pods和服务是无法相互访问的。管埋人员可以手动的打通Project之间的

网络，使其可以相互访问。此方案对企业既有网络无侵入性，可快速部署；

多租户支持：

每个用户项目分配一个惟一的虚拟网络ID(VNID)

防止交叉项目沟通；

项目VNIDs可以合并以允许通信；

VNID0预留给管理服务，不受限制；

IHott

47M/U8

OPENSHIFT

节点内的SDN流量

Onp«dnMnt)SwwcXT

OVSpo<t»10Wup

存储

持久化存储分为平台内置组件的持久化存储和应用的持久化存储。

平台的持久化存储可根据企业已有的存储平台确定，openshift本身支持NFS、

、等存储。

GlusterFSxCinderCeph

应用系统需要使用持久化数据的，优先建议使用对象存储，其次是使用nas.

监控和日志

推荐和企业已有的统一监控和日志平台。

监控推荐直接使用内置的Prometheus,可定制多层次丰富的告警策略，node

节点的基础监控可使用zabbix之类的工具作为平台带外监控工具补充，除此还需

重点关注OCP内部基础组件的监控，如etcd.ovs-sdn.router等监控，另外

还要增加syslog关键字监控用来探查平台整体的监控状况，提前处理。

平台调度

Openshift从APIServer接收到创建Pod的请求以后，会为其安排一个可以运

行的节点。在调度的过程中首先会选取所有满足Pod要求的节点，然后根据不同

的算法为所有的节点进行打分，最后将Pod调度到合适的节点上。结合Node

labels和NodeSelector的使用，可以实现复杂的pod调度策略。管理员可以为

基础设施打上多级标签（比如region二rl,zone=zl,rack=si）,部署应用时可

以通过Label指定该应用需要运行的基础设施。部署人员可以指定Pod之间的亲

和关系（Affinity）,将互相访问频繁的Pod同时部署在网络距离短的节点上（比

如同一个节点、机架）＜,也可以指定服务的反亲和属性，使同一个服务的多个Pod

尽可能的在集群上分散部署（不同的节点、机架、机房），这样也就提高了服务

的高可用性。

权限和多租户管理

租户是指多组不同的应用或者用户同时运行在一个基础资源池之上，实现软件、

硬件资源的共享，为了安全需求，平台需要提供资源隔离的能力。在OCP中，

project是一个进行租户隔离的概念，它来源于kubernetes的namespace,并

对其进行了功能的扩展。利用Project,OCP平台从多个层面提供了多租户的支

持。

1.权限控制

2.网络隔离

3.Router隔离

4.物理资源池隔离

5.对接外部LDAP,可实现细粒度的权限控制;

6.根据要求定制个性化see角色;

POLICY:RolesPROJECT:MyProject

Rol«:VKw•一・MkcyBinOig

Ru<<iVerbs.।.・RoleBinding

is：(Mt,MS|UserIexwWwAV

(po<士水•一JUMC1

Rut«RuU

AOI•:can

RMI«RUWHS（§）曲

Rol•:Admin

.J总..1

RuK。3・

UR2

负载均衡

router本身可做平台层内部的多层次的7层控制，外部还需增加一个负载均衡层,

对接企业已有的F5、LVS、Nginx等负载均衡设备，建议新增一层7层控制，分

为内网负载均衡器和外网负载均衡器。

https证书也置于这一层，这样router直接启用http的80服务即可。

团队组织架构

容H团队负费人

应用系统上云方案

上容器云流程

开发测试环境流程

生产环境流程

应用上容器云评估（架构梳理）

1.了解目前项目的架构，确定哪些组件采用容器化方案

2.目前数据库采用传统架构，部署到物理机或虚机

3.微服务架构，单体应用

4.主流微服务框架(SpringCloud、dubbo)的kubernetes方案；

混合云下的交付

Jenkins+Helm,这里不做展开

应用容器化改造过程中应注意的几个问题

应用的无状态化，日志输出

1、jdk版本是否要升级

参考：

/blog/2017/04/04/openjdk-and-containers

/#more-433899

java开发时企业应用的主力，相信java类开发上容器云是第一要务Jdkll提供

原牛容器(contained)支持，另外Java8ul31及以上版本开始支持了Docker的

epu和memory限制。如果应用不能升级jdkll,那就升级到Java8ul31e

epulimit

即如果没有显式指定-XX:ParalllelGCThreads或者-XX:CICompilerCount那

么JVM使用docker的epu限制。如果docker有指定epulimitJvm参数也有

指定-XX:ParalllelGCThreads或者-XX:CICompilerCount,那么以指定的参数

为准。

memorylimit

在java8ul31+及java9,需要力口上-XX:+UnlockExperimentalVMOptions

-XX:+UseCGroupMemoryLimitForHeap才能使得Xmx感知docker的

memorylimit。

2、Debug工具：

不建议将基础镜像搞大，添加过多的dubug工具，BusyBox是一个集成了三百

多个最常用Linux命令和工具的软件。BusyBox包含了一些简单的工具例如反

cat和echo等等,还包含了一些更大、更复杂的工具，例grep、find、mount

以及telnet。有些人将BusyBox称为Linux工具里的瑞士军刀。简单的说

BusyBox就好像是个大工具箱，它集成压缩了Linux的许多工具和命令，也包

含了Android系统的自带的shell。

平台运维过程的几点问题

1、一次Node节点hang死的处理记录

查看系统syslog发现一下关键日志：

rpcerror:code=2desc=ociruntimeerror:execfailed:

container_linux.go:247:startingcontainerprocesscaused"open

/proc/self/task/124250/attr/exec:toomanyopenfilesinsystem

更改文件数解决

[root^nodeOlulimit-a

corefilesize(blocks,•c)0

datasegsize(kbytes,-d)unlimited

schedulingpriority(e)0

filesize(blocks,-f)unlimited

pendingsignals(-i)1547028

maxlockedmemory(kbytes,-1)64

maxme«orysize(kbytes,-m)unlimited

openfiles(n)265535

pipesize(512bytes,•P)8

POSIXqueues(bytes.-q)8192G0

real-ti®epriority(-Oe

stacksize(kbytes,-S)8192

cputime(seconds,-t)unlimited

maxuserprocesses(-U)1547028

virtual(kbytes,-v)unlimited

filelocks(-x)unlimited

2、扩容计算节点,新节点的pod报"dialtcp:lookup...nosuchhost"错误

经食，是新增节点的dnsmasq信息未同步到其他节点上，需重启其他节点的

dnsmsq服务;

3、扩容新节点后，新节点报错；

atomic-openshift-node[2588]:E070119:02:26.5479942588

summary.go:102]Failedtogetsystemcontainerstatsfor

"/system.slice/atomic-openshift-node.service":failedtogetcgroupstats

for"/system.slice/atomic-openshift-node.service":failedtogetcontainer

infofor"/system.slice/atomic-openshift-node.service":unknown

container"/system.slice/atomic-openshift-no