作者Y147258369·2021-12-05 20:26

云计算架构师·某城商银行

某城商银行生产容器云平台建设实践经验分享

字数 9031阅读 8245评论 4赞 6

# 文章摘要：
本文以城市商业银行数字化转型为背景，对城商银行传统应用迁移容器云平台的实践经验进行总结，探索出适合城市商业银行特有金融架构特征的容器云平台建设路线。从业务需求出发，通过建设以容器云平台为基础的底层IT资源平台，为业务发展提供安全、稳定、可靠、灵活的支撑。同时，本文也针对容器云平台落地面临的容器存储、容器云网络、以及DevOps建设等问题进行实践经验分享。

# 一、   容器云平台建设背景
随着互联网金融的兴起，互联网企业依托互联网，特别是移动互联网为公众提供越来越多方便快捷、稳定高效的服务，对传统的金融行业带来了很大冲击。为了应对此场景，银行业以金融科技为依托，通过科技创新引领银行的转型升级，基于业务发展的需要和快速发展的容器技术，金融行业也在思考自身的互联网化战略、容器云规划等。其中重要内容之一，是希望从技术层面更有效地支持业务创新，如使用微服务架构实现更高的灵活性、扩展性、高可用性，更高效的业务上线效率等，IT部门需要解决这些问题从而更好的提升研发和运维团队的生产力，从而更加灵活、高效、快速的满足业务系统需求，更好提升业务价值。随着容器技术的不断发展和完善，容器云的价值也逐渐被发掘出来,跟随云计算技术发展的趋势，建设并推广适合自身的基于容器技术的云平台是关键任务。

# 二、   需求分析
在明确建设容器云平台这一目标的基础上，我们对现有的需求场景进行了梳理：
(一)    随着行业内市场竞争的越发激烈，业务部门的需求变化越发频繁，有着对研发部门的软件交付周期越来越短的需求；同时推进标准化应用的部署和交付，采用容器镜像的方式实现运行环境的标准化，屏蔽应用部署过程中针对不同环境需要的环境配置、安装步骤等复杂过程。把原先部署、配置的运维工作提前到开发交付阶段，在制作镜像的阶段解决运维上线中出现的问题；

(二)    促进DevOps的落地实施：结合容器的理念及其技术特点，能够更好的与CI/CD技术进行融合，促进CI/CD理念的落地，可从技术手段上保证项目管理方式和管理理念的真正有效落地；

(三)    有效整合现有资源：容器可运行在多种云平台环境中，比如裸金属，传统IAAS平台（vSphere、Openstack），公有云等，可利用企业已有异构基础资源的统一化管理，这种统一管理应用的模式屏蔽环境差异性，降低系统运维难度；

(四)    提升资源利用率：容器是基于操作系统的轻量级虚拟化技术，与传统的虚拟技术相比，多个容器可以共享操作系统的内核进程和内核资源，从而有效节省操作系统级资源开销， 通过容器密度的提升更好的利用资源；

(五)    加速企业软件资产积累：镜像仓库通过对应用镜像的集中管理可实现类似应用商店的功能，有利于更好的沉淀和积累企业软件资产，从而更加快速高效的提供各种运行环境。

(六)    为满足业务的监管和安全要求，平台需要考虑应用的高可用性和业务连续性、多租户安全隔离、不同等级业务隔离、防火墙策略、安全漏洞扫描、镜像安全、审计日志等。

# 三、   总体设计
首先，根据需求分析确定容器云平台需要具备管理大规模容器集群能力，包括：提供容器所需的高可用集群、资源池管理、网络通信方案、存储方案、编排调度引擎、微服务运行框架、镜像管理、事件告警、集群监控和日志收集等。最终设计容器云功能架构如下图所示：
![](/home/attachment/202112/05/1254057_163870634732753.png)

