金融行业容器云平台需求分析及架构设计经验总结

金融行业容器云平台需求分析及架构设

计经验总结

通过近十年云化的推进，大多数有一定规模的企业已经实现了基础架构资源的

云化和池化，这里的资源指的是诸如虚拟机、数据库、网络、存储。用户可以

用很短的时间获取业务应用所需的机器、存储和数据库。基础架构资源云化其

实并不是目的，而是手段。最终的目标是让承载业务的应用可以更快地上线。

但现实是，通过laaS获取的大量的基础架构资源并不能被我们的最终业务应用

直接消费。应用还必须进行或繁或简的部署和配置，才可能运行在云化的虚拟

机之上。部署涉及操作系统配置的修改、编程语言运行环境的安装配置以及中

间件的安装配置等。部署的过程在一些企业仍然是通过手工完成，低效且容易

出错。有的企业则是通过简单的自动化方式完成，提高了效率，但是满足不了

后期更高级别的要求，如动态扩容、持续部署。即使勉强通过了简单的自动化

实现，后期随着部署平台类型的增多以及复杂化，维护的难度将会陡然增高，

无法真正做到随时随地持续交付、部署。

基于这个背景，业界需要有一种手段来填充业务应用和基础架构资源的这道鸿

沟。让应用可以做到“一键式”快速的在基础架构资源上运行。为了实现这个

目标，业界出现了多种不同的平台，即服务云的容器方案。最终命运之神的棒

槌砸到了一个叫Docker的开源项目上。Docker通过对Linux内核已有机能的

整合和强化，为业务应用提供了一个绝妙的方案。最后其简单易用的用户命令

行，让Docker快速地获取了巨大的用户基础，也成就了今日其在容器界的池

位。目前Docker结合Kubernetes的解决方案是业界应用最为广泛的容器云解

决方案。Kubernetes是Google开源的容器集群管理系统。它构建Docker技术

之上，为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容等整一

套功能，本质上可看作是基于容器技术的Micro-PaaS平台，即第三代PaaS的

代表性项目。

在1月25日的线上活动交流中,围绕容器云落地金融行业的可行性分析，容器

云和docker/openstack/openshift之间的关系，容器云落地技术细节等方面进

行了讨论，得到了各位专家的支持。大家旬对容器云如何在金融保险行业落地

相关的问题，体现出了高度的参与热情。在此，对大家关注的问题以及针对这

些问题各位专家的观点总结如下：

问题分类解答

一、容器云落地金融行业可行性分析

Q1：在传统应用往容器迁移需要哪些注意事项？是不是所有应用都可以迂移到

容器上？

A1：

从理论上来讲，所有的应用应该都是可以迁移到容器环境的。但是，在实际的

场景中，往往一些需要弹性伸缩，无状态服务的那些应用，会优先考虑使用容

器的场景。传统应用向容器环境的迁移，需要注意到：

1）访问的策略/权限的变化

2）服务拆分，是否是微服务化

3）存储数据，是有状态还是无状态，是临时数据还是持久化存储数据

4）高可用场景

Q2：传统保险行业转型为微服务架构，原来的老架构的业务如何拆分成符合微

服的形式？

A2：

微服务架构在数据层是根据微服务划分把数据分离，但并隔离数据，而是通过

提供数据服务（实现数据中台）为其他微服务或业务应用提供数据支持。因此

一个微服务可以有自己独立的数据库（可能不需要oracle那么强大的数据库

T）o

中间件是需要的，比如消息中间件，需要分布式部署，以支持分布式消息处

理。

数据层数据模型的重构必然会影响业务逻辑的封装

服务编排，和容器编排我们觉得还不一样。我们更希望在服务层去考虑业务逻

辑的编排。容器更多是使用其弹性、无状态等特哇

数据库一般像oracle,mysql都是主从模式或者双主模式，很少有分布式的场

景；中间件，像weblogic有分布式的部署方式

