当前银行行业伴随云计算、大数据、人工智能等技术的发展，特别是受去年疫情影响，很多业务由线下转为线上，在新业务形态、需求、创新等方面都对现有IT架构提出新的挑战，同时也带来了企业对IT基础设施的敏捷化需求。当前多数金融行业企业在云计算建设主要集中在IaaS和PaaS，目标是为降本增效，同时为上层业务的快速创新和迭代提供有效支撑。传统的IaaS主要集中在计算、存储、网络等基础设施层面，资源调度颗粒度粗，资源使用率提升并不明显，随着技术发展和开源社区的成熟，企业建设方向从IaaS转向PaaS，而且容器、Kubernetes、微服务架构等新技术在弹性伸缩、资源使用率提升、业务快速迭代、运维效率提升等方面表现出色，容器和PaaS的需求在金融行业由试用转向大规模推广应用，建设企业级容器PaaS平台也成金融行业新一代基础架构。

随着银行行业越来越多的业务从线下迁移至线上，对业务的连续性、数据安全性提出新的要求。金融行业具备信息化程度高和信息安全要求高两大特征，如果数据中心不能提供数据备份、数据恢复、业务容灾等，则该数据中心是不可用的，是不符合金融安全监管要求的。因此如何保障金融机构信息系统安全高效的运行，不仅要选择适合自身生产环境的容器云平台技术方案，还要考虑不同信息系统采用不同灾备方案，以达到 TCO 的最优化。

本期就结合：城商行生产环境容器云平台同城及异地容灾架构设计在线进行探讨交流，交流问题汇总如下：

1、城商行如何选择适合自身的容器云平台技术方案？以及采用的灾备方案？

城商行如何选择适合自身的容器云平台技术方案？并且如何确定不同业务系统在容器云平台上应该采用的灾备方案制定？

回复1：sf7071 软件开发工程师 , 某大型银行
选择主流技术方案即可，目前市场上的容器云平台主流都是采用Kubernetes+Docker为核心技术，其他还配套有监控模块、日志模块、DevOps模块、微服务模块、云管平台、镜像仓库等，可根据自身需要进行组合引入。灾备方面，平台层可考虑异地联邦集群部署的方式，发布应用时同时在两地进行部署，应用层依靠入口流量智能路由、底层数据库实时同步等机制来保障。

回复2：魏新宇 副首席解决方案架构师 , 红帽企业级开源解决方案中心
城商行建议选择企业开源容器云方案，而不是 DIY 。容灾方案建议通过部署多套容器云集群，将应用部署到不同容器云实现。

回复3：onionpiece 云平台工程师 , 建信金科
基本都是在kubernetes基础做的，如何选择，是一个结合自身，层层剥茧的过程。
本地化如何、是否便于使用和运维，是否带有配套DevOps模块，镜像仓库如何做到高可用和流转，是否有成熟认证、日志、监控、告警对接方案，这都是基本功。
稳定性、高可用设计、灾备方案、平滑升级，这些是不同方案PK的重点项目。
网络方案能否兼顾云原生应用开发和传统应用改造过渡，能否很好的打通容器和非容器基础设施，能否将容器纳入到传统网络的管辖之下，能否利用上传统网络的VLAN隔离、硬件负载、防火墙等设施，这些是网络方面仁者见仁的加分项。
存储方案能否利用已有的存储资源池或设备，如果要配套建设诸如ceph等，己方人员是否有能力应对，这些事存储方面的加分考量项。
当然安全也是一个要考虑的点。

回复4：老孙 软件工程师 , 兴业数金
除了k8s或ocp的技术选型外，部署规划、网络、存储的选型很关键。
1、部署规划，考虑如何在不同网络区域建设集群，集群的规模、数量；还是考虑建设大型集群（结合underlay的网络跨网络区域）
2、网络主要看使用underlay还是overlay，要结合网络监控、运维需求和应用技术架构的需求；
3、存储一个是平台组件本身使用的存储，二是提供给上云应用的存储；考虑性能、方便管理、扩展性、可靠性等需求
灾备方面，主要涉及承载的应用需要考虑的设计。容器平台更多的定位是基础设施。不同机房，都需要建设容器集群承载应用，同时对镜像、集群关键信息，etcd数据进行完整备份

回复5：lansh 高级系统工程师 , 某保险股份有限公司
1）根据行业的要求和特性，结合公司的实际情况（当前的已有的系统架构，相关的平台复用，人员的技术储备，公司的组织架构）来选择适合自身的容器云平台技术方案 2）根据不同的业务系统的服务等级和系统架构，差异化采用不同的灾备方案，数据库和客户的相关非架构化的数据的灾备方案尤其要重视和注意。

