导读：

当前银行在进行容器云平台建设的过程中会面临两种技术路线选择：商用路线与自研路线。这两种技术路线应该如何选择评估? 选择商用路线，主要是采用商用产品和服务进行容器云平台的建设和运营。选择自研路线则是依靠企业自身容器云平台团队进行建设落地。本期交流活动重点围绕自研or商用技术路线，应该如何选择？挑战会有哪些？两大问题，希望通过交流活动理清思绪，帮助更多准备建设容器云平台的银行提供更加清晰的选择决策逻辑和经验参考、从容应对建设挑战。

参与用户包括来自中国银行、、兴业银行、山东农信、广州农商银行、包商银行、振兴银行等22家企业的一线技术精英参与到本次交流，针对容器云平台建设过程中的实践经验与难点挑战，参会用户积极发表了自己的见解与看法。最终在热烈的氛围中交流研讨活动就银行生产中心容器云平台技术路线的选择问题达成了一致共识，挑战的痛难点也得到了一致的解答。本期重点从：中小银行对于商用与自研的技术路线选择、商用技术路线的实施建议、自研技术路线的困难和挑战、落地和案例这四个方面细为11个交流主题进行总结，希望给大家在选用容器云自研和商用路线时提供一定的参考和帮助。

一、 容器云商用、自研技术路线选择

银行在容器云的技术路线选择方面，需要考虑方方面面，其中最核心的是巨大的管理和人才的挑战。银行在选择容器云的初衷有很多，比如云计算技术的升级，系统集群在调度、网络、存储、性能以及安全方面的需求，资源的管控以及资源的弹性伸缩，业务服务化、分布式、容器云的需求。因此需要根据需求对商用、自研的技术路线进行匹配，选择合适的技术线路。下面的交流重点也是围绕银行在容器商用和自研路线上应该怎么去选以及如何评估，给与大家一些参考帮助。

1、容器云平台商用路线和自研路线是否可以共存？两者的边界在哪里？

嘉宾： henrylv206 架构师 , 建信金融
个人认为，最好是二选一； 首先，目前的容器云平台，大都基于 k8s 实现，技术原理上相同； 其次，不同的容器云平台，可能会引入不同的扩展，甚至可能由不同的团队负责运维，对公司来说，不仅是成本，故障处理和运维管理也是一个负担；再次，不同的容器云平台，对于后续的升级、改造，可能会引起不同的独立发展路线，管理起来比较复杂；所以，在存在自研容器云平台的条件下，没必要再引入纯商业的容器云平台，即使有些业务应用的引入带有容器云平台，也建议适配公司内部自研的容器云平台。

嘉宾： 魏新宇 副首席解决方案架构师 , 红帽企业级开源解决方案中心
看自身团队的能力和人员数量。建议中小客户采用有技术支持的开源商业产品，这样出现问题可以借助厂商的力量解决问题。事实上，大多数大型的金融客户的容器云，也都有 IT 厂商的技术支持。

嘉宾： rechen 云计算架构师 ,
1 、中小银行建设容器云平台，鉴于团队的规模和精力有限，建议使用商业版本，团队聚焦于做好容器云平台的高可用性和对应用侧的运营技术支持。
2 、大中银行建设容器云平台，初期也是建设使用商业版本，在团队的技术水平和队伍组织规模都达到自研的门槛，可以以课题模式从开发测试环境、信创资源池建设等领域开始启动自研。

2、如果初期选择商用路线，之后希望实现自研，国内国外有哪些产品适合做自研的容器技术底座？

嘉宾： henrylv206 架构师 , 建信金融
既然是自研，个人认为还是直接以 kubernetes 为底座更好，这样可以更灵活地适配扩展需要，同时与 k8s 社区也能保持直接的关联关系； 另外，如果想更快地接触更多的企业功能，比如镜像管理、 CI/CD 等附加功能，也可以试试 openshift 等开源产品。

嘉宾： 魏新宇 副首席解决方案架构师 , 红帽企业级开源解决方案中心
可以使用 OpenShift 的社区版 OKD 。使用 K8S 的弊端在于，需要自己把开源组件挨个组装，需要进行大量 bug 的 trouble shooting ，意义不大。

嘉宾： tongyizhou 战略产品业务拓展经理 , 红帽企业级开源解决方案中心
直接基于 CNCF 中零散的开源组件（如 k8s ）自研会消耗巨量的人力和时间，同时企业会自己承担更多的技术风险。对于绝大多数企业来说，更成熟合理的策略是基于成熟的容器平台进行外围功能研发，在享受容器平台提供商研发成果的同时保证企业对定制化功能的掌控。

最优的选择是 CNCF 框架 platform 类别中已经认证的平台。同时具备如下特点的：

