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

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

【摘要】目前金融行业正在大力建设基于容器和K8S为底层技术架构的PaaS云平台，用于快速部署各种各样的生产应用。传统应用使用负载均衡设备实现业务统一入口和同城容灾，如何在K8S上实现同样的目标，同时保持架构的稳定和高效，是目前金融行业最新的关注点。本篇文章围绕这一主题，结合民生银行容器业务发布架构的探索与实践，给大家分享一些经验。一、前言近期，业界首例通过负载均衡统一发布容器业务的架构在民生银行测试网上线，解决了在标准K8S业务发布方式中遇到的一系列运维难题，使用创新性的架构实现了传统环境与容器环境业务发布管理上的统一性，包括功能统一、变更统一、运维统一，同时提升容器业务发布架构整体的性能和效率。在软件定义一切的指导思想下，过去几年间，金融行业通过私有云、行业云、生态云等的建设，基本上具备了IaaS云的服务能力，目前金融行业正在大力建设基于容器和K8S为底层技术架构的PaaS云平台，用于快速部署各种各样的生产应用。传统应用使用负载均衡设备实现业务统一入口和同城容灾，如何在K8S上实现同样的目标，同时保持架构的稳定和高效，是目前金融行业最新的关注点。本篇文章围绕这一主题，结合民生银行容器业务发布架构的探索与实践，给大家分享一些经验。二、标准容器业务发布方式面临的挑战1、Nodeport

和Ingress通常来说，K8S通过Nodeport类型的Service资源和Ingress资源控制着外部请求访问K8S内的容器业务，这是容器业务发布的标准方式，也是大多数金融行业所采用的发布方式。一个容器业务发布相关的组件及流程如下图所示：图-1：容器应用标准发布方式Service是K8S的标准对象资源，容器应用通过该资源实现入访能力，通常底层技术由iptables或ipvs实现，NodePort类型的Service可以提供固定的IP地址和端口用于外部请求访问。

IngressResources是K8S的标准对象资源，一个Ingress资源中可定义多条规则，每一条规则通常关联一个域名，外部请求通过该域名可访问该规则下所有容器应用，一条规则内也可定义多个Path，每一个path对应一个容器应用，这样实现一个Ingress关联多个容器应用。IngressController即入口控制器，通常是一种容器化的代理服务器应用，用于提供http类业务的转发，通过service对外提供服务。Ingresscontroller的主要工作是将Ingress资源中定义的访问规则转换成其实际配置，并基于K8SAPI对容器的变化实时感知从而完成配置项的更新，同时负责相关流量的转发。

LoadBalancer既负载均衡器在数据平面将外部请求转发给Service提供的IP地址和端口，一般挂载多个Node用于容灾和流量负载分担。外部请求一般访问容器应用的有两种路径，如下所示：NodePort发送访问请求到负载均衡负载均衡基于负载算法将请求发送到Node节上的特定端口，即容器应用通过NodePortService发布的IP和端口

Node节点根据Service资源中定义的端口与容器应用的对应关系，确定目标容器应用，通过iptable转发规则完成实际流量转发Ingress发送访问请求到负载均衡负载均衡基于负载算法将请求发送到Node节上的特定端口，即Ingresscontroller通过NodePortService发布的IP和端口Node节点根据Service资源中定义的端口与容器应用的对应关系，确定目标容器应用为Ingresscontroller，通过iptable转发规则完成实际流量转发