回复6：强哥之神 容器云架构师及技术经理 , 上汽云计算中心
这个问题的范围有点大，容器云平台主流技术方案还是 K8S+Docker，当然还有涉及微服务的场景的 Istio 等。至于 不同业务系统在容器云平台上应该采用的灾备方案制定 ，这个需要看业务场景，一般的有通过 global DNS 配合多集群的 ingress 或 SLB 来实现业务访问的 HA，还要考虑业务在多数据中心的灾备、单数据中心多集群的灾备，这里涉及到的更多的是业务的数据存储及同步相关

2、城商行上容器云平台是直接上测试环境OR直接上生产环境？衡量的标准是什么？

回复1：魏新宇 副首席解决方案架构师 , 红帽企业级开源解决方案中心
取决于应用的特点。目前有开发测试是容器云、生产是容器云和 VM 混合的情况。应用上容器云的准入标准可以参考：
1.已建立了清晰的可自动化的编译及构建流程
应用使用了如Maven、Gradle、Make或Shell等工具实现了构建编译步骤的自动化。这将方便应用在容器平台上实现自动化的编译及构建。
2.已实现应用配置参数外部化
应用已将配置参数外部化与配置文件或环境变量中，以便于应用容器能适配不同的运行环境。

3. 已提供合理可靠的健康检查接口
   容器平台将通过健康检查接口判断容器状态，对应用服务进行状态保持。
4. 已实现状态外部化，实现应用实例无状态化
   应用状态信息存储于数据库或缓存等外部系统，应用实例本身实现无状态化。
5. 不涉及底层的操作系统依赖及复杂的网络通信机制
   应用以处理业务为主，不强依赖于底层操作系统及组播等网络通信机制以提高可移植性。
   6.部署交付件及运行平台的大小在2GB以内
   轻量级的应用便于在大规模集群中快速传输分发，更符合容器敏捷的理念。
   7.启动时间在5分钟以内
   过长的启动时间将不能发挥容器敏捷的特性

回复2：ljosef 系统架构师 , 某股份制银行
建议完成技术选型后，同步建设。容器平台隶属基础设施，是应用运行的底座，业务的运行应当有一致的测试和生产环境，避免异构影响，同时提供生产和测试的技术参考。
测试环境主要衡量如下指标：
1、验证平台的高可用
2、验证平台的基础功能
3、验证业务开发测试流程，重要看一下与CICD工具的集成能力
4、验证业务高可用的部署架构
5、验证业务扩缩容场景下的业务可用性和稳定性
生产环境主要衡量如下指标：
1、应急响应能力
2、灾难恢复能力
3、平滑升级能力
4、备份还原能力
5、监控告警能力
6、安全审计能力

回复3：onionpiece 云平台工程师 , 建信金科
一般而言，能够达到服务生产的程度，容器云平台的测试环境和预发布环境都是必要的。
测试环境的建设更多是服务于应用系统的研发团队。有容器化经验的应用团队会更明确该怎么做，无论是镜像制作、部署模型、服务发布都会更能充分利用容器平台；而缺乏相关经验的应用团队可能会出现使用非官方镜像、未经考虑的设置资源配比等情况，这些都会加剧测试环境的混乱程度，搞成一锅粥。所以测试环境是绕不过去的，在这个阶段，容器云平台的使用方和运维方可以在协商之下，界定好容器平台的使用规范。而预发布环境更多的是为容器云平台的运维方准备的，平台所有的变更要在这里预演，和生产环境相关的故障重新、定位分析、修复试错要在这里进行。测试环境 -> 预发布环境 -> 生产环境，这一条链路伴随着镜像成品、配置方案的沉淀，并且也只有前置环境沉淀下来的成品和配置才能流转到下一个环境。

如果衡量标准说的是上测试环境还是直接生产，那么就前面说的，通常来说直接上生产环境基本就是铤而走险。但也有例外，例如想先用一些无状态的app应用来做试点。如果资源充足、架构设计合理，那么应用发版的时候可以选择A/B或蓝绿发布来增加抗风险能力，同时尽量使用反亲和来规避平台节点故障带来的风险。

而如果说的是平台建设的方案选择标准，最重要的稳定性、高可用和灾备设计。至于其他方面就需要结合自身，看看更倾向于什么，包括运维方式是否匹配现有规范和传统，网络方案能否兼顾云原生应用的开发和传统应用的改造过渡，已经存储方案能够充分利用已有资源池或设备。