1、类型 - 全开源：全开源意味着企业可以更轻松的与平台集成，也意味着企业可以随时看代码、抄作业，未来自研深度和广度的调整都会更灵活；
2、许可 - Apache2.0: 作为自研基础的，选择获得此许可的平台可以避免出现知识产权纠纷及法律风险。注：社区版本的 k8s遵循的就是 Apache2.0的开源许可
在 2021 年8月这个时间点，符合以上全部要求的平台有：
Redhat Openshift
Rancher Kubernetes

嘉宾： rechen 云计算架构师 ,
初期锻炼队伍，国内推荐用飞致云的 kubeoperator 做自研的容器技术底座。 国外的推荐 rancher 或 openshift 的社区版 Openshift Origin

3、中小银行如何建立自研或商用技术路线的评估体系来实现容器云平台技术路线的选择？

嘉宾： henrylv206 架构师, 建信金融

选择自研或商用，我觉得从几个方面考虑：
组织意愿，选择自研需要一种魄力，愿意承担未来可能发生的各种问题；而选择商用可能就由服务提供商帮助解决；
人才梯队，选择自研就需要有一支专业的云原生技术团队，能够理解技术原理和解决生产故障；而选择商用的话，可能只需要有运维人员即可；
技术积累，选择自研，最好有良好的研发团队和研发背景，这样引入新的云平台研发，在研发管理上能有一定经验；若过往都是使用商用产品，建议继续使用商用；
使用规模，如果自身业务量不大，选择商用更方便快捷；
其它：成本或自主可控，从长远来看，自研是要能节约成本，并且拥有独立知识产权，如果不能满足，还是考虑商用吧。

嘉宾： rechen 云计算架构师 ,
鉴于中小银行的 IT 投入和容器团队的规模有限，因此容器云平台的技术路线上，建议以走商用技术路线为主。 团队重点关注在运维好，使用好的商用容器云平台，在容器云平台的基础上，投入配套建设好DEVOPS 平台，提升 IT 研发效能和交付效率。

嘉宾： sf7071 云计算研发工程师, 某大型银行
建议考虑几方面：
成本，自研需要持续投入大量人力成本，商用产品引入相对可控，市场上有不同价位的产品；
风险，自研需要承担因经验、能力不足带来的技术风险，比如架构缺陷、运行故障、安全漏洞等，自身能够 hold 住？
自主度，自研代表自主掌控，万事不求人；商用一般会受限于厂商产品的研发计划。一般情况下建议商用，组织有意愿的可以在使用商业产品的同时培养人才、积攒经验，为后续自研打基础。但往往不太可能完全自主，自研+商业技术支持服务相结合可能更好。

嘉宾： 顾黄亮 技术总监 , 苏宁消费金融有限公司
其他回答已经涉及题主所需考虑的问题了，我进行简单的总结。
1 、人员成本评估，因为容器云技术覆盖到底层的基础运维和应用的研发测试等内容，因此对团队成员的要求具备门槛。
2 、技术存储评估，需要完成对容器技术和服务编排技术等容器云相关技术的知识贮备，涉及知识面广且复杂
3 、流程存储评估，容器云可以更好的促进 devops 理念的落地实施， CI/CD 等会对现有流程带来改变或造成影响，因此做好 IT 组织架构梳理，做好职责明确，从流程上做好准备
4 、基础架构成本评估，容器云运行的环境是基于物理机还是IaaS层，需要做好规划并进行环境储备

嘉宾： 魏新宇 副首席解决方案架构师 , 红帽企业级开源解决方案中心
建议中小银行采用商业开源的容器云上生产。

二、 容器云商用技术路线的实施建议

银行选择商用容器云技术路线的多数更为看重云服务的稳定性和可靠性，对服务商提供的技术和运维支持有较高要求。因此商用技术路线的实施更多的依托于第三方实施团队，以及和自有团队之间的衔接。容器云的商用技术体系有几个前置条件，分别是完善的底层设施配套，成熟的全体系技术，以及多场景的云计算生态，所以银行采用商用技术路线的实施也是将这几种前置条件转换成优势，最终实现可靠的性能保障和成熟的服务支持体系。

1、商用路线为什么适合作为中小银行建设容器云平台的选择，应该如何进行选型？

嘉宾： sf7071 云计算研发工程师 , 某大型银行
中小银行选择商用路线建设容器云平台，目的很明确，一是高效，拿来就用；二是不用投入自身人力成本去研究和运维，一般中小银行可能本身很多软件都是采购或者外包研发的，自身科技力量并不具备成熟条件去建设复杂的容器云平台，可以站在先进的技术平台上集中精力发展业务。目前市场上的容器云平台产品也有很多可选择的，那么在商业产品选型引入时，我觉得需要注意几点：