其次就是构建PaaS平台的技术原型，PaaS平台为开发人员提供了构建应用程序的环境，加快应用开发速度，实现平台即服务。经过对需求的梳理后，针对平台总体技术栈进行了选型，选定了基于Intel至强可扩展处理器的物理服务器部署容器云平台，使用Docker和Kubernetes等云原生技术实现核心的PaaS平台，使用HAProxy和F5负载均衡设备实现平台及业务访问高可用，使用Habor和制品库作为镜像仓库。实现架构如下图所示：
![](/home/attachment/202112/05/1254057_163870637668832.png)
PaaS平台是通过提高基础设施的敏捷而加快业务的敏捷，与此同时，DevOps则是在流程交付上加快业务的敏捷，通过DevOps可以实现应用的持续集成，持续交付，加快价值流交付，实现业务的快速迭代。为了实现此目的我们设计在开发测试环境和生产运营环境部署两套PaaS平台，开发环境与代码仓库，项目管理等工具集成支撑开发测试需求。生产运营区与自动化平台、ITSM管理系统等集成，实现标准规范化，流程可控化，达到稳态和敏态双态运营。同时开发测试环境与生产环境通过开放特定端口进行镜像复制，满足安全要求。具体架构如下图所示：
![](/home/attachment/202112/05/1254057_163870640739911.png)

# 四、   详细设计
## （一）资源池管理
本次部署将容器云部署在基于Intel至强可扩展处理器的物理服务器上，为软件开发测试提供基础运行环境。

2021年4月7日,英特尔正式发布了旗下第三代英特尔® 至强® 可扩展处理器，采用了英特尔最新的Ice Lake架构，代号Ice Lake SP。
![](/home/attachment/202112/05/1254057_163870644292443.png)

作为新一代数据中心平台的核心产品，第三代至强可拓展处理器Ice Lake-SP基于10nm制程工艺，并采用Sunny Cove微架构，HCC芯片共有28个核心，XCC芯片则最多可提供40个核心，支持8通道DDR4 3200内存以及新一代傲腾持久内存200系列，提供64条PCIe 4.0通道。
![](/home/attachment/202112/05/1254057_163870650478147.png)

第三代英特尔® 至强® 可扩展处理器主打内置AI加速特性，英特尔表示其AI性能比上一代快74%。也支持硬件级安全功能和硬件级数据加密加速器，企业应用效率更高。

安全性方面，新一代也给与了优化加强，内置英特尔SGX模块，可以隔离和处理多达1TB超大容量的代码和数据，还可以对内存加密，可以有效保护数据安全。另外，内置加密加速功能，可以在众多加密算法中提供更有益的性能，运行加密密集型负载时，可以有效保护客户数据，但这不影响整体性能。

容器云平台整体分成3个部分，分业务区和管理区、核心区以及DMZ区，共需33台物理服务器提供计算资源。具体计算资源规划如下：

管理集群依托现有管理区虚拟化资源及3台物理服务器部署容器云平台管理集群、镜像仓库、云平台部署节点。存储采用现有NAS存储。负载均衡设备由两台虚拟机搭建HAproxy和keeplive提供。

生产区、DMZ区与核心区业务集群分别使用20台、5台和5台物理服务器部署容器云业务集群。负载均衡采用F5实现。存储由NAS和分布式存储设备提供存储资源。

## （二）网络设计
**1.网络拓扑设计**
![](/home/attachment/202112/05/1254057_163870654283265.png)
如上图所示，新业务无需外部访问，外向流量由F5统一负载。通过两台虚拟机搭建的HAproxy和keeplive实现高可用。环境的部署均是自动化安装。镜像的发布，Pod的管理，项目的划分，配额的定义由平台管理员在运维集群中进行统一配置。

**2.负载均衡设计**
![](/home/attachment/202112/05/1254057_163870659310317.png)
在大部分场景下需要使用外部LB设备来解决k8s本身服务暴露方面的诸多问题。通过使用F5 Container Connector这一解决方案来实现容器平台对外服务的暴露，充分利用现有F5实现更加丰富的应用交付功能。使容器平台内的业务一样可以充分拥有和非容器平台一样的应用交付特性，同时也保持了运维体系的一致性。

