1 前言

在金融行业的传统IT基础架构中，专有硬件负载均衡设备（如F5、Radware等）普遍具备功能强、性能高、运行稳定等特点，成为解决应用系统对外提供统一服务的首选方案。近年来，随着OpenStack、Kubernetes等云技术的兴起，应用系统的微服务化、快速迭代对资源的弹性伸缩能力提出了更高的要求，这就要求负载均衡有更好的灵活性和开放性。开源负载均衡软件因其开放的设计，完善的API接口以及对应用灵活部署需求的满足，在金融行业的云环境中逐步推广使用。民生银行在Kubernetes容器平台建设中，探索使用了一种灵活的软件F5解决方案，在利用F5传统优势的同时，也满足了容器应用的高灵活性要求。

2 Kubernetes服务发布方式及局限性

Service是Kubernetes最核心的资源对象之一，通过它可以为一组具备相同功能的容器应用提供一个统一的访问入口地址，并将请求负载分发到后端的各个容器应用上。这一点与传统IT基础架构中F5等负载均衡设备将访问请求负载分发到后端功能相同的应用上类似，Kubernetes集群中每个节点上运行的kube-proxy其实就是一个智能的软件负载均衡器，它负责把对Service的请求转发到后端的某个pod实例上，并在内部实现服务的负载均衡与会话保持机制。Service被分配了一个全局唯一的虚拟IP地址，称为ClusterIP。但ClusterIP只能实现集群内部的访问（即东西向服务），对于需要通过外部IP对外提供访问（即南北向服务）的场景，Kubernetes提供了三种主要方案，分别是NodePort 、LoadBalancer 、Ingress。

2.1 NodePort

NodePort 的实现方式是在每个节点上为需要外部访问的Service开启一个对应的TCP监听端口，外部系统用<NodeIP>:<NodePort>可以从集群外部访问一个NodePort服务，NodePort 服务会路由到 ClusterIP，通过kube-proxy转发至后端的容器，完成对服务的访问。NodePort的方式是解决服务暴露问题最直接的做法，其配置和维护都很简单，但它依赖于kube-proxy，目前仅支持轮询算法以及源地址会话保持。在负载均衡的其他特性方面还有一定缺陷。另外，NodePort占用node节点一个独立的端口，限制了集群中暴露服务的数量。且在实际使用过程中定义一个NodePort，需要在Kubernetes集群中的所有节点上开通此端口的入访能力，因此一般会结合集群外的负载均衡设备，与kube-proxy形成两级负载均衡的架构，对性能会产生一定影响，同时增加成本。

2.2 LoadBalancer

LoadBalancer 是Kubernetes深度结合云平台的一个组件，使用它构建服务时，实际上是向底层IaaS申请创建一个负载均衡来实现。IaaS网络和容器网络在不同云平台的融合方案不同，因此LoadBalancer 和云平台的网络方案深度耦合，只能在特定的云平台上使用，局限性较大。

2.3 Ingress

Ingress可以很好的解决LoadBalancer和NodePort的限制。它由3个组件组成：Ingress策略集、Ingress Controller和反向代理负载均衡器（如Nginx）。Ingress策略集定义了集群外的流量到达集群内的Service的规则。Ingress Controller与Kubernetes的API交互，实时感知后端Service、pod的变化，再结合Ingress策略集生成配置，然后更新反向代理负载均衡器的配置，实现动态服务发现与更新。反向代理负载均衡器对集群外流量进行负载分发。现有的Kubernetes版本已将Nginx与Ingress Controller合并为一个组件Nginx-Ingress-Controller，无需单独部署Nginx。但Kubernetes原生Ingress是一个七层负载均衡技术，仅适用于http服务。另外，其并未解决Kubernetes环境下，不同租户的服务隔离问题。

3 F5容器服务发布方案及实践

随着容器技术的发展，在应用容器化、微服务化的趋势下，F5公司基于多年在负载均衡领域的经验推出了Kubernetes容器服务解决方案，既兼顾了容器环境下应用随时可能启停、迁移等灵活性要求，又具备传统F5稳定、安全、高性能等特性。

F5容器服务解决方案实现了容器的南北向服务更加灵活的发布能力。相对于开源方案具备以下优势。

