前言
在 騰訊雲TKE - 基於 Cilium 統一混合雲容器網路（上） 中，我們介紹 TKE 混合雲的跨平面網路互通方案和 TKE 混合雲 Overlay 網路方案。公有云 TKE 叢集新增第三方 IDC 節點服務中，為了應對客戶不同使用場景的需求（特別是對於網路效能損耗的低容忍度要求），TKE 混合雲網路方案同時提出了基於 BGP 直接路由的 Underlay 網路方案。該網路模型採用 GoBGP 實現，基於 Cilium 打通了 Node-Pod 以及 Pod-Pod 之間網路，能夠保證較高的網路效能，並且支援大規模叢集擴充套件。
此網路方案在 TKE 公有云上線前，已經過 騰訊雲專有云敏捷PaaS平臺 TCNS 私有化環境的大規模實踐，並在 騰訊雲 TKEStack 中得到了整合和開源。本文將詳細介紹 TKE 混合雲基於 BGP 直接路由的 Underlay 容器網路方案的設計與實現。
背景介紹
客戶需求的多樣性，特別是對網路效能損耗的容忍程度決定了 Underlay 網路方案勢在必行。為什麼選擇 BGP 協議呢？ 相較於 OSPF、RIP 這些內部閘道器協議，BGP 著眼於控制路由的傳播以及選擇最佳路徑。BGP 最大的優勢在於具有較強的可擴充套件性，能夠滿足大規模叢集橫向擴充套件的需求。另一方面，BGP 足夠簡單穩定，並且業內也有著基於 BGP 落地生產環境的成功案例。
根據叢集規模大小的不同，BGP 路由模式有著不同的方案。當叢集規模較小時，可以使用 Full Mesh 互聯模式，它要求同一個 AS 內的所有 BGP Speaker 全連線，並且所有外部路由資訊必須重新分發到同一個 AS 的其他路由器。隨著叢集規模擴大，Full Mesh 模式效率將急劇降低，Route Reflection 模式是一種成熟的替代方案。RR 方案下允許一個 BGP Speaker （也即是 Route Reflector）向其他 BGP Peer 廣播學習到的路由資訊，大大減少了 BGP Peer 連線數量。
與已有方案相比，騰訊混合雲採用基於 GoBGP 實現 Cilium 的 Underlay 方案，該方案基於 GoBGP 提供的良好的程式設計介面實現了自己的 BGP Agent，具備很好的可擴充套件性。其特點如下：
- 支援大規模叢集的擴充套件
- 支援 BGP 鄰居發現
- 支援網路視覺化
- 支援 VIP 和 PodCIDR 路由宣告
- 支援 ECMP 等高階路由協議
- 實現 Cilium native-routing 功能
- 支援 L3 層網路通訊
騰訊混合雲 Underlay 容器網路方案
在不改變 IDC 機房內部網路拓撲的情況下，接入層交換機和核心層交換機建立 BGP 連線，藉助於機房內部已有的路由策略實現。針對 Node 所處的物理位置分配 PodCIDR，每個節點將 PodCIDR 通過 BGP 協議宣告給接入層交換機，實現全網通訊的能力。
- 每個接入層交換機與其管理的 Node 二層聯通，共同構成一個 AS。每個節點上跑 BGP 服務，用於宣告本節點路由資訊。
- 核心層交換機和接入層交換機之間的每個路由器單獨佔用一個 AS，物理直連，跑 BGP 協議。核心層交換機可以感知到全網的路由資訊，接入層交換機可以感知與自己直連的 Node 上的路由資訊。
- 每個 Node 上只有一條預設路由，直接指向接入層交換機。同一個接入層交換機下的 Node 通訊下一跳指向對端。
鄰居發現
在 BGP 實現的叢集網路中，經常存在節點新增和刪除的情形，如果採用靜態配置對等體的方式，需要頻繁的操作交換機進行對等體增刪的操作，維護工作量很大，不利於叢集的橫向擴充套件。為了避免手動對交換機進行操作，我們支援基於配置接入層交換機和軟體層面實現的路由反射器這兩種模式來動態發現 BGP 鄰居。
通過接入層交換機實現動態鄰居發現
接入層交換機充當邊界路由器，並開啟 Dynamic Neighbors 功能，H3C、Cisco以及華為的路由器具體開啟 Dynamic Neighbors 配置請參考官方文件。Node上的 BGP 服務主動與接入層交換機建立 iBGP 連線，並宣告本地路由，接入層交換機將學習到的路由宣告給整個資料機房內部。
通過RR實現動態鄰居發現
物理交換機或者 Node 節點充當反射路由器 RR，反射路由器與接入層交換機建立 iBGP 連線，Node 節點上的 BGP 服務與反射路由器建立連線。Node上的BGP服務將本地路由宣告給 RR，RR 反射到接入層交換機，接入層交換機接著宣告給整個資料機房內部。
下一跳
每個 Node 上跑 BGP 服務，將本節點的上的 PodCIDR 宣告給接入層交換機，每個接入層交換機可以感知到直連的所有 Node 上的 PodCIDR。接入層交換機下的 Node 之間相互學習路由下發到本地，流量經過接入層交換機二層轉發。跨接入層交換機的節點之間通訊下一跳指向接入層交換機，同一個接入層交換機下的節點之間通訊下一跳指向對端節點。下圖展示了同一個接入層交換機下以及跨接入層交換機下節點的路由學習情況，可以直觀的根據路由表判定下一跳地址。
-
同一個接入層交換機下通訊鏈路：10.2.0.2節點與10.2.0.3節點處在同一個接入層交換機下，具備二層連通，報文經過封裝後不經過三層轉發直接被送到對端。
-
不同接入層交換機之間通訊鏈路：10.2.0.2節點與10.3.0.3節點處在不同的接入層交換機下，報文需要經過接入層交換機和核心交換機路由後才能到達對端。
BMP 監控
基於 BGP Monitoring Protocol 開發 BMP Server，用於對 BGP 會話的執行狀態進行實時監控，包括對等體關係的建立與關閉、路由資訊等。利用收集到的BMP Message直接定位故障。
優雅重啟
BGP 是基於 TCP 實現的路由協議，TCP 連線異常斷開後，開啟 Graceful Restart 功能的交換機不會刪除 RIB 和 FIB，仍然按照原有的轉發表項轉發報文，並啟動 RIB 路由老化定時器。BGP Peer 需要兩端同時開啟 Graceful Restart 功能才能生效，Graceful Restart可以有效防止BGP鏈路震盪，提升底層網路的可用性。
自定義 IPAM
在 Kubernetes 常見配置中，會通過 kube-controller-manager 的 allocate-node-cidrs 和 configure-cloud-routes 等引數來為節點分配 PodCIDR 並配置路由。然而，社群的這種方案限制了節點只能有一段 PodCIDR，並且不能動態擴充。這種一個節點一個 PodCIDR 的策略太簡單，導致 IP 資源利用率太低，某些節點規格小可能用不完，某些節點規格大卻不夠。
在混合雲場景下，我們發現客戶對於 IPAM 提出了更高的要求：
- 希望節點的 PodCIDR 可以是多段的
- 希望節點的 PodCIDR 可以支援按需動態擴充和回收
為了解決這個問題，我們使用了自己的 tke-ipamd 元件來實現自定義的 IPAM 功能，原理如下圖所示：
- 不再由 kube-controller-manager 元件來分配節點 PodCIDR，而是由
tke-ipamd元件統一給節點分配 PodCIDR - Cilium Agent 通過 CiliumNode 物件讀取
tke-ipamd分配的 PodCIDR，響應 CNI 請求給 Pod 分配 IP tke-ipamd通過 list-watch 機制監聽節點 IP 資源使用情況，當節點 IP 資源使用率過高時動態擴充節點的 PodCIDR
效能測試
為了對 TKE 混合雲 Underlay 容器網路的效能有更好的瞭解，我們使用 netperf 工具對其進行了效能測試，可以看到，Underlay 在網路吞吐和頻寬上基本沒有效能損耗。
總結與展望
在介紹了混合雲場景下，TKE 基於 Cilium 的混合雲容器網路的互聯方案和 Overlay 網路方案後，本文重點介紹了基於 BGP 路由的 Underlay 網路方案。TKE 混合雲 Underlay 容器網路方案利用了 BGP 的擴充套件性，能夠滿足大規模叢集橫向擴充套件的需求，同時也能在效能上相對於節點網路做到基本無損，為客戶提供更高的資料面轉發效能。此網路方案在 TKE 公有云上線前，已經過騰訊雲專有云敏捷 PaaS 平臺 TCNS 私有化環境的大規模實踐，並在 騰訊雲 TKEStack 中得到了整合和開源。
混合雲與容器結合正在吸引越來越多企業客戶的目光，其在資源擴容、多活備災、業務分散式部署等場景可以提高企業現有計算資源利用率，給客戶帶來顯著受益。騰訊雲容器團隊打通公有云與 IDC 環境差異，為客戶提供統一管理檢視，實現多雲場景、IDC 場景以及邊緣場景的統一。除了單叢集能力的統一，騰訊雲容器團隊在叢集註冊、多叢集管理、跨雲跨叢集互訪等方面也有統一的方案，歡迎關注與體驗。
參考資料
容器服務（Tencent Kubernetes Engine，TKE）是騰訊雲提供的基於 Kubernetes，一站式雲原生 PaaS 服務平臺。為使用者提供整合了容器叢集排程、Helm 應用編排、Docker 映象管理、Istio服務治理、自動化DevOps以及全套監控運維體系的企業級服務。