解读证券行业生产环境容器云平台规划架构设计四大难点

Posted 2021-04-10 twt企业IT社区

随着证券行业的发展，支撑业务的IT系统也在逐渐壮大。为了快速响应业务需求，敏捷交付成为了IT系统建设新的要求。容器技术作为敏捷交付的最佳拍档，券商已经陆续开始在生产环境部署规划容器云平台，支撑如融资融券、行情等生产应用。为了帮助广大券商同行了解以及更好地面对容器云平台架构规划设计阶段的挑战，社区组织了交流活动，邀请证券行业专家及相关厂商专家进行探讨。以下是活动中交流问题的总结梳理，包括容器云容器云与基础架构、与devops、与微服、与监控等相关问题，供大家参考。本文由社区专家 wykkx 整理。

一、容器云基础架构相关

【 Q1 】容器网络的架构与原有经典的三层架构区别较大，如何设计容器的网络架构使之能在保证网络的高性能、高可靠性、易维护的前提下还能满足监控、合规、风控、审计的要求？

【 A1】 acbogeh 富国基金 系统工程师：

macvlan 优点是固定 IP ，缺点是规模大的话维护路由表是个工作量。

Calico 性能比 MacVLAN 要差一点，但是 Calico 使用 BGP 可以方便的对接物理网络，有丰富的 Network Policy ，能够满足大部分要求。

【 A2 】 wanshaoyuanit Rancher 技术咨询顾问：

面对金融监控要求容器云网络一般都会要求：

1 、 POD 拥有跟数据中心同二层网络 ip 。

因此这类需求目前都需要一些 underlay 的网络插件能解决，如 calico-bgp 和 macvlan ，但如果使用 calico-bgp 的话需要将 bgp 路由同步到数据中心的路由器上，不然防火墙无法对 POD 的 IP 开白名单，对于大部分金融客户来说基本上不太可能直接使用 calico-bgp 这种方式，剩下只有使用 macvlan 了，但直接所有 POD 使用 macvlan 会降低 POD 的灵活性和，并且 pod 的密度比 vm 的密度大得多，如果前期没有规划好，同一个 vlan 内 POD 数量过多，容易造成广播风暴。为此 Rancher 针对此类需求专门开发了双网卡的 CNI 网络插件 canal+macvlan。

【 Q2 】容器云平台承载生产应用以后，必然要面对双机房高可用部署这个问题，应该注意哪些问题？

【 A1 】  wanshaoyuanit Rancher 技术咨询顾问：

双机房部署容器云平台需要考虑机房之前的网络质量问题，主要是需要考虑 etcd 组件网络性能， etcd 组件对网络要求如下：集群 leader 选举超时应至少为 100 毫秒，集群成员间连接最大超时时间为 50 秒上限。

【 Q3】容器云平台落地过程中高可用性、备份恢复、监控告警、应用对外暴露如何实现？

容器云对大多数工程师还是一个比较新的技术，如何实现容器云的高可用、备份恢复、监控告警、应用对外暴露是运维工程师日常运营过程中经常遇到的问题。

【 A1 】  wanshaoyuanit Rancher 技术咨询顾问：

高可用：

对于 Kubernetes 来说主要关注 master 节点上几个核心组件的高可用如 api-server 、 Controller-manager 、 etcd 、 kube-scheduler

1 、 Etcd 通过本身的集群机制，组成 etcd 集群保证集群高可用；

2 、 controller-manager 、 scheduler 本身有 leader 选举机制保证高可用；

3 、 api-server 为组件访问 etcd 和外部访问集群的统一入口，本身为无状态的，所以通常情况下 HA 的做法是通过外部 LB 做为统一入口进行 HA

ps: 通过 Rancher 建自定义集群只需要选择 3 个 master 节点角色会自动进行高可用配置

备份恢复：

因为在 Kubernetes 集群中集群内定义的所有资源对象都是存储在 etcd 中，所以针对集群的备份和恢复本质上是对 etcd 的备份。原生的 Kubernetes 可以直接通过 etcdctl 进行备份和恢复，通过 rancher 管理的集群 UI 上有手动备份恢复和自动备份功能，帮助用户定期自动备份集群，保证集群可靠性。