**（1）  负载均衡功能方面：**
采用AS3模式的CIS可以实现Nodeport和Ingress的所有功能，CIS容器与F5设备之间的交互都是基于AS3接口，AS3接口传递的参数是 JSON 对象，该对象中包括容器业务发布所关联的所有配置项，包括高级负载均衡配置，TLS加密配置，高级健康检测配置等。

**（2）  负载均衡-容器业务自动化发布**
容器业务统一发布架构中F5和calico通过BGP组成集群，提供K8S集群服务的总入口，这一层部署的 F5硬件设备，具有出色的性能、硬件的优势、标准化成熟的落地方案，同时F5 做负载分发与单个K8S集群绑定， F5负责单个K8S集群中的容器应用发布。AS3模式的CIS容器部署在K8S集群内，作为F5的控制器，CIS容器通过对K8S集群内Configmap资源进行监控，将Configmap资源中的内容转化为F5的配置，将配置推送给 F5 ，CIS容器还通过K8S标准的API接口完成业务发现和实时监听集群内Pod的变化，一旦Pod发生变化，相应的更新会及时推送给F5，并完成更新。

网络自动化系统将需求转换为F5的配置和Configmaps资源配置，通过API接口实现F5配置的自动下发以及K8S集群内Configmaps资源的更新，CIS通过监听Configmaps的资源变化完成F5 配置的更新，从而完成容器业务统一发布的自动化。

发布一个应用业务时，L7层面的HTTP应用发布，可以通过创建K8s-ingress资源来实现，F5会自动发现配置。L4的TCP应用发布，在创建好工作负载以后，创建一个带有特殊label的svc，然后在为这个svc创建一个含有特殊label的configmap，实现业务发布。

## （三）制品库设计
**1. 制品库架构规划**
系统架构图如下图所示
![](/home/attachment/202112/05/1254057_163870667037108.png)
1. 制品库部署方案
（1） 接入访问
生产环境接入访问统一使用F5负载均衡，挂载两台Artifactory制品库服务节点，通过F5配置实现制品库前台的访问请求转发,以及镜像制品上传、拉取请求的处理。
与开发测试制品库同步只需开通防火墙上由生产到开发测试的单向访问策略，具体开通生产环境制品库两台服务器实IP地址到开发测试环境域名（映射开发测试F5虚地址）和端口访问策略。

注：制品同步功能在配置上实际为以生产制品库服务器为制品拉取请求的本地仓库，开发测试制品库服务中的准生产制品库作为远程私服仓库，在生产制品库的远程私服仓库地址出配置上开发测试制品库的域名+准生产制品库名称路径，即可实现手动或定时的拉取操作。

**（2） 制品库服务及存储**
制品库核心服务部分部署两台Artifactory服务器，软件自身可部署HA高可用，结合前端Nginx实现。后端数据库使用我行要求的Oracle 19C版本。

## （四）存储设计
底层存储方面与现有商业NAS存储产品进行对接。为上层应用提供多种不同类型，不同等级的存储资源。具体实现方式分以下两种。

**1. 对接商业化存储：（直接使用商业化存储提供的标准NFS）**
按照业务的存储需求在存储设备上创建好存储卷，并设置好允许访问的ClientIP段（集群节点IP），通过容器云管理平台进行StorageClass和PV创建和验证。应用管理员负责创建PVC，申请StorageClass资源和PV资源。

**2.对接商业化分布式存储（使用商业化存储标准CSI接口-vSAN）**
在使用 Cloud Native Storage 环境中，会在 vSphere 中运行的虚拟机或节点集群上部署一个通用 Kubernetes 集群。在其上部署有状态应用程序时，Kubernetes 用户直接与集群进行交互。
![](/home/attachment/202112/05/1254057_163870669627383.png)

## （五）CI/CD设计
持续集成（CI：Continuous Integration）与持续交付（CD：Continuous Delivery）是软件开发和交付中的实践。

