k8s 裸金属集群部署metalLB软负载均衡 —— 筑梦之路

metalLB 官方网站

Repo：https://github.com/metallb/metallb

官网：https://metallb.universe.tf/installation

metalLB解决什么问题？

MetalLB 是一个用于裸机 Kubernetes 集群的负载均衡器实现，使用标准路由协议。

k8s 并没有为裸机集群实现负载均衡器，因此我们只有在以下 IaaS 平台（AliCloud, AWS, Azure）上才能使用 LoadBalancer 类型的 service。

因此裸机集群只能使用 NodePort 或者 externalIPs service 来对面暴露服务，然而这两种方式和 LoadBalancer service 相比都有很大的缺点。

前提条件

 MetalLB 要求如下：

• 一个 Kubernetes 集群, Kubernetes 版本 1.13.0+, 没有网络负载均衡器功能；

• 可以与 MetalLB 共存的集群网络配置；

• 一些供 MetalLB 分发的 IPv4 地址；

• 当使用 BGP 操作模式时，您将需要一台或多台能够发布 BGP 的路由器；

• 使用 L2 操作模式时，节点之间必须允许 7946 端口（TCP 和 UDP，可配置其他端口）上的流量，这是 hashicorp/memberlist 的要求。

原理说明

   在公有云的 Kubernetes 集群中, 你申请一个负载均衡器, 云平台会给你分配一个 IP 地址. 在裸金属集群中, MetalLB 来做地址分配。

  MetalLB 不能凭空造 IP, 所以你需要提供供它使用的 IP 地址池. 在 Service 的创建和删除过程中, MetalLB 会对 Service 分配和回收 IP, 这些都是你配置的地址池中的 IP.

如何获取 MetalLB 的 IP 地址池取决于您的环境。如果您在托管设施中运行裸机集群，您的托管服务提供商可能会提供 IP 地址供出租。在这种情况下，将租用例如 /26 的 IP 空间（64 个地址），并将该范围提供给 MetalLB 以用于集群服务。

 工作模式

   MetalLB 是裸机 Kubernetes 集群的负载均衡器实现，使用标准路由协议，主要用于暴露 K8s 集群的服务到集群外部访问，MetalLB 可以让我们在 K8s 集群中创建服务类型为 LoadBalancer 的服务，并且无需依赖云厂商提供的LoadBalancer。

它具有两个共同提供此服务的工作负载：地址分配（address allocation）和外部公告（external announcement），对应在 K8s 中部署的 controller 和 speaker。

• address allocation：地址分配这个功能比较好理解，首先我们需要给 MetalLB 分配一个 IP 段，接着它会根据K8s 的 Service 中的相关配置来给 LoadBalancer 的服务分配 IP，LoadBalancer 的 IP 可以手动指定，也可以让 MetalLB 自动分配。地址分配主要就是由作为 Deployment 部署的 controller 来实现，它负责监听集群中的 Service 状态并且分配 IP。

• external announcement：外部公告的主要功能就是要把服务类型为 LoadBalancer 的服务的 EXTERNAL-IP 公布到网络中去，确保客户端能够正常访问到这个 IP。MetalLB 对此的实现方式主要有三种：ARP/NDP 和 BGP，其中ARP/NDP 分别对应 IPv4/IPv6 协议的 Layer2 模式，BGP 路由协议则是对应 BGP 模式。外部公告主要通过由 DaemonSet 部署的 speaker 来实现，它负责在网络中发布 ARP/NDP 报文或者是和 BGP 路由器建立连接并发布BGP 报文。

  不管是 Layer2 模式还是 BGP 模式，两者都不使用 Linux 的网络栈，也就是说我们没办法使用诸如 ip 命令之类的操作准确的查看 VIP 所在的节点和相应的路由，相对应的是在每个节点上面都能看到一个 kube-ipvs0 网卡接口上面的IP。同时，两种模式都只是负责把 VIP 的请求引到对应的节点上面，之后的请求怎么到达 pod，按什么规则轮询等都是由kube-proxy 实现的。

  Layer 2 中的 Speaker 工作负载是 DaemonSet 类型，在每台节点上都调度一个 Pod。首先，几个 Pod 会先进行选举，选举出 Leader，Leader 获取所有 LoadBalancer 类型的 Service，将已分配的 IP 地址绑定到当前主机的网卡上。也就是说，所有 LoadBalancer 类型的 Service 的 IP 同一时间都是绑定在同一台节点的网卡上。

