前言

G行全棧云容器大規(guī)模運行在信創(chuàng)服務(wù)器的虛擬機里，發(fā)現(xiàn)如跨NUMA訪問CPU可能導(dǎo)致性能不均衡、容器網(wǎng)絡(luò)和IaaS SDN耦合、虛擬層本身資源消耗等諸多問題。為解決這些問題，G行探索將容器運行在裸金屬服務(wù)器上，推出裸金屬容器平臺方案，使用純?nèi)龑泳W(wǎng)絡(luò)設(shè)計，其中東西向網(wǎng)絡(luò)流量使用開源Calico容器組件，南北向網(wǎng)絡(luò)流量使用自研ELB。本文主要介紹Calico BGP相關(guān)技術(shù)原理、實踐和思考。

BGP介紹

BGP（Border Gateway Protocol，邊界網(wǎng)關(guān)協(xié)議）為取代外部網(wǎng)關(guān)協(xié)議（EGP）協(xié)議而創(chuàng)建，屬于經(jīng)典網(wǎng)絡(luò)路由協(xié)議。BGP相關(guān)的開源項目有bird、goBGP 等，開源軟件運行在云平臺的宿主主機上，使主機與網(wǎng)絡(luò)設(shè)備交換路由信息，實現(xiàn)云上網(wǎng)絡(luò)和云下網(wǎng)絡(luò)的通信。

關(guān)鍵概念：

• AS(Autonomous System): 一個自治系統(tǒng)是受控于一家組織機構(gòu)的路由器集合。在企業(yè)內(nèi)部AS號是統(tǒng)一管理的，根據(jù)網(wǎng)絡(luò)設(shè)備的AS號異同，可分為IBGP和EBGP。
• IBGP(Internal BGP)：在相同AS路由器之間建立會話，一般認(rèn)為IBGP運行在安全的網(wǎng)絡(luò)環(huán)境。特點是IBGP的路由信息只能傳一跳，不會傳遞給其他IBGP路由節(jié)點。否則，需要開啟Router Reflect特性。
• EBPG(External BGP)：在不同AS路由器之間建立會話。特點是EBGP路由器之間會同步彼此的路由。?

圖一 網(wǎng)絡(luò)架構(gòu)

在典型Spine-Leaf架構(gòu)下，Spine與Leaf之間運行EBGP協(xié)議，Leaf與裸金屬服務(wù)器之間運行IBGP協(xié)議。

Calico網(wǎng)絡(luò)

Calico是基于CNI實現(xiàn)的純?nèi)龑泳W(wǎng)絡(luò)開源項目，首個版本在2015年發(fā)布，截止當(dāng)前版本為Calico 3.26.1。該項目已被業(yè)界廣泛接受，并擁有許多大規(guī)模的實際案例。

圖二 Calico架構(gòu)示意圖

1. Calico關(guān)鍵組件

• Felix

Felix負(fù)責(zé)管理容器網(wǎng)絡(luò)，配置容器IP地址、路由、iptables、安全策略等功能。在每個Worker節(jié)點運行代理程序，負(fù)責(zé)與容器管理平面通信，獲取并配置網(wǎng)絡(luò)和安全策略。

• Confd

監(jiān)控Calico相關(guān)數(shù)據(jù)（BGP配置、IPAM配置等），動態(tài)生成Bird配置文件，并使Brid重新加載配置文件。

• Brid

發(fā)布路由：從Felix獲取路由，并把路由分發(fā)給BGP鄰居，外部流量通過該路由找到POD所在Worker節(jié)點。

路由反射 (Route Reflector): 收到IBGP鄰居發(fā)布的BGP路由，并反射路由給其他IBGP鄰居。

路由過濾:物理網(wǎng)絡(luò)設(shè)備的所有路由表項會同步到本機，配置路由過濾，可以大量減少本機的路由條目。

• Typha

Flex通過Tyhpa直接跟Etcd交互，不再經(jīng)過容器管理平面，在百節(jié)點以上的規(guī)模，能夠有效降低對容器管理平面的訪問壓力。

2. Calico組網(wǎng)模式

•  IPIP模式