回复4：sf7071 软件开发工程师 , 某大型银行
建议在引进后同步建设：容器云平台的价值在于充分利用资源、提高交付效率、所测及所投等，一切的起点在测试环境，过程中涉及CI/CD、质量门禁、制品晋级等，大量前期工作都是在测试环境完成，所以建设测试环境是首先要做的，也是重中之重。只有在测试环境通过了测试的应用系统才能投产，生产环境也要同步建设就绪，且需与测试环境保持高度一致，这样才能保证通过测试的镜像可直接运行于生产环境。

回复5：老孙 软件工程师 , 兴业数金
容器云平台上生产环境需考虑几个维度的问题。
1、基础设施层的高可用：物理机（不同机架）、虚拟机（分布）、网络设备双活、存储选型（SAN、SAS）
2、平台这一层，包含的关键组件，dns，ovs，etcd，master等的高可用方案；
3、平台网络方案的选型，结合网络监控需求，应用架构需求，网络隔离需求，underlay还是overlay。
4、平台的数据备份和应急处理方案，巡检方案、监控告警方案的落地；
5、用于支撑平台上应用的仓库、负载均衡方案、存储方案、CD方案的落地
6、应用的管理、滚动更新、灰度、回滚、集群容量管理方案的落地
逐步落地实现即可。

回复6：lansh 高级系统工程师 , 某保险股份有限公司
金融行业中系统的可用性和稳定性有比较高的要求，在选用哪个容器云平台时，想必都进过了严格的选型和测试；测试和生产容器云平台上线的优先和在传统的虚拟平台等一致，一般都先上测试环境，相应的应用系统在容器云平台测试成功后，才会发布于容器云的生产环境；其标准的权衡因公司实际的情况而异，一般涉及：1）行业规范和及标准（要求）2）先开发-测试-生产这样一个常规流程 3）特殊情况特殊处理。

回复7：强哥之神 容器云架构师及技术经理 , 上汽云计算中心
一般是遵寻UAT->SIT->PRD这样的业务上线过程，标准在于确定业务上产线是稳定的、高可用的、高性能的。

回复8：按照实际生产规范流程要求：
1、测试环境主要以测试工作为主，当完成全部应用服务测试后即可向其他环境发布，如：预生产环境、生产环境。
2、生产环境主要是日常使用应用为主，对环境要求比较稳定、能够及时响应业务请求与处理，不会涉及功能修改、开发、测试等使用需求。

回复9：nameless 技术总监 , 某云计算厂商
先说衡量标准，业务的稳定性和可靠性！
一般业务上生产环境需要经过多个流程和环节，首先业务能否在容器云平台运行，运行是否稳定和可靠，业务运行在容器云平台是否经过功能集成测试和压力测试等等，只有这些都通过了才能在生产环境运行！

一般上生产环境还会考虑业务的灾备和容灾场景。

3、开发、测试、生产环境如何规划容器云平台？

是分别在搭建容器云集群还是混合在一个或二个容器云集群更好？

回复1：onionpiece 云平台工程师 , 建信金科
看自身条件，包括资金、人员等。
生产环境最好是单独的集群，毕竟稳定性和可用性压倒一起。当然也有例外，例如不打算投入太多，只在容器平台上跑一些有容忍的内部系统的时候，可以考虑混部。
开发和测试环境通常可以混部。但如果考虑做一些适配性自研，涉及到对容器云平台自身的改造时，就需要注意到这里所说的开发环境在容器应用开发的基础上多了一类用途。这类开发工作会导致容器平台的不可用，有条件的话，针对这类进行单独部署。
总的来说，只要条件允许，单独部署更好。对于运维同学来说，增加了工作量，但是没有明显的工作复杂度增减；而如果混部的话，可能会直接导致复杂度的增加。但单独部署的时候，就需要设计流程，如何将镜像和配置等在多个集群或平台间流转。而混部的话，可以考虑用同一套镜像仓库和配置仓库，但同时也意味着要做好明确的规范和权限管理。
混部的时候，如果条件尚可，那么可以将节点打上不同分区label，将节点划分出不同的组，用于开发的、用于测试的、用于生产的，等等。这样做的好处是故障区的切分，但同时你需要为生产组多分配一些节点，以满足反亲和的目的来提升可用性。

----更新----
关于镜像和配置的流转设计，可以认为这和CI/CD相关，当然也要结合企业自身情况。在没有CI/CD的情况下，以镜像为例，需要由项目开发组自己负责镜像构建，当需要提测的时候，为镜像打上约定好的tag，这时利用harbor的replication机制，针对提测tag将镜像同步到测试环境的镜像仓库。测试人员针对提测镜像进行测试后，为通过的镜像打上可以投产的tag，再有harbor将这类镜像流转到生产的仓库。