Ingresscontroller根据Ingress资源中定义的转发规则，把相关流量转发给业务应用容器外部请求访问容器应用的两种方式中，Ingress相比于NodePort多了一层转发逻辑，为何要使用这种复杂的方式那？这主要是因为NodePort本质上是基于iptable技术实现的，只有四层负载均衡能力，而Ingress具备七层负载均衡能力，一些高级功能如cookie会话保持，源地址透传，http路径转发等只能在Ingress上实现。2、主流的Ingresscontroller通过上面的内容可以看出，IngressController在容器业务发布中主要扮演着重要角色，是大部分容器业务交付的实际控制者，这种情况下IngressController的技术选择就极为关键，我们来看一下市场上主流的IngressController都有哪些。图-2：ingresscontroller下载量对比（数据来自dockerhub）根据dockerhub()上IngressController镜像下载量统计，目前整个容器入口控制中最受欢迎的实现是Nginx和F5，两者都有超过1000万的下载量，两者下载量排名都是其它入口控制器下载量的数倍。其中Nginx的实现以开源软件Nginx为主，F5公司在2019年收购Nginx后推出了基于Nginx加强版（NginxPlus）的容器入口控制器，相比较开源版，NginxPlus容器入口控制器在图形化监控、容器安全和及商业化支持方面进行了加强。而F5的f5networks/k8s-bigip-ctlr主要依附于F5在应用交付控制领域的积累，通过部署bigip-ctlr容器使F5设备能够直接为容器应用提供负载均衡能力，这种实现最显著的特点是功能全面、高性能。分析图-2中排名前10的容器IngressController的实现，会发现大多数入口控制器的实现都是基于开源Nginx或HAProxy，这也与金融行业IngressController的实际情况一致。目前金融行业在容器入口控制技术路线上选择主要以开源技术为主，最具代表性的是开源Nginx和HAProxy。Nginx占大多数，几乎所有金融行业都有在基于Nginx进行容器业务交付控制，也有一些国有大行或股份制银行使用HAProxy的技术路线。3、民生银行原有Nodeport和Ingress业务发布架构经过近2年的容器云建设，容器云在我行数据中心测试环境和生产环境已经成为新业务上线的主要承载平台。而具体到容器业务发布的方式，民生银行在结合了同业部署、容灾以及高可用等多种因素，使用如下架构完成容器业务的发布。图-3：容器业务发布原有架构同城双中心机房独立部署容器集群需要同城容灾部署的容器应用在两个容器集群完成部署同一容器集群内的业务通过NodePort和Ingress完成业务对外发布

N+M架构的F5集群挂载两个集群特定的Node完成跨容器集群业务的统一对外发布这一架构在标准的容器业务发布方案上对同城容灾和不间断服务的需求进行了优化，使用F5集群实现业务的统一IP+端口对外发布，挂载不同集群的Node让流量分担到多个Node上实现了流量的负载和跨集群容灾，减少单Node的转发压力。使用主流的开源的NginxIngressController，实现7层的业务负载均衡，每种业务使用不同的namespace进行隔离，包括NodePort、Ingress和IngressController。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,Nginxingress等多个组件，故障点较多且无法使用现有手段对所有组件实现运维监控。三、通过负载均衡架构统一发布容器业务1、CIS和AS3图-4：F5CIS控制平面与数据平面CIS是一款由F5公司提供的容器入口控制产品，提供商业的支持和维护。如上图所示，与其它IngressController相比，CIS只做控制平面的工作，它同样容器化部署在K8S集群内，监控容器内的Configmaps和Ingress等资源实现配置下发，将Configmaps和Ingress中定义的内容转换成F5虚拟服务配置，然后调用管理API将F5虚拟服务配置推送至F5硬件或虚拟化F5VE。数据平面，容器入口流量经F5直达容器应用POD。CIS有三种运行模式，监控的资源对象和支持的功能对比详见表-1所示：在Ingress模式下，CIS的使用方式与其它IngressController没有任何区别，它监控标准的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+NginxIngress架构和F5+CIS架构的业务转发性能。性能对比基于同一个测试应用，分别通过新老架构进行容器业务发布，测试基于同一请求，请求返回结果约0.25KB，测试对比的维度包括RTS(每秒钟完成的请求总数)、TPS（每秒钟完成的事务总数）以及吞吐量，测试结果如下图-6所示。图-5：性能对比评测从图中性能对比结果可以看出，同一个容器应用，F5+CIS架构的性能明显高于NodePort+NginxIngress架构，RPS指标新架构性能是老架构性能的4倍；吞吐量对比新架构性能是老架构性能的4倍；而TPS指标主要受限于容器应用的处理能力，在同等条件下，该指标新架构性能是老架构性能的2倍。3、民生银行使用F5和AS3CIS实现容器业务发布针对原有容器业务发布架构存在问题，我们对不同的容器业务发布方案进行了调研和测试，最终我们选取了双层F5和AS3CIS作为容器业务统一发布架构，目前该架构已在测试环境上线，架构如图所示：图-6：容器业务统一发布新架构同城双中心机房独立部署容器集群同城容灾部署的容器应用在两个容器集群部署容器业务发布使用K8S的Configmaps资源实现配置管理，通过K8S集群内部署的F5CIS容器实现对F5VE的管理和动态配置推送第二层F5VE设备通过CIS容器管理，动态挂载实际业务POD实现容器业务对外直接发布