业务逻辑有很大的变化，微服务的架构设计总体上是采用了服务注册，服务发

布等方式对传统的服务进行了拆分，使得各个服务之间解耦

编排一般采用了k8s的容器部署方式来解决

Q3：容器云对业务办理有哪些方面的改革和提升？

A3：

云计算使传统意义上的数据中心从原来的成本中心转变成服务中心，支持向公

司内部输出规范的、有质量保证的服务，降低服务成本、运营成本的同时促进

IT部门运维模式发展变革，简化系统建设、运维工作，提升工作效率。

项目建成后，将会对大地保险IT业务带来如下提升：

X缩短上线周期

云计算的引入能够显著缩短硬件资源、平台环境、应用系统的部署周期，支持

各部门在最短时间内以“随需即取”的方式获取系统部署所需的一切服务资

源，运维管理团队即可根据服务模板实现远程快速部署和动态调整，减少重复

性建设工作，支撑业务的快速发展变化。

入进一步实现绿色节能

云计算构建于池化的硬件资源基础上，并进一步实现服务化封装及更高层级的

细粒度服务复用，从而相应降低对数据中心机房的电力、制冷、空间消耗，实

现机房绿色节能。

入促进运维模式发展变革

针对业务需求部门提供自助式服务，需求部门依据定制的云服务目录选取所需

的计算资源、存储空间、网络服务、基础平台环境等服务项并提交申请，运维

管理团队根据定制成型的服务模板，依靠自动化技术及云管理平台来交付规范

的、有质量保证的服务，将传统运维模式转变为以服务为中心的方式，降低系

统建设、运维、管理工作量。

Q4：PAAS云平台选型？

A4：

总的来说openshifi是基于Kuberenies之上的，所以比k8s要完善些，稳定

性应该说更好些。但openshift商业版费用还是不低，特别是实时费用。不管

k8s或openshift其实目前都不算是成熟的平台，都需要很多额外的工作，因

此如果选择商用版本成本会比较高。在目前基本上都处于概念验证阶段，投资

太大也不见得就一定能有好的收益。所以大多数都是选择开源版本测试，上生

产也大多是非核心业务，无关大局。

基于这个背景，业界需要有一种手段来填充业务应用和基础架构资源的这道鸿

沟。让应用可以做到“一键式”快速的在基础架构资源上运行。为了实现这个

目标，业界出现了多种不同的平台，即服务云的容器方案。最终命运之神的棒

槌砸到了一个叫Docker的开源项目上。Docker通过对Linux内核已有机能的

整合和强化，为业务应用提供了一个绝妙的方案。最后其简单易用的用户命令

行，让Docker快速地获取了巨大的用户基础，也成就了今日其在容器界的池

位。目前Docker结合Kubernetes的解决方案是业界应用最为广泛的容器云解

决方案。Kubernetes是Google开源的容器集群管理系统。它构建Docker技术

之上，为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容等整一

套功能，本质上可看作是基于容器技术的Micro-PaaS平台，即第三代PaaS的

代表性项目。

二、容器云和

docker/openstack/openshift之间的

关系

QI：Docker是必须要和k8s结合使用么？

A1：

docker是容器，可以当独用

k8s是容器调度管理框架，可以调度docker,也可以调度其他支持的容器

docker可以单独的使月在某些环境中，k8s是一个容器的使用平台，通过一些

机制保证了容器在某些流程中的顺利运行。为开发测试生产的流程打通提供了

解决方案

Q2：openstack里好多容器相关的项目，各自特色和成熟度怎样？

A2：

1)zun

Zun是Openstack中提供容器管理服务的组件，彳2016年6月建立。Zun的目

标是提供统一的OponstackAPI用于启动和管理容器，支持多种容器技术。Zun

原来称为Higgins,后改名为Zun。Zun计划支持多种容器技术，Docker,

Rkt,clearcontainer等，目前只支持Docker。OpenStackQueens版本发

布，由于容器社区的火热，一项值得关注的补充则为"Zun"，它在OpenStack

