在上一篇出海記博文提到，本想試試 Cilium 的一個高科技，卻試驗失敗。

這個(ge)高科技(ji)就是，Cilium 可以(yi)實現(xian)一個(ge)“魔法”，給 Kubernetes LoadBalancer Service 分配一個(ge)虛(xu)擬(ni) IP，當內網中的機器訪問(wen)這個(ge) IP 時，Cilium 會選(xuan)舉1臺(tai)節點服務器，填上(shang)它的 MAC 地(di)址，瞞天過海地(di)與請求方進(jin)行通信。如(ru)果(guo)用上(shang)這個(ge)科技(ji)，就可以(yi)用 Kubernetes Service 取代阿里云(yun)負載均(jun)衡作為 control-plane 的負載均(jun)衡，省(sheng)錢又環(huan)保。

上次試驗(yan)失敗后(hou)，心里有些不(bu)甘心，又繼(ji)續折(zhe)騰(teng)。本想(xiang)(xiang)著成功后(hou)能發篇博(bo)文(wen)分享勝利(li)經驗(yan)，沒想(xiang)(xiang)到現實(shi)很骨感——失敗其實(shi)是(shi)注定的(de)，因(yin)為忽略了一個關鍵點(dian)——云上的(de)網絡是(shi)一個虛擬(ni)(ni)世界，基(ji)于 ARP 協議的(de)巧妙玩法，在現實(shi)（虛擬(ni)(ni)現實(shi)）面前行不(bu)通。

于是，這篇原本打算分(fen)享勝(sheng)利經驗的(de)出(chu)海記博文被迫降(jiang)級為分(fen)享失敗經驗。

以下是(shi)試(shi)驗 Cilium L2 Announcements 失敗(bai)過程的分享。

首先，在阿里云專有網絡 VPC 中預留 172.21.48.240/28 網段給 Cilium LoadBalancer 使用(yong)

接著，更新 cilium 的部署(shu)，開啟 cilium 與負載均衡相(xiang)關的特(te)性(xing)

cilium upgrade --version 1.18.1 \
  --namespace kube-system \
  --set bpf.masquerade=true \
  --set kubeProxyReplacement=true \
  --set l2announcements.enabled=true \
  --set l2NeighDiscovery.enabled=true \
  --set externalIPs.enabled=true

相比之前的 cilium 部署(shu)，多(duo)了3個配(pei)置(zhi)選項

--set l2announcements.enabled=true
--set l2NeighDiscovery.enabled=true
--set externalIPs.enabled=true

部署完成后(hou)，檢查一(yi)下配置(zhi)是否生效(xiao)

~ # cilium config view | grep enable-l2
enable-l2-announcements                           true
enable-l2-neigh-discovery                         true
~ # kubectl -n kube-system exec ds/cilium -- cilium-dbg status --verbose | grep externalIPs                                                                                                        2 ?
- externalIPs:    Enabled

都生效了。

接下來，部署用于轉發請求到 api-server 的 LoadBalancer Service，清(qing)單文件 lb-service.yaml 內容如(ru)下(xia)

apiVersion: v1
kind: Service
metadata:
  annotations:
    io.cilium/lb-ipam-ips: 172.21.48.240
  labels:
    component: kube-apiserver
    tier: control-plane
  name: kube-api
  namespace: kube-system
spec:
  selector:
    component: kube-apiserver
    tier: control-plane
  ports:
  - name: https
    port: 6443
    protocol: TCP
    targetPort: 6443
  type: LoadBalancer

下(xia)單(dan)部(bu)署這個 service

# kubectl apply -f lb-service.yaml    
service/kube-api created

查看部署情況

~ # kubectl get svc --field-selector spec.type=LoadBalancer -n kube-system
NAME       TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
kube-api   LoadBalancer   10.107.192.67   <pending>     6443:31920/TCP   31s

這個(ge) kube-api service 監(jian)聽于 6443 端口，將轉發請求給 control-plane 的(de) api-server，看上(shang)去是一個(ge)稱職的(de) control-plane 負載均衡，但它現在(zai)(zai)只是一個(ge)擺設，中看不中用，因為只有(you) CLUSTER-IP，沒有(you) EXTERNAL-IP，只能在(zai)(zai) k8s 集群內部訪(fang)問，而要作為 control-plane 負載均衡，需要能通過節點服務器所在(zai)(zai)的(de)網絡訪(fang)問。

再接下來，部署 CiliumLoadBalancerIPPool，清單中 cidr 對應的是阿里(li)云 VPC 預留的網段，清單文(wen)件 lb-ip-pool.yaml 內容如下

apiVersion: "cilium.io/v2alpha1"
kind: CiliumLoadBalancerIPPool
metadata:
  name: api-server
  annotations:
spec:
  blocks:
  - cidr: "172.21.48.240/28"

下單部署

~ # kubectl apply -f lb-ip-pool.yaml
ciliumloadbalancerippool.cilium.io/api-server created

查看部署結果

~ # kubectl get CiliumLoadBalancerIPPool
NAME         DISABLED   CONFLICTING   IPS AVAILABLE   AGE
api-server   false      False         16              77s
~ # kubectl get svc --field-selector spec.type=LoadBalancer -n kube-system
NAME       TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)          AGE
kube-api   LoadBalancer   10.107.192.67   172.21.48.240   6443:31920/TCP   17m