回复2：魏新宇 副首席解决方案架构师 , 红帽企业级开源解决方案中心
主要是看网络隔离。如果不要求物理隔离，就通过namespace隔离。如果有物理隔离的要求，就部署多套集群。通过镜像仓库打通。

4、容器云平台的容灾机制与传统数据中心相比，优势有哪些？不足有哪些？

容器云平台的容灾机制与传统数据中心相比，优势有哪些？不足有哪些？针对具体的业务场景是否有具体的方案？

回复：魏新宇 副首席解决方案架构师 , 红帽企业级开源解决方案中心
由于容器云本身主要承载无状态应用，因此容灾主要是持久化存储的灾备，可以借助底层存储实现。容器云本身的备份，主要是k8s对象，deployment svc route 之类的，可以通过脚本把yaml文件备份出来。etcd提供备份脚本，可以导出数据文件。

5、微服务与容器云的边界划分是什么？

回复1：魏新宇 副首席解决方案架构师 , 红帽企业级开源解决方案中心
SpringCloud与K8S的考量，其实就是SpringCloud要不要跨多个K8S集群的事情。
比较理想的情况是：SpringCloud和K8S完全对齐,也就是一套Spring Cloud运行在一套K8S集群。在这种情况下，微服务、配置中心、注册中心都在相同的K8S集群中。这样，微服务在指向配置中心的时候，写配置中心的SVC就可以，这样做的好处是网络I/O路径短。
但是，如果SpringCloud跨多个K8S，会有什么问题呢？
我们先看两种实现方式：

1.配置+注册中心在一个K8S集群上：如果K8S集群的SDN用的是underlay网络，那么其他K8S集群注册的时候，由于其pod ip和宿主机ip在同一个网络平面，注册中心能够准确识别pod的ip，问题也不大。但这时候，就需要手工配置跨K8S集群的dns了。例如pod hostname到pod id的解析。这种方式的弊端是：
（1）微服务去注册中心注册时，网路I/O路径长。需要先经过注册中心所在K8S的ingress，才能到pod（数据中心一般不让用nodeport）。
（2）数据中心网络需要打开BGP（因为用到了类似caloci的underlay sdn方案）
（3）underlay网络方案比较耗费数据中心的IP。

2.配置+注册中心在一个K8S集群上：如果K8S集群的SDN用的是overlay网络，那么其他K8S集群注册的时候，由于pod ip和宿主机ip不在同一个网络平面，注册中心不能够准确识别pod的ip，只能识别到pod所在K8S宿主机的IP（pod以SNAT的方式访问集群外部），这就有问题了。想要解决这个问题，可以考虑使用pod的多网络平面，也就是给pod增加第二个虚拟网卡，挂载数据中心同一个网络平面的IP。具体技术类似macvlan、ipvlan。这种方式不用再单独配置DNS。

这种方式的弊端是：
当宿主机的上启动的macvlan数量较多时，网卡性能会下降。
以上两种实现方式，各有优劣势。
https://mp.weixin.qq.com/s?__biz=MzAwMDc2NjQ4Nw==&;amp;mid=2663502397&idx=1&sn=4bb5ef56a5651a147acdeb23664df2ec&chksm=81d69545b6a11c53c4b827e8c6d747c8b333ce2b660d7794de61a0a068e64ea1837d04fd248e&token=295652040&lang=zh_CN#rd

回复2：容器和微服务没有所谓边界问题，两种技术思想和解决业务场景各有侧重。
微服务作为一种当下流行的技术架构，主要解决原有架构中服务比较重、依赖性比较强，所需要承载服务的资源要求比较高，无法快速响应业务变化等问题。
容器解决底层物理资源、虚拟资源利用率不足、容灾备份跨集群保障等方面问题。
当微服务架构越来越成熟后，容器作为微服务载体能够提升微服务架构的稳定、高可用、数据安全以及快速响应变化等诉求。所以微服务和容器即可相辅相成又可独立使用。

回复3：xushuhao11 网络工程师 , eccom
微服务是重构业务的方法吧，而容器云是承载微服务的一种更好的方法。同样都是为了更好的为业务服务的手段。

6、使用开源容器框架来搭建云平台，如何实现异构云服务的快速切换？

回复1：onionpiece 云平台工程师 , 建信金科
最朴素的方案就是切流量，流量整体从主中心切到备中心。
既然应用系统已经经过容器化改造，或则就是云原生应用，那么无论是运行在商业云平台还是开源k8s上，本质上是没有却别的。因为大家基本上都是基于k8s做的，可能会有影响的地方是，如果商业云平台自研了控制器，部署单元，服务管理功能等，那么在使用的时候要小心，需要考虑如果让应用在原生的k8s环境上同等的拉起。
相比之下，数据的同步可能要多考虑，这包括两方面。其一是应用编排组织发布的元数据(例如yaml文件，configMap等)，需要确保在主发生的变更能够同步到备；其二是应用数据，建议是通过应用容器通过挂卷的方式，把数据放到后端存储上，然后后端存储再考虑怎样做数据同步。

