银行首创通过负载均衡架构统一发布容器业务

　【摘要】目前金融行业正在大力建设基于容器和 K8S 为底层技术架构的 PaaS 云平台，用于快速部署各种各样的生产应用。传统应用使用负载均衡设备实现业务统一入口和同城容灾，如何在 K8S 上实现同样的目标，同时保持架构的稳定和高效，是目前金融行业最新的关注点。

　一、前言

　近期，业界首例通过负载均衡统一发布容器业务的架构在银行测试网上线，解决了在标准 K8S 业务发布方式中遇到的一系列运维难题，使用创新性的架构实现了传统环境与容器环境业务发布管理上的统一性，包括功能统一、变更统一、运维统一，同时提升容器业务发布架构整体的性能和效率。

　在软件定义一切的指导思想下，过去几年间，金融行业通过私有云、行业云、生态云等的建设，基本上具备了 IaaS云的服务能力，目前金融行业正在大力建设基于容器和 K8S 为底层技术架构的 PaaS 云平台，用于快速部署各种各样的生产应用。

　传统应用使用负载均衡设备实现业务统一入口和同城容灾，如何在 K8S 上实现同样的目标，同时保持架构的稳定和高效，是目前金融行业最新的关注点。本篇文章围绕这一主题，结合银行容器业务发布架构的探索与实践，给大家分享一些经验。

　 二、标准容器业务发布方式面临的挑战

　1、Nodeport 和 Ingress

　通常来说，K8S 通过 Nodeport 类型的 Service 资源和 Ingress 资源控制着外部请求访问 K8S 内的容器业务，这是容器业务发布的标准方式，也是大多数金融行业所采用的发布方式。一个容器业务发布相关的组件及流程如下图所示：

　 图-1：容器应用标准发布方式

　 Service 是 K8S 的标准对象资源，容器应用通过该资源实现入访能力，通常底层技术由 iptables 或 ipvs实现，NodePort 类型的 Service 可以提供固定的 IP 地址和端口用于外部请求访问。

　 Ingress Resources 是 K8S 的标准对象资源，一个 Ingress 资源中可定义多条规则，每一条规则通常关联一个域名，外部请求通过该域名可访问该规则下所有容器应用，一条规则内也可定义多个 Path，每一个 path 对应一个容器应用，这样实现一个 Ingress 关联多个容器应用。

　 Ingress Controller 即入口控制器，通常是一种容器化的代理服务器应用，用于提供 http 类业务的转发，通过 service 对外提供服务。Ingress controller 的主要工作是将 Ingress 资源中定义的访问规则转换成其实际配置，并基于 K8S API 对容器的变化实时感知从而完成配置项的更新，同时负责相关流量的转发。

　 Load Balancer 既负载均衡器在数据平面将外部请求转发给 Service 提供的 IP 地址和端口，一般挂载多个 Node 用于容灾和流量负载分担。

　外部请求一般访问容器应用的有两种路径，如下所示：

　NodePort

　 发送访问请求到负载均衡

　 负载均衡基于负载算法将请求发送到 Node 节上的特定端口，即容器应用通过 NodePort Service 发布的IP 和端口

　 Node 节点根据 Service 资源中定义的端口与容器应用的对应关系，确定目标容器应用，通过 iptable 转发规则完成实际流量转发

　Ingress

　 发送访问请求到负载均衡

　 负载均衡基于负载算法将请求发送到 Node 节上的特定端口，即 Ingress controller 通过 NodePort Service 发布的 IP 和端口

　 Node 节点根据 Service 资源中定义的端口与容器应用的对应关系，确定目标容器应用为 Ingress controller，通过 iptable 转发规则完成实际流量转发

　 Ingress controller 根据 Ingress 资源中定义的转发规则，把相关流量转发给业务应用容器

　外部请求访问容器应用的两种方式中，Ingress 相比于 NodePort 多了一层转发逻辑，为何要使用这种复杂的方式那？这主要是因为 NodePort 本质上是基于 iptable 技术实现的，只有四层负载均衡能力，而 Ingress 具备七层负载均衡能力，一些高级功能如 cookie 会话保持，源地址透传，http 路径转发等只能在 Ingress 上实现。

　2、主流的 Ingress controller

　通过上面的内容可以看出，Ingress Controller 在容器业务发布中主要扮演着重要角色，是大部分容器业务交付的实际控制者，这种情况下 Ingress Controller 的技术选择就极为关键，我们来看一下市场上主流的 Ingress Controller 都有哪些。

　 图-2：ingress controller 下载量对比（数据来自 docker hub）

