一般來說只有雲端託管的k8s才有提供 LoadBalancer類型的service資源,雲端服務供應商會自動建立對應的網路負載均衡器並設定必要的健康檢查機制,但如果是自建k8s使用了 LoadBalancer 類型的service服務的話,EXTERNAL-IP會永遠卡在pending狀態,自建的k8s並不支援LoadBalancer類型的service資源,必須透過額外的方式處裡,目前OpenStack還有等等要介紹的MetalLB可以讓k8s使用LoadBalancer類型的service資源。當有 LoadBalancer 服務物件需要建立時,MetalLB 就從預先指定的 IP 位址池 (address pool) 中配置一個給該服務使用,位址池中可以是私有 (private) 或者公開 (public) 的 IP。MetalLB 透過兩種機制來進行節點故障時 IP 位址的容錯轉移 ,以確保 LoadBalancer 服務的 IP 位址的可用性,目前 MetalLB 透過下列方式來將 IP 位址從故障的節點轉而綁定的新的節點:
MetalLB需要以下環境才能運行:
.運行Kubernetes 1.13.0或更高版本,尚不具有網路負載平衡功能。 .一些用於MetalLB的IPv4網址。 .如果使用BGP模式,還需要一個或多個能夠支援BGP協定的路由器。 .叢集的CNI網路套件可以與MetalLB共存,詳見下圖。
CNI網路套件 | 相容性 |
---|---|
Calico | Mostly |
Canal | Yes |
Cilium | Yes |
Flannel | Yes |
Kube-ovn | Yes |
Kube-router | Mostly |
Weave Net | Mostly |
kubectl edit configmap -n kube-system kube-proxy
# 修改以下設定,將strictARP改成true
strictARP: true
kubectl apply -f <https://raw.githubusercontent.com/metallb/metallb/v0.11.0/manifests/namespace.yaml>
kubectl apply -f <https://raw.githubusercontent.com/metallb/metallb/v0.11.0/manifests/metallb.yaml>
kubectl get all -n metallb-system
L2模式 address 指定EXTERNAL-IP的配發範圍,如果使用L2模式的話,建議是跟節點IP相同網段
apiVersion: v1
kind: ConfigMap
metadata:
namespace: metallb-system
name: config
data:
config: |
address-pools:
- name: default
protocol: layer2
addresses:
- 192.168.1.230-192.168.1.240
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配置如下所示:
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 create deployment my-nginx --image=nginx --port=8080 --replicas=3
kubectl expose deployment/my-nginx --name=my-nginx --port=80 --target-port=80 --type=loadbalancer