這時你會發現 kube-api service 的 EXTERNAL-IP 被分配了一個節點所在網絡（阿里云VPC）的 IP 地址，這個 IP 是通過部署清單中的 io.cilium/lb-ipam-ips: 172.21.48.240 指定的，如果沒有指定，會從 CiliumLoadBalancerIPPool cidr 指定的網段中分(fen)配一個。

我們試試在其中(zhong)一臺(tai)節點服務器上訪問(wen)這個(ge) IP 與 6443 端口(kou)

~ # curl -k //172.21.48.240:6443/livez
ok

竟然可以訪問了，我們只是部署了 CiliumLoadBalancerIPPool，其他什(shen)么也沒做，是 cilium 根據我(wo)下的菜單（清單文件），知(zhi)道(dao)我(wo)的口味，把一切(qie)都包辦了。

現(xian)在，k8s 集群中(zhong)的任(ren)一節(jie)點都可以通(tong)過 172.21.48.240 訪問負載均衡(heng)，不管是 control-plane 還是 worker 節(jie)點，

但僅僅這樣是不夠(gou)的，比(bi)如(ru)向集群加入新節點或者節點服務器重啟時， 怎么訪問這臺負載均衡？

我們還需要再(zai)下一(yi)個(ge)菜單，開(kai)啟 cilium 的(de)魔法能(neng)(neng)力 —— L2 Announcements，讓同一(yi)個(ge)內(nei)網中沒有加入集群的(de)服(fu)務器也能(neng)(neng)訪(fang)問(wen)負載均(jun)衡(heng)，清單文(wen)件 lb-l2-announcements.yaml 內(nei)容如下

apiVersion: "cilium.io/v2alpha1"
kind: CiliumL2AnnouncementPolicy
metadata:
  name: control-plane
spec:
  serviceSelector:
    matchLabels:
      component: kube-apiserver
      tier: control-plane
  nodeSelector:
    matchExpressions:
    - key: node-role.kubernetes.io/control-plane
      operator: Exists
  loadBalancerIPs: true
  externalIPs: true

注：serviceSelector 需要對(dui)應之前部署的(de) LoadBalancer Service

下單部署

~ # kubectl apply -f lb-l2-announcements.yaml 
ciliuml2announcementpolicy.cilium.io/control-plane created

查看部署情況

# kubectl get CiliumL2AnnouncementPolicy                                                          
NAME            AGE
control-plane   29s

查看(kan) lease 是否生(sheng)效(xiao)

~ # kubectl -n kube-system get lease | grep "cilium-l2announce"
cilium-l2announce-kube-system-kube-api   kube-cp-03 

查看 l2-announce 是否正常

~ # kubectl -n kube-system get pod -l 'app.kubernetes.io/name=cilium-agent' -o wide | grep kube-cp-03                                                                              1 ?
cilium-sgjv9   1/1     Running   8 (21m ago)   14d   172.21.49.58   kube-cp-03   <none>           <none>

~# kubectl -n kube-system exec pod/cilium-sgjv9 -- cilium-dbg shell -- db/show l2-announce
IP              NetworkInterface
172.21.48.240   eth0

確認 L2 Announcements 已(yi)部署(shu)成功。

找一臺內(nei)網中沒有加入(ru) k8s 集群的服務器測試一下(xia)，看是否可以訪(fang)問(wen)負載均衡的 6443 端口

~ # telnet 172.21.48.240 6443
Trying 172.21.48.240...

連不上，L2 Announcements 沒(mei)起作用。

用(yong) arping 命令測試(shi)一下 APR 解析是否正常

~ # arping 172.21.48.240
ARPING 172.21.48.240
58 bytes from ee:ff:ff:ff:ff:ff (172.21.48.240): index=0 time=59.783 usec
58 bytes from ee:ff:ff:ff:ff:ff (172.21.48.240): index=1 time=69.028 usec
58 bytes from ee:ff:ff:ff:ff:ff (172.21.48.240): index=2 time=88.491 usec

ARP 解析雖然成功了，但卻是一個很奇怪的 MAC 地址 ee:ff:ff:ff:ff:ff。一開(kai)始(shi)以(yi)為是(shi) cilium-agent 在(zai)搞鬼，但后來試(shi)著 arping 一個根本不存在(zai)的內網(wang) IP，竟然也是(shi)這個 MAC 地(di)址！原來，阿里云 VPC 中的任何內網(wang) IP 都是(shi)這樣解析。這時(shi)才意識到，問題(ti)應該與身(shen)在(zai)云上有關(guan)。

后(hou)來在網上找到一篇博文(wen) 終于真相大白：

發工單后回答說：
ecs底層是虛擬化的(de)(de)網絡，不是傳統的(de)(de)物理(li)(li)網絡。表(biao)項的(de)(de)學習(xi)是通過arp代理(li)(li)實(shi)現(xian)，為了避免大量ARP學習(xi)影響組(zu)件性能，所以看到的(de)(de)都是同一個MAC ee:ff:ff:ff:ff:ff ，是正常的(de)(de)現(xian)象。

原(yuan)來(lai)，阿里(li)云 VPC 的(de)(de)(de)虛擬(ni)網(wang)絡并未完全遵循標準(zhun)的(de)(de)(de) ARP 協(xie)議，Cilium 巧妙的(de)(de)(de) L2 Announcements 方案如同“無根之木(mu)”，在云平臺這個虛擬(ni)世界的(de)(de)(de)“物理(li)定律”下，其(qi)失(shi)效(xiao)是(shi)必然的(de)(de)(de)。所以，這次(ci)失(shi)敗是(shi)命中注定的(de)(de)(de)。

參考：