在Kubernetes集群中部署MetalLB实现负载均衡

概述

在公有云部署的kubernetes集群中，有公有云厂商提供LoadBalancer类型的Service。但是在基于本地环境部署的k8s集群是我们常用的测试环境和开发环境；需要通过NodePort和externalIPs方式将外部流量引入集群中，这就带来了很多的不便。

尤其是我们通过helm去部署一些服务时，尝尝会依赖于LoadBalancer的资源类型，导致创建的services中type: LoadBalancers会一直处于Pending状态；我们不得不进行仓库的fetch，然后手动进行values的修改。

Metallb 通过标准路由协议能解决该问题。MetalLB 也是 CNCF 的沙箱项目，最早发布在
https://github.com/google/metallb 开发，后来迁移到 https://github.com/metallb/metallb 中。

MetalLB 通过 MetalLB hooks 监听SVC的变化；然后通过Speaker组件采用对应的模式将外部流量引流到kubernetes集群node节点的可达路径。而具体到Pod中则是通过kuber-proxy依据转发模式(iptables或ipvs)将流量转发到Pod中。

MetaLB负责从主机维度实现负载均衡，而pod副本间的负载是通过kube-proxy实现。MetalLB负责IP地址分配、依据设定的广播模式进行广播、节点选举、节点失效切换等功能。而引流的过程则通过ARP、NDP和BGP标准路由协议实现。

主要的两大功能：

1. 地址分配：用户需要在配置中提供一个地址池，Metallb 将会在其中选取地址分配给服务。
2. 地址广播（IP外部声明）：根据不同配置，Metallb 会以二层（ARP/NDP）或者 BGP 的方式进行地址的广播。

工作模式：

1. BGP模式（Layer 3），使用BGP协议分配地址池；运行 BGP 的设备之间可以交换路由信息，我们可以将自己的 IP 段通过 BGP 协议告诉其他设备，这样其他设备就能正确的路由数据包到服务器上了。BGP 需要路由器的支持。如果Calico也是使用的BGP模式，有可能会有冲突从而导致metallb无法正常工作。
2. ARP（IPV4）/NDP(IPV6)工作模式（Layer2）；使用 ARP/NDP 协议分配地址池；在服务器的内部子网里找未使用的 IP，然后等其他电脑访问这个 IP 的时候，我们回应一个 ARP 包，其他电脑就知道这个 IP 在哪里可以通信了，尽管这个 IP 其实没有绑定到任何网卡上，也有可能只是 iptables 里的一条记录。分配的 IP 只能和服务器其他 IP 位于同一子网，这就要求我们所有的节点必须在同一个二层网络内。

更多详情请参考官方文档：https://metallb.universe.tf/。

架构

二层部署的架构图，参考红帽openshift官方文档。

上图显示了与 MetalLB 相关的以下概念：

• 应用程序可以通过在 172.130.0.0/16 子网上具有集群 IP 的服务获取。该 IP 地址可以从集群内部访问。服务也有一个外部 IP 地址，用于分配给服务的 MetalLB，即 192.168.100.200。
• 节点 1 和 3 具有应用程序的 pod。
• speaker 守护进程集在每个节点上运行一个 pod。MetalLB Operator 启动这些 pod。
• 每个 speaker pod 都是主机网络的 pod。容器集的 IP 地址与主机网络上节点的 IP 地址相同。
• 节点 1 上的 speaker pod 使用 ARP 声明服务的外部 IP 地址 192.168.100.200。声明外部 IP 地址的 speaker pod 必须与服务的端点位于同一个节点上，端点必须为 Ready 条件。
• 客户端流量路由到主机网络，并连接到 192.168.100.200 IP 地址。在流量进入节点后，服务代理会根据您为服务设置的外部流量策略，将流量发送到同一节点上的应用 pod 或其他节点。
• 如果节点 1 不可用，则外部 IP 地址将故障转移到另一节点。在具有应用 pod 和服务端点实例的另一个节点上，speaker Pod 开始宣布外部 IP 地址 192.168.100.200，新节点接收客户端流量。在图中，唯一的候选项是节点 3。

部署

环境要求

集群版本信息如下：

支持MetalLB的CNI如下：

注意事项：