如何部署

 1. 环境说明

实验环境：

• 1、k8s version：v1.27.4

• 2、containerd：v1.6.22

   部署 Layer2 模式需要把 K8s 集群中的 ipvs 配置打开 strictARP，开启之后 K8s 集群中的 kube-proxy 会停止响应 kube-ipvs0 网卡之外的其他网卡的 arp 请求，而由 MetalLB 接手处理。我们只需要在 K8s 集群中编辑kube-proxy 配置即可。

注意：当前集群为v1.27.4，默认已经是ipvs模式了。

kubectl edit configmap -n kube-system kube-proxy
#搜索ipvs33     ipvs:34       excludeCIDRs: null35       minSyncPeriod: 0s36       scheduler: ""37       strictARP: true        #新增38       syncPeriod: 0s39       tcpFinTimeout: 0s40       tcpTimeout: 0s41       udpTimeout: 0s42     kind: KubeProxyConfiguration43     metricsBindAddress: ""44     mode: ipvs            #默认ipvs

 2. 使用 Layer2 模式，直接使用下面的命令一键安装即可

wget https://raw.githubusercontent.com/metallb/metallb/v0.13.9/config/manifests/metallb-native.yamlkubectl apply -f metallb-native.yaml

3. 检查验证

kubectl get pods -n metallb-system -owide

  对于 2 层模式的配置使用是最简单的，因为不需要什么特定的协议配置，只需要 IP 地址即可。L2模式不需要将 IP 与你的工作节点的网络接口绑定，它的工作方式是直接响应你本地网络上的 ARP 请求，把机器的 MAC地址给客户端。

4. 配置metalLB

 

  要 Layer2 模式进行配置，需要创建一个 IPAddressPool 资源对象，用来指定用于分配的 IP 池，这部分一定要在 DHCP 服务器上做 IP 资源的保留，以防止IP被再次分配，造成异常；

比如我们这里创建如下所示的一个分配给 LB 的 IP 池对象：

cat ip-pool.yaml
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:name: ip-poolnamespace: metallb-system
spec:addresses:- 192.11.182.222-192.11.182.226        #分配给LB的IP池

 注意：我们可以看出 MetalLB 的二层模式是非常简单的（另一种 BGP 模式需要路由器支持），只要保证 IP 地址池与集群是同一个网段即可。

接着，需要创建一个广播声明，可以关联上面的 IP 池对象，这样会使用关联的 IP 池地址。为了通告来自 IPAddressPool 的 IP，L2Advertisement 实例必须关联到 IPAddressPool。 

cat advertise.yaml
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:name: l2advernamespace: metallb-system
spec:ipAddressPools:- ip-pool

kubectl apply -f ip-pool.yamlkubectl apply -f advertise.yaml

5. 部署测试

cat demoLB.yaml
apiVersion: v1
kind: Service
metadata:name: demo-svc
spec:selector:app: demoports:- protocol: TCPport: 80targetPort: 80type: LoadBalancer    #此处必需为 LoadBalancer
---
apiVersion: apps/v1
kind: Deployment
metadata:name: demo-dep
spec:replicas: 2selector:matchLabels:app: demotemplate:metadata:labels:app: demospec:containers:- name: demoimage: nginx

kubectl apply -f demoLB.yaml

总结

MetalLB 的二层模式是非常简单的（另一种 BGP 模式需要路由器支持），只要保证 IP 地址池与集群是同一个网段即可。当然缺点也很明显：

• 所有的流量都会在同一个节点上，该节点的容易成为流量的瓶颈，当 VIP 所在节点宕机之后，需要较长时间进行故障转移（一般在 10s），这主要是因为 MetalLB 使用了memberlist 来进行选主；

• 当 VIP 所在节点宕机之后重新选主的时间要比传统的 keepalived 使用的 vrrp 协议要更长，难以定位 VIP 所在节点；

• MetalLB 并没有提供一个简单直观的方式让我们查看到底哪一个节点是 VIP 所属节点，基本只能通过抓包或者查看 pod 日志来确定，当集群规模变大的时候这会变得非常的麻烦；

• 所以有条件的可以考虑使用 BGP 模式。