【导读】本文主要结合江南农村商业银行（以下简称：江南农商行）容器云平台一期、二期的建设经验进行简要分析和分享，旨在探索一条适合农商行的容器云平台建设路径。通过容器云平台建设赋能业务，为业务应用提供更加灵活、快捷、高可用、弹性的云原生基础设施能力支撑，并顺应内外部数字化转型的趋势和需求。

一、项目背景

1、背景概述

近年来，IT 领域新兴技术层出不穷、百家争鸣，新的技术演进趋势如数字化转型、云原生等纷至沓来，新的政策、战略也不断清晰、细化。此外，在数字经济时代，企业要具备更强的市场竞争力、快速应对业务需求，已经非常依赖于信息技术的支持，这对企业的 IT 建设不断提出更高的要求，对企业的 IT 人员不断提出更高的要求。

在这样的大背景下，江南农村商业银行非常重视采用稳定、可靠的先进技术，为业务发展提供强有力的信息化支撑。近年来，我行积极开展 IT 领域的演进规划，包括业务蓝图规划和支撑平台整体规划。从战略解读层面、业务现状分析层面、科技建设现状层面、监管要求层面、以及同业实践层面等多个层面、不同维度，对规划进行设计、细化和执行。

成立以来，我行已搭建了数百套业务系统以满足日益增长的业务需求。这些系统成功地支持了我行业务的平稳快速发展，但站在行业技术突飞猛进的历史关口，行内整体的 IT 能力建设仍然有诸多需要演进、优化之处。如：微服务架构创新实践相对较少、基础平台支持能力相对不足、管理系统较多需要整合等等。

基于以上行业趋势以及行内规划，容器作为近年来非常重要的一项“新兴”技术，与我行整体 IT 规划相契合，与微服务落地实践、基础平台增强等需求吻合，因此在 2020 年下半年，我行启动了容器云平台的建设工作。

2、整体思路及目标

（1）建设一套全行级的统一容器云平台

经过调研分析，我们认为容器云平台的定位应该是云原生时代的基础设施平台，为各类云原生应用提供资源管控能力和应用生命周期管理能力。基于这个定位，以及当前行内的云原生业务应用的类型和规模现状，我们认为待建的这套容器云平台的定位应当是一套全行级的统一容器云平台。当然，在未来，如果行内云原生应用数量和类型急剧攀升，理论上也存在使用多套容器云平台进行承载和管理的可能性，但是在当前，从 CAPEX、OPEX、使用便利性、运维便利性、标准化及规范性等角度考虑，我们希望建设一套全行级的统一容器云平台。

（2）建设一套与业务松耦合的“中立的”容器云平台

近年来，业务厂商提供的业务系统很多都是微服务架构的应用，有些厂商在提供业务系统时自带了容器底座，甚至有一些业务厂商本身也做容器平台。但是从全局来看、从长远来看，我们希望建设一套与业务系统、业务厂商松耦合的“中立的”容器云平台。

（3）配合微服务架构应用上线，建设一套真正“用起来”的容器云平台

作为基础设施类型的平台，我们对容器云平台的要求是建好后一定要用起来，而不仅仅是做个创新、做个试点。这一点刚好与行内希望做业务架构创新、主要是微服务架构应用的实践这一规划不谋而合。作为云原生体系的两大关键技术，容器和微服务是相辅相成、1+1＞2 的关系，因此我们的目标是通过容器云平台支撑微服务架构应用的上线；通过微服务架构应用的落地夯实容器云平台的基础设施平台地位。所以在建设容器云平台之初我们很早就选定了几个试点应用，待容器云平台建好，即第一时间做应用上云。

二、项目难题

在项目落地之前，除了一些技术细节考量，首先要做好整体的建设路径规划。容器技术对于行内来说相对较新，我们希望采用务实的、平稳的、分阶段的、与整体 IT 规划相匹配的建设方式。

在这样的整体基调下，我们首先要面临至少以下四个主要问题：

1、如何设计一条符合行内业务实际的、务实高效的建设路径？

