首页 > 其他分享> > Kubernetes负载均衡器：Metallb

Kubernetes负载均衡器：Metallb

2021-06-29 19:51:49 作者：互联网

一. 概述

在使用kubenetes的过程中，如何将服务开放到集群外部访问是一个重要的问题。当使用云平台（阿里云、腾讯云、AWS等）的容器服务时，我们可以通过配置service为LoadBalancer模式来绑定云平台的负载均衡器，从而实现外网的访问。但是，如果对于自建的kubernetes裸机集群，这个问题则要麻烦的多。

祼机集群不支持负载均衡的方式，可用的不外乎NodePort、HostNetwork、ExternalIPs等种方式来实现外部访问。但这些方式并不完美，他们或多或少都存在的一些缺点，这使得裸金属集群成为Kubernetes生态系统中的二等公民。

MetalLB旨在通过提供与标准网络设备集成的Network LB实施来解决这个痛点，从而使裸机群集上的外部服务也尽可能“正常运行”，减少运维上的管理成本。

二. 部署要求

MetalLB需要以下环境才能运行：

运行Kubernetes 1.13.0或更高版本的群集，尚不具有网络负载平衡功能。
集群网络配置可以与MetalLB共存，详见下图。
一些用于MetalLB的IPv4地址。
如果使用BGP模式，您还需要一个或多个能够支持 BGP协议的路由器。

watermark,size_14,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_20,type_ZmFuZ3poZW5naGVpdGk=

三. 工作原理

Metallb包含两个组件，Controller和Speaker，Controller为Deployment部署方式，而Speaker则采用daemonset方式部署到集群内部各个Node节点。

具体的工作原理如下图所示，Controller负责监听service变化，当service配置为LoadBalancer模式时，从IP池分配给到相应的IP，并进行IP的生命周期管理。Speaker则负责监听Service的变化，并依据具体的协议发起相应的广播或应答，根据工作模式的不同，可采用Leader的方式或负载均衡的方式来响应请求。当业务流量通过TCP/UDP协议到达指定的Node时，由Node上面运行的Kube-Proxy组件对流量进行处理，并分发到对应的Pod上面。

watermark,size_14,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_20,type_ZmFuZ3poZW5naGVpdGk=

四. 工作模式

MetalLB支持两种模式，一种是Layer2模式，一种是BGP模式

Layer2模式

第2层模式下，Metallb会在Node节点中选出一台做为Leader，与服务IP相关的所有流量都会流向该节点。在该节点上， kube-proxy将流量传播到所有服务的Pod。当leader节点出现故障时，会由另一个节点接管。

局限性：

在二层模式中会存在以下两种局限性：单节点瓶颈以及故障转移慢的情况。

单个leader选举节点接收服务IP的所有流量。这意味着服务的入口带宽被限制为单个节点的带宽，单节点的流量处理能力将成为整个集群的接收外部流量的瓶颈。

在当前的实现中，节点之间的故障转移取决于客户端的合作。当发生故障转移时，MetalLB发送许多2层数据包，以通知客户端与服务IP关联的MAC地址已更改。

大多数操作系统能正确处理数据包，并迅速更新其邻居缓存。在这种情况下，故障转移将在几秒钟内发生。在计划外的故障转移期间，在有故

障的客户端刷新其缓存条目之前，将无法访问服务IP。对于生产环境如果要求毫秒性的故障切换，目前Metallb可能会比较难适应要求。

BGP模式

在BGP模式下，群集中的每个节点都与网络路由器建立BGP对等会话，并使用该对等会话通告外部群集服务的IP。假设您的路由器配置为支持多路径，则可以实现真正的负载平衡：MetalLB发布的路由彼此等效。这意味着路由器将一起使用所有下一跳，并在它们之间进行负载平衡。数据包到达节点后，kube-proxy负责流量路由的最后一跳，将数据包送达服务中的一个特定容器。

负载平衡的方式取决于您特定的路由器型号和配置，但是常见的行为是基于数据包哈希值来平衡每个连接，这意味着单个TCP或UDP会话的所有数据包都将定向到群集中的单个计算机。

局限性：

基于BGP的路由器实现无状态负载平衡。他们通过对数据包头中的某些字段进行哈希处理，并将该哈希值用作可用后端数组的索引，将给定的数据包分配给特定的下一跳。
但路由器中使用的哈希通常不稳定，因此，只要后端集的大小发生变化（例如，当节点的BGP会话断开时），现有连接就会被随机有效地重新哈希，这意味着大多数现有连接连接最终将突然转发到另一后端，该后端不知道所讨论的连接。

五. 安装部署

启用kube-proxy的ARP模式

$ kubectl edit configmap -n kube-system kube-proxy
#设置strictARP值为true
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "ipvs"
ipvs:
  strictARP: true

安装MetalLB相关组件

$ kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.5/manifests/namespace.yaml
$ kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.5/manifests/metallb.yaml
 
#创建secret
$ kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"

这会将MetalLB部署到metallb-system 名称空间下的群集中。清单中的组件是：

metallb-system/controller deployment,这是处理IP地址分配的群集范围的控制器。
metallb-system/speaker daemonset,这是说明您选择的协议以使服务可访问的组件。
controller和speaker 的服务帐户，以及组件需要运行的RBAC权限。

Layer2模式配置

创建configmap

$ vi metallb-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 192.168.214.50-192.168.214.80   #分配给LB的IP段

$ kubectl apply -f metallb-config.yaml

BGP模式配置

对于具有一个BGP路由器和一个IP地址范围的基本配置，您需要4条信息：

MetalLB应该连接的路由器IP地址，
路由器的AS号，
MetalLB应该使用的AS号，
以CIDR前缀表示的IP地址范围。

例如，如果您要给MetalLB范围192.168.10.0/24和AS编号64500，并将其连接到AS编号为64501的地址为10.0.0.1的路由器，则configmap配置如下所示：

$ vi metallb-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    peers:
    - peer-address: 10.0.0.1
      peer-asn: 64501
      my-asn: 64500
    address-pools:
    - name: default
      protocol: bgp
      addresses:
      - 192.168.10.0/24

$ kubectl apply -f metallb-config.yaml

六. 功能验证

本实例中我们使用上面的Layer2配置来验证功能，并进行访问测试。

创建示例yaml文件，包括svc与deployment

apiVersion: v1
kind: Service
metadata:
  name: myapp-svc
spec:
  selector:
    app: myapp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer    #类型选择LoadBalancer
 
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
  labels:
    app: myapp
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: nginx
        image: nginx:1.19.4
        ports:
        - containerPort: 80

$ kubectl apply -f myapp.yaml

查看SVC状态，已获取到IP

watermark,size_14,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_20,type_ZmFuZ3poZW5naGVpdGk=

通过外部浏览器访问

watermark,size_14,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_20,type_ZmFuZ3poZW5naGVpdGk=

七. 项目成熟度

MetalLB项目目前处于beta阶段，已被多个人员和公司用于多个生产和非生产集群中。根据错误报告的频率，暂时未发现有较大的BUG。

更详细信息可参见官网：https://metallb.universe.tf

标签：Metallb,metallb,Kubernetes,IP,BGP,MetalLB,均衡器,节点,路由器
来源： https://blog.51cto.com/u_14065119/2955679