项目中负责提供容器服务，旨在通过与Neutron、Cinder、Keystone以及其它

核心OpenStack服务相集成以实现容器的快速普及。通过这种方式，OpenStack

的原有网络、存储以及身份验证工具将全部适用于容器体系，从而确保容器能

够满足安全与合规性要求。

2)magnum

Magnum是OpenStack口一个提供容器集群部署的服务。

Magnum是一个Pass层的OpenStack项目°

Magnum使用Heat部署一个包含Docker和Kubernetes的操作系统镜像，让容

器集群运行在虚拟机(VirtualMachine)或者裸机(BareMetal)中。

3)kolla

简单来说，Kolla就是充分应用容器特性，实现容器化部署OpenStack服务的

DevOps工具。

Kolla显著的特点是「开箱即用」和「简易升级J,前者由编排工具

(Ansible/Kubernetes)提供自动化支撑,后者则完全是Container的功劳。

Kolla追求为每一个OpenStackService都构建相应的Container,将升级/

回滚的粒度(隔离依赖关系集)降维到Service或Project级别，实现升级/

回滚的原子性。假若升级失败，则直接启动OldVersionContainer完成回

滚。

4)kuryr

Ku:ryr最开始创立的时候，其目的是为了提供Docker与Neutron的连接。将

Neutron的网络服务带给Docker。随着容器的发展，容器网络的发展也出现了

分歧。主要分为两派，一个是Docker原生的CNM(ContainerNetwork

Model),另一个是兼容性更好的CNI(ContainerNetworkInterface)。

Kuryr相应的也出现了两个分支，一个是kuryrTibnetwork(CNM),另一个是

kuryr-kubernetes(CNI)。

Q3：openstack里利用裸机部署k8s容器云平台统一资源池有啥好方法？

A3：

Zun是Openslack中提供容器管理服务的组件，亍2016年6月建立。Zun的目

标是提供统一的OpenstackAPI用于启动和管理容器，支持多种容器技术。Zun

原来称为Higgins,后改名为Zun。Zun计划支持多种容器技术，Docker,

Rkt,clearcontainer等，目前只支持Docker。OpenStackQueens版本发

布，由于容器社区的火热，一项值得关注的补充则为“Zun”，它在OpenStack

项目中负责提供容器服务，旨在通过与Neutron、Cinder、Keystone以及其它

核心OpenStack服务相集成以实现容器的快速普及。通过这种方式，OpenStack

的原有网络、存储以及身份验证工具将全部适用于容器体系，从而确保容器能

够满足安全与合规性要求。

Q4：红帽的openshift平台和kubernets是什么关系？

A4：

OpenShift是一个开源容器云平台，是一个基于主流的容器技术Docker和

Kubernetes构建的云52•台。作为一个开源项目，OpenShift已有5年的发展历

史，其最早的定位是一个应用云平台(PaaS)°在Docker时代来临之前，各厂

商和社区项目倾向构建自己的容器标准，如CloudFoundry的Warden、

OpenShift的Dear,但是在Docker成为主流及社区的技术发展方向后，

OpenShift快速的拥抱了Docker,并推出了市场上第一个基于Docker及

Kubernetes的容器PaaS解决方案。OpenShift对Docker及Kubernetes的整合

和OpenShift项目最大的贡献方红帽有着很大的关系。RedHat是OpenShift

项目最大的贡献者，同时也是Docker和Kubernetes项目重要的贡献方。

OpenShift前几年在容器和PaaS领域的经验积累，叠加上Docker和

Kubemeles容器及容器编排上的特性，一经推出就受到了广泛的关注和好评，

连续两年获得InfeWorld年度技术创新大奖。

通过OpenShift这个平台，企业可以快速在内部网络中构建出一个多租户的云

平台，在这朵云上提供应用开发、测试、部署、运维的各项服务。OpenShift

在一个平台上贯通开发、测试、部署、运维的流程，实现高度的自动化，满足

