1.概念
MetalLB 会在 Kubernetes 内运行，监控服务对象的变化，一旦监测到有新的 LoadBalancer 服务运行，并且没有可申请的负载均衡器之后，就会完成地址分配和外部声明两部分的工作。
2.地址分配
在云厂商提供的 Kubernetes 集群中，Service 声明使用 LoadBalancer时，云平台会自动分配一个负载均衡器的IP地址给你，应用可以通过这个地址来访问。
使用 MetalLB 时，MetalLB 会自己为用户的 LoadBalancer 类型 Service 分配 IP 地址，当然该 IP 地址不是凭空产生的，需要用户在配置中提供一个 IP 地址池，Metallb 将会在其中选取地址分配给服务。
3.外部声明
一旦 MetalLB 为服务分配了IP地址，它需要对外宣告此 IP 地址，并让外部主机可以路由到此 IP。
外部声明有两种模式：
Layer 2 模式
BGP 模式
1、Layer 2 模式
Layer 2 模式下，每个 Service 会有集群中的一个 Node 来负责。服务的入口流量全部经由单个节点，然后该节点的 Kube-Proxy 会把流量再转发给服务的 Pods。也就是说，该模式下 MetalLB 并没有真正提供负载均衡器。尽管如此，MetalLB 提供了故障转移功能，如果持有 IP 的节点出现故障，则默认 10 秒后即发生故障转移，IP 会被分配给其它健康的节点。
优缺点：
优点：
是它的通用性：它可以在任何以太网网络上运行，不需要特殊的硬件。
缺点：
Layer 2 模式下存在单节点瓶颈，服务所有流量都经过一个Node节点。这意味着服务的入口带宽被限制为单个节点的带宽。
由于 Layer 2 模式需要 ARP/NDP 客户端配合，当故障转移发生时，MetalLB 会发送 ARP 包来宣告 MAC 地址和 IP 映射关系的变化，地址分配略为繁琐。
2、BGP 模式
BGP 模式下，集群中所有node都会跟上联路由器建立BGP连接，并且会告知路由器应该如何转发service的流量。
优缺点：
优点：
BGP模式下才是一个真正的 LoadBalancer，通过BGP协议正确分布流量，不再需要一个Leader节点。
缺点：
不能优雅处理故障转移，当持有服务的节点宕掉后，所有活动连接的客户端将收到 Connection reset by peer。
需要上层路由器支持BGP。而且因为BGP单session的限制，如果Calico也是使用的BGP模式，就会有冲突从而导致metallb无法正常工作。
4.环境要求
Kubernetes 1.13.0 版本或更高版本的集群。
Kubernetes 集群网络组件需要支持 MetalLB 服务，具体参考: https://metallb.universe.tf/installation/network-addons/
MetalLB 需要能分配IPv4地址。
根据操作模式的不同，可能需要一个或多个能够使用BGP的路由器。
参考文件（两个部署文件结合参考）：
https://blog.csdn.net/weixin_43357497/article/details/109056990
https://article.itxueyuan.com/Zo8enW
https://www.cnblogs.com/fengjian2016/p/11936651.html
部署如下：
1.kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.8.3/manifests/metallb.yaml
2.创建configmap,用于指定ip地址池
3.创建自定义svc(type类型为loadbanlance,会选取ip地址池中ip)和deployment,每要新建不同的服务，都需要指定不同的svc和deployment（上面两步是固定的）