作为一个基础设施平台，容器平台涉及到的面还是比较广的，包括但不限于：

• 计算、存储、网络、安全等平台自身能力建设；

• 与哪些周边系统交互、集成，功能边界如何切分；

• 如何承载业务系统、承载哪些业务系统；

• 自身的可用性等非功能性设计。

围绕以上各方面，如何规划好整个项目的建设内容、建设路径，是一个项目成功与否的关键，也是摆在我们面前的第一个重要问题。

2、IT 环境复杂，如何设计一套面向业务的、可灵活扩展的部署方案？

行内 IT 环境经过长期建设与发展，目前已经比较成熟，同时也比较复杂。包含多个网络区，如 DMZ 区、APP 区、核心区等，不同区域之间有着不同的网络策略、运行不同类型的业务系统；包含多套环境，如开发环境、测试环境、准生产环境、生产环境等。

如何在当前较为复杂的 IT 环境中部署容器平台，使得该平台能够满足不同区域的业务支撑需要、以及不同环境的使用需要，并且能够随着业务的不断发展进行灵活的容量扩展，成为摆在我们面前的另一个重要问题。

3、资源使用体系复杂，如何实现资源的隔离与绑定？

行内现有开发团队、测试团队、运维团队、第三方业务厂商团队等多个团队、多种成员角色，如何实现多网络区、多环境的资源与不同的团队成员之间的绑定、隔离，实现精细化的多租户管理、资源配额 ，是项目整体设计时要考虑的另一个重要问题。

4、如何与行内现有组织架构和流程融合，形成一套最匹配的流程？

行内已有相对比较成熟的一套组织架构和业务流程，覆盖开发到测试到运维监控。新建的容器平台如何与这套已有的组织架构和流程相融合，既能充分发挥新平台的特性和优势，又能最大化复用现有体系，是项目建设前的另一个关键问题。

5、选择哪些应用上云？

容器平台建好后，如何合理地使用平台、最大程度发挥平台的价值，也是一个至关重要的问题。因此，如何选择合适的应用进行上云，是体现平台建设价值和成果的非常重要的一环。

三、项目方案

1、建设路径思路

项目的整体建设路径我们倾向于基于扎实务实、匹配现状、体现价值的整体思路。

扎实务实：

容器对于行内来说是一项比较新的技术，建设之初，行里对容器技术并没有太多经验。因此，我们希望初期建设步伐以扎实务实为目标。在了解了行业和厂商最佳实践后，选择先建设落地经验较多的商用基础平台，然后在使用过程中再不断对功能、易用性等进行打磨、个性化。

匹配现状：

作为一套基础平台，向下要管理各类云化资源，如容器计算节点资源、容器网络等，向上要能够支撑云原生应用的平稳运行和全生命周期管理，因此容器云平台不可避免地要与较多的周边系统进行对接集成。

为了充分发挥容器平台的作用，最大程度沿用行内已有的流程、工具和习惯，并综合考虑项目的建设周期和成本，需要设计好容器平台与哪些周边系统对接，以及功能如何切分。其中主要包括以下几个方面：

• 代码的构建和镜像制作：通过行内统一的配置中心完成，保持现有工作方式和习惯，保护历史投资；

• 监控：与行内现有值班室相关系统做对接，方便监控团队进行统一监控；

• 告警：与行内邮箱网关以及微信网关进行对接，便于第一时间查收告警信息，保持现有告警推送和查看的工作方式和习惯；

• 负载：与行内现有 F5 进行对接，保持现有负载均衡的性能和方式。

体现价值：

我们对容器云平台的建设目标并不是仅仅做技术研究或创新试点，而是希望平台能够真正承载起业务生产的各类需求，并为业务系统带来传统云平台所不具备的新价值。因此，我们在项目建设之初，就计划选择若干套业务应用运行于容器云平台之上。整体思路是优先选择微服务架构应用、逐步将更加重要的应用迁移至容器云平台。如果应用是由第三方厂商提供的，要综合考虑第三方厂商的技术实力和服务能力。最终实现通过应用上云帮助容器平台扎根、通过容器平台反哺业务发展。