Calico默認(rèn)網(wǎng)絡(luò)架構(gòu)，IPIP可理解為IPinIP，屬于overlay的網(wǎng)絡(luò)架構(gòu)。不依賴于外部交換機設(shè)備，即可實現(xiàn)網(wǎng)絡(luò)組網(wǎng)。缺點是報文的封裝和解封裝對網(wǎng)絡(luò)效率有影響，節(jié)點規(guī)模有限制。

•  BGP模式

Calico最佳實踐推薦該模式，計算節(jié)點與網(wǎng)絡(luò)設(shè)備建立BGP鄰居，并對外宣告POD的路由信息，網(wǎng)絡(luò)設(shè)備學(xué)習(xí)到路由信息后，外部用戶就可通過路由直接訪問POD的地址，期間不涉及到報文的封裝，網(wǎng)絡(luò)效率非常高。在合理的網(wǎng)絡(luò)架構(gòu)設(shè)計下，節(jié)點規(guī)模靈活擴展且不影響網(wǎng)絡(luò)效率。缺點是一般硬件網(wǎng)絡(luò)設(shè)備和云平臺的計算節(jié)點是由不同團隊管理，遇到網(wǎng)絡(luò)故障時需聯(lián)合處置。

3. IPAM地址管理?

?Calico通過IPPool進行IPAM管理，IPPool定義了地址池名字、地址段、blockSize等字段。IPPool的配置樣例如下：

apiVersion：crd.projectcalico.org/v1

kind: IPPool

metadata:

  name: ippool-test-0

spec:

  blockSize: 32

  cidr: 1.1.1.0/24

  ipipMode: Never

  natOutgoing: false

  nodeSelector: “!all()”

  vxlanMode: Never

nodeSelector: 該字段與Kubernetes節(jié)點的Label進行映射。默認(rèn)為all(),表示所有節(jié)點均可使用。設(shè)置為!all()，表示所有node均不可自動使用，可通過設(shè)置命名空間或者POD的注解，實現(xiàn)IPPool的綁定。

block/blockSzie: block主要功能是路由聚合，減少對外宣告路由條目。block在POD所在節(jié)點自動創(chuàng)建，如在worker01節(jié)點創(chuàng)建1.1.1.1的POD時，blocksize為29，則該節(jié)點自動創(chuàng)建1.1.1.0/29的block，對外宣告1.1.1.0/29的BGP路由，并且節(jié)點下發(fā)1.1.1.0/29的黑洞路由和1.1.1.1/32的明細(xì)路由。在IBGP模式下，黑洞路由可避免環(huán)路。如果blockSize設(shè)置為32，則不下發(fā)黑洞路由也不會造成環(huán)路，缺點是路由沒有聚合，路由表項會比較多，需要考慮交換機路由器的容量。

Calico創(chuàng)建block時，會出現(xiàn)借用IP的情況。如在 worker01節(jié)點存在1.1.1.0/29的block，由于worker01節(jié)點負(fù)載很高，地址為1.1.1.2的POD被調(diào)度到worker02節(jié)點，這種現(xiàn)象為IP借用。woker02節(jié)點會對外宣告1.1.1.2/32的明細(xì)路由，在IBGP模式下，交換機需要開啟RR模式，將路由反射給worker01上，否則在不同worker節(jié)點的同一個block的POD，由于黑洞路由的存在，導(dǎo)致POD之間網(wǎng)絡(luò)不通。可通過ipamconfigs來管理是否允許借用IP(strictAffinity)、每個節(jié)點上最多允許創(chuàng)建block的數(shù)量(maxBlocksPerHost)等。

4 BGP模式下路由分析

舉例說明，創(chuàng)建1.1.1.0/31的地址池，IPPool配置如下：

root@master1:~# calicoctl get ippool ippool-test-0

NAME            CIDR             SELECTOR

ippool-test-0   1.1.1.0/31       all()

使用該地址池，創(chuàng)建一個名字為nettool的POD，創(chuàng)建完成后，查看workloadendpoint資源信息。可查看得到，POD的IP地址為1.1.1.1/32，其網(wǎng)絡(luò)接口對應(yīng)在worker01節(jié)點的網(wǎng)卡為cali200f7a51a47。

root@master1:~# calicoctl get workloadendpoint

NAMESPACE   WORKLOAD   NODE        NETWORKS         INTERFACE

default     nettool    worker01    1.1.1.1/32       cali200f7a51a47

