内容简介：在说说我的homelab里，伊布介绍了家里的homelab，其中包括了kubernetes集群的信息。这里面伊布比较不满意的是，kubernetes集群没有L4负载均衡，对外暴漏服务时，只能使用nodePort的方式，比较麻烦：必须要记住不同的端口号。前两天去上海kubeCon的时候，看到有人介绍他的树莓派集群，其中L4负载均衡使用的是metalLB，瞬间眼前一亮，这不就是伊布一直想要的东西嘛！
在说说我的homelab里，伊布介绍了家里的homelab，其中包括了kubernetes集群的信息。这里面伊布比较不满意的是，kubernetes集群没有L4负载均衡，对外暴漏服务时，只能使用nodePort的方式，比较麻烦：必须要记住不同的端口号。
前两天去上海kubeCon的时候，看到有人介绍他的树莓派集群，其中L4负载均衡使用的是metalLB，瞬间眼前一亮，这不就是伊布一直想要的东西嘛！
MetalLB 可谓是“穷人的LoadBalancer”。kubernetes本身并没有实现LoadBalancer；如果是云上用户，可以使用云服务商提供的provider；而对于bare metal的用户来说，则可以使用metalLB来达到相同的目的。
metalLB的两个核心特性：
地址分配
metalLB会为用户的load balancer类型service分配IP地址，该IP地址不是凭空产生的，需要用户预先分配。
外部声明
地址分配后还需要通知到网络中的其他主机。metalLB支持两种声明模式：
- Layer 2模式：ARP/NDP
- BGP模式
Layer 2 模式
Layer 2模式下，每个service会有集群中的一个node来负责。当服务客户端发起ARP解析的时候，对应的node会响应该ARP请求，之后，该service的流量都会指向该node（看上去该node上有多个地址）。
Layer 2模式并不是真正的负载均衡，因为流量都会先经过1个node后，再通过kube-proxy转给多个end points。如果该node故障，metalLB会迁移 IP到另一个node，并重新发送免费ARP告知客户端迁移。现代操作系统基本都能正确处理免费ARP，因此failover不会产生太大问题。
Layer 2模式更为通用，不需要用户有额外的设备；但由于Layer 2模式使用ARP/ND，地址池分配需要跟客户端在同一子网，地址分配略为繁琐。
BGP模式
BGP模式下，集群中所有node都会跟上联路由器建立BGP连接，并且会告知路由器应该如何转发service的流量。
BGP模式是真正的LoadBalancer。
metalLB部署
安装metalLB比较简单。
kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.7.3/manifests/metallb.yaml
编排文件主要部署2个组件：
metallb-system/controller metallb-system/speaker
注意，部署后，还需要根据具体的地址通告方式，配置configmap metallb-system/config
。controller会读取该configmap，并reload配置。
下面分别介绍两种模式的部署。
Layer 2模式部署
如下是Layer 2模式加的config，在伊布的环境下，为service分配的地址池是 192.168.0.10-192.168.0.100
。
将下面的编排文件使用kubectl apply到集群上去。
kind: ConfigMap
apiVersion: v1
metadata:
name: config
namespace: metallb-system
data:
config: |
address-pools:
- name: default
protocol: layer2
addresses:
- 192.168.0.10-192.168.0.100
至此，metalLB Layer 2 mode的配置就结束了。来验证下。
$ kubectl get pods nginx-68995d8957-bczhf -o wide NAME READY STATUS RESTARTS AGE IP NODE nginx-68995d8957-bczhf 2/2 Running 0 19d 10.244.0.78 ubuntu-1 $ kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx LoadBalancer 10.97.187.100 192.168.0.10 80:32353/TCP 179m
可以看到，svc nginx分配的的外部IP地址是 192.168.0.10
，这也是伊布的地址池中的第一个IP。浏览器访问 192.168.0.10
，可以正常显示nginx的页面。
metalLB是怎么做的呢？
先在客户端上看看 192.168.0.10
的ARP地址。
❯❯❯ arp 192.168.0.10 ? (192.168.0.10) at 0:c:29:f3:b2:1d on en0 ifscope [ethernet] ❯❯❯ arp ubuntu-1 ubuntu-1.lan (192.168.0.154) at 0:c:29:f3:b2:1d on en0 ifscope [ethernet]
有点意思。 192.168.0.10
的mac地址，和ubuntu-1的地址是一样的。显然，因为nginx pod是运行在ubuntu-1上的，因此当客户端发起ARP请求的时候，ubuntu-1上的speaker会应答该请求，将流量导向ubuntu-1。
去看ubuntu-1的speaker的日志，可以看到一些记录。
{"caller":"arp.go:102","interface":"ens160","ip":"192.168.0.10","msg":"got ARP request for service IP, sending response","responseMAC":"00:0c:29:f3:b2:1d","senderIP":"192.168.0.234","senderMAC":"00:22:6d:57:a2:1c","ts":"2019-06-30T04:31:29.524752775Z"}
那么报文到了ubuntu-1之后呢？伊布们来看看iptables规则。
-A KUBE-SERVICES -d 192.168.0.10/32 -p tcp -m comment --comment "default/nginx: loadbalancer IP" -m tcp --dport 80 -j KUBE-FW-4N57TFCL4MD7ZTDA -A KUBE-FW-4N57TFCL4MD7ZTDA -m comment --comment "default/nginx: loadbalancer IP" -j KUBE-MARK-MASQ -A KUBE-FW-4N57TFCL4MD7ZTDA -m comment --comment "default/nginx: loadbalancer IP" -j KUBE-SVC-4N57TFCL4MD7ZTDA -A KUBE-SVC-4N57TFCL4MD7ZTDA -j KUBE-SEP-HQ2WPKJSGAOND4TJ -A KUBE-SEP-HQ2WPKJSGAOND4TJ -s 10.244.0.78/32 -j KUBE-MARK-MASQ -A KUBE-SEP-HQ2WPKJSGAOND4TJ -p tcp -m tcp -j DNAT --to-destination 10.244.0.78:80
是不是似曾相识？对，这些规则，和nodePort类型的service的iptables规则，是类似的。
至此，Layer 2模式的metalLB就可以正常工作了。
BGP模式部署
Layer 2模式通用，不过
毕竟，将系统的可靠性依赖于免费ARP，不是一种正经的做法。
BGP模式部署，对环境有一定的要求：
得有一个可以运行BGP协议的上联交换机。
在伊布的homelab中，kubernetes的node是hp gen8上运行的虚拟机，从逻辑上来看，可以认为，各个vm是连接到WNDR4300的。因此，只要WNDR4300上可以运行bgp协议，就可以支持BGP模式部署。
伊布的WNDR4300上运行的是openwrt，这是一个完全自主可控的路由器操作系统，生态比较完善，十分推荐。
openwrt上可以运行 quagga 。 quagga 是一个unix平台下的经典路由软件套件，实现了以下路由协议：OSPFv2, OSPFv3, RIP v1 and v2, RIPng and BGP-4。在这里，伊布将使用quagga的bgp功能，来完成metalLB的BGP模式部署。
当然，如果您不想使用openwrt，也可以使用商业路由器，如UBNT ER系列，H3C/HW等厂家的路由器。
openwrt安装quagga
openwrt使用opkg来管理软件包，默认的源在国内使用比较慢，您可以使用ustc的镜像源。
修改 /etc/opkg/distfeeds.conf
：
src/gz openwrt_core http://mirrors.ustc.edu.cn/lede/releases/18.06.2/targets/ar71xx/nand/packages src/gz openwrt_base http://mirrors.ustc.edu.cn/lede/releases/18.06.2/packages/mips_24kc/base src/gz openwrt_luci http://mirrors.ustc.edu.cn/lede/releases/18.06.2/packages/mips_24kc/luci src/gz openwrt_packages http://mirrors.ustc.edu.cn/lede/releases/18.06.2/packages/mips_24kc/packages src/gz openwrt_routing http://mirrors.ustc.edu.cn/lede/releases/18.06.2/packages/mips_24kc/routing src/gz openwrt_telephony http://mirrors.ustc.edu.cn/lede/releases/18.06.2/packages/mips_24kc/telephony
需要安装 quagga、quagga-zebra、quagga-bgpd，以及用于管理的quagga-watchquagga、quagga-vtysh。
root@OpenWrt:~# opkg install quagga quagga-zebra quagga-bgpd quagga-watchquagga quagga-vtysh
安装好以后，启动quagga，启动后会监听2601、2605、179端口号。
root@OpenWrt:~# /etc/init.d/quagga start root@OpenWrt:~# netstat -antp|grep LISTEN tcp 0 0 0.0.0.0:2601 0.0.0.0:* LISTEN 23173/zebra tcp 0 0 0.0.0.0:2605 0.0.0.0:* LISTEN 23178/bgpd tcp 0 0 0.0.0.0:179 0.0.0.0:* LISTEN 23178/bgpd
openwrt配置BGP协议
从拓扑上来说，WNDR4300会跟kubernetes上的各个node建立BGP peer对，在这里伊布设置WNDR4300的AS为65000，kubernetes上各个node的AS为65009。
ssh登录到OpenWrt后，使用vtysh命令进入Quagga的命令行。配置如下。
OpenWrt# configure terminal OpenWrt(config)# router bgp 65000 OpenWrt(config-router)# neighbor 192.168.0.154 remote-as 65009 OpenWrt(config-router)# neighbor 192.168.0.154 description "ubuntu-1" OpenWrt(config-router)# neighbor 192.168.0.153 remote-as 65009 OpenWrt(config-router)# neighbor 192.168.0.153 description "ubuntu-2" OpenWrt(config-router)# neighbor 192.168.0.171 remote-as 65009 OpenWrt(config-router)# neighbor 192.168.0.171 description "ubuntu-3" OpenWrt(config-router)# neighbor 192.168.0.163 remote-as 65009 OpenWrt(config-router)# neighbor 192.168.0.163 description "x1" OpenWrt(config-router)# neighbor 192.168.0.127 remote-as 65009 OpenWrt(config-router)# neighbor 192.168.0.127 description "x201"
此时，只是配置了WNDR4300的BGP，还需要配置kubernetes上各个node的路由信息。
kubernetes上配置BGP协议
前面伊布已经安装了metalLB的controller和speaker，只是使用的是Layer 2模式。要改为BGP模式，只要修改configmap config就可以了。
apiVersion: v1
kind: ConfigMap
metadata:
namespace: metallb-system
name: config
data:
config: |
peers:
- peer-address: 192.168.0.1
peer-asn: 65000
my-asn: 65009
address-pools:
- name: default
protocol: bgp
addresses:
#- 192.168.0.10-192.168.0.100
- 192.168.9.0/24
需要注意的是，伊布重新分配了一个新的网段 192.168.9.0/24
，而没有使用Layer 2模式的 192.168.0.10-192.168.0.100
。伊布理解这是BGP模式的一个优势，完全解决了Layer 2模式ARP造成的依赖，可以使用更多更灵活的网段。
地址池修改后，svc的地址也必然需要发生变化，不过伊布在实践中发现，controller此时并不会重新分配地址，而只是报了错误，提示用户当前svc的地址不在地址池中。anyway，只要重启controller，就可以重新分配地址了。
看看当前的BGP状态。
OpenWrt# show ip bgp summary BGP router identifier 192.168.1.4, local AS number 65000 RIB entries 3, using 216 bytes of memory Peers 5, using 24 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 192.168.0.127 4 65009 651 654 0 0 0 00:25:58 2 192.168.0.153 4 65009 1111 1139 0 0 0 00:26:19 2 192.168.0.154 4 65009 652 664 0 0 0 00:26:17 2 192.168.0.163 4 65009 632 647 0 0 0 00:26:19 2 192.168.0.171 4 65009 648 670 0 0 0 00:26:19 2
可以看到，WNDR4300和kubernetes上的各个node建立了BGP邻居；查看speaker的日志，会看到如下的日志，表示BGP会话已经established了。
struct { Version uint8; ASN16 uint16; HoldTime uint16; RouterID uint32; OptsLen uint8 }{Version:0x4, ASN16:0xfde8, HoldTime:0xb4, RouterID:0xc0a80104, OptsLen:0x1e}
{"caller":"bgp.go:63","event":"sessionUp","localASN":65009,"msg":"BGP session established","peer":"192.168.0.1:179","peerASN":65000,"ts":"2019-06-30T12:54:07.707648249Z"}
controller重启后，为前面svc nginx重新分配的地址为 192.168.9.0
。来看看WNDR4300上的路由表项。
OpenWrt# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, P - PIM, A - Babel,
> - selected route, * - FIB route
K>* 0.0.0.0/0 via 192.168.1.1, eth0.2, src 192.168.1.4
K>* 119.28.4.177/32 via 192.168.1.1, eth0.2
C>* 127.0.0.0/8 is directly connected, lo
C>* 192.0.2.0/24 is directly connected, wg0
C>* 192.168.0.0/24 is directly connected, br-lan
C>* 192.168.1.0/24 is directly connected, eth0.2
B>* 192.168.9.0/32 [20/0] via 192.168.0.153, br-lan, 00:36:46
B>* 192.168.9.1/32 [20/0] via 192.168.0.153, br-lan, 00:36:46
可以看到，最后两条为BGP路由，会将 192.168.9.0
的报文转发到 192.168.0.153
。此时在客户端浏览器上访问 192.168.9.0
，会显示nginx的页面（客户端的默认路由为WNDR4300的IP地址 192.168.0.1
）。
BGP模式解析
下面来解析下BGP模式。
由于客户端的默认路由是WNDR4300的IP 192.168.0.1
，因此浏览器访问 192.168.9.0
时，报文会发送给WNDR4300。
在WNDR4300上查BGP路由，Next Hop命中 192.168.0.153
，WNDR4300将报文转发给 192.168.0.153
。
报文到 192.168.0.153
后，会命中iptables规则，将报文转发给实际Pod的EndPoint，之后的流程就跟一般访问svc类似了。
-A KUBE-SERVICES -d 192.168.9.0/32 -p tcp -m comment --comment "default/nginx: loadbalancer IP" -m tcp --dport 80 -j KUBE-FW-4N57TFCL4MD7ZTDA
可见，报文经路由器转发后，实际仍然是由kubernetes上的一个node进行集群内部的转发的，这一点与Layer 2模式类似。
failover
那么，如果 192.168.0.153
故障了呢？来详细查看下WNDR4300上的bgp路由。
OpenWrt# show ip bgp
BGP table version is 0, local router ID is 192.168.1.4
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* 192.168.9.0/32 192.168.0.127 0 65009 ?
* 192.168.0.154 0 65009 ?
*> 192.168.0.153 0 65009 ?
* 192.168.0.163 0 65009 ?
* 192.168.0.171 0 65009 ?
* 192.168.9.1/32 192.168.0.127 0 65009 ?
* 192.168.0.154 0 65009 ?
*> 192.168.0.153 0 65009 ?
* 192.168.0.163 0 65009 ?
* 192.168.0.171 0 65009 ?
可见，实际Next Hop包含了kubernetes所有的node，但当前只使用了一个（即 >
指向的条目）；当 192.168.0.153
故障时，BGP会快速切换到另一个Hop，完成故障转移。
总结
本文介绍了MetalLB，并介绍了MetalLB的两种部署模式：Layer 2模式和BGP模式。在实际应用中，如果条件满足，推荐使用BGP模式。
Ref：
以上所述就是小编给大家介绍的《穷人的LoadBalancer》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
Spring Cloud微服务实战
翟永超 / 电子工业出版社 / 2017-5 / 89
《Spring Cloud微服务实战》从时下流行的微服务架构概念出发，详细介绍了Spring Cloud针对微服务架构中几大核心要素的解决方案和基础组件。对于各个组件的介绍，《Spring Cloud微服务实战》主要以示例与源码结合的方式来帮助读者更好地理解这些组件的使用方法以及运行原理。同时，在介绍的过程中，还包含了作者在实践中所遇到的一些问题和解决思路，可供读者在实践中作为参考。 《Sp......一起来看看 《Spring Cloud微服务实战》 这本书的介绍吧!