回复：魏新宇 副首席解决方案架构师 , 红帽企业级开源解决方案中心
切换指的是访问流量切换？如果是流量切换，通常是通过全局负载均衡器实现。
如果异构容器云，可以借助于Ansible工具，书写playbook，进行自动化配置。避免大量手工操作。

7、容器云平台数据的灾备方案？

容器云平台中存储数据文件如何考虑同步？

回复1：魏新宇 副首席解决方案架构师 , 红帽企业级开源解决方案中心
容器云的持久化数据通过PVC/PV实现。而PV基于外部存储实现，如Ceph。数据同步要使用存储实现，不要用容器云的通讯网络，否则带宽消耗太大。

回复2：onionpiece 云平台工程师 , 建信金科
如果说的是一个K8S集群内Pod间的同步，那么可以通过数据卷的挂载来完成，相关数据放在后端的文件存储中，再由Pod按需挂载。并且卷在挂载时可以分配只读、读写的权限。
至于跨集群下的数据同步，只要是通过卷把数据挂出去，做到应用和数据分离的话，那么这就会变成了一个单纯的数据同步问题，与是否是容器化没有关系。

8、容器云平台承载的缓存数据库的容灾方案？

容器云平台承载缓存数据库采用什么样的容灾措施？跨中心集群还是单中心集群，数据同步有何优劣？

回复1：魏新宇 副首席解决方案架构师 , 红帽企业级开源解决方案中心
容器云上运行有状态应用，比如redis，比较成熟的做法是使用Operator。通过Operator做缓存/DB集群在K8S上的管理。这种模式的缓存群通常是不跨K8S集群的，也不必跨，因为持久数据是在DB上的。

回复2：容器存储类型分类三大类：临时存储、半持久化存储、持久化存储。
1、 容器 临时存储，当pod设定为emptydir时，需要为pod所在node开辟一个空的存储卷，临时存储作为预设检查点、临时存储使用。
2、 容器 半持久化存储，避免pod漂移到其他node节点时，pod不能够跨node读取存储资源，需要hostpath来映射。
3、 容器 持久化存储，满足不同业务场景，采用PV(PersistentVolume)、PVC(PersistentVolumeClaim)、NFS三大类定义持久化存储方案，对于PV又分为静态和动态两种方式。
PV/PVC持久化：
•支持数据卷的动态和静态挂载能力
•支持安装任意storage class
•支持数据卷随pod漂移，保证业务系统的正常使用
•支持快照、回滚和克隆
NFS持久化：
•支持各种类型NFS持久化存储方式
•支持NFS存储类型包括：Ceph、Sheepdog、GlusterFS、CephFS、Lustre、MooseFS
•支持分布式存储适合容器场景，选择适合的存储方式

9、S2I与传统意义上的CI/CD GIT OPS的区别？

请详细区分下S2I的持续集成与传统集成，云平台基础上的Git Ops的一些区别及优势。

回复1：onionpiece 云平台工程师 , 建信金科
大魏老师讲的很全面：）
S2I设计理念很好，如果企业没有一个专门负责CI/CD的团队，那么用S2I就好。但如果有的话呢，要让这班兄弟转岗么。
S2I在强调应用系统研发人员的自给自足之外，还带来了就地处理的能力，即在当前集群可以直接制作新镜像，直接就地部署，对于研发人员来说，这是一个强大的正反馈循环。但这仅限于开发测试环境，镜像以及配置等制品的产生并没有嵌入到整条标准流程链中，还是得需要CI/CD的标准链来规范推动镜像和配置等制品在不同阶段的审核和流转。
jenkins也有plugin支持对接容器平台，将编译和打包环境通过Pod放到容器平台上去做，所以资源和扩展性可能不是什么主要问题。

回复2：魏新宇 副首席解决方案架构师 , 红帽企业级开源解决方案中心
CI构建
Jenkins集群在CI流程中调用Maven执行构建，Maven通过插件按指定的Dockerfile生成应用的容器镜像。
●常规CI方案
●每个开发团队均需要编写Dockerfile
●微服务多语言多版本混合构建时无隔离
●构建资源池不可动态扩展
●资源利用率较低