　根据 docker hub(https://hub.docker.com)上 Ingress Controller 镜像下载量统计，目前整个容器入口控制中最受欢迎的实现是 Nginx 和 F5，两者都有超过 1000 万的下载量，两者下载量排名都是其它入口控制器下载量的数倍。

　其中 Nginx 的实现以开源软件 Nginx 为主，F5 公司在 2019 年收购 Nginx 后推出了基于 Nginx 加强版（Nginx Plus）的容器入口控制器，相比较开源版， Nginx Plus 容器入口控制器在图形化监控、容器安全和及商业化支持方面进行了加强。而 F5 的 f5networks/k8s-bigip-ctlr 主要依附于 F5 在应用交付控制领域的积累，通过部署 bigip-ctlr 容器使 F5 设备能够直接为容器应用提供负载均衡能力，这种实现最显著的特点是功能全面、高性能。

　分析图-2 中排名前 10 的容器 Ingress Controller 的实现，会发现大多数入口控制器的实现都是基于开源 Nginx或 HAProxy，这也与金融行业 Ingress Controller 的实际情况一致。目前金融行业在容器入口控制技术路线上选择主要以开源技术为主，最具代表性的是开源 Nginx 和 HAProxy。Nginx 占大多数，几乎所有金融行业都有在基于Nginx 进行容器业务交付控制，也有一些国有大行或股份制银行使用 HAProxy 的技术路线。

　3、银行原有 Nodeport 和 Ingress 业务发布架构

　经过近 2 年的容器云建设，容器云在我行数据中心测试环境和生产环境已经成为新业务上线的主要承载平台。而具体到容器业务发布的方式，银行在结合了同业部署、容灾以及高可用等多种因素，使用如下架构完成容器业务的发布。

　 图-3：容器业务发布原有架构

　 同城双中心机房独立部署容器集群

　 需要同城容灾部署的容器应用在两个容器集群完成部署

　 同一容器集群内的业务通过 NodePort 和 Ingress 完成业务对外发布

　 N+M 架构的 F5 集群挂载两个集群特定的 Node 完成跨容器集群业务的统一对外发布

　这一架构在标准的容器业务发布方案上对同城容灾和不间断服务的需求进行了优化，使用 F5 集群实现业务的统一IP+端口对外发布，挂载不同集群的 Node让流量分担到多个 Node上实现了流量的负载和跨集群容灾，减少单 Node的转发压力。使用主流的开源的 Nginx Ingress Controller，实现 7 层的业务负载均衡，每种业务使用不同的namespace 进行隔离，包括 NodePort、Ingress 和 Ingress Controller。

　4、标准架构带来的运维难题

　虽然基于 nodeport 和 ingress 的业务发布方式基本能够满足大部分场景，但在银行数据中心应用容器化改造的大场景下，随着容器平台承载的业务数量越来越多、业务的重要性越高、以及 K8S 集群的数量越来越多，原有容器业务发布架构存在诸多不便的地方，限制了容器的优势和推广使用。从运维管理和使用的角度来看，面临如下挑战：

　功能受限

　基于 IP 访问的 http 类业务在我行广泛应用，这类业务如需实现 cookie 会话保持或者源地址透传等 7 层功能，在标准架构下均需要使用 Ingress 实现，而 Ingress 必须通过域名的方式进行访问，在应用没有完成 DNS 改造前无法实现会话保持需求。同样 Nodeport 和 Ingress 缺少一些专业负载均衡的功能，如高级负载均衡算法、自定义会话超时时间等等，传统应用在容器化改造过程中必须完成相应逻辑整改后才能完成上线。

　性能平庸

　受限于 Nodeport 和 Ingress 的底层实现机制，以及流量绕行无法直达业务 POD，业务吞吐、TPS、RPS 的性能远低于传统非容器业务发布方式，访问量大的业务面临转发性能问题。

　变更管理难度大

　传统业务对外发布通常由网络部门统一管理，容器业务发布所需的配置分散在 F5 设备、K8S 内的 Service 资源以及Ingress 资源中，并且 K8S 中不同 namespace 的资源往往是租户管理员自行管理，应用发布往往需要跨越网络、云平台、应用三个部门协同处理，沟通成本较高，配置管理难度较大。

　运维监控难度高

　因 Nodeport 和 Ingress 的实现机制，业务流量无法直达业务 Pod，会在 Node 之间绕行，造成带宽浪费和性能下降的问题，不利于网络流量分析。同时，流量需要穿越 F5, Iptable, Nginx ingress 等多个组件，故障点较多且无法使用现有手段对所有组件实现运维监控。

　 三、通过负载均衡架构统一发布容器业务

　1、CIS 和 AS3

　 图-4：F5 CIS 控制平面与数据平面

　CIS 是一款由 F5 公司提供的容器入口控制产品，提供商业的支持和维护。如上图所示，与其它 Ingress Controller相比，CIS 只做控制平面的工作，它同样容器化部署在 K8S 集群内，监控容器内的 Configmaps 和 Ingress 等资源实现配置下发，将 Configmaps 和 Ingress 中定义的内容转换成 F5 虚拟服务配置，然后调用管理 API 将 F5 虚拟服务配置推送至 F5 硬件或虚拟化 F5 VE。数据平面，容器入口流量经 F5 直达容器应用 POD。

　CIS 有三种运行模式，监控的资源对象和支持的功能对比详见表-1 所示：

　在 Ingress 模式下，CIS 的使用方式与其它 Ingress Controller 没有任何区别，它监控标准的 Ingress 资源，将对应的规则转换成 F5 虚拟服务的配置推送给 F5 设备；cccl 和 AS3 模式是 CIS 独有的功能，它监控的是 configmap 对象，cccl 主要的优势是下发性能，但不支持服务动态发现，不支持高级负载均衡特性；AS3 最大的优势就是功能全面，几乎 F5 所有应用交付控制的功能都可以在容器应用交付中使用，而且支持服务动态发现，在 Configmaps完成了虚拟服务的配置后，只需要在对应要发布的容器业务服务中添加几个标签，即可完成容器服务的虚拟发布，例如表-2：

　 经过详细的调研和测试，AS3 模式的 CIS 可以实现 Nodeport 和 Ingress 的所有功能，CIS 容器与 F5 设备之间的交互都是基于 AS3 接口，AS3 接口传递的参数是 JSON 对象，该对象中包括容器业务发布所关联的所有配置项，包括高级负载均衡配置，TLS 加密配置，高级健康检测配置等。

　每个 CIS 容器支持对接一个 F5 设备，当 CIS 容器性能不足时可以横向扩容 CIS 容器数量，通过监听不同的Configmaps 资源发布不同的容器应用实现负载，多个 CIS 容器可以对接同一个 VE，也可以对接不同的 VE。

　2、新架构下性能大幅提升

　为了更好的了解新架构的性能，在这一阶段进行了性能对比评测，主要对比我行原有 NodePort+Nginx Ingress 架构和 F5+CIS 架构的业务转发性能。性能对比基于同一个测试应用，分别通过新老架构进行容器业务发布，测试基于同一请求，请求返回结果约 0.25 KB，测试对比的维度包括 RTS(每秒钟完成的请求总数)、TPS（每秒钟完成的事务总数）以及吞吐量，测试结果如下图-6 所示。

　 图-5：性能对比评测

　从图中性能对比结果可以看出，同一个容器应用，F5+CIS 架构的性能明显高于 NodePort+Nginx Ingress 架构，RPS 指标新架构性能是老架构性能的 4 倍；吞吐量对比新架构性能是老架构性能的 4 倍；而 TPS 指标主要受限于容器应用的处理能力，在同等条件下，该指标新架构性能是老架构性能的 2 倍。

　3、银行使用 F5 和 AS3 CIS 实现容器业务发布

　针对原有容器业务发布架构存在问题，我们对不同的容器业务发布方案进行了调研和测试，最终我们选取了双层 F5和 AS3 CIS 作为容器业务统一发布架构，目前该架构已在测试环境上线，架构如图所示：

　 图-6：容器业务统一发布新架构

　 同城双中心机房独立部署容器集群

　 同城容灾部署的容器应用在两个容器集群部署

　 容器业务发布使用 K8S 的 Configmaps 资源实现配置管理，通过 K8S 集群内部署的 F5 CIS 容器实现对F5 VE 的管理和动态配置推送

　 第二层 F5 VE 设备通过 CIS 容器管理，动态挂载实际业务 POD 实现容器业务对外直接发布

　 第一层 F5 物理设备通过挂载两个集群对应的 F5 VE 设备实现跨容器集群业务的统一对外发布

　容器业务统一发布架构中的第一层为 F5 N+M 集群，提供 K8S 双中心集群服务的总入口，这一层部署的 F5 是硬件设备，具有出色的性能、硬件的优势、标准化成熟的落地方案，同时对第二层的 F5 做负载分发。第二层选用的是虚拟化的 F5 VE 设备，F5 VE 通过 VMware 虚机的方式部署，与单个 K8S 集群绑定，一组主备 F5 VE 只负责单个K8S 集群中的容器应用发布。

　AS3 模式的 CIS 容器部署在 K8S 集群内，作为 F5 VE 的控制器，CIS 容器通过对 K8S 集群内 Configmap 资源进行监控，将 Configmap 资源中的内容转化为 F5 的配置，将配置推送给 F5 VE，CIS 容器还通过 K8S 标准的 API 接口完成业务发现和实时监听集群内 Pod 的变化，一旦 Pod 发生变化，相应的更新会及时推送给 VE，并完成更新。

　网络自动化系统将需求转换为第一层 F5 的配置和 Configmaps 资源配置，通过 API 接口实现第一层 F5 配置的自动下发以及 K8S 集群内 Configmaps 资源的更新，CIS 通过监听 Configmaps 的资源变化完成第二层 F5 VE 配置的更新，从而完成容器业务统一发布的自动化。

　4、场景举例：基于 IP 的双中心会话保持业务发布

　我们通过一个容器应用的发布场景来说明这个架构是如何的工作的，这个应用通过 IP 地址访问需要 cookie 会话保持同时需要双中心容灾。假定业务应用名称为 app，有两个 K8S 集群名称为 A 和 B，集群 A 对应的 VE 设备的 VS地址段为 10.1.1.0/24，集群 B 对应的 VE 设备的 VS 地址段为 10.1.2.0/24，第一层 F5 硬件设备的 VS 地址段为10.1.10.0/24，app 业务发布过程如下：

　 图-7：双层架构下容器业务发布

　 为满足双中心容灾，将 app 部署到 A,B 两个 K8S 集群，同时给 service 打特定标签。

　 在集群 A 上更新 configmap 内容，给 app 应用配置如高级负载均衡，cookie 会话保持、负载算法后等相关功能，分配的 IP 为 10.1.1.20:80。

　 集群 A 中 CIS 容器监听到 confgmap 的更新内容后，通过 service 标签实现应用发布关联，向第二层 VE设备推送配置，完成业务发布。

　 在集群 B 上的有类似步骤，同样将 app 发布到其对应的 VE 上，分配的 IP 为 10.1.2.20:80。

　 在一层 F5 上创建虚拟服务并保持启用的功能与 configmap 中一致，分配 IP 为 10.1.10.20:80，对应的 Pool Member 为第二层 VE 设备的虚拟服务 IP，既为 10.1.1.20:80 和 10.1.2.20:80。

　 当请求访问 http://10.1.10.20 时，经过一层 F5 时会根据相关算法和会话保持逻辑将请求转发给第二层VE，经过第二层 VE 时同样根据相关算法和会话保持逻辑将请求转发给实际业务的 POD。

　5、运维难题迎刃而解

　新的容器业务发布架构在功能上除了提供标准 NodePort+Ingress 架构支持的所有功能外，还解决了目前我行在业务发布方面遇到的问题，具体包括：

　 功能全面

　新架构中的负载均衡功能通过专业设备实现，功能全面，7 层功能不再依赖 Ingress 和域名，业务无需改造，助力推广应用容器化。

　 性能强大

　采用专业负载均衡设备，流量直达业务 Pod，业务吞吐、TPS、RPS 的能力大大提升，支持高吞吐业务系统上线容器平台。

　 变更管理简便

　业务发布使用统一方式配置，而不用 NodePort 和 Ingress 混合配置，配置集中在独立 Namespace 的 Configmaps资源上，支持跨 Namespace 进行业务发现和发布。应用发布流程可以由网络部门单独完成，与传统业务发布方式形成了统一，配置复杂度降低的同时大大降低了变更管理的难度。

　 运维监控简便

　因 VE 直接挂载 Pod，流量可以从负载均衡设备直达业务 Pod，流量只经过 F5 设备和业务 POD，提升网络性能的同时故障点大幅减少，可以直接复用现有流量监控及网络运维方案。

　 架构高可用，可扩展

　CIS 容器使用 K8S 中的 Deployment 方式部署保证其高可用，VE 主备集群部署的同时使用 VMware 机制保持高可用，F5 物理设备使用 N+M 架构实现高可用，F5、VE、CIS 三层均可以横向扩展提升性能适应严苛的生产环境。

　 四、展望未来

　容器在金融行业的部署规模日益增长，可以预见在未来的一段时间内，应用容器化将会是一个主流技术方向。从文章中可以看出，容器应用的发布方式在银行逐渐由“可用”向“好用”方向探索和转变，银行自身的特点决定了一个好的技术架构需要同时考虑功能、性能、运维管理以及组织架构等多个方面，往往一个新技术在银行数据中心大规模部署前需要进行针对性适配和改造，这也是银行容器业务统一发布架构产生的原因。运维人员可以用更加便捷、高效、统一的方式完成各类容器应用的上线和发布工作，减少了大规模容器部署环境下运维的难度，也使开发人员更加专注于应用本身。

　云的本质是资源的高效整合体，计算、存储、网络均是其重要的组成部分。在云网融合的大背景下，网络如何发挥其专业性让云更好的服务于数据中心是我们网络人努力的方向。当前，容器云在金融行业落地还存在许多运维难题，例如容器网络的安全隔离，容器网络的整体监控，容器网络的流量采集与监控，相信在不久的将来这些问题将会被我们一一解决。未来，我们将持续推进新技术在数据中心落地，助力于业务的不断创新，落实我行的科技金融战略。