软件开发中，集成是一个很可能发生未知错误的过程。持续集成是一种软件开发实践，通过团队中的成员频繁提交代码到代码仓库，且每次提交都能通过自动化测试进行验证，从而使问题尽早暴露和解决，降低了解决问题、修复问题的难度和时间。

持续交付是持续集成的扩展，指的是将通过自动化测试的软件部署到产品环境。持续交付的本质是把每个构建成功的应用更新交付给用户使用。在持续交付的世界里，我们对完成的定义不是测试完成，而是交付到客户手中。持续交付可以快速获取用户反馈；适应市场变化和商业策略的变化。开发团队保证每次提交的修改都是可上线的修改，那么决定何时上线，上线哪部分功能则完全由产品业务团队决定。

**CI/CD流程图：**
![](/home/attachment/202112/05/1254057_163870672737644.png)
CICD流程：
1、编码并完成本地调试后提交代码至Git；
2、在TFS上触发流水线CI/CD过程；
3、TFS调用构建代理执行编译、打包等任务；
4、构建容器镜像并上传到仓库；
5、将应用部署到指定的容器集群；

## （六）应用管理
应用管理员负责运行基于容器镜像的轻量级应用或微服务，提供应用的微服务编排能力、应用全生命周期管理。

**1. 应用编排**
 Helm是目前Kubernetes服务编排领域的唯一开源子项目，做为Kubernetes应用的一个包管理工具，Helm通过软件打包的形式，支持发布的版本管理和控制，很大程度上简化了Kubernetes应用部署和管理的复杂性。Helm具有以下特性：
（1） 查找并使用流行的软件，将其打包为 Helm Charts，以便在 Kubernetes 中运行
（2） 以 Helm Charts 的形式共享您自己的应用程序
（3） 为您的 Kubernetes 应用程序创建可复制的构建
（4） 智能地管理您的 Kubernetes 清单文件
（5） 管理 Helm 包的发行版

本次项目将组件编排文件、应用编排文件与Chart模板相结合，自定义应用编排模板，对应用进行部署、升级和运行管理，实现应用的统一管理。

组件编排文件(Yaml)：是一种能够直观识别数据序列化格式，可读性高，易于表达资料序列的编程语言。K8S YAML规范：  是专门用于 Kubernetes容器编排、资源配置的描述语言，是规范基于 Kubernetes 的应用容器化开发、测试、生产上线过程中一种新型交付标准。

应用编排文件：目标应用中，各个组件编排文件的集合整理，包括运行时、服务发布、存储卷等。

Chart模板：分离Yaml中的公共参数和可变参数，进一步形成应用整体资源编排的描述模板，一键发布整个应用。
![](/home/attachment/202112/05/1254057_163870675652205.png)
**2. 生命周期管理**
应用程序的全生命周期管理包括：上架、部署、升级、下架、支持运行时动态管理策略、高可用及故障自愈等；容器云平台提供应用商店功能，多个应用可以通过编写Chart文件形式，发布到应用商店中，在应用商店中进行应用程序的一键部署、升级操作。与此同时，通过容器云管平台提供的图形化界面，还可以对应用负载进行调整，例如：修改镜像、配置信息、副本数量、发布服务的端口、挂载的存储卷等，并且还对工作负载Pod设置存活性（LivenessProbe）和可用性（ReadinessProbe），进行周期性健康检查。云平台默认提供基于CPU、MEM指标为触发条件的典型弹性伸缩场景，即水平自动伸缩（Horizontal Pod Autoscaler）；

为保障业务连续性，容器云平台通过Deployment控制器来管理无状态的应用Pod，Deployment 为Pod 和 ReplicaSet，提供了一个声明式定义（declarative）方法，用来替代以前的Replication Controller 来方便的管理应用。你只需要在Deployment 中描述您想要的目标状态是什么，Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的目标状态。Deployment控制器实际操纵的，就是Replicas对象，而不是Pod对象。