简化的架构：目前开源方案中，在业务量增大后，需要在容器外部再部署负载均衡设备来实现node级的扩展，而F5的方案只需要通过一组设备就可以实现pod或node级的扩展，简化结构，方便使用。
广泛的应用场景：目前开源方案只能支持七层应用的分发对用户的使用场景有所限制；F5的方案可以支持四、七层方案，可以满足用户绝大部分的使用场景。
灵活的发布能力：开源方案使用node的IP地址进行发布，发布场景受到很大限制；F5方案中VS（VirtualServer）地址可以使用用户规划的任意网络地址进行发布，实现灵活部署的需要。
增强的应用交付能力：开源方案在应用交付的算法、健康检查等都比较简单；F5方案中提供了19种负载均衡算法、38种健康检查、11中会话保持方法，丰富的方法方便用户各种应用的灵活配置。
监控能力：开源方案实现了基本分发功能，但监控能力很弱，对数据流以及业务的监控很有限。F5方案中，可以通过本身的HSL功能实现最高每秒20万日志的发送，同时可以配合requestlog或irules方式可以读取到所有应用层数据，方案网络故障排除及系统层分析，为大数据平台提供数据支撑。
安全防护能力：F5本身提供了大量的安全功能，包括SSL、访问控制、应用防护等。开源方案只提供了基本的应用分发功能，没有安全功能扩展。

该解决方案包含2个组件，VE（Virtual Edition）和CC（Container Connector）。VE是F5LTM的软件化商业产品，可以安装在虚拟机或者物理机上，其功能与硬件设备完全一致。CC是F5解决方案的一个关键组件，为用户提供了企业级支撑，同时也是开源产品，用户可以根据自己的需要对CC进行功能扩展。它以容器的形式部署在Kubernetes集群中，通过读取Kubernetes API获取集群内的服务资源并将其转化为VE上的配置。管理员可以为每一个租户部署一组CC，每组CC独立控制VE上的一个对象配置隔离区域（partition），该partition下的资源完全由该组CC独立控制。该方案中，负载均衡策略的定义可以由多种方式实现，可以使用Ingress，也可以使用ConfigMap。

图1 组件调用关系

民生银行经过前期技术预研，选择F5 CC+VE方案，利用CC与Kubernetes进行API交互，实现与容器平台的联动，满足容器应用的灵活性需求；配置上采用ConfigMap进行负载均衡策略下发，实现在Kubernetes层面进行F5策略配置工作；网络架构上采用VE直接对集群中的pod进行负载分发，减少网络层次，提升负载均衡性能；同时，通过将Kubernetes的namespace与VE的partition映射，实现不同容器租户负载均衡资源的隔离。

3.1网络部署方案

目前，民生银行Kubernetes环境采用的是Flannel VXLAN网络模型，容器网络由Flannel负责分配与管理，不同节点上的容器间互访由Flannel自动化管理各个节点上的路由表、ARP表及FDB表。本方案中，F5 VE是以虚拟Kubernetes node节点加入到集群，需要配置VXLAN网络信息，这些网络信息会被Flannel同步到各个节点。同时，CC从Flannel获得其它容器的网络信息后传递给VE，VE上生成相应的表项后，实现与容器之间直接通信。

图2 网络部署图

3.2 服务发布方案

在服务发布上，通过部署YAML文件方式进行发布，操作均在Kubernetes管理平台上进行，可采取的形式如下：

基于VE资源属性的ConfigMap方式进行发布，此发布模式下，根据VE定义的ConfigMap资源属性进行发布，VSIP，健康检查，负载均衡算法等均在该ConfigMap中定义。ConfigMap方式支持以下类型的发布：
- 像传统F5部署一样部署所有高级应用交付特性（iApp）
- 发布L4类型业务
- 发布L7类型业务
- 应用WAF安全特性
基于Ingress的发布，实现基于L7策略的发布。
发布UnattachedPool，此场景主要用于有自动化分配VS地址需求的场景。

同时，对于上述网络模型下，也支持通过VE FQDN技术实现headless服务的自动化发现，通过在Kubernetes内发布标准的headless服务，容许VE访问Kubernetes内置的DNS服务，即可实现通过域名自动化发现相关endpoints到VE中，实现更加灵活的自定义发布：

图3 F5 VE FQDN配置

3.3 资源隔离方案

在Kubernetes内不同的namespace（以下简称NS）隔离不同的资源对象时，管理员为每个NS创建一组 CC，监视NS内的资源对象，并将其发布到同一个VE的不同partition上或者不同的VE上，以达到资源隔离的目的。

