vlambda博客
学习文章列表

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

通过上面的内容可以看出，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的技术路线。

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

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

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

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

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

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

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

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

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

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

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

图-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。

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

图-5：性能对比评测

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

针对原有容器业务发布架构存在问题，我们对不同的容器业务发布方案进行了调研和测试，最终我们选取了双层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配置的更新，从而完成容器业务统一发布的自动化。

图-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。

新的容器业务发布架构在功能上除了提供标准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三层均可以横向扩展提升性能适应严苛的生产环境。

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

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

                     编辑：民生运维文化建设组