## （七）监控日志
**1.  日志采集**
在容器云平台中，日志包含两个层面，一个层面是容器云平台自身运行的日志，包括底层基础环境的宿主机运行日志、云平台管理组件的日志等；另一个是应用层面的日志，就是对真正对外提供业务服务能力容器的日志，包括对应用容器运行状态、运行过程的记录以及出现问题时的故障记录。其中容器云平台自身运行日志的主要查看用户是云平台的运维人员，主要用于平台出现故障时的问题排查，与业务运行无关。相较于容器云自身运行日志，应用日志更加需要及时关注。

对于应用日志的收集工作，将在Pod视图提供日志实时查看的功能，采用Filebeat组件以Sidecar容器的形式，收集Pod内主容器应用日志，传输给Kafka，Logstash作为Consumer消费Kafka的数据，日志数据结果处理后最终存储在Elasticsearch，最后使用Kibana输出到web端供相关人员查看、检索和下载日志。并可进行复合条件查询、关键字模糊查询、上下⽂检索。 日志采集流程图如下图所示。
![](/home/attachment/202112/05/1254057_163870679576462.png)
**2.  监控预警**
对于应用容器的监控也是后期持续运维工作中比较重要的一项工作，全方位监控和高价值预警是此次容器云平台追求的目标之一。在设计具体的监控功能时，从以下几个维度进行了考虑和设计。

**（1）公共组件监控**
云管平台上除支持常规资源监控外，对于平台常见的中间件，提供针对性的指标监控面板。通过exporter分别收集各个公共组件的信息汇总至Prometheus，根据指定的告警规则可以出发邮件或短信告警，同时会将数据传至Grafana，将采集的数据进行一个可视化的展示，用户可更直观的看到组件的状态。如下图所示。
![](/home/attachment/202112/05/1254057_163870684542972.png)
**（2）应用服务监控**
应用以容器的方式运行时，往往不需要关注某个应用单个容器实例的消失和新增，需要将侧重点放在整体应用服务的可用性和性能即可。通过业务应用的标准化输出日志，可对日志提取出应用的性能相关数据并进行分析。本文中部署的云平台中可针对单一应用进行详细信息的查看，采集到业务指标后，再把结果对接到监控模块。

为了实现对应用性能的监控，应用需要提供API接口暴露指标数据，然后根据Prometheus SDK构建Exporter，通过sidecar的方式把Exporter部署到应用里，Exporter把指标数据以metrics格式暴露出来，创建ServiceMonitor，Prometheus通过ServiceMonitor收集metrics指标数据，实现应用的性能监控。如下图所示。
![](/home/attachment/202112/05/1254057_163870686897899.png)

# 五、   经验总结和展望
打造金融云平台既是大势所趋，也是银行业实现数字化转型的桥头堡。目前，我行已实现全面云化，形成了包括私有云、容器云、开发测试云、托管云等在内的银行云生态，同时搭建了一整套完整的云平台流程管理制度和规范。提升服务功效超过30%，节约2万小时的人工成本，目前我行云上业务稳步增长，已达40多个，其中包含智能客服、财政业务、网银业务、个贷业务等。

从技术角度而言，采用容器化部署业务系统，具有以下优势：
应用更快部署：微服务比传统的单体应用小得多。较小的服务可以缩短修复错误所需要的时间。微服务是独立发布的，可以快速添加、测试和发布新功能。

降低应用代码复杂度：由于微服务比巨大的单体应用小很多，所以每个微服务的代码量是可控的，这让代码修改变得更加容易。

应用易于扩展：微服务通常是独立部署的。各个服务可以根据服务接受的负载量灵活的扩容和缩容。系统可以将更多的计算、存储、网络资源分配给接受高流量的服务，实现资源上的按需分配。

从管理角度而言，为了保证微服务的顺利实施，也遵循了一些原则和最佳实践：

IT团队重组为DevOps团队：有微服务团队负责微服务的整个生命周期管理，从开发到运营。DevOps团队可以按照自己的节奏管理组员和产品，控制自己的节奏。

将服务打包为容器：通过将应用打包成容器，可以形成标准交付物，大幅提升效率。