监控告警：

容器云平台监控和容器应用监控主要使用 Prometheus ，告警可以通过 Altermanager webhook 方式对接自己外部的统一告警系统， rancher 已经内置了 Prometheus 监控包含多个层面监控包括：集群层面资源使用监控和组件性能监控、节点资源监控、容器应用资源监控。对于一些需要针对业务的监控可以使用自定义监控方式实现对业务指标监控。

应用对外暴露：

可以通过 NodePort 和 Ingress 若有 F5 硬件负载均衡器可以直接通过容器云平台与 F5 集成实现 F5 直接转发流量请求到 POD 中，这几种方式的对比优缺点如下：

通过 NodePort 进行暴露

1 、通过 Nodeport 四层暴露方式，需要在内网开防火墙

2 、端口随机且无法进行统一权限管理

3 、 iptables 模式规则过多，容易造成转发性能瓶颈

4 、四层转发，配置模式单一

通过 Ingress 进行暴露

1 、 L7 负载均衡器通过域名或路径区别转发到服务，统一转发到 Ingress-controller 转发到后端服务中

2 、防火墙只需要开通节点 80 和 443 端口

3 、需要配置 DNS 服务器进行域名解析

4 、可配置非常丰富规则

通过 F5 与集群对接实现应用对外暴露，通过 Kubernetes 策略自动生成 F5 规则

方式一：NodePort 模式

转发路径：

Internet --> F5 --> Worker Nodes/Ports --> Pod IP

此种模式有如下缺点：

服务必须使用 NodePort 方式暴露

某些高级应用交付功能不可用，例如 L7 的会话保持

额外的网络延迟

BIG-IP 控制器对 Pod 的健康程度等可见有限

通过 F5 与集群对接实现应用对外暴露

方式二：cluster 模式

转发路径：

Internet --> F5 --> Pod IP

这是一种更优雅的方式，优点如下：

可以使用任何类型的 Kubernetes service 。

完整的应用交付能力，包括 L7 持久性。

BIG-IP 控制器可以完全了解 Pod 的运行状况。

【 Q4 】容器云平台的弹性伸缩策略有哪些？

弹性伸缩，目前有哪些策略？每项策略的原理是什么？什么场景建议弹性伸缩？什么场景建议提前扩容？弹性扩容是否对数据库产生压力，该如何避免？两地三中心资源调度，该如何设计弹性伸缩策略？

【 A1 】 wanshaoyuanit Rancher 技术咨询顾问：

在容器云平台中实现弹性伸缩主要通过一个叫 HPA 的资源对象实现 实现策略主要通过 cpu 和内存的阀值检测扩缩容，但也可以通过自定义业务指标，如通过 QPS 设定的阈值进行弹性伸缩。

通过 cpu 和内存值的扩容实现原理是：

1 、监控指标的获取

早期 kubernetes 版本是使用 hepster ，在 1.10 后面版本更推荐使用 metric-server

2 、 hepster 简单来说是 api-server 获取节点信息，然后通过 kubelet 获取监控信息，因为 kubelet 内置了 cadvisor 。

metric-server ，简单来说是通过 metric-api 来获取节点信息和监控信息。https://github.com/kubernetes-incubator/metrics-server

通过自定义监控指标扩容实现原理是：

实现 prometheus 实现自定义 metric 来更加灵活的监控指标实现弹性伸缩。

1 、 pod 内置一个 metrics 或者挂一个 sidecar 当作 exporter 对外暴露。

2 、 Prometheus 收集对应的监控指标。

3 、 Prometheus-adapter 定期从 prometheus 收集指标对抓取的监控指标进行过滤和晒算，通过 custom-metrics-apiserver 将指标对外暴露。

4 、 HPA 控制器从 custom-metrics-apiserver 获取数据。

什么场景建议弹性伸缩？