2、部署方案设计

行内有多个网络分区和多套环境，如下图。

包括四个网络区：DMZ 区、APP 区、核心区、带外管理区，其中带外管理区可与各区通信，其他各区之间网络隔离。

包括四套环境，开发、测试、准生产、生产。

▲图示：多网络区、多环境组成的复杂环境

部署位置规划：

在设计部署方案时，首先要考虑到容器云平台管理门户与 K8s 集群之间的网络通信问题。K8s 集群承载各类业务，因此可能位于各个网络区。容器云平台管理门户需要对各个 K8s 集群进行统一的调度管理，所以容器云平台管理门户所处的位置应当可以和各个网络区通信。结合行内的实际网络情况，我们选择将管理门户部署在带外管理区，在各个网络区部署对应的业务集群。

部署环境规划：

▲图示：可按业务/环境/集群等多维度灵活建设、扩展的部署架构

首先，需要将生产与非生产隔离开，我们在生产环境以及非生产环境（包含开发环境、测试环境、准生产环境）分布部署了一套容器云平台及配套组件。

其次，不同的业务区创建各自的业务集群，各个业务区可根据业务规模、业务需要等选择部署一个或多个集群，后续也可按具体业务进行针对性的集群数量或规模的扩缩容。

另外，通过资源逻辑分区的方式，可以将计算节点划分成不同环境的逻辑资源分区（分组），实现按照环境的资源精细化管理，后续可按环境维度进行针对性扩缩容。

通过以上设计方案，整体上可实现按照业务、环境、集群等多维度的精细化管理，后续可以根据业务发展需要，从多种维度进行容量的扩展或收缩。比如，当未来新增了某个业务（区），可以新增对应的业务集群；或者某个业务规模不断扩大，可以考虑新增该业务对应的集群数量；再或者，某个环境的资源不足，可以向该环境的计算节点分区中增加更多的资源。

部署方案关键点小结：

（1）生产与非生产隔离，分别部署一套容器云平台；

（2）非生产环境交付应用镜像，通过单向网络策略，生产环境将镜像拉过来；

（3）各网络区相互隔离，内部部署各自集群，如核心区部署核心区集群，运行核心区应用；

（4）各集群内做逻辑分区，如开发环境分区、测试环境分区、准生产环境分区等；

（5）保证整个系统的可扩展性。未来可随时根据业务增长需要，增加集群或分区资源。

3、资源使用体系设计

面对多集群、多环境、多租户等诸多的资源和用户，如何将资源与租户进行匹配也是一个重要问题。针对这个问题，我们采用了分层的资源建设及绑定的方式。

首先，容器云平台搭建完成后，我们通过平台在不同的业务区创建了对应的 K8s 业务集群。但是集群是一个较大的概念，直接将集群资源与租户进行绑定，这样的颗粒度比较粗，不利于后续的精细化管理。因此，在集群之上，我们引入了分区的概念，通过分区，将每个集群进一步分为若干个逻辑分区，比如 A 业务的开发环境分区、B 业务的测试环境分区、C 业务的准生产环境分区等等。分区具备共享和独享两种业务属性，共享分区的资源可以供各个租户共同使用，独享分区的资源仅可供某一指定租户使用，从而最大程度地实现资源使用率和业务资源隔离的平衡。

创建好分区后，需要根据业务或是组织架构等设计租户。我们结合实际情况，选择按照业务应用以及所处环境进行了租户的设计，如负责 A 应用开发的团队，可以设计成 A-dev 租户；负责 B 应用测试的团队，可以设计成 B-test 租户。设计好租户后，将各环境的资源分配给对应环境的租户，实现资源与租户的绑定，以及资源按环境和按业务的隔离。

整体体系如下图：

▲图示：层次化资源建设及使用体系设计

4、整体流程设计