第一层F5物理设备通过挂载两个集群对应的F5VE设备实现跨容器集群业务的统一对外发布容器业务统一发布架构中的第一层为F5N+M集群，提供K8S双中心集群服务的总入口，这一层部署的F5是硬件设备，具有出色的性能、硬件的优势、标准化成熟的落地方案，同时对第二层的F5做负载分发。第二层选用的是虚拟化的F5VE设备，F5VE通过VMware虚机的方式部署，与单个K8S集群绑定，一组主备F5VE只负责单个K8S集群中的容器应用发布。AS3模式的CIS容器部署在K8S集群内，作为F5VE的控制器，CIS容器通过对K8S集群内Configmap资源进行监控，将Configmap资源中的内容转化为F5的配置，将配置推送给F5VE，CIS容器还通过K8S标准的API接口完成业务发现和实时监听集群内Pod的变化，一旦Pod发生变化，相应的更新会及时推送给VE，并完成更新。网络自动化系统将需求转换为第一层F5的配置和Configmaps资源配置，通过API接口实现第一层F5配置的自动下发以及K8S集群内Configmaps资源的更新，CIS通过监听Configmaps的资源变化完成第二层F5VE配置的更新，从而完成容器业务统一发布的自动化。4、场景举例：基于IP的双中心会话保持业务发布我们通过一个容器应用的发布场景来说明这个架构是如何的工作的，这个应用通过IP地址访问需要cookie会话保持同时需要双中心容灾。假定业务应用名称为app，有两个K8S集群名称为A和B，集群A对应的VE设备的VS地址段为/24，集群B对应的VE设备的VS地址段为/24，第一层F5硬件设备的VS地址段为/24，app业务发布过程如下：图-7：双层架构下容器业务发布为满足双中心容灾，将app部署到A,B两个K8S集群，同时给service打特定标签。在集群A上更新configmap内容，给app应用配置如高级负载均衡，cookie会话保持、负载算法后等相关功能，分配的IP为0:80。集群A中CIS容器监听到confgmap的更新内容后，通过service标签实现应用发布关联，向第二层VE设备推送配置，完成业务发布。在集群B上的有类似步骤，同样将app发布到其对应的VE上，分配的IP为0:80。在一层F5上创建虚拟服务并保持启用的功能与configmap中一致，分配IP为0:80，对应的PoolMember为第二层VE设备的虚拟服务IP，既为0:80和0:80。

当请求访问0时，经过一层F5时会根据相关算法和会话保持逻辑将请求转发给第二层VE，经过第二层VE时同样根据相关算法和会话保持逻辑将请求转发给实际业务的POD。5、运维难题迎刃而解新的容器业务发布架构在功能上除了提供标准NodePort+Ingress架构支持的所有功能外，还解决了目前我行在业务发布方面遇到的问题，具体包括：功能全面新架构中的负载均衡功能通过专业设备实现，功能全面，7层功能不再依赖Ingress和域名，业务无需改造，助力推广应用容器化。

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

变更管理简便业务发布使用统一方式配置，而不用NodePort和Ingress混合配置，配置集中在独立Namespace的Configmaps资源上，支持跨Namespace进行业务