建议一些无状态的，需要面临访问峰值，需要提前准备服务器，预防访问量增长造成的服务器压力过大业务配置弹性伸缩，如经常做秒杀活动的一些业务。

弹性扩容是否对数据库产生压力，该如何避免？

对于弹性扩容的应用多个实例副本连接后端数据库必然会增加后端数据库的压力，建议提前规划好数据库的资源和连接数，避免因为连接过多导致数据库性能问题。

两地三中心资源调度，该如何设计弹性伸缩策略？

目前容器云平台的弹性伸缩实现的范围只在本集群范围内。

【 Q5 】如何保证外购容器化业务系统完美落地到容器云平台？

【 A1 】 wykkx 某基金公司 系统架构师：

说实话，这个执行落地比较难。外购的业务系统在做容器化输出的时候，都会考虑自包含，同时各个商用的容器云平台也会做产品级的调整，因此要完美的落地到每个公司自己的容器云平台，最好在 poc 测试阶段就进行测试验证，并且进行全面验证。

【 A2 】wanshaoyuanit Rancher 技术咨询顾问：

如果外购的业务系统已经是容器化的那其实工作量还是小很多的，因为现在容器化编排工具 Kubernetes 统一天下了，所以我理解只要对应的容器镜像和部署 yaml 文件或 chart 包就可以部署到容器云平台上了，但不排除有些容器化比较早的业务系统还是用的 docker-compose 的部署方式，那就需要做一些转化了，将 docker-compose 文件转换成 Kubernetes 的 yaml 文件。

举个简单例子：

我们有个客户想把一套多年前买的云管系统上 Rancher 容器云平台，但因为是几年前的，所以当年的部署方式的是使用 docker-compose 方式部署的，所以客户找到厂商和我们一起，但由于厂商方并不懂 k8s ，所以 Rancher 先把一些 k8s 的一些基本概念和 k8s 与 docker-compose 区别进行了讲解，后面由外购业务系统厂商将对应的 docker-compose 文件进行转换成 yaml 然后成功部署到容器云平台中。

二、容器云与 devops

【 Q1 】容器云平台如何与 DevOps 平台深度融合产生价值？

【 A1 】 jiangjf2DevOps 安信证券 工程师：

容器化，微服务和 DevOps 是云原生架构的三个特征，三者的发展也是互相促进的过程。我们最开始尝试 DevOps 实践的试点项目是主要基于虚拟机来部署的，在环境的一致性、标准化，环境的准备时间，统一升级等方面遇到了很大的挑战。这些问题对于应用容器化提出了诉求。在容器云平台的建设推广过程中，也对通过 DevOps 工具平台来承载规范、流程，提高自动化，简化使用，降低门槛，更好的支持应用上云提出了诉求。因此从平台建设的角度来说，两个平台之间存在很多对彼此的需求。

在我们 DevOps 实践过程中，容器云平台首先为 CICD 工具的搭建提供了基础资源，通过容器云平台的监控和故障恢复机制来保证工具平台的可用性，这对于初期采用一些开源工具社区版本的方案来说是很好的支撑。其次容器云平台为流水线的建设提供了动态创建和回收的标准化的构建资源池，并为其在共享存储、资源隔离、监控等方面的需求提供方案。然后还为应用提供了快速准备开发、测试环境的能力，支持应用环境的标准化和一致性。

在应用迁移到容器云平台的过程中，流水线也提供了从特性开发到集成，构建、部署、测试整个过程的支持，不断完善着应用交付过程的流程和规范；同时迁移过程中各种资源的申请和工具平台的接入也向 DevOps 平台提出了提供自助服务简化工具平台的接入和资源申请的流程，减少人工审批环节，等待时间等诉求。

两个平台的建设是相对独立的过程，可能会由不同团队来建设，需要强调以应用视角来进行统一规划和考虑，避免在应用上云的过程中，需要学习各种工具平台，重复的接入和沟通。在建设初期这可能是一个比较容易被忽视的问题。容器云平台与 DevOps 平台的融合产生价值，需要以应用实践的效果来检验，最终体现在项目团队在质量、效率、成本、安全的改进上。