S2I
OpenShift在隔离的容器环境中进行应用的构建编译并生成应用的容器镜像。
●基于容器集群的CI方案
●开发团队通过容器镜像精确定义构建环境
●基于容器的构建环境，提供更好的隔离性
●满足多语言多版本微服务混合构建的场景
●构建资源池可动态扩展，更灵活
●构建与应用运行共享资源池，介绍运维工作量
●资源按需投入及回收，利用率较高

GitOps 的核心思想是 CI/CD 从 git 发起，因此对开发人员更友好。但 GitOps 的实现，例如通过 ArgoCD ， ArgoCD 在 CICD 过程中需要借助 Jenkins 和 S2I 这样的工具来实现。

10、Openshift在私有环境部署怎样实现TCP服务快速发布？

我们在公有云上可以通过提供的负载均衡设备，快速的将tcp的端口暴露出Openshift集群，让外部可以访问，但是在私有部署的方式，只有Http的方式可以通过主机头的方式快速发布，请问在私有云里面有没有相关设备可以配合Openshift，或者Openshift本身能不能提供此类功能？

回复1：魏新宇 副首席解决方案架构师 , 红帽企业级开源解决方案中心
OpenShift 发布 TCP 应用没有任何问题。关键的问题在 Ingress 。 OpenShift 的 Ingress 默认支持 7 层。如果 TCP 应用： 1. 使用 NodePort 2. 使用开源 MentalLB 的方案做四层引入。

回复2：onionpiece 云平台工程师 , 建信金科
可以这样设计：
· svc通过nodePort方式暴露； - 将masters节点挂载负载均衡后面暴露，可以是硬件负载或者自己搭，主要得预设一个区间范围的端口映射，例如openshift集群内nodePort的范围是2w-4w的话，那么负载均衡上就要将相应的端口转发到masters上对应的2w-4w端口；
· 通过网络规划，使用DNS、VIP等手段，将入访流量引流到负载上；
前两步不必说，第三步如果也以静态的方式去做，那么整体下来也可以达到所谓的快速。

11、容器云化后给应用扩展带来了便利，相比传统有些顾虑：1负载方案怎选？2有状态的应用数据持容灾怎做？

1，大规模app扩展 软负载与硬负载如何选取？负载能力，维护性，管理性？
2，容器支持有状态的应用数据持久化，当规模较大时，同城容灾数据如何持续保护保护又该如何做？
3，kubernets编排工具 ，针对中小银行如何选取？

回复1：onionpiece 云平台工程师 , 建信金科
以下内容是在使用kubernetes这一基础上展开：
1.如果app的调用方或者说client也都来自容器集群内部，那么选择软负载，k8s的svc已经支持IPVS了，性能值得一测，而维护性和管理性将不是问题。当然也可以选择其他的开源方案。至于硬件负载，使用场景主要有两类，一类是要为来自容器集群外的client提供负载，另一类是用作整个平台北向的安全访问入口。后者很好理解，这里说一下前者。当需要为来自集群外的client提供负载时，需要考虑#1 硬件负载如何与后端app Pod在网络层面打通，#2 对于app Pod的扩缩容，如何即使更新负载均衡的配置。

2. 可以考虑通过挂卷的方式，将有状态应用的数据沉降到后端存储去。按照这个思路去设计，那这就不是容器的问题了。当然你可能会考虑不只是应用的数据，还包括集群的元数据，包括组织空间，部署信息，配置信息等，可以考虑社区的velero，或者其他方案，这块并不难。 3. 这个真的是结合自身需求，仁者见仁智者见智的问题。

回复2：sf7071 软件开发工程师 , 某大型银行
1，大规模app使用硬件负载+软件负载结合，硬件负载作为入口保障安全稳定，软件负载可容器化部署，通过横向扩展满足性能要求。
2，不建议将数据直接落地到容器云平台上，应平台与数据分离，采用传统的存储方案或者分布式存储方案；
3，kubernetes已是当前的主流和事实标准，大多数的选择。

12、容器的应用日志如何持久化保存？

回复1：onionpiece 云平台工程师 , 建信金科
如果有专门的日志系统，那么通过sidecar或者daemonset pod来吐到日志系统将是显而易见的方案。

如果容器平台提供了ELK/EFK，那么应用方和平台方经过协商，应用日志吐到指定路径，再由平台方采集也是比价好的方案。可能的缺点会出在平台方提供的日志查询能力能否满足应用方的需求。但如果只是日志保存，那么该方案足矣。

最后作为下策可以选择挂卷来存储，对于deployment来说考虑文件存储，对于statefulset额外可以考虑块存储。

回复2：sf7071 软件开发工程师 , 某大型银行
将日志输出到统一的日志中心服务里，或者挂载存储设备将日志保留下来。