行内已有自己或第三方的开发团队、测试团队、运维团队、值班室监控团队等较为成熟的组织架构和职责划分，并且已经有了一些统一的代码仓库、配置中心等统一平台。因此，在设计容器云平台的整体流程时，我们希望尽量与现有的组织、工具、流程进行深度的、平滑的融合，充分体现新老系统各自的价值。最终形成了下图的整体流程：

▲图示：容器侧整体流程示意图

非生产侧，开发人员提交代码至代码仓库，配置管理岗人员进行代码分支管理，根据相应分支进行编译、打包、制作镜像、并推送至对应环境的镜像仓库。随后，开发人员在开发环境进行服务发布、测试验证，然后流转至测试阶段。测试人员依次在测试环境和准生产环境进行服务发布、测试验证。测试验证无误后，生产环境镜像仓库会从准生产环境镜像仓库拉取经过验证的镜像。

生产侧，负责发布的人员进行生产环境服务发布。服务上线后，由值班室人员进行 24 小时监控。

5、应用上云方案设计

容器云平台建设完成、并与周边系统集成对接后，下一步要做的主要工作是应用的上云。整体的上云原则主要包括几个方面：一业务一方案、先测试后生产、先边缘应用后核心应用。按照这个思路，配合行内的微服务架构应用实践的规划，经过容器平台一、二期的建设，目前容器平台已经承载了数字化管理类平台、智能零售类平台、数据中台类应用、数字员工类应用、智能外呼类应用、云柜类应用等多套业务系统。

▲图示：典型上云流程

6、其他关键设计

作为一个基础设施平台，除了以上各类整体设计，实际上容器云平台要考虑的方面还有很多，比如如何与行内配置中心对接、关键组件如镜像仓库和监控组件如何实现高可用、基础镜像如何管理、基础镜像版本更新流程如何设计、监控告警系统如何设计等等，因为篇幅关系，本文不一一赘述。在此主要挑选两个关键方面进行概述：基础镜像版本管理以及监控告警管理。

（1）基础镜像版本管理

镜像是整个容器生态中非常核心的一环，因此对于镜像管理的良好设计也非常重要。

对于基础镜像的管理，我们首先将基础镜像分为了两大版本类型：维护版本和对外提供版本。维护版本是当有新需求或者安全要求时，更改基础镜像形成的版本。以当天日期的年-月-日 为 Tag。对外提供版本是供配置组使用的版本，一直为 latest。如，当前维护版本是 2022-07-20 ，到 7 月 23 日时，因其它原因需要变更基础镜像，会再生成一个 2022-07-23 的维护版本，通过测试后，将 2022-07-23 版本 Retag 为 latest，并且推送至镜像仓库。

配置组使用基础的镜像以 latest Tag 结尾，当下次配置组更新应用镜像时，使用的基础镜像就是 2022-07-23 版本的镜像。

通过这样设计，对外提供的版本相当于只有一个 latest 版本，从而实现更加简便的镜像更新及使用，不用每一次镜像更新后都修改 dockerfile。

▲图示：基础镜像版本管理

除了基础镜像的版本管理，我们还设计了基础镜像的更新流程，如下图：

▲图示：基础镜像更新流程

在发现重大漏洞、需要更新基础镜像时，按以上流程进行判断。如漏洞影响到的是 OS 层，则需要先更新 OS 镜像，再重新构建中间件镜像；如漏洞未影响 OS 层、只影响中间件层，则只需要更新中间件版本进行修复。

（2）监控告警管理

容器的监控告警，我们选择了业界比较成熟和通用的 Prometheus 方案。Prometheus Server、AlertManager、Grafana 等关键组件均采用了集群化部署，提高可用性。

▲图示：监控告警系统整体架构

告警的推送方面，我们根据行内习惯，对接了邮件、微信两个通知渠道。两个渠道对应的消息接收人员不同，微信通知仅发给行内员工，邮件则可以发给包括业务厂商、容器平台厂商等所有相关人员。

▲图示：告警推送示意图

四、项目建设

1、建设路径

我行容器云平台整体上采用了分期建设的策略。目前处于二期的中后期。算入试运行和驻场运维，每期周期约为一年。