应用持续集成及持续交付和部署的需求；满足企业及组织对容器管理、容器编

排的需求。通过OpenShift的灵活架构，企业可以以OpenShift作为核心，在

其上搭建一个企业的DcvOps引擎，推动企业的DcvOps变革和转型。

三、容器云落地技术细节

Q1：容器的双活解决方案有哪些？

A1：

从问题的提出来看，可能涉及到几个方面：

1）容器平台的双活

这个主要涉及到多个pod节点之间的冗余或者说高可用，这个k8s的架构可以

保证其高可用

2）容器自身的双活

这个可以由容器平台来保证，保证同时有＞二2个的容器在对外提供服务，如果

容器的数量少于2个的话，立即启动一个相同的的容器，来对外提供服务。

应用多活是根本，容器、虚机都只是手段。

Q2：容器云的持久化存储设计，使用传统存储，还是分布式存储，哪个更加合

适？

A2:

持久化存储一般是通过plungin进行驱动的，无论对于传统存储，还是分布式

存储，驱动的模式都是一样的。

至于到底是采用传统存储，还是分布式存储，主要还是要看存储场景，内容，

以及存储是否需要支持弹性伸缩。传统存储在可靠性，安全性以及易用性方

面，都有比较好的技术支持；分布式存储是最近几年兴起的，在不断的完善中

形成了对传统存储的挑战，无论在技术的成熟度还是服务的支持力度上，相对

传统存储还是有一定的差距的，但是它代表了未来存储发展的方向，有很多企

业投入了很大的精力去发展它，未来肯定会取代大部分传统存储的场景。

Q3：在落地金融保险行业的过程中，对于数据库，对于传统应用的访问策略有

什么特别之处

A3：

1）对于传统应用的访问策略

•Openshift产品推荐通过NodePort类型的Service为某个应用对外暴露一

个服务端口。NodePort类型的Service会在集群中的所有节点上监听一个持定

的端口，访问任意一个计算机节点的端口，即可方问内部容器中的服务。在集

群的所有节点的这个端口都会预留给该应用所用。

•在F5VS的PoolMember中配置所有节点，通过Keepalived来实现HA

•应用系统和用户不用改变现有的访问方式

2）数据库访问方案

内网计算节点可以直接访问数据库

DMZ区计算节点访问数据库有2种方案：

•计算节点直接通过内网防火墙访问该应用数据库

内网防火墙仅开通应用所在节点访问内部数据库的端口，例如本期项目，XXX

应用仅使用2个节点，则防火墙仅开通这2个节点访问XXX数据库的权限

•计算节点经Outbound路由通过内网防火墙访问内网数据。

这oOutbound路由在Openshift中称之为EgressRoutero

因此，内网防火墙仅开通应用所在节点访问内部数据库的端口，例如，应用A

仅通过路由节点A和B访问内部数据库，则防火曙仅开通这2个节点访问A数

据库的权限

Q4：容器云平台在监控方面与传统的环境有什么不同？对日志的处理，有什么

特别之处

A4：

1）传统应用日志

有别于当前流行的容器应用，的传统应用同时一个中间件会运行多个应用，且

应用通过log4j等机制保存在文件中方便查看和排错。因为容器运行的特性，

对于这部分的日志我们需要持久化到外置存储中。

日志的分类如下：

•中间件日志

•dump文件

・应用日志

日志保存在计算节点上挂载的NFS存储。为了规范和方便查找。日志将会按

OCP平台中的namespace建立目录，进行划分。

2)新应用日志

应对分布式环境下日志分散的解决办法是收集日志，将其集中到一个地方。收

集到的海量日志需要经过结构化处理，进而交给需要的人员分析，挖掘日志的

价值信息。同时不同的人员对日志的需求是不一样的，运营人员关注访问E

志，运维人员关注系统日志，开发人员关注应用日志。这样就需要有一种足够