進入該容器，查看路由和接口信息。可查看得到，容器默認(rèn)路由為169.254.1.1，且均指向eth0。通過ethtool查看得到，eth0接口的peer_ifindex為532。

root@master1:~# kubectl exec -it nettool sh

kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.

sh-4.4# ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

       valid_lft forever preferred_lft forever

2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000

    link/ipip 0.0.0.0 brd 0.0.0.0

4: eth0@if532: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc noqueue state UP group default

    link/ether 86:61:23:4e:4e:d0 brd ff:ff:ff:ff:ff:ff link-netnsid 0

    inet 1.1.1.1/32 scope global eth0

       valid_lft forever preferred_lft forever

sh-4.4# ip route

default via 169.254.1.1 dev eth0

169.254.1.1 dev eth0 scope link

sh-4.4# ethtool -S eth0

NIC statistics:

     peer_ifindex: 532

     rx_queue_0_xdp_packets: 0

     rx_queue_0_xdp_bytes: 0

     rx_queue_0_xdp_drops: 0

登錄worker01節(jié)點，查看index為532的網(wǎng)卡接口，正是該接口cali200f7a51a47。worker01節(jié)點已經(jīng)配置了ARP代理(主機上網(wǎng)卡不管ARP請求的內(nèi)容，直接將自己的Mac地址作為應(yīng)答的行為稱為ARP Proxy)。Calico把worker01節(jié)點當(dāng)做容器的默認(rèn)網(wǎng)關(guān)使用，所有報文會發(fā)送到節(jié)點上，節(jié)點再根據(jù)路由信息進行轉(zhuǎn)發(fā)。

root@worker01:~# ip a |grep 532

532: cali200f7a51a47@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc noqueue state UP group default

root@worker01:~# cat /proc/sys/net/ipv4/conf/cali200f7a51a47/proxy_arp

1

針對回程報文，我們查看節(jié)點的1.1.1.1對應(yīng)路由，也正是該接口cali200f7a51a47。此時worker01節(jié)點的收發(fā)報文通路已經(jīng)明了。

root@worker01:~# route -n |grep cali200f7a51a47

1.1.1.1     0.0.0.0         255.255.255.255 UH    0      0        0 cali200f7a51a47

最后，確認(rèn)下交換機的路由情況。目的地址為1.1.1.1的下一跳為192.168.1.4，該IP地址是worker01主機IP。此時POD就可以跟外部進行通信。

Destination/Mask        Proto   Pre     Cost    Flags   NextHop         Interface

1.1.1.1/32              IBGP    255     0       RD      192.168.1.4     vlanif100

<switch>

全棧云探索實踐

綜合考慮微隔離、網(wǎng)路可觀測等技術(shù)儲備已在G行推廣使用，Calico默認(rèn)不開啟網(wǎng)絡(luò)安全策略，依靠微隔離做網(wǎng)絡(luò)安全管控。主要考慮BGP和IPAM上設(shè)計和管理網(wǎng)絡(luò)。

1.BGP配置

1) 創(chuàng)建BGPconfigurations配置文件，聲明節(jié)點的默認(rèn)AS號。

root@master1:~# cat bgpconfigurations.yaml

apiVersion: crd.projectcalico.org/v1

kind: BGPConfiguration

metadata:

  name: default

spec:

  asNumber: 1111111

  logSeverityScreen: Info

  nodeToNodeMeshEnabled: false

2) 創(chuàng)建BGPPeer，明確交換機的AS號、BGP Peer IP，并將含有rr-group=rr1 的節(jié)點與交換機建立鄰居。

root@master:~# cat bgppper1.yaml

apiVersion: crd.projectcalico.org/v1

kind: BGPPeer

metadata:

  name: bgp-peer-1

spec:

  asNumber: 1111111

  nodeSelector: rr-group == 'rr1'

  peerIP: 192.168.1.1

3) Kubernetes的節(jié)點打rr-group=rr1的標(biāo)簽

root@master1:~# kubectl get node --show-labels |grep rr1 |grep worker01

worker01   Ready    worker                 21d    v1.23.15   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=worker01,kubernetes.io/os=linux,node-role.kubernetes.io/worker=,rr-group=rr1

4) 交換機配置