【 A2 】 gxcornflakes 某金融单位 信息技术经理：

DevOps 在于轻量级流程，精髓在于自动化。

两者结合，通过自动化流程实现持续集成 CI 、持续交付 CD 、持续部署 CD ，让开发更注重于业务，提高效率，让运维通过编写脚本等方式实现自动化摆脱繁复的运维工作，提高工作效率，更注重于容量、性能、监控、排障等后台运维工作以及运维平台的思考和建设。

简言之：通过建设规范化流程，提升自动化能力，实现降本增效。

【 A3 】 wykkx 某基金公司 系统架构师：

容器平台由于其天然具备的标准化基础，天然具备做 devops 的基础，这也是为什么很多公司在做 devops 的起步时会选择使用容器平台的原因。其次，从广义的 devops 来讲，容器云平台的租户模式和标准中间件交付能力，都是 devops 落地过程中起到积极作用的。因此，窃以为容器云平台和 devops 平台应该在面向能力交付的维度进行深度融合。

【 A4 】 acbogeh 富国基金 系统工程师： 

容器的特性决定了其天然的就是满足 devops 精神的，更容易 cicd 。

【 Q2 】容器云平台与虚拟机平台 devops 工具兼容问题？

对于很多公司而言，在使用容器云平台之前，都有自己的一套基于虚拟机的 devops 流水线平台，那么在使用容器云平台以后，如何在 devops 流水线平台上同时兼容基于容器和虚拟机的 devops 流程？

【 A1 】 jiangjf2DevOps 安信证券 工程师：

我理解这里主要的差异在构建节点和工具层面，对于流水线过程来说，只是在部署环节的实现不同。也就是整条流水线的其中一个 stage 的实现不同，对流水线过程来说不一定存在差异。部署过程流水线提供的是发布到虚拟机和容器云平台的能力，比如我们在虚拟机的部署方面是通过 ansible 来进行的，容器云平台的部署则是通过 Kubectl 命令行工具管理 Kubernetes 集群。应用部署逻辑则是由项目团队提供 playbook 或 yaml 文件，设置环境信息：对于虚拟机来说是 ip ，对于容器来说是 namespace 。也就是平台提供两种部署方式的能力，项目团队只需要关注自己需要哪种部署方式，以及流水线在什么时间需要执行部署任务。在后续的建设中我们计划通过统一的发布平台来提供应用部署到虚拟机和容器云平台的支持，流水线基于统一的发布平台完成部署过程，进一步减小用户对两种部署方式差异的感知。

【 A2 】anonymous：

我们建议将容器平台作为基础设施，然后在容器和 IaaS 平台之上建设一个统一的应用发布平台。最后 CICD 流水线的最后一步与这个应用发布平台对接。这样在开发测试阶段，可以实现兼容容器和虚拟机的应用发布，在生产环境也可以实现容器 / 虚拟机应用的统一发布管理。

三、容器云与微服务

【 Q1 】微服务体系与容器云如何融合？

微服务体系有自己的治理与度量监控体系，容器云也有 k8s 的编排与部署。在真实生产环境下，容器云的编排可以取代传统的微服务治理体系吗？是替代关系还是融合关系？如何实践？

【 A1 】 mtming333 甜橙金融翼支付 系统运维工程师：

在真实生产环境下，替代和融合都困难，有一定开发改造量，而在平台之上独立部署微服务架构较好。当然也有尝试做融合的，看到鹅厂有投入精力做注册中心同步。

【 Q2 】容器中的东西向流量如何管理和隔离，以便防止异常的访问出现？

【 A1 】 wykkx 某基金公司 系统架构师：

API网关，流量管理，鉴权，降级，限流，都可以做。

【 A2 】wanshaoyuanit Rancher 技术咨询顾问：

可以通过 NetworkPolicy 实现东西向流量隔离，但 NetworkPolicy 无法实现更高级的管理；

可以通过 Cilium 实现透明安全策略与流量可视化、流量重定向等更高级的应用；