根据预算选择适合的产品范围，一分钱一分货，不计成本则可选顶尖产品，这是永恒的真理；
对框定的产品进行poc，横向进行比较，在过程中观察稳定性、性能、厂商服务能力（包括出现问题时的解决效率、服务人员的稳定性等等），功能方面选择能够满足当前需要的就行，因为基本功能都差不多，产品设计方面也大同小异；
厂商口碑，多与同业交流，了解厂商的服务体系、服务质量、产品表现等，选择一家综合实力更强的会省心很多。

嘉宾： rechen 云计算架构师
选型时，要严谨地做个POC技术测试，测试的指标建议关注下面6类指标：部署类指标、可用性指标、扩展性指标、易管理性指标、非功能性指标、安全指标

嘉宾： tongyizhou 战略产品业务拓展经理 , 红帽企业级开源解决方案中心
选择商用平台即是依托平台供应商更成熟完整的技术方案为企业节约珍贵的研发资源，也是依靠平台供应商的服务能力分担生产风险。从宏观和长远考虑，对绝大多数企业来说这都是比自研更优的方案（自研的困惑请见魏新宇对本问题的回答）商用容器平台在选型时要关注下列非常重要却通常被忽略的角度：

技术路线：商用平台的全部组件来自CNCF框架为最优，因为CNCF框架是国内外业界公认未来5-10年的标准技术框架。越多的组件来自CNCF框架意味着商用平台未来技术路线出现偏差的可能性越小，作为平台使用者的用户风险也最小
先进性：先进性是作为用户很难理智评判与判断的，可以多参考国内外评级机构的专业评测，如 ForrestWave ，Gartner 等，可以节省大量的立项研究资源
稳定性：商用平台研发过程中有层层的安全加固及企业级的稳定性测试，才能保证平台的稳定性大大高于开源社区的组件，也才能承载企业级的生产
开放性、可控性：作为云原生技术的底座，容器技术的演进速度远大于前几个时代的平台技术。如此的演进速度下企业平台的技术也是演进的，变化的。选择的商用平台技术开放性是保证未来企业技术自主权的重要指标（如未来可能会出现在商用平台上增加少量社区组件或第三方商用组件的情况）
兜底服务：商用容器平台均基于开源社区组件，商用平台提供商在上游开源社区的代码贡献量是衡量供应商是否真正理解核心开源组件的重要指标。只有真正理解核心开源组件的容器供应商才有能力对企业提供核心组件代码级的支持服务，也才能在企业最需要供应商支持时（如遇到k8s内核bug）获得相应的服务支持

嘉宾： 顾黄亮 技术总监 , 苏宁消费金融有限公司
其实商用产品的优点非常突出，重点有两个。
1 、购买成熟化的市场产品，这种模式建设周期相对较短，在进行本行落地定制化的过程中一般有应用案例可参考，一般建设周期相对较短。
2 、可以针对某个细节进行定制化开发，定制研发多以落地为主，技能要求相对较低。
3 、最核心的是保障方面，较为可靠，且有后备技术支撑。

嘉宾： lansh 高级系统工程师, 某保险股份有限公司
选择商用路线建设容器云平台：往往有以下几个原因：1. 项目时间紧，选用开源的平台进行研发时间赶不上；2. 相关人员的数目投入较少，人力成本低；3. 少踩一下开源平台的坑，遇到紧急的问题，商业能及时提供解决，把运维风险较大转移至商业平台公司，降低运维风险。 选型：1. 都进行POC 2对比各大平台的成熟度，使用便利度，和价格成本

嘉宾： 强哥之神 容器云架构师及技术经理 , 上汽云计算中心
这个也不是一概而论，有的银行愿意投资团队去做的话，就会自研。当然大多数可能会选择商用。因为在银行中，银行业务才是重点，平台可以当作一个工具，只要找个好的工具，把业务支撑好，目的就达到了，所以选择商用是大多数银行的做法。当然商用也要选择好的，特别是稳定性、高可用要好的，除了这个，还要满足可扩展性，可迭代性等，这个主要是要求在升级平台或组件过程中不要影响到业务，特别是银行中支付这种重要的业务。

嘉宾： JanXC 系统架构师, nec
我觉得对于中小银行选择商用路线主要原因有两方面，一方面是技术实力水平，大家都知道安装、部署试用是最简单的，但是生产环境错综复杂，各个系统对接及接口需要开发级和架构级的人员参与，中小银行大多缺乏该类人才，且招聘的成本和难度都很大；另一方面就是中小企业看重收益，相比大企业更看重最短时间的投入产出，这就要求项目不会有长时间用来调研、实施以及测试等，采用商业路线，可以尽快成型。

嘉宾： 魏新宇 副首席解决方案架构师 , 红帽企业级开源解决方案中心
K8S和 CNCF中相关的容器云多达几十个。中小银行没必要把精力放在各种开源组件的对接和修复bug 上，而是应关注容器云怎么实现业务的敏捷和高可用，做出业务创新。 选择商用平台有助于客户降低成本（想象一下自研需要至少 20 人以上的开发和运维团队，一年的工资需要开多少），提升业务的稳定性。