回复3：容器应用日志管理：
1、采用ELK/EFK应用架构，核心组件由Elasticsearch、Logstash/Filebeat、Kibana三部分组成。支持应用和服务视角的日志查看、搜索、告警。
2、支持采集容器标准输出和容器内部日志文件。
3、支持多集群日志统一采集及管理。
容器日志持久化保存采取方案：
1、挂载目录 bind， 创建一个目录，将目录挂载到 容器中产生日志的目录。
2、使用数据卷 volume， 创建数据卷，创建容器时绑定数据卷。
3、计算容器 rootfs 挂载点，使用挂载宿主机目录的方式采集日志对应用会有一定的侵入性，因为它要求容器启动的时候包含挂载命令。
4、在代码层中实现直接将日志写入redis。

13、容器云平台的所在的宿主机采用虚拟机还是物理机？

采用物理机和虚拟机各有什么优点和缺点

回复1：onionpiece 云平台工程师 , 建信金科
如果条件允许，可能物理机更好。

虚拟机方案突出的特点是隔离性更好，资源管理更灵活，以及抽象。在你不打算引入kata或者kubevirt的情况下，使用虚机来当做容器平台的node节点，无疑可以提供更好的隔离性选择，因为同一台物理机可以切分成多个虚机node，而不同的node可以通过打上不同维度的label；通过label，node可以界定为指定业务部门、指定项目组的专有node，从而提升了隔离性。至于资源管理的灵活性，很好理解，略过不提。再说抽象，想象这样一个场景，容器需要和node上的资源进行绑定，如果是物理机，那么底层故障会直接导致容器故障，而至于虚拟机，由于可以迁移，从而隔绝了物理环境故障对容器的迫害。

同时，我们可以看到由于虚拟机方案夹带了一层虚拟化，很多事情就被迫多了一道手续。像CMDB，监控，告警这些朴素工作量的事情还好说。比较麻烦的是故障排查，还得多看一层 。例如当业务部门保障应用系统遇到网络抖动、延迟时，需要额外排查虚拟化网络方案是否存在问题，排查故障时是否发生了虚机迁移等。此外，虚拟机也是要占资源的，也会吃系统开销，所以无论是资源利用率，还是性能都会打折扣。最后，就容器场景而言，虚机迁移会让人感觉比较迷惑，毕竟容器自己就会“迁移”。

当然，还是应该结合实际情况，具体问题具体分析。

例如在企业已经有了IaaS的情况下，如果容器平台投产到IaaS的虚机上，好处是很多问题可以依托IaaS提供的方案进行解决，例如存储可以直接用IaaS的块和文件存储，打通容器和虚机的网络也会比较容易（毕竟由于存量改造的问题，应用部门不可能一步到位的容器化），容器可以使用IaaS的云负载均衡来对外暴露，容器和非云化系统的打通也可以借鉴虚机方案等等。当然前提是IT部门是否有足够的人力和技术储备来cover交叉环境下的各种问题。

而如果投产到物理机，就网络方面，在使用underlay网络模式的CNI的基础上，如果实现了固定IP，那么将更好的应对企业在容器化改造过渡阶段所遇到的阵痛，因为容器可以直接和底层传统网络打通（当然对于网络管理部门来说，由此带来的IP使用的巨大增量可能是个挑战）；同时在组织内部，传统的VLAN、负载均衡、防火墙等也可以应用到容器；就存储层面，容器可以直接使用高性能的本地SSD或者后端SAN存储。但缺点也很明显，由于不具有虚机带来的资源切割，一个节点的CRI故障将导致更多的容器同时遇到问题；对此，平台方需要考虑如何设计集群中节点资源的冗余量以应对疏散的容器；而另一方面，对于一些企业，使用物理机就意味着资源集中，节点数变少，这就意味着对强制反亲和的容器而言可选择的节点变少。

回复2：nameless 技术总监
结合自身实际情况，一般从几个因素考虑：
1、是否已具备IaaS环境，如果没有IaaS环境，可以直接上物理机，跳过IaaS可以减少IaaS平台采购、运维的成本；
2、如果已有IaaS环境，考虑自身业务对资源的需求，IaaS网络、存储等是否对容器云平台有影响，业务对资源的需求，业务是否弹性扩缩容，业务对网络、存储的要求等等；

回复3：feng5371 云计算研发工程师 , 中国农业银行
物理机的考虑：资源利用率进一步提升，消除虚拟化带来的不稳定因素，一般建议用于对IO性能要求高的场景；
虚拟机的考虑：借助虚拟化资源灵活高效的管理优势，可更好地划分资源用途，在一定程度上屏蔽硬件故障带来的影响。
建议容器云平台的管理节点使用虚拟机+ssd存储，计算节点采用虚拟机和物理机结合，分场景使用，如默认使用虚拟机，如运行MySQL等高IO性能要求的服务时，或者需要GPU计算能力时，采用物理机。