开放、灵活的方法让麻有关心日志的人在日志收集过程中对其定义、分割、过

滤、索引、查询。

OpenShift使用EFK来实现日志管理平台。该管理平台具备以下能力：

■日志采集，将日志集中在一起

■索引日志内容，快速返回查询结果

■具有伸缩性，在各个环节都能够扩容

■强大的图形查询工具、报表产出工具

EFK是Elasticsearch：以下简写为ES)+Fluentd+Kibana的简称。ES负责数据

的存储和索引，Fluentd负责数据的调整、过滤、传输，Kibana负责数据的展

不O

Fluentd无论在性能上，还是在功能上都表现突已，尤其在收集容器日志领域

更是独树一帜，成为众多PAAS平台日志收集的标准方案。

Openshift部署环境使用EI'K进行日志管理。QA环境和生产环境部署描述如

下:

Fluentd以DaemonSet方式部署，将收集宿主机口的docker和OCP日志，并发

送到ESo0CP集群内的每个结点都会启动一个Fluentd容器。

ES用于日志存储，会部署在infra结点，同时配置成replicas=2,实现高可

用。

3）监控

PaaS平台的监控包括系统监控、容器监控等。监控流程由信息收集、信息汇总

和信息展示等几个部分组成。

在Openshift中默认使用kubenetes的监控信息收集机制，在每个节点上部署

cadvisor的代理，负责收集容器级别的监控信息。然后将所有信息汇总到

heapster,heapster后台的数据持久化平台是Cassandra。最后由hawkular从

Cassandra获取信息进行统一的展示。

Q5：容器可以像虚拟机一样漂移么？

A5：

容器的属性不依赖于某一个固定的虚拟机或者物理机，可以在不同的物理机和

虚拟机之间漂移。

需要注意的是，在漂移的过程中，其网络属性需要能够随之进行迁移。这个需

要在配置中将其网络标签支持漂移。

Q6：容器云平台在落地金融机构的过程中，如何进行安全、鉴权方面的设计？

A6：

1）多租户管理

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

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

在OCP中，project是一个进行租户隔离的概念，它来源于kubernetes的

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

供了多租户的支持。

1.权限控制。通过OCP平台细粒度的权限管理机制，管理员可以对不同的

用户和组设置不同project的权限，不同用户登录以后只能操作和管理

特定的project

2.网络隔离。OCP平台使用openvswitch来管理内部的容器网络，提供两

种类型的网络模式，一种是集群范围内互通的平面网络，另一种是

project级别隔离的网络。每个project都有一个虚拟网络ID

(VNID),不同VNID的流量被openvswitch自动隔离。所以不同项目之

间的服务在网络层不能互通。

3.Router隔离。Router是0CP平台一个重要软件资源，它提供了外部清求

导入OCP集群内部的能力。0CP提供了Router分组的功能，不同的

project可以使用独立的Router,不互相干扰，这样就避免了由于某些

应用流量过大时对其他应用造成干扰。

4.物理资源池隔离。在多租户的环境中，为了提高资源的利用率一般情况

下物理资源池是共享的，但是有些用户也会提供独占资源池的需求。针

对这种类型的需求，OCP平台利用nodeSe：ector的功能可以将基础设施

资源池划分给特定的project独享，实现从物理层面的隔离。2)权限

管理对于企业级的应用平台来说，会有来自企业内外不同角色的用户，

所以灵活的、细粒度的、可扩展的权限管理是必不可少的。0CP从设计

初期就考虑到企业级用户的需求，所以在平台内部集成了标准化的认证

服务器，并且定义了详细的权限策略和角色。

5.认证：OCP平台的用户是基于对OCPAPI的调用权限来定义的，由亍

OCP所有的操作都是基于API的，也就说月户可以是一个开发人员或者

管理员，可以和OCP进行交互。OCP内置了一个基于OAulh的通用身份

认证规范的服务器。这个OAuth服务器可以通过多种不同类型的认证源

对用户进行认证。

6