嘉宾： Hsia SA , 某消费金融
选择商业路线一方面是考虑有大厂背书，不必过多投入自身人力研究学习以及后期运维；另一方面是考虑产品易用性，自带较多功能，拿来即用。

2、银行如果选择容器云商用路线，在产品选择上应该注意哪些？

嘉宾： rechen 云计算架构师
1 、建议可以搭建一个研究环境，此环境使用开源的（自研），这样可以深入研究和测试。
2 、正式业务应用的环境，还是要保持开发测试、生产环境的软件一致，利于推广运营和故障定位。

嘉宾： henrylv206 架构师, 建信金融

1. 最好是能够开发测试、生产保持一致，虽然目前对于 k8s 的使用，核心是一样的，但不同的商业版本或多或少会增加一些自己的扩展功能；
2. 如果开发测试、生产不一致，在应用开发上尽量只使用 k8s 的原生功能，对于一般的商用产品，k8s 原生功能一般也不会变，这样好做环境切换时的适配；同时尽量保持开发测试的开源与生产的商用的 k8s 版本保持一致。

嘉宾： 埃里克 资深解决方案架构师 , 红帽企业级开源解决方案中心
开发测试和生产最好保持一致。商用的最好还是一些主流大厂比较好，偏门的化万一没了自己的技术积累又需要重新开始，不太划算。

如果是自己学习和了解就最好两个都学一下，毕竟最后学习的目的也是为了上生产。

3、如果采用商用容器云平台，是选择一整套私有云平台包含容器云还是单独采用容器云平台比较好？

嘉宾： henrylv206 架构师 , 建信金融
这个根据自身情况吧。 目前 k8s 是容器云平台事实上的标准，而且其即可以部署在物理机上，也可以部署在虚拟机上，而且能够通过插件适配不同的网络和存储，所以在容器云平台的采购上，完全可以做为一个独立的产品来采购。

嘉宾： 北京不眠夜 产品经理
作为银行，业务数据是核心。因此，建议容器采用私有化部署，公有云可以放一些对外的服务在上面，主要做好相关的网络安全和数据安全。

容器云采购，不光是容器云自身的问题，还要考虑到未来容器云与 DevOps 、微服务平台、云管平台整合的问题。因此，采购时要考虑厂商是否能提供相关领域的产品、方案或服务。

如果，您还没有建设私有云，可以考虑 IaaS 和PaaS 一并采购。 若所以产品都采购一家产品，好处是方案完善，打通成本相抵比较低。但也容易让厂商捆绑，未来平台调整会非常困难。

嘉宾： JanXC 系统架构师 , nec
建议整体规划、逐步落地推行吧，如果先有了私有云平台，在搭建容器云的时候，还是要与私有云进行整合的，毕竟在生产环境来说，虚拟机和容器会是一个较长时间的并行局面，这就决定了两个平台要相互打通、整合。

三、 容器云自研技术路线的困难和挑战

对于走自研的技术路线银行而言，大量开源产品的使用大大压降了容器云的研发费用，同时合作者会持续不断对开源软件进行更新，另一方面开源的商业模式也使得供应商带来的锁定限制被打破，为企业客户提供了更高的灵活性和可控性，这些都是自研路线的优势。而劣势也很明显，如果银行自身缺乏足够的IT实力，同时开源软件因某些原因削弱专业团队的支持，即将面临开源代码的质量，这会对银行自身造成潜在威胁。所以需要更好的了解选择自研技术路线需要应对的困难和挑战是否可以克服，否则还是需要进行更好的技术沉淀，资源积累，别贸然选择自研。下面几个交流的问题，可以充分表明自研的困难和挑战，让银行IT专家可以更好的进行评估。

1、银行如果选择容器云自研路线，可能会遇到哪些困难和挑战 ？

嘉宾： henrylv206 架构师, 建信金融