一期的主要建设内容主要包含三个方面：建设容器平台自身、与周边系统集成、试点应用上云。建平台阶段，主要是要结合行内 IT 环境，做好部署方案的设计、容器资源的统一管理、整体流程设计等；集成阶段，尽量沿用了行内现有的相关统一平台和习惯，与容器平台进行对接打通；上应用阶段，主要考虑选择哪些应用上容器。

结合一期的使用和试点情况，二期主要对平台进行增强、优化、个性化。二期主要工作内容包括：

（1）随着容器平台上运行的业务应用越来越多，二期对平台计算节点进行了扩容；

（2）通过对平台进行大版本升级，我们保持了平台功能的先进性和非功能层面的优化，并且对 K8s 集群版本一并做了升级；

（3）我们结合一期使用过程中的体验，提出了几个定制化开发需求，使得平台更符合行内的使用习惯、进一步提升平台使用效率和使用体验；

（4）进一步优化平台整体的可用性、安全性。主要包括在原有容器平台自带的基础安全能力之外，部署企业级的容器安全平台，进一步增强容器侧的安全性。

▲图示：我行容器云平台建设路径

2、建设规模

非生产环境：1 套容器云平台，2 个集群，100+个 node，约 2000 个 pod。

生产环境：1 套容器云平台，3 个集群，50+个 node，约 1000 个 pod。

上云业务：管理类平台、零售类应用、数字员工类平台、OCR 识别类应用、智能外呼类应用等约 10 套业务应用；

3、后续规划思路

对于容器平台的后续发展规划，目前主要考虑以下几个方面：

• 信创能力建设；

• 迁移更多业务应用至容器云平台，不断提升平台的规模效应和价值；

• 结合一二期使用情况，继续对平台功能进行个性化定制、丰富。

五、项目收益

整体上，容器云平台在我行已经得到了一定规模的应用，在帮助我行快速响应业务需求、加速业务迭代、缩短业务上线时间、简化工作协同、减少人工操作、降本增效等方面发挥了较为明显的作用。具体收益主要体现在以下方面：

效率提升：

（1）环境就绪时间大幅缩短，因为传统虚拟化平台的环境就绪涉及到大量的手工操作和长流程。而容器平台基于镜像技术，可以显著提升自动化水平并屏蔽各环境差异性；

（2）服务发布操作效率和简易性提升显著，只需要在前端界面上简单操作，以及某版本服务第一次发布时做一些配置，后续发版很简单；

（3）发布成功率相当于 100%。基于容器镜像技术，如果某版本服务发布有问题，只需要解决一次，后面就可正常发布。

业务可用性提升：

业务中断时间明显缩短。传统用虚机承载业务，业务进程 OOM 时会卡住，而使用容器之后，业务进程 OOM 时容器可以自动重启、恢复，大大提升了业务可用性。

资源成本降低：

资源利用率提升没有做量化分析，但是肯定会高很多，因为对于同一台物理机，以往会在其上部署多台虚机。而建了容器平台之后，会部署少量更大规格的虚机然后在虚机之上部署多个容器，从而可以大幅减少虚机 Guest OS 的开销。

人力成本降低：

（1）容器平台使用非常简单，对人员技能要求显著降低、使用效率变高；

（2）各个环节的人工操作均有不同程度变少。

六、项目回顾与展望

持续优化演进、持续为业务和用户服务、持续从技术层面赋能并带来更大的价值，是 IT 领域的永恒旋律。容器云平台项目作为我行整体 IT 规划和演进中的一环，很好地符合了行内的建设预期，在顺应数字化和云原生演进大趋势、配合支撑微服务应用落地、提供云原生基础设施新特性、降本增效等方面带来了很多显著的变化和新的价值。

后续行内会进一步扩大、深化容器云平台的规模和能力，同时持续进行其他 IT 方面的演进，通过科技创新，为用户带来更多更优质好用的业务服务，助力进一步深化我行的高质量发展之路，助力打造农商行一流品牌。

点击BoCloud博云了解更多解决方案