可以通过 Istio 等服务网格技术实现流量劫持、流量路由等服务治理能力。

这些都是 Rancher 集群中集成的能力。

【 Q3 】容器云如何设计两地三中心部署微服务？

微服务注册与发现，如 Springcloud ，同城双活如何部署设计，异地灾备如何部署设计；注册中心需要部署几套？微服务发现，如何做到获取同城的服务？

【 A1 】 wanshaoyuanit Rancher 技术咨询顾问：

目前企业采用比较多的微服务框架主要基于 Dubbo 或 Spring Cloud ，服务注册中心一般是 eureka 、 zookeeper 以及后来推出的 nacos ，同城双活环境下，可以跨集群部署一套注册中心，微服务应用调用时优先调用同集群微服务，当同集群无可用服务提供方时，调用跨集群服务提供方。另外，当存在跨集群服务调用的情况时，在规划容器云网络时就要考虑跨集群网络互通问题。如果无法实现网络互通，可能就要采用访问代理或者灾备的建设思路。kubernetes 本身也提供了原生的 service 功能，对于 kubernetes 环境下的 spring cloud 和 dubbo 的落地，也可以参考下官方社区的 spring-cloud-kubernetes （ https://github.com/spring-cloud/spring-cloud-kubernetes ）和 dubbo-kubernetes （ https://github.com/apache/dubbo-kubernetes ）项目，可以借鉴 。

四、容器云与监控

【 Q1 】容器环境的微服务如何进行链路可视化，通过 APM 工具的话哪些比较适合容器环境使用？

【 A1 】 wykkx 某基金公司 系统架构师：

链路可视化如果是基于进程级别的，其实不是特别在意是容器环境还是虚拟机环境，都是向下屏蔽的。如果预算有限，建议使用开源的 skywalking 方案，该方案无入侵，功能强大，社区活跃，建议使用。

【 A2 】 jiangjf2DevOps 安信证券 工程师：

如果引入服务网格如 istio ，则通过 jaeger 支持的比较好，服务网格的代理 envoy ，会自动生成 traceID ，可以由 jaeger 收集起来，形成调用链，类似的还有 skywalking ，也在和 envoy 对接中。

如果不引入服务网格，则需要应用对接 skywalking ， jaeger ，即在应用进程内启动一个 agent ，对链路数据收集后发送到 server 端处理。

【 A3 】 wanshaoyuanit Rancher 技术咨询顾问：

目前容器环境下的微服务监控方案也比较成熟，可选择性也比较多，像商业的 Dynatrace 就能够很好的的实现从底层到应用层的全景监控，开源的方案目前比较主流的有 Pinpoint 、 Skywalking 、 Istio 等，其中 Pinpoint 和 Skywalking 主要采用 Java 语言开发，对 Java 生态有着非常好的支持，启动时通过 Java agent 的方式就可以快速集成，对于其他语言社区也提供了一些集成方案， Istio 这种就是目前主流的服务网格的方案，与语言无关，通过 sidecar 的方式集成，也可以实现微服务链路可视化。

ps ：rancher 已经集群 istio ，可以直接在 UI 上查看应用关系调用。

【 Q2 】容器云平台故障排查？

容器云平台的使用方式和传统的物理机以及虚拟机都有较大的差距，那么在生产系统使用容器云平台部署应用以后，如果出现生产问题，应该如何快速定位和解决问题，需要开发人员和运维人员具备什么样的技能？

【 A1 】 wanshaoyuanit Rancher 技术咨询顾问：

建议选择专业的容器云厂商提供专业的服务。

以下为我司技术专家总结的一些经验：

1、建议您在使用测试环境时或者是上线生产前就应当建立一个相对完善的生产环境问题应急处理办法和标准，以应对生产环境中的紧急问题情况处理。

3、关于如何快速定位和解决问题，有点些太过宽泛。但是快速解决问题的基础是首先要对整个平台的架构和各组件的功能交互非常熟悉和有最基本的运维思路。最起码要判断这个问题是 docker 层面的， k8s 层面的还是平台层面的。在深入去看具体组件或者资源的问题，看日志看现象看资源使用。

3、开发人员和运维人员需要具备容器知识， docker 和 k8s 的使用和运维经验 ( 包含组件交互原理，网络，存储，资源分配，监控，日志等 ) 。

排查问题的思路：

观察问题：细致的观察问题发生时的情况，做好对问题的描述和记录

收集信息：尽可能的去收集问题发生时的日志信息。比如说平台日志，容器日志，应用日志。还有环境信息，内核版本， docker 版本， k8s 版本，网络模式等。

复现问题：接下来根据收集到的信息，清楚复现问题的步骤，并记录。

收缩范围：排查无关的因素和影响，缩小范围。

定位问题：把产生问题的可能原因定位在一个或几个上。这样可以通过控制变量去进一步排除问题的可能。

解决方案：根据这些问题可能会出现的原因，去指定一个解决方案。

执行方案，解决问题：要做好记录，要预留足够的时间避免新的问题的产生。

解决问题的思路：

是否需要做应急策略

考虑是否可以复现问题，如果可以复现的话记录并观察这个复现的过程，有可能在复现过程中，就可以直接定位问题发生的原因。

如果故障是偶发性的，是有极小概率出现的，就比较难排查，这依赖于系统是否有足够的故障期间的现场信息来决定是否可以定位原因。

复现后，通过已掌握的技术知识和经验基本可以确定问题产生的原因，列举出来。

考虑一下这些问题产生的原因是不是有优先级的关系，先去解决可能性大的原因。提升效率。

接下来逐一对这些问题产生的原因进行排查，并对每一个排查的过程做记录

如果超出所考虑的这些原因，那么需要重新回头再去看问题如何解决。

应急恢复的方法：

首先还是要保证系统的可用性

服务整体性能下降或异常，可以考虑重启服务；

应用做过变更，可以考虑是否需要回切变更；

资源不足，可以考虑应急扩容；

应用性能问题，可以考虑调整应用参数、日志参数；

系统漏洞问题，是否考虑升级版本

【 A2 】 acbogeh 富国基金 系统工程师：

1、k8s 的命令得熟，有些问题还是得进容器看

2、日志统一收集，用统一的日志平台来看日志比较方便

3、skywalking 等工具来完成链路的调用监控，找到问题所在。

【 Q3 】现有监控系统如何和容器云平台监控对接和融合？

1 、容器云平台监控技术用什么？会覆盖哪些监控，比如主机 / 容器资源监控、容器平台组件监控、容器内部中间件 / 业务监控？

2 、现有监控系统技术用什么？

3 、容器云平台监控怎么和现有监控系统对接，哪些维度数据会对接，如监控数据、告警数据？现有监控会展示容器云哪些监控数据？

【 A1 】 acbogeh 富国基金 系统工程师：

zabbix/promethus 两条路线，前者相对还是适合传统基建告警；后者偏向容器

但是一般企业希望统一告警，那目前可以用 zabbix 对接 promethus 的 alert export 来实现告警统一收集统一发送。

【 A2 】 wanshaoyuanit Rancher 技术咨询顾问：

容器云平台监控和容器应用监控主要使用 Prometheus ，告警可以通过 Altermanager webhook 方式对接自己外部的统一告警系统， rancher 已经内置了 Prometheus 监控包含多个层面监控包括：集群层面资源使用监控和组件性能监控、节点资源监控、容器应用资源监控。对于一些需要针对业务的监控可以使用自定义监控方式实现对业务指标监控。

针对多集群的监控， rancher 内集成了统一监控展示，将多个集群中的 top 信息进行统一展示如 : 最消耗 cpu 、 memory 的 pod top10。

一般情况下，与现有监控系统都是在监控指标展示层面进行对接，将数据通过统一的大屏进行展示。

点击阅读原文，有更多精彩交流内容

觉得本文有用，请转发、点赞或点击“在看”，让更多同行看到

下载 twt 社区客户端 APP

或到应用商店搜索“twt”