1. 首先是人才：云原生相关技术作为前沿技术，有经验的专业人才不易寻找；
2. 其次是技术：对于云计算相关技术的深入理解，如何作出满实际需要的解决方案，比如：
3. 集群方面：面对不同的业务类型及规模和特点，可能提供的集群方式也不尽相同，比如共享集群、专有集群，甚至共享分区或私有分区；
4. 计算方面：节点类型（物理机、虚拟机）、宿主机系统（centos、ubuntu）、容器运行时（docker、kata）、k8s 等及其相关版本的 选 型，以及特定应 用场景相关调度策略的二次开发；另外对于特定 场 景，比如ai，还需要有gpu 等相关的支持；
5. 网络方面： 针对不同的应用场景，可能建立容器网络的方式也不尽相同（比如：overlay、underlay、隧道），甚至还需要实现特定能力的定制开发，比如 IP 固定；
6. 存储方面：在容器云平台提供存储方面，不同数据中心，底层存储类型或iaas平台不尽相同，也需要自定义开发k8s csi 扩展组件，实现存储资源的自动供给；
7. 部署架构：以金融核心应用为例，需要满足多活跨AZ的要求，这就需要在原生k8s 部署方式的基 础上进行扩展， 实现应用跨AZ跨k8s 集群部署，保障业务 多活高可用。
8. 再次，在一个已有完善运维管理体系的机构之中，上线一个新的容器云平台，势 必会有一些管理流程、运维工具、 监控系 统的对 接，以及相关的沟通交流；
9. 最后，新的云原生技术的普及， 对于习惯传统技术研发及运维的人员来说 ，新的技术的引入，适当的宣传 和技术支持也是必不可少的，当然也是一个不小的挑 战 。

嘉宾： rechen 云计算架构师
容器云平台的建设模式选择自研与否，是需要先规划清楚此平台上要承载哪些业务应用。

如果是关键业务应用，则为保持业务连续性，自研容器云平台的高可用性、稳定性会是最大的挑战。 如果是承载些边缘应用，则自研容器云平台用户体验、工具打通、应用上云等工作会遇到困难。

嘉宾： 魏新宇 副首席解决方案架构师 , 红帽企业级开源解决方案中心
通过很多开源组件拼接处一个容器云，难度并不是非常高。难点在于运维、升级、故障诊断。 K8S 每年出三个版本， K8S 升级不？升级的话，其他组件升级不 ? 只要有几个组件升级，就可能带来适配性的 bug 。此外，生产上出现问题，靠网上搜索解决方案，压力还是很大的。

嘉宾： 顾黄亮 技术总监 , 苏宁消费金融有限公司
银行很少选择自研，就算有，也是某一个局部的支撑工具，笔者经历过很多次自研项目，也包括容器云，从笔者自身的经验，来回复自研路线中需要考虑的问题。
1 、需要核算技术选型的成本，容器云的自研重点在于容器和服务编排，这两个选定后基本可以确定产品的系统架构，如果系统架构不确定，实施后再进行修改或者更换的成本是非常巨大的。
2 、需要考虑开源框架快速发展，目前主流的编排技术均为开源软件，随着容器云技术在企业中越来越多的普及应用，开源软件自我完善和发展的速度比较快，版本更迭频繁，甚至不同版本之间架构等差异比较大。因此需要更加关注软件生命周期过程中框架的平滑升级和过渡。
3 、需要提前预演应用高可用的风险，从架构层面看，容器云是一个整体，容器云内部架构出现异常，可能会导致整个云异常，影响容器云上的所有应用。因此，高可用、可靠性需要反复测试演练，并形成灾难恢复应急文档。
4 、控制企业内部落地的风险，容器云上运行的是银行业务系统，因此必须遵循银行系统的特点，比如满足应用系统安保等级要求等，容器云的落地，一方面是技术方面的风险，比如和行内各种现有系统的对接等；一方面是制度流程方面的风险，容器云必然会带来很多新的思维和理念，这些最终需要靠制度流程来保证实施，需要进行流程梳理和修改，避免 “ 水土不服 ” 。

嘉宾： rechen 云计算架构师
银行以自研方式建设容器云平台的核心挑战和困难，有多方面。（1）基础设施方面的支持，譬如要考虑银行有成熟稳定的 IAAS 资源池的支撑， 选择好操作系统和确保供应商支持到位。 （2）是团队建设，譬如核心技术骨干的培养，保障骨干队伍的稳定性 （3）运营体系的建设。走自研的路线，好处是自主可控和节省采购成本，但是要趟的坑较多，运营运维的成本较大，需要加强规范、培训和架构治理，引导业务应用开发方使用好容器云平台。

2、银行如果选择容器云自研路线，如何解决容器云自研过程中遇到的困难和挑战 ？

嘉宾： 埃里克 资深解决方案架构师 , 红帽企业级开源解决方案中心
很好的问题，本人参与过国内大客户的一些云平台的自研，自研的话首先是需要有个专门的团队针对平台进行开发和运维，另外需要有些团队进行平台的推广和项目的迁移工作，以为 Kubernetes 社区是一个比较活跃，同时涉及的技术面相对比较广泛的社区，需要对底层的 OS 技术，网络技术以及存储技术，上层的应用都有一定的了解，因此首先需要具备扎实的技术功底，另外需要关注容器社区的发展和补丁的发布，最好是有时间去研究源码，这样才知道底层的实现原理，出现深坑的时候能有一定的主动性，因此其实投入是相对比较大的。

