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 数量）：
扩容后状态：
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、云计算、微服务领域的产品研发和技术研究工作。
刘婉辉：任职民生银行云技术管理中心，负责行内云平台落地、推广等工作，目前致力于容器及容器编排技术研究以及云平台运维管理等。
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论