• BGP建立鄰居
•  BGP Policy，防止對外發(fā)布不可信路由

5) 裸金屬Kubernetes節(jié)點查看BGP狀態(tài)，Established意味著BGP鄰居已經(jīng)建立。

root@worker01:~# calicoctl node status

Calico process is running.

IPv4 BGP status

+--------------+---------------+-------+------------+-------------+

| PEER ADDRESS |   PEER TYPE   | STATE |   SINCE    |    INFO     |

+--------------+---------------+-------+------------+-------------+

| 192.168.1.1  | node specific | up    | 2023-08-17 | Established |

| 192.168.1.2  | node specific | up    | 2023-08-17 | Established |

+--------------+---------------+-------+------------+-------------+

IPv6 BGP status

No IPv6 peers found.

2. IPAM配置相關(guān)信息

G行云平臺底座和業(yè)務(wù)的IP分開管理，業(yè)務(wù)自行決定POD的親和或反親和，業(yè)務(wù)部署在自己的命名空間，不會出現(xiàn)多種業(yè)務(wù)在同一個命名空間部署的情況。

在超過20個節(jié)點的容器平臺，應(yīng)用POD會頻繁發(fā)生IP地址借用情況，block的路由聚合效率大幅度降低。綜合考慮交換機性能和容量，地址池的blockSize設(shè)置為32，交換機不開啟RR特性。

為確保IP不會被其他業(yè)務(wù)使用，設(shè)定所有地址池的nodeSelector為!all()。

root@master1:~# calicoctl get ippool                         

NAME                    CIDR                    SELECTOR

ippool-test-0           1.1.1.0/24              !all()

ippool-test-1           1.1.2.0/24              !all()

ippool-test-2           1.1.3.0/24              !all()

ippool-test-3           1.1.4.0/24              !all()

在namespace中設(shè)定對應(yīng)annotation。

apiVersion: v1

kind: Namespace

metadata:

  annotations:

    cni.projectcalico.org/ipv4pools: '["ippool-test-0"]'

  name: test

3. Calico相關(guān)監(jiān)控

Calico監(jiān)控體系從三個方面進行覆蓋。

• Calico組件和功能的監(jiān)控，包含IPPool監(jiān)控、Felix、Typha等組件監(jiān)控。
• Calico網(wǎng)絡(luò)邊界的監(jiān)控，主要是跟交換機的網(wǎng)絡(luò)邊界監(jiān)控，網(wǎng)絡(luò)流量通過可觀測平臺監(jiān)控，網(wǎng)絡(luò)控制面依賴于BGP報文的監(jiān)控。
• 容器平臺網(wǎng)絡(luò)固有的監(jiān)控，跟采用哪種CNI插件無關(guān)。如Calico相關(guān)POD健康與否、業(yè)務(wù)POD網(wǎng)絡(luò)狀態(tài)、容器節(jié)點網(wǎng)絡(luò)信息等。

圖三 Calico監(jiān)控體系

Calico BGP模式相關(guān)思考

建設(shè)方面：Calico BGP建設(shè)需要多團隊的配合。管理物理網(wǎng)絡(luò)設(shè)備的團隊，需全局規(guī)劃網(wǎng)絡(luò)設(shè)備的BGP信息、AS號和靜態(tài)路由等，技術(shù)上避免單臺交換機宕機引起路由的震蕩（如一對Leaf交換機擁有不同AS號，會造成路由震蕩）；管理云平臺的團隊，需要合理配置iBGP和IPPool，避免發(fā)布非法路由，影響其他網(wǎng)絡(luò)設(shè)備。

運維方面：變更管理/故障管理需云和網(wǎng)配合進行，明確雙方分工和問題界定，緊密協(xié)作。比如管理云平臺的團隊配置BGP Filter功能，物理網(wǎng)絡(luò)設(shè)備配置BGP Policy，防止對外發(fā)布非法路由，形成雙保險。在技術(shù)探索過程中，引入可觀測平臺全鏈路流量和BGP監(jiān)控等工具，最大程度將問題邊界描述清晰，并提高運維效率。

后續(xù)細(xì)化Calico BGP監(jiān)控指標(biāo)，探索Calico eBPF數(shù)據(jù)面的實現(xiàn)，弱化iptables對網(wǎng)絡(luò)的影響。