城商行生产环境的容器云平台同城及异地容灾架构设计难点解读
Posted twt企业IT社区
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了城商行生产环境的容器云平台同城及异地容灾架构设计难点解读相关的知识，希望对你有一定的参考价值。
社区近期组织了“城商行生产环境容器云平台同城及异地容灾架构设计”主题探讨，现将活动中的问答和分享汇总如下，供大家参考。
1、开发、测试、生产环境如何规划容器云平台？是分别在搭建容器云集群还是混合在一个或二个容器云集群更好？
@onionpiece 建信金科 云平台工程师：
看自身条件，包括资金、人员等。
生产环境最好是单独的集群，毕竟稳定性和可用性压倒一起。当然也有例外，例如不打算投入太多，只在容器平台上跑一些有容忍的内部系统的时候，可以考虑混部。
开发和测试环境通常可以混部。但如果考虑做一些适配性自研，涉及到对容器云平台自身的改造时，就需要注意到这里所说的开发环境在容器应用开发的基础上多了一类用途。这类开发工作会导致容器平台的不可用，有条件的话，针对这类进行单独部署。
总的来说，只要条件允许，单独部署更好。对于运维同学来说，增加了工作量，但是没有明显的工作复杂度增减；而如果混部的话，可能会直接导致复杂度的增加。但单独部署的时候，就需要设计流程，如何将镜像和配置等在多个集群或平台间流转。而混部的话，可以考虑用同一套镜像仓库和配置仓库，但同时也意味着要做好明确的规范和权限管理。
混部的时候，如果条件尚可，那么可以将节点打上不同分区label，将节点划分出不同的组，用于开发的、用于测试的、用于生产的，等等。这样做的好处是故障区的切分，但同时你需要为生产组多分配一些节点，以满足反亲和的目的来提升可用性。
关于镜像和配置的流转设计，可以认为这和CI/CD相关，当然也要结合企业自身情况。在没有CI/CD的情况下，以镜像为例，需要由项目开发组自己负责镜像构建，当需要提测的时候，为镜像打上约定好的tag，这时利用harbor的replication机制，针对提测tag将镜像同步到测试环境的镜像仓库。测试人员针对提测镜像进行测试后，为通过的镜像打上可以投产的tag，再有harbor将这类镜像流转到生产的仓库。
@魏新宇 红帽 副首席架构师：
主要是看网络隔离。如果不要求物理隔离，就通过namespace隔离。如果有物理隔离的要求，就部署多套集群。通过镜像仓库打通。
（直接点击问题即可↑↑↑）
3、容器云平台的容灾机制与传统数据中心相比，优势有哪些？不足有哪些？针对具体的业务场景是否有具体的方案？
@魏新宇 红帽 副首席架构师：
由于容器云本身主要承载无状态应用，因此容灾主要是持久化存储的灾备，可以借助底层存储实现。容器云本身的备份，主要是k8s对象，deployment svc route 之类的，可以通过脚本把yaml文件备份出来。etcd提供备份脚本，可以导出数据文件。
4、微服务与容器云的边界划分是什么？
@魏新宇 红帽 副首席架构师：
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数量较多时，网卡性能会下降。
以上两种实现方式，各有优劣势。可参考文章《SpringCloud与K8S的边界考量》
@annoymous:
容器和微服务没有所谓边界问题，两种技术思想和解决业务场景各有侧重。
微服务作为一种当下流行的技术架构，主要解决原有架构中服务比较重、依赖性比较强，所需要承载服务的资源要求比较高，无法快速响应业务变化等问题。
容器解决底层物理资源、虚拟资源利用率不足、容灾备份跨集群保障等方面问题。
当微服务架构越来越成熟后，容器作为微服务载体能够提升微服务架构的稳定、高可用、数据安全以及快速响应变化等诉求。所以微服务和容器即可相辅相成又可独立使用。
@xushuhao11 eccom 网络工程师：
微服务是重构业务的方法吧，而容器云是承载微服务的一种更好的方法。同样都是为了更好的为业务服务的手段。
5、使用开源容器框架来搭建云平台，如何实现异构云服务的快速切换？
@onionpiece 建信金科 云平台工程师：
最朴素的方案就是切流量，流量整体从主中心切到备中心。
既然应用系统已经经过容器化改造，或者就是云原生应用，那么无论是运行在商业云平台还是开源k8s上，本质上是没有区别的。因为大家基本上都是基于k8s做的，可能会有影响的地方是，如果商业云平台自研了控制器，部署单元，服务管理功能等，那么在使用的时候要小心，需要考虑如果让应用在原生的k8s环境上同等的拉起。
相比之下，数据的同步可能要多考虑，这包括两方面。其一是应用编排组织发布的元数据(例如yaml文件，configMap等)，需要确保在主发生的变更能够同步到备；其二是应用数据，建议是通过应用容器通过挂卷的方式，把数据放到后端存储上，然后后端存储再考虑怎样做数据同步。
@魏新宇 红帽 副首席架构师：
切换指的是访问流量切换？如果是流量切换，通常是通过全局负载均衡器实现。
如果异构容器云，可以借助于Ansible工具，书写playbook，进行自动化配置。避免大量手工操作。
6、容器云平台数据的灾备方案？容器云平台中存储数据文件如何考虑同步？
@魏新宇 红帽 副首席架构师：
容器云的持久化数据通过PVC/PV实现。而PV基于外部存储实现，如Ceph。数据同步要使用存储实现，不要用容器云的通讯网络，否则带宽消耗太大。
@onionpiece 建信金科 云平台工程师：
如果说的是一个K8S集群内Pod间的同步，那么可以通过数据卷的挂载来完成，相关数据放在后端的文件存储中，再由Pod按需挂载。并且卷在挂载时可以分配只读、读写的权限。
至于跨集群下的数据同步，只要是通过卷把数据挂出去，做到应用和数据分离的话，那么这就会变成了一个单纯的数据同步问题，与是否是容器化没有关系。
7、容器云平台承载的缓存数据库的容灾方案？跨中心集群还是单中心集群，数据同步有何优劣？
@魏新宇 红帽 副首席架构师：
容器云上运行有状态应用，比如redis，比较成熟的做法是使用Operator。通过Operator做缓存/DB集群在K8S上的管理。这种模式的缓存群通常是不跨K8S集群的，也不必跨，因为持久数据是在DB上的。
@annoymous:
容器存储类型分类三大类：临时存储、半持久化存储、持久化存储。
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
支持分布式存储适合容器场景，选择适合的存储方式
8、S2I与传统意义上的CI/CD GIT OPS的区别？请详细区分下S2I的持续集成与传统集成，云平台基础上的Git Ops的一些区别及优势。
@魏新宇 红帽 副首席架构师：
CI构建
Jenkins集群在CI流程中调用Maven执行构建，Maven通过插件按指定的Dockerfile生成应用的容器镜像。
常规CI方案
每个开发团队均需要编写Dockerfile
微服务多语言多版本混合构建时无隔离
构建资源池不可动态扩展
资源利用率较低
S2I
OpenShift在隔离的容器环境中进行应用的构建编译并生成应用的容器镜像。
基于容器集群的CI方案
开发团队通过容器镜像精确定义构建环境
基于容器的构建环境，提供更好的隔离性
满足多语言多版本微服务混合构建的场景
构建资源池可动态扩展，更灵活
构建与应用运行共享资源池，介绍运维工作量
资源按需投入及回收，利用率较高
GitOps 的核心思想是 CI/CD 从 git 发起，因此对开发人员更友好。但 GitOps 的实现，例如通过 ArgoCD ， ArgoCD 在 CICD 过程中需要借助 Jenkins 和 S2I 这样的工具来实现。
@onionpiece 建信金科 云平台工程师：
大魏老师讲的很全面：）
S2I设计理念很好，如果企业没有一个专门负责CI/CD的团队，那么用S2I就好。但如果有的话呢，要让这班兄弟转岗么。
S2I在强调应用系统研发人员的自给自足之外，还带来了就地处理的能力，即在当前集群可以直接制作新镜像，直接就地部署，对于研发人员来说，这是一个强大的正反馈循环。但这仅限于开发测试环境，镜像以及配置等制品的产生并没有嵌入到整条标准流程链中，还是得需要CI/CD的标准链来规范推动镜像和配置等制品在不同阶段的审核和流转。
jenkins也有plugin支持对接容器平台，将编译和打包环境通过Pod放到容器平台上去做，所以资源和扩展性可能不是什么主要问题。
9、Openshift在私有环境部署怎样实现TCP服务快速发布？
【问题描述】我们在公有云上可以通过提供的负载均衡设备，快速的将tcp的端口暴露出Openshift集群，让外部可以访问，但是在私有部署的方式，只有Http的方式可以通过主机头的方式快速发布，请问在私有云里面有没有相关设备可以配合Openshift，或者Openshift本身能不能提供此类功能？
@魏新宇 红帽 副首席架构师：
OpenShift 发布 TCP 应用没有任何问题。关键的问题在 Ingress 。OpenShift 的 Ingress 默认支持 7 层。如果 TCP 应用：1. 使用 NodePort 2. 使用开源 MentalLB 的方案做四层引入。
@onionpiece 建信金科 云平台工程师：
可以这样设计：
· svc通过nodePort方式暴露；- 将masters节点挂载负载均衡后面暴露，可以是硬件负载或者自己搭，主要得预设一个区间范围的端口映射，例如openshift集群内nodePort的范围是2w-4w的话，那么负载均衡上就要将相应的端口转发到masters上对应的2w-4w端口；
· 通过网络规划，使用DNS、VIP等手段，将入访流量引流到负载上；
前两步不必说，第三步如果也以静态的方式去做，那么整体下来也可以达到所谓的快速。
10、容器云化后给应用扩展带来了便利，相比传统有些顾虑：1负载方案怎选？2有状态的应用数据容灾怎做？
【问题描述】1，大规模app扩展 软负载与硬负载如何选取？负载能力，维护性，管理性？2，容器支持有状态的应用数据持久化，当规模较大时，同城容灾数据如何持续保护保护又该如何做？3，kubernets编排工具 ，针对中小银行如何选取？
@onionpiece 建信金科 云平台工程师：
以下内容是在使用kubernetes这一基础上展开：
1.如果app的调用方或者说client也都来自容器集群内部，那么选择软负载，k8s的svc已经支持IPVS了，性能值得一测，而维护性和管理性将不是问题。当然也可以选择其他的开源方案。至于硬件负载，使用场景主要有两类，一类是要为来自容器集群外的client提供负载，另一类是用作整个平台北向的安全访问入口。后者很好理解，这里说一下前者。当需要为来自集群外的client提供负载时，需要考虑#1 硬件负载如何与后端app Pod在网络层面打通，#2 对于app Pod的扩缩容，如何即使更新负载均衡的配置。
2. 可以考虑通过挂卷的方式，将有状态应用的数据沉降到后端存储去。按照这个思路去设计，那这就不是容器的问题了。当然你可能会考虑不只是应用的数据，还包括集群的元数据，包括组织空间，部署信息，配置信息等，可以考虑社区的velero，或者其他方案，这块并不难。3. 这个真的是结合自身需求，仁者见仁智者见智的问题。
@sf7071 某大型银行 软件开发工程师：
1，大规模app使用硬件负载+软件负载结合，硬件负载作为入口保障安全稳定，软件负载可容器化部署，通过横向扩展满足性能要求。
2，不建议将数据直接落地到容器云平台上，应平台与数据分离，采用传统的存储方案或者分布式存储方案；
3，kubernetes已是当前的主流和事实标准，大多数的选择。
11、容器的应用日志如何持久化保存？
@onionpiece 建信金科 云平台工程师：
如果有专门的日志系统，那么通过sidecar或者daemonset pod来吐到日志系统将是显而易见的方案。
如果容器平台提供了ELK/EFK，那么应用方和平台方经过协商，应用日志吐到指定路径，再由平台方采集也是比价好的方案。可能的缺点会出在平台方提供的日志查询能力能否满足应用方的需求。但如果只是日志保存，那么该方案足矣。
最后作为下策可以选择挂卷来存储，对于deployment来说考虑文件存储，对于statefulset额外可以考虑块存储。
@sf7071 某大型银行 软件开发工程师：
将日志输出到统一的日志中心服务里，或者挂载存储设备将日志保留下来。
@annoymous:
容器应用日志管理：
1、采用ELK/EFK应用架构，核心组件由Elasticsearch、Logstash/Filebeat、Kibana三部分组成。支持应用和服务视角的日志查看、搜索、告警。
2、支持采集容器标准输出和容器内部日志文件。
3、支持多集群日志统一采集及管理。
容器日志持久化保存采取方案：
1、挂载目录 bind， 创建一个目录，将目录挂载到 容器中产生日志的目录。
2、使用数据卷 volume， 创建数据卷，创建容器时绑定数据卷。
3、计算容器 rootfs 挂载点，使用挂载宿主机目录的方式采集日志对应用会有一定的侵入性，因为它要求容器启动的时候包含挂载命令。
4、在代码层中实现直接将日志写入redis。
12、容器云平台的所在的宿主机采用虚拟机还是物理机？采用物理机和虚拟机各有什么优点和缺点？
@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故障将导致更多的容器同时遇到问题；对此，平台方需要考虑如何设计集群中节点资源的冗余量以应对疏散的容器；而另一方面，对于一些企业，使用物理机就意味着资源集中，节点数变少，这就意味着对强制反亲和的容器而言可选择的节点变少。
@nameless 技术总监 :
结合自身实际情况，一般从几个因素考虑：
1、是否已具备IaaS环境，如果没有IaaS环境，可以直接上物理机，跳过IaaS可以减少IaaS平台采购、运维的成本；
2、如果已有IaaS环境，考虑自身业务对资源的需求，IaaS网络、存储等是否对容器云平台有影响，业务对资源的需求，业务是否弹性扩缩容，业务对网络、存储的要求等等；
@feng5371 中国农业银行 云计算研发工程师：
物理机的考虑：资源利用率进一步提升，消除虚拟化带来的不稳定因素，一般建议用于对IO性能要求高的场景；
虚拟机的考虑：借助虚拟化资源灵活高效的管理优势，可更好地划分资源用途，在一定程度上屏蔽硬件故障带来的影响。
建议容器云平台的管理节点使用虚拟机+ssd存储，计算节点采用虚拟机和物理机结合，分场景使用，如默认使用虚拟机，如运行mysql等高IO性能要求的服务时，或者需要GPU计算能力时，采用物理机。
13、OpenShift上应用级灾备与双活的实现？
【问题描述】如何在多个 OCP集群和多个DC中保证有状态应用的高可用？无状态和有状态应用程序的高级灾难恢复策略。
@魏新宇 红帽 副首席架构师：
有状态应用的高可用，目前业内主流的做法是通过Operator实现。MySQL MongoDB TiDB AMQ等等现在都采取Operator方式在容器云部署。真正意义上的多OCP双活需要打通OCP集群之间Pod通讯的隧道， Submariner就是做这件事的。Submariner在2021年下半年会在OCP上正式GA。可参考我的文章《论跨Kubernetes集群Pod通信的必要性和实现方式》
14、微服务部署到Openshift之后注册中心是否还有必要存在？
【问题描述】在传统的微服务中注册中心起到了服务发现和负载均衡的作用，在使用Openshift或者K8S相关技术之后，服务发现和负载均衡都由平台解决了，那注册中心在后续的发展当中是不是要取消掉，如果取消掉与网关之间的联动该如何实现？
@魏新宇 红帽 副首席架构师：
如果微服务使用 Istio ，就没有必要。但如果是 SpringCloud ，还是需要独立的注册中心。
@nameless 技术总监 :
微服务的注册中心还是需要的，k8s很好的解决了微服务业务部署的问题，但对业务本身注册和管理还需要业务本身来做。
15、银行核心系统的跨地域、跨可用区、跨集群的容器化部署和高可用架构最佳实践？
@魏新宇 红帽 副首席架构师：
OpenShift 的服务注册发现用的是 ectd 。这是一个强一致性的 K-V 数据库。Etcd 心跳默认是 200ms 。所以，如果跨地域、跨可用区的网络不能满足网络延迟小于 200ms ，那每个环境部署单独的容器云，通过类似 ArgoCD 的 gitops 多集群的应用部署。不建议将 OpenShift 集群跨网络区部署。
16、容器云技术方案选型？目前市场上红帽Openshift、Rancher、灵雀云等等厂商优劣势对比分析
@sf7071 某大型银行 软件开发工程师：
红帽Openshift的优势在于稳定、综合实力强、售后有保障，具备操作系统、Web服务器中间件等配套服务能力。劣势在于成本、客户化和定制化方面；
Rancher和灵雀云优势在于客户化程度高，可提供定制化服务，成本适中。
17、如何保障容器云平台业务数据的安全性？
【问题描述】如何保障容器云平台业务数据的安全性，确保数据不会损坏，包括业务所需的数据库、容器云平台的PV/PVC、镜像、ETCD等数据备份容灾。
@sf7071 某大型银行 软件开发工程师：
pv/pvc并非落地数据的存储设备，而是对存储设备的关联和引用，需要备份存储设备上数据。而pv/pvc本身直接备份yaml文件即可，建议将应用的yaml文件直接以源代码方式管理，随时可用。对于数据库，本身与容器云平台无直接关系，仍采用传统的数据库灾备方案。对于ETCD，里面存储了集群信息，包括了已发布的应用信息，非常重要，需要重点备份。
@nameless 某云计算厂商 技术总监：
一般容器云数据分为管理平台数据和业务数据(ETCD、PV/PVC等)：
1、管理平台数据：有些容器云产品是自研的，有平台数据，有平台相关的DB数据等，一般是按传统方式备份和容灾；也有部分容器云平台采用CRD方式，没有专门的数据库，管理数据也放ETCD上，直接备份整个k8s集群就可以；
2、业务数据：一般是k8s的数据，建议直接备份整个k8s集群，包括etcd、PV/PVC等；
原题：城商行生产环境容器云平台同城及异地容灾架构设计探讨总结 有任何问题，欢迎点击文末阅读原文到社区原文下留言探讨 觉得本文有用，请转发、点赞或点击在看，让更多同行看到
资料/文章推荐：
https://www.talkwithtrend.com/Topic/98447
下载 twt 社区客户端 APP
或到应用商店搜索“twt”
以上是关于城商行生产环境的容器云平台同城及异地容灾架构设计难点解读的主要内容，如果未能解决你的问题，请参考以下文章