嘉宾： lzj7618937 质控经理 , cib
如果选择自研肯定得考虑到后续不断出现的各种问题，而且这种底层平台问题可能还会涉及到硬件层面的兼容性问题，万一没有相关设备兼容，是准备自研相关驱动么？成本太高，不建议，银行就该干银行做的事，没必要把钱花在这上面，多花点心思如何服务好客户不好么？

嘉宾： tongyizhou 战略产品业务拓展经理 , 红帽企业级开源解决方案中心
这个问题比较复杂，从开源软件研发特点的角度来看有以下分种情况：

基于社区版开源软件自研：这是国内企业采用最多的方式。此研发方式的核心是要考虑并解决自研软件与社区版本间演进性差别的问题。例如企业在 k8s1.8 版本的基础上进行了自研（增加了部分功能，修复了很多 bug ），当社区版本演进至 2.0 时，企业版本需要在 2.0 的基础上重新实现 1.8 版本上的自研功能，才能顺利升级到 2.0 版本。长此以往，云原生时代开源软件快速的演进性会导致企业自研面临两难问题：不升级则不能享受到社区版开源中的新成果；升级则牵一发动全身，随着版本演进需要重写的代码量越来越大。解决方法有二：
a. 对于非核心部分的功能增强，建议利用好社区版组件的 API 在组件外单独开发，保证此部分功能与社区版组件清晰明确的界限；
b. 对于必须要修改社区版核心组件的研发及 bug 修复，建议参考红帽 “ 上游优先 ” 的研发策略，将自己的代码提交至上游社区（如 k8s 社区），这部分代码被社区接纳后会自动被集成到后续发行的社区版本中。以此避免相同代码在企业更新社区软件版本时的重复撰写与维护。
基于企业级开源软件自研：这是国际上先进云原生玩家的思路。企业可以选取 100% 开源的企业级社区软件作为研发基础（企业级开源软件保证了较高的稳定性和较少的 bug ；100% 开源保证了企业可以基于其研发不会有法律或知识产权风险），利用企业级开源软件的 API在外围进行功能增强研发，打包形成自己的产品。企业级开源软件本身的稳定性、演进性等会消耗大量研发力量又少有行业属性价值的功能则直接依靠企业级开源软件供应商的版本演进解决。这种方式在保证了开源组件稳定性、演进性的同时，大大节省了企业的研发力量投入，是一举多得的思路。

嘉宾： henrylv206 架构师 , 建信金融
打铁还须自身硬！选择自研，还是要建立一支专业的容器云平台研发团队才好，学习业内优秀产品，跟进社区技术发展趋势，整合优秀开源实践，同时聚焦金融产品，加强底层关键能力及核心技术的自主研发，扩展云原生技术能力。

嘉宾： rechen 云计算架构师
1 、即使选择容器云自研路线，也要以交付业务价值为导向，以及注意实施节奏上进行迭代演进。自研的每个迭代做好规划和关联基础设施面的技术选型，譬如 IAAS 层需选择商用稳定的产品。
2 、容器云的第一个迭代中，K8S 集群建议选择商用发行版，第一个迭代内容重点在面向应用侧的交付，譬如 DEVOPS 的CI、CD ，和银行现有运维工具平台、用户权限体系、研发管理流程的对接。这个环节建议和外部厂商合作伙伴进行合作。
3 、在容器云的研发、运维、运营团队建设成型后，可以深度上，择机将自研范围扩展到 K8S 集群软件，譬如容器云平台可以纳管社区版 K8S 。广度上，在容器云平台的自研范围拓展到 serverless 、微服务的能力建设上。

嘉宾： penganxiang 系统架构师 , 互联网企业
云平台这种基础设施，最大的挑战是业务改造和迁移，目前云原生还是那么火，很多产品社区也是非常活跃的，技术大佬非常多，个人认为是更多的问题是符合自己业务场景的平台和工具的选择，例如网络 CNI 、存储方案等都有很多，需要前期做一些调研，选择一款更适合的。

嘉宾： sf7071 云计算研发工程师 , 某大型银行
容器云目前基本都是基于 Kuberentes ，作为银行科技部门，不太可能有更多精力深入开源社区去贡献代码，所以我认为自研的范围应该是将 Kubernetes 等开源软件有机组装在一起形成容器云的底座，在上层自研开发适合本地管理流程和用户使用习惯的容器云管理门户，以期与自有其他研发运维工具链进行对接，形成内部的 DevOps 生态。在这个过程中，可能遇到的问题包括但不限于如下两方面： （1）开源软件选择、更新机制以及团队建设。除了 Kubernetes以外，要组成容器云还需要其他软件的配合，比如负载均衡、 web 中间件、镜像仓库、 CI/CD 工具、监控、日志、 DNS 、网络、存储、操作系统、高可用切换等等，需要成立专业技术团队进行研究和测试。对于品种选择，建议调研并选择业务主流，同时研究备用方案；对于版本选择，建议选择当前次新版，并在未来相对长一段时间保持稳定，非必要不升级。对于团队建设，建议社招引入专业技术人才，并结合内部培养，通过前期技术研究打造一支具有自主研发运维的容器云专业团队，以期形成良性循环。（2）开源软件使用过程中遇到疑难问题 在容器云的建设和后续使用过程中，难免遇到疑难杂症，比如与底层基础软硬件设施适配问题、开源软件 bug、安全架构和安全保障等等，可能自身团队能力层次暂时无法快速解决，建议同步引入外部技术支持服务，辅助建设和运维，但最好不要依赖外部技术支持服务做所有的事情。