图4 k8s namespace和F5 partition关系

对于业务访问量相对较小的环境，可以选择复用VE，不同NS对应不同的partition，提高资源的利用效率。随着业务规模的扩大，可以采用不同NS对应不同的VE的方案进行扩容。

4 实际应用效果与收益

本节以某项目为例，介绍本方案在落地场景中探索使用的应用效果和收益。该项目为典型三层架构体系，在Web区和App区均部署了高可用的F5 VE用于服务发布。实施效果与收益如下：

4.1 实现F5设备动态感知容器服务能力

通过部署在Kubernetes租户内的F5 CC动态感知容器服务的变化，解析服务创建以及销毁事件，动态更新F5 VE设备，实现服务自动发现，动态感知能力。以此来支持应用弹性伸缩能力。

初始状态：

弹性伸缩（增加replicas数量）：

kubectl scale --replicas=3 deployment/nginx-server -n scfp

扩容后状态：

4.2 实现F5到pod的负载转发能力

通过F5 VE和Kubernetes集群建立的VXLAN网络，实现了VE服务直接访问pod的能力，如下图：

通过实现以上功能，减少了NodePort的服务器端口独占以及端口不足的问题，同时减少了NodePort方式下对kube-proxy的依赖。

4.3 实现负载均衡多租户能力

在F5 VE方案中通过伪host定义、CC定义、F5 VE下发策略等配置明确定义了F5 VE租户（partition）和Kubernetes租户（namespace）之间的一对一关系，实现了F5 VE和Kubernetes的多租户联动支持能力。为F5 VE设备在容器环境下租户化运营提供了基础。

如下图所示，在实际应用场景下，Kubernetes租户是scfp，F5 VE partition是scfp_partition。

所有Kubernetes的scfp租户下发布的服务，对应在F5 VE上的转发策略，仅在scfp_partition下可见。

4.4 实现F5设备在容器环境下的自服务能力

F5 VE在实现租户安全的前提下，实现了通过Kubernetes原生语义ConfigMap定义F5 VE负载均衡策略，通过Kubernetes的命令行实现F5设备规则的配置管理能力，实现了在租户内F5资源的自服务能力。

4.5 丰富容器环境下负载均衡算法

通过引入F5，丰富了容器环境中的负载均衡算法。在ConfigMap中的balance字段可以实现负载均衡转发算法的选择，默认是round-robin，除此之外还有18种算法。在实际应用中，我们采用的是least-connections-member算法，如下图所示：

综上所述，我们对Kubernetes的容器管理能力和F5的负载转发能力进行强强联合，在实际应用中充分利用F5 VE、F5 CC在应用系统交付、配置自动化、应用系统弹性伸缩等方面的特性，取得了显著效果。

5 总结

本文我们对Kubernetes服务发布能力以及F5提供的VE+CC服务发布能力进行介绍及比较分析，并对F5 VE+CC方案的效果及收益进行详尽阐述。

后续我们将依托F5 VE+CC自身具备的数据深度挖掘能力，在容器业务级探测、容器应用性能监控、容器应用数据可视化等方面进行更多的探索和分享。另外，F5 VE+CC作为云服务能力，我们会在后续工作中逐步完善，更好的以租户化、服务化的方式满足应用弹性伸缩、蓝绿发布、灰度发布等需求。

作者信息

李高：任职民生银行网络管理中心，负责数据中心网络规划、建设及相关运维工作。现主要负责民生银行云环境下SDN网络的技术研究及整体规划建设工作。
张寿元：任职民生银行云技术管理中心，高级工程师，负责行内云平台建设、落地工作，之前负责行内中间件系统运维工作，超过十五年的IT经验，熟悉软件开发，运维管理等。
王全：任职民生银行网络管理中心，负责行内数据中心网络规划、建设、运维等工作，在应用交付/负载均衡技术领域具有十年以上的研究及实践经验。目前在云计算、SDN网络环境下的自动化运维、应用数据智能分析方面进行积极的探索和实践。
卢宇亮：任职民生银行云技术管理中心，负责云平台研发和推广工作。毕业于北京理工大学，先后从事DevOps、云计算、微服务领域的产品研发和技术研究工作。
刘婉辉：任职民生银行云技术管理中心，负责行内云平台落地、推广等工作，目前致力于容器及容器编排技术研究以及云平台运维管理等。

创作场景

民生银行：基于 F5 技术实现 Kubernetes 生产环境最佳实践