使用弹性基础架构：将微服务部署到PaaS上而非传统的虚拟机。容器云平台建设不仅仅需要容器等云原生技术的创新，基础架构技术栈的突破对保障性能、安全可靠性及可维护性同样非常重要。

持续集成和交付流水线：通过流水线打通从开发到运维的整个流程，有效助力了微服务的落地。

容器技术发展非常迅速，现在应用大多以容器作为承载介质，前两年在容器云上承载的应用类型主要是Web类，随着容器云领域的不断发展，越来越多的应用类型将迁移至容器云，包括有状态应用。在这种情况下，应用的集成、API管理和流程自动化就显得越发重要。随着技术的发展，相信更多强大优秀产品的整合会越来越强。

inter 容器云平台需求分析

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论4 条评论

ghl116

软件开发工程师兴业数金
2021-12-30 19:39

【文章价值点】随着容器技术的不断发展和完善，越来越多的金融机构选择搭建容器云平台实现应用上云，提升效率。本文从资源池管理，网络设计、制品库设计、存储设计、CI/CD设计、应用管理和监管日志等几个方面详细的介绍了城商银行的容器云平台的建设方案及经验，给还未上云的金融机构一些建设指导，具有较好的指导意义。【文章建议】本文重点介绍了整体的方案，但是也希望可以多分享一些系统建设中遇到的难点，踩过的坑及解决方案，重要组件的选型考量等，比如为什么网络是calico？；系统上线后运维方面痛点及解决方案。【文章内容疑问】Paas平台为什么没有采用openshift等成熟的商业平台？

lijunpeng运维负责人腾讯云
2021-12-29 10:34

该文章整体上从需求出发，到整个容器化生命周期管理落地做了一个整体的规划设计，目前看是采用私有云话的容器化部署方案，整体设计方案较合理，但是缺少一些东西，一方面就是金融比较关注的安全方面，整个设计中完全没有设计到安全的部分，另外一方面是容灾没考虑，这是最重要的，但是欠缺的东西。另外其实传统架构或者业务迁移容器化的重点，主要在业务适配容器这方面，容器化的架构其实已经很成熟了，但是怎么做到适配，怎么做到容器化的业务迁移转换，是难点，可以多分享这方面的经验，谢谢作者的分享

笑笑

存储架构师华大基因
2021-12-28 19:56

【文章价值点】: 文章完整的介绍了城商行在数字化转型中转向容器云的思路和落地方案【文章建议】：减少Intel处理器的篇幅，内容会更紧凑【文章内容疑问】：作者在文中特别强调了Intel处理器的强悍能力，不知道和容器云解决方案有什么特别的关联【文章内容概括】: 城商行的需求如下： 1.提高软件交付周期 2.推动DevOps落地 3.整合现有资源 4.提高资源利用率 5.加速企业软件资产积累 6.满足监管和安全要求设计方案具有以下能力： 1.提供高可用集群 2.资源池化 3.网络通信方案 4.存储方案 5.编排调度引擎 6.微服务运行框架 7.镜像管理 8.事件告警、集群监控和日志收集使用docker+K8s做技术底座，HAProxy+F5做负载均衡，Harbor做镜像仓库。采用虚拟机+3台物理机搭建管理集群以及镜像仓库+云平台部署节点，存储使用NAS 生产区、DMZ区、核心区分别使用20台、5台、5台物理机，复制均衡采用F5，存储使用NAS+VSAN 【个人看法】文章从架构到落地的细节都有很好的体现，非常值得大家参考。谢谢作者的分享。

孙建军软件架构设计师兴业数金
2021-12-28 16:07

该文章从行业容器云需求出发，详细阐述了资源池设计、网络设计、制品库设计、存储设计、持续集成和持续交付、应用管理、监控日志等方面。因为项目背景是从传统架构迁移到容器云，建议可多分享传统架构迁移到容器云架构的经验。

Ctrl+Enter 发表

匿名评论

某城商银行生产容器云平台建设实践经验分享

添加新评论4 条评论

本文隶属于专栏

相关文章

相关问题

相关资料