嘉宾： zhuqibs 软件开发工程师 , Mcd
这个问题，一般企业两条路，如果人多时间多，那就自研；如果钱多时间少，那就买现成的。 如果是自研，坑一定是少不了的，我的观点是分情况，改买现成的，一定要买，不要省这个钱，但有些可以自研。 （1）比如 ceph 这种分布式云，最好不要自研，你自己搭起来的能用是一回事，但用于生产就是另一回事了，一旦遇到网络上 bug ，那一定死定了，这个容器中涉及网络的，别犹豫，找个现成的。（2）容器云中的 crd 开发，这个可以找社区或官方的成熟组件，不用自已研发，你自己研发的，没有长时间的测试，谁敢用。 （3）省下的，就是ui界面了，这个可以自我研发

嘉宾： henrylv206 架构师 , 建信金融
自研过程中遇到的问题不一定都是技术型的，也有些可能是规范或者应用上的问题，对此，解决不同问题，采取的方案也不同，但对于容器技术上的问题：建立一支专业的容器云平台技术研发团队是必不可少的，学习业内优秀产品，跟进社区技术发展趋势，整合优秀开源实践，同时也要结合自身场景需求，加强底层关键能力及核心技术的研发，扩展云原生技术能力。

对于其它非容器技术问题，比如内部应用运行要求、管理规范、运维管理、及规模化推广等问题，需要加强内部协作、跨部门沟通，以及一些运维工具的开发实现，同时也需要建立一支专业的应用容器化技术团队，更好地支撑容器云平台在企业的落地。

嘉宾： sf7071 云计算研发工程师, 某大型银行
有几点建议：

内部要先从思想上进行云思维转型和统一，这是一切管理活动、技术方案等决策的基础和大前提；
要有专业能力强大的容器云研发团队和运维团队，且职责分工要清晰；
有外部力量支撑，从方案、疑难杂症、技术视野、能力培训等多方面辅助自研和自运维；
内部相关组织机构要充分协作，包括管理、应用研发、技术平台、运维等相关部门，遇到问题不可怕，可怕的是所有问题都压在一个点。

嘉宾： 顾黄亮 技术总监 , 苏宁消费金融有限公司
大体分为两类，技术范围的和非技术范围，笔者将过程中的问题大致分为三类，分别是稳定可靠、自主可控、简单易用。
1 、稳定可靠，金融企业对稳定可靠特外重视，尤其是持牌机构，因此格外需求容器云应该要保证业务高 SLA 。
2 、自主可控，金融企业的架构优化往往需求基础架构进行配合，尤其近几年新技术得到频繁的运用，以微服务为例，所以需要格外关注容器云的开源组件的迭代问题，作为企业用户，版本升级的时候会有很大的风险性和不确定性。
3 、简单易用，使用容器云不是目的，目的是解决企业目前面临的问题，给企业带来价值，如 CI/CD 、面临高并发的时候快速扩容、故障快速恢复和迁移、应用快速交付、复杂集群快速部署等问题

嘉宾：
1 、可持续性技术输出
金融企业主业在金融交易上，而容器云作为 IT 的一种底层技术选择，自研的动力并不充足。因此，能否有长时间稳定的开发团队来支撑，这是需要注意的问题。

2 、内部推广困难
在内部推广过程中，往往会遇到应用开发团队不愿意使用的问题。有应用团队对容器不了解，排查使用新技术的情况；也有平台不好用的问题。 根据我的经验，
（1）领导要对容器化应用有足够重视，推动各个团队使用；
（2）反复给应用团队培训容器，让其了解容器能够给其带来的价值；
（3）对于已经熟悉开源 K8s 的开发人员，更喜欢用 yaml 发布；运维人员对 k8s 了解有限，需要界面化操作。这两种类型，平台都需要兼顾。

3 、人员需要持续学习
既然干上 IT 这行，就要活到老学到老。需要对 K8s 及周边技术的持续学习，包括对开源社区的动向也要及时了解。