14、OpenShift上应用级灾备与双活的实现？

如何在多个 OCP集群和多个DC中保证有状态应用的高可用
无状态和有状态应用程序的高级灾难恢复策略。

回复：魏新宇 副首席解决方案架构师 , 红帽企业级开源解决方案中心
有状态应用的高可用，目前业内主流的做法是通过Operator实现。MySQL MongoDB TiDB AMQ等等现在都采取Operator方式在容器云部署。真正意义上的多OCP双活需要打通OCP集群之间Pod通讯的隧道， Submariner就是做这件事的。 Submariner在2021年下半年会在OCP上正式GA。
https://mp.weixin.qq.com/s?__biz=MzAwMDc2NjQ4Nw==&;amp;mid=2663498290&idx=1&sn=1cd8b09d8ad1551be682b07079e61db1&chksm=81d6854ab6a10c5cc69f70545fb14e398b68578378ddb84c90c640e1c6c5d70ec4c70afc22ec&token=295652040&lang=zh_CN#rd

15、微服务部署到Openshift之后注册中心是否还有必要存在？

在传统的微服务中注册中心起到了服务发现和负载均衡的作用，在使用Openshift或者K8S相关技术之后，服务发现和负载均衡都由平台解决了，那注册中心在后续的发展当中是不是要取消掉，如果取消掉与网关之间的联动该如何实现？

回复1：魏新宇 副首席解决方案架构师 , 红帽企业级开源解决方案中心
如果微服务使用 Istio ，就没有必要。但如果是 SpringCloud ，还是需要独立的注册中心。

回复2：nameless 技术总监 , 某云计算厂商
微服务的注册中心还是需要的，k8s很好的解决了微服务业务部署的问题，但对业务本身注册和管理还需要业务本身来做。

16、银行核心系统的跨地域、跨可用区、跨集群的容器化部署和高可用架构最佳实践？

银行核心系统的跨地域、跨可用区、跨集群的容器化部署和高可用架构最佳实践？

回复：魏新宇 副首席解决方案架构师 , 红帽企业级开源解决方案中心
OpenShift 的服务注册发现用的是 ectd 。这是一个强一致性的 K-V 数据库。 Etcd 心跳默认是 200ms 。所以，如果跨地域、跨可用区的网络不能满足网络延迟小于 200ms ，那每个环境部署单独的容器云，通过类似 ArgoCD 的 gitops 多集群的应用部署。不建议将 OpenShift 集群跨网络区部署。

17、容器云技术方案选型？目前市场上红帽Openshift、Rancher、灵雀云等等厂商优劣势对比分析

容器云技术方案选型？目前市场上红帽Openshift、Rancher、灵雀云等等厂商优劣势对比分析：从运维角度、售后、成本等方面进行对比对比。

回复：sf7071 软件开发工程师 , 某大型银行
红帽Openshift的优势在于稳定、综合实力强、售后有保障，具备操作系统、Web服务器中间件等配套服务能力。劣势在于成本、客户化和定制化方面；
Rancher和灵雀云优势在于客户化程度高，可提供定制化服务，成本适中。

18、如何保障容器云平台业务数据的安全性？

如何保障容器云平台业务数据的安全性，确保数据不会损坏，包括业务所需的数据库、容器云平台的PV/PVC、镜像、ETCD等数据备份容灾；

回复1：sf7071 软件开发工程师 , 某大型银行
pv/pvc并非落地数据的存储设备，而是对存储设备的关联和引用，需要备份存储设备上数据。而pv/pvc本身直接备份yaml文件即可，建议将应用的yaml文件直接以源代码方式管理，随时可用。对于数据库，本身与容器云平台无直接关系，仍采用传统的数据库灾备方案。对于ETCD，里面存储了集群信息，包括了已发布的应用信息，非常重要，需要重点备份。

回复2：nameless 技术总监 , 某云计算厂商
一般容器云数据分为管理平台数据和业务数据(ETCD、PV/PVC等)：
1、管理平台数据：有些容器云产品是自研的，有平台数据，有平台相关的DB数据等，一般是按传统方式备份和容灾；也有部分容器云平台采用CRD方式，没有专门的数据库，管理数据也放ETCD上，直接备份整个k8s集群就可以；
2、业务数据：一般是k8s的数据，建议直接备份整个k8s集群，包括etcd、PV/PVC等；