• 参考 CLOUD COMPATIBILITY https://metallb.universe.tf/installation/clouds/ 查看你的环境是否支持 MetalLB
• 使用 BGP 工作模式时，需要一台或多台支持 BGP 的路由器
• 由于第 2 层模式依赖于 ARP 和 NDP，客户端必须位于没有中断服务的节点所在的同一子网，以便 MetalLB 正常工作。另外，分配给该服务的 IP 地址必须在客户端用来访问该服务的网络所在的同一子网中。
• 使用 L2 工作模式时，所有的节点必须在同一个二层网络内；必须允许节点之间通过 7946 端口（TCP & UDP，可以配置其他端口）通信，memberlist服务监听在该端口；二层模式不需要将 IP 绑定到工作节点的网络接口上。它的工作原理是直接响应本地网络上的 ARP 请求，将本机的 MAC 地址提供给客户端
• 从 Kubernetes v1.14.2 开始，若 kube-proxy 使用 IPVS 模式，需要开启 strict ARP （严格的ARP）模式，使用 kubectl edit configmap -n kube-system kube-proxy 修改如下：

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "ipvs"
ipvs:
  strictARP: true

通过helm安装

MetalLBKubernetes manifests、Kustomize 和 Helm 三种安装方式；这里我们采用helm安装：

$ helm repo add metallb https://metallb.github.io/metallb
 $ helm search repo -l metallb
 $ helm fetch metallb/metallb --version=0.13.4
 $ tar zxvf metallb-0.13.4.tgz
 #这里我们可以根据自己的需求进行values值的修改，例如原镜像地（quay.io）址无法拉取，我们可以先拉取然后上传到自己的镜像仓库，然后修改地址
 $ kubectl create namespace metallb-system
 $ helm install metallb -n metallb-system ./metallb

验证安装，如下图所示

在metallb-system的namespace下，会安装两个组件：

• controller deployment：负责监听service资源的变化；依据对应的IP地址池进行IP地址分配的控制器。
• speaker daemonset：负责监听service资源的变化；通过protocols维护服务间联通，并依据具体的协议发起对应的广播和应答、以及节点leader的选举。

speaker pod 响应 IPv4 服务和 IPv6 的 NDP 请求。

通过manifest安装

要安装 MetalLB，使用yaml应用清单：

$ kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.13.4/config/manifests/metallb-native.yaml

配置

由于我们的集群工作在测试环境中，我们采用的是L2工作模式下。

第 2 层模式最容易上手，并且可以在任何环境中工作——不需要花哨的路由器。

定义要分给负载均衡服务的IP地址池。

新版本metallb使用了CR（Custom Resources），这里我们通过IPAddressPool的CR，进行地址池的定义。

如果实例中不设置IPAddressPool选择器L2Advertisement；那么L2Advertisement默认为该实例所有的IPAddressPool相关联。

创建metallb-config-ipaddresspool.yaml：

apiVersion: metallb.io/v1beta1
 kind: IPAddressPool
 metadata:
   name: first-pool
   namespace: metallb-system
 spec:
   addresses:
   - 192.168.74.100-192.168.74.110

进行L2关联地址池的绑定。这里也可以使用标签选择器。

创建metallb-config-L2Advertisement.yaml：

apiVersion: metallb.io/v1beta1
 kind: L2Advertisement
 metadata:
   name: example
   namespace: metallb-system
 spec:
   ipAddressPools:
   - first-pool

测试

创建类型为LoadBalancer的SVC进行测试，创建yaml文件tutorial-1.yaml：

apiVersion: apps/v1
 kind: Deployment
 metadata:
   name: nginx
   namespace: default
 spec:
   selector:
     matchLabels:
       app: nginx
   template:
     metadata:
       labels:
         app: nginx
     spec:
       containers:
       - name: nginx
         image: nginx:1
         ports:
         - name: http
           containerPort: 80
 ---
 apiVersion: v1
 kind: Service
 metadata:
   name: nginx
   namespace: default
 spec:
   ports:
   - name: http
     port: 80
     protocol: TCP
     targetPort: 80
   selector:
     app: nginx
   type: LoadBalancer

结果如下图所示：

通过浏览器进行访问：

参考网址：

• https://access.redhat.com/documentation/zhcn/openshift_container_platform/4.9/html/networking/_load-balancing-with-metallb。
• https://metallb.universe.tf/。