嘉宾： penganxiang 系统架构师 , 互联网企业
整个平台建设过程中肯定会遇到很多问题，例如技术架构选型、版本缺陷，一些特殊的场景满足等 一些技术架构之类的问题主要是看团队的技术水平，自研过程可以适当的引进一些云厂商做咨询之类的。但是当平台和业务场景耦合到一起就比较有特色了，有相同的案例较少，需要不断的提升团队的技术水平。

3、银行如果考虑自研路线，要关注哪些技术领域？从易到难的迭代建设的顺序如何 ？

嘉宾： henrylv206 架构师 , 建信金融
重点关注以 k8s 为中心 cncf 社区开源项目。 首先是学习 docker 和k8s ，先从部署和试用开始，目前发展已比较成熟，搭建一个开发、测试环境不会太复杂，使用已有工具，比如： kubeadm 、kubespray 等； 其次，建立镜像仓库，研究学习 k8s 相关原理及常见问题故障分析，并根据自己的业务需求和资源情况，选择合适的网络、存储方案；再次，建立相关的容器云平台监控、告警系统和日志系统，一般就是prometheus 、alertmanager 、grafana 、EFK 等。从业务应用上，先从一些无状态业务应用开始，或者 devops 的 job 任务开始，逐步熟练容器云平台的使用和研究。

四、 容器云落地实践和案例

容器云的落地实践，需要遵循几个步骤，首先需要对内部的系统体系和结构进行梳理，梳理出相应的容器云适配场景，如资源密集型，计算密集型，网络交互密集型的场景；其次进行容器云的技术选型和建设；第三个阶段是逐步上云阶段，优先选择轻负载应用和偏互联网侧的应用，最后阶段是容器云的维护和DevOps建设的阶段。如果有多云场景，还需要考虑多云的管理和相关的流程的衔接。

1、对于容器云平台来说，是单独建设好还是通过云管平台管理起来进行统一的资源调度好？

嘉宾： rechen 云计算架构师
这和单位的组织机构有关系。譬如如果云管平台团队先建立且运营良好，则容器云平台可以由云管平台进行统一管理。

容器云平台的建设，除了资源调度这个因素，更重要是运营支持、平台运维和培训支持等工作，是需要团队负责做的。

嘉宾： 强哥之神 容器云架构师及技术经理 , 上汽云计算中心
这里云管不知是否指多容器集群管理，如果是的话，则这个看具体需求场景，规模小的，就不需要云管，目前主流的容器云有openshitf, rancher, kubesphere 等。

嘉宾： 魏新宇 副首席解决方案架构师, 红帽企业级开源解决方案中心
通常是容器云先建设，当集群数量多了，构建容器云管平台。主要是因为：只有用了一段时间容器云，企业才会了解自身对容器云管的特色需求。

2、中小银行容器云平台建设如何快速落地，目前商业 、自研路线有哪些可参考案例？

嘉宾：henrylv206 架构师 , 建信金融
容器云的快速落地，一是容器云平台本身的建设，这个商业或自研，根据自身情况来定； 其次是业务应用的容器化改造，如何推动业务上容器云的积极性，在银行内部，可能至上而下推动会好些； 再者，对于核心金融系统上容器云，原生的 k8s 能力恐怕是不行的，还要根据金融级要求做一定的改造； 找参考案例的话，建议是找一些金融核心业务容器化的案例，比如个贷、信用卡等业务，可能更适合金融场景。

嘉宾： rechen 云计算架构师
中小银行容器云平台的快速落地和成功实施，2个重要因素是：1、行方要选择好建设模式和技术路线，建设好团队和关注推广运营。2、选择好一个合适的合作伙伴，譬如浦发银行容器云平台是选择了某家合作伙伴，持续演进。自研的案例还有建行、微众银行的容器云平台。

嘉宾： 魏新宇 副首席解决方案架构师 , 红帽企业级开源解决方案中心
商业方案可以参考农行、招行。工行的容器云是自研的。

五、交流达成的共识总结

通过本场银行同行的交流活动达成了一些交流共识如下，仅供参考：

（1）以容器云为代表的云计算2.0将成为未来主流IT基础设施，容器云带来了全新的IT服务架构，使企业将更多的资源和精力聚焦到自身核心业务上。
（2）在容器云的技术选型方面，自研和商用两条路线将长期共存，两种技术路线都有各自的优缺点，企业需要根据实际情况进行选择，建议没有自研能力规模的银行还是选择商用路线比较合适，协作才是长期共赢。
（3）在容器云落地实施过程中，需要遵循相关的步骤和流程，分别是场景梳理、容器云建设、应用改造和最终的赋能。
（4）容器云自研必须要克服的难点：人才、技术（运维、升级、故障诊断）、成本。
（5）容器云的专业分工越来越明显，根据不同行业、不同企业、不同场景的需求，相关的领域级能力会越来越明显，同时容器云的生态也愈加完善，生态平台成为未来颇为确定的行业趋势。