一、背景介绍

外部硬件负载均衡作为容器业务统一入口的架构模式已在我行运行3年之久，通过长时间的容器云平台使用经验与负载均衡运维经验积累，在我行容器云环境形成一套特有的负载均衡适配模型，现部署模式下实现了应用上线人员以自服务的形式将容器服务对外暴露。根据2022年1月银保监会办发[2022]2号中关于科技能力建设的指导意见，坚持关键技术自主可控原则，降低外部依赖、避免单一依赖。为配合推进指导意见，同时考虑到容器云平台适配再开发成本，网络架构模型的改造成本，信创负载均衡选型便基于现模型进行。

二、环境介绍

1、网络部署模型如下：

我行现有容器云集群规模较小，一组主、备部署的负载均衡设备与SND border组建EBGP邻居，在负载均衡的configmap yaml文件中加入路由宣告的配置，将负载均衡的VIP以BGP动态路由形式宣告至border，border接收的路由VIP路由条目下一跳自动会被置为负载均衡的floating IP，设备主备切换时宣告的下一跳不会变更，消除了路由收敛带来的影响。同时，容器云集群pod ip通过calico BGP对外宣告，满足全网可达条件。负载均衡设备默认不接收pod ip等BGP邻居宣告的外部路由，通过将默认路由指向border寻址pod ip，减少应用负载均衡在非“本职”能力上的性能消耗。

负载均衡侧BGP配置：

access-list int-ipv4 permit 10.x.x.x/16
!
ipv6 access-list int-ipv6 permit fdx:x:x:x::/64
!
router bgp 6x
bgp router-id 10.x.x.x
bgp graceful-restart restart-time 120
redistribute kernel route-map int-ipv4
neighbor 10.x.x.x remote-as 6x
neighbor 10.x.x.x remote-as 6x
neighbor 10.x.x.x ebgp-multihop 2
neighbor 10.x.x.x next-hop-self
neighbor 10.x.x.x remote-as 6x
neighbor 10.x.x.x ebgp-multihop x
neighbor 10.x.x.x next-hop-self
neighbor fdxx:x:x:x::x remote-as 6x
neighbor fdxx:x:x:x::x remote-as 6x
neighbor fdxx:x:x:x::x ebgp-multihop x
neighbor fdxx:x:x:x::x next-hop-self
neighbor fdxx:x:x:x::x remote-as 6x
neighbor fdxx:x:x:x::x ebgp-multihop x
neighbor fdxx:x:x:x::x next-hop-self
!
address-family ipv6
redistribute kernel route-map int-ipv6
neighbor fdxx:x:x:x::x activate
neighbor fdxx:x:x:x::x activate
neighbor fdxx:x:x:x::x activate
exit-address-family
!
route-map int-ipv4 permit 10
match ip address int-ipv4
!
route-map int-ipv6 permit 20
match ipv6 address int-ipv6
!

2、业务发布模型如下：

通过积累传统负载均衡多年运维经验，归纳总结出三大类适配我行业务发布逻辑的容器负载均衡业务策略发布模型，分别为：TCP模式、TCP快速转发模式、HTTP模式，在TCP模式可扩展为FTP协议模式，HTTP 模式中可扩展在http header中插入客户端源地址及使用cookie加密会话保持功能，如web应用类业务使用HTTP模式、综合前置业务使用TCP快速转发模式、Ftp类业务使用TCP模式等，由上线人员通过容器云管平台自行选择业务发布场景，容器云管平台自动生成负载均衡的configmap发布到容器云，再由负载均衡的控制pod识别configmap文件并发送到容器云集群外部的负载均衡设备，在设备上自动生成负载均衡策略配置，形成一条完整全自动对外服务暴露的流水线。

TCP应用场景模型，包含开启VIP路由宣告：

apiVersion: v1
kind: ConfigMap
metadata:
  name: f5-hello-tcp-8080
  namespace: twt-test
  labels:
    f5type: virtual-server
    as3: "true"
data:
  template: |
    {
      "class": "AS3",
      "action": "deploy",
      "persist": true,
      "declaration": {
        "class": "ADC",
        "schemaVersion": "3.21.0",
        "id": "f5-twt-L7-ex",
        "remark": "f5-twt-L7-ex",
#### F5上租户名字，对应SVC中的cis.f5.com/as3-tenant: tenant_twtnginx
        "tenant_twtnginx": {
          "class": "Tenant",
####对应SVC中的cis.f5.com/as3-app: app_twtnginx
          "app_twtnginx": {
            "class": "Application",
            "template": "generic",
####VS名称需按照域名加端口形式命名
            "twt-8080": {
####TCP协议使用4层转发模式，https也采用该模式
              "class": "Service_L4",
####remark里需自动绑定namespace名称，用于监控平台自动将策略绑定到应用系统及pool up/down告警接收人
              "remark": "ns名称",
              "virtualAddresses": [
                {
####声明虚地址，在调用class service_address中内容
                "use":"twt-L4"
                }
              ],
####声明对外发布端口
              "virtualPort": 8080,
####声明pool名称，在调用class pool中内容
              "pool": "pool_twtnginx",
              "snat": "auto",
              "persistenceMethods": []
            },
####对应SVC中的cis.f5.com/as3-pool: pool_twtnginx
            "pool_twtnginx": {
              "class": "Pool",
####负载均衡算法需采用基于member的最小连接数
              "loadBalancingMode": "least-connections-member",
              "monitors": [{
####健康检查调用定制的健康检查
                "use":"tcp-twt"
              }],
              "members": [{
####发布的pod端口
                "servicePort": 80,
####地址为自动识别的pod ip，pod自动扩缩容也会自动做出变化
                "serverAddresses": []
              }]
            },
####配置发布的虚地址
            "twt-L4": {
              "class": "Service_Address",
####设置虚地址
              "virtualAddress": "10.xxx.xxx.xxx",
              "arpEnabled": true,
              "icmpEcho": "enable",
####架构采用BGP动态路由，必须开启路由宣告，保持默认always
              "routeAdvertisement": "always",
              "spanningEnabled": false
            },
####定制专用tcp健康检查
            "tcp-twt": {
            "class": "Monitor",
####健康检查类型为tcp
            "monitorType": "tcp",
####根据应用填写tcp检查方式，发送应用可处理的字符串
            "send": "esb00101",
####返回内容必须为tcp正常返回字符
            "receive": "000"
            }
          }
        }
      }
}

三、难点

（1）服务对外暴露难点：我行容器业务对外暴露标准必须使用容器负载均衡，负载策略发布模式由传统负载均衡管理员上线转变成开发人员自服务形式，负载设备管理员如何将策略场景化，使得负载策略自服务简单、易用成为关键点。

（2）信创选型难点：信创负载市场百花齐放，信创选型既要解决当前非信创容器负载所面临的问题，又要适配当前环境考虑周边成本。

四、信创负载均衡信创选型

结合我行实际情况，为实现业务应用的全面自主可控，在2023年开始在信创负载均衡领域进行探索，适配现部署架构模型，充分考虑现有业务与未来业务需求并结合金融行业对信创负载均衡的使用与管理需求，邀请多家厂商开展入场POC测试，评价模型中的10个必要评价维度逐级细分为189个测试评价项，分为传统负载均衡和容器负载均衡部分测试，性能测试放在传统负载均衡测试中，重复性较强就不再赘述，以下主要是容器负载均衡相关测试项。

考虑到我行未来可能部署超大规模的容器集群，除容器环境负载均衡必备的基本功能外，附加测试多个现架构下未使用的功能。（负载均衡部署在容器云的控制pod以下简称为cc（container controler））

超大规模集群的容器集群反馈到容器负载均衡为配置策略数量的庞大，由于需要cc需要同步配置到容器负载均衡，cc原则上就是pod扩容性能比较容易，而容器负载均衡属于硬件商用设备，管理进程的性能会受限制且能够扩容的性能有限，此外容器负载均衡同时兼顾处理监控平台获取设备状态、策略策略状态等工作时也会占用部分管理核cpu的处理能力，容器负载均衡将成为管理性能瓶颈。虽然只是会影响业务pod滚动更新、扩缩容、新策略上线、修改等平台操作时负载均衡配置变化时的速度，但也会直接影响业务上线及灾难事件恢复的速度。

解决该问题，控制策略数量成为关键点。负载均衡策略在单组设备以策略数量或承载系统数量的容量管理方式进行控制，单组设备策略数量或承载系统数量达到一定规模时，进行设备和cc扩容，新建的cc识别特定标签进行配置同步，该方式在容器云集群到达一定规模时使用多个cc进行分摊，识别标签同时避免了cc识别namespace name方式在容器集群规模过大时导致cc的配置文件过长及新的ns上线时频繁更新cc配置文件。

1.多组负载均衡对接单集群模式

cc配置如下：

2.运维性能测试

此项测试主要面向单台设备策略的容量管理，配置下发、获取、修改耗时涉及到的管理核cpu使用率，明确单台设备的负载均衡策略部署达到什么量级时进行扩容：

五、总结与展望

通过POC测试，明确了信创负载均衡在我行容器架构下的适配程度，为我行打造全链路自主可控基础设施支撑业务的目标做准备，及在未来超大规模容器集群的背景下，作为业务唯一入口的负载均衡设备该如何应对。

非信创负载均衡设备在我行已使用多年，运维人员积累的丰富的管理经验，并结合我行自动化运维平台形成了一套完整的运维体系。在自主可控的方针的指导下，未来我行数据中心将存在多种信创传统、容器应用负载均衡设备，针对设备产品、设计架构的差异，运维平台模型需针对多种信创负载均衡设备进行适配、重构，以实现统一管理、统一监控、统一自动化、统一数据采集的负载均衡运维体系。