作者
魏后民，騰訊雲后台開發工程師，關注容器、Kubernetes、Cilium等開源社區，負責騰訊雲 TKE 混合雲容器網絡等相關工作。
趙奇圓，騰訊雲高級工程師，主要負責騰訊雲容器網絡設計和研發工作。
前言
混合雲 並不是一個新鮮的概念，但隨着容器技術的發展，混合雲與容器的結合正在得到越來越多的關注。通過容器等雲原生技術，可以屏蔽混合雲異構集群底層計算資源基礎設施的差異，實現多雲場景、IDC 場景乃至邊緣等場景的統一。混合雲將不再是公有雲和私有雲的簡單結合，而是計算負載無處不在的分布式雲，可以充分發揮其在資源擴容、多活容災、多集群混合部署等場景的優勢。
騰訊雲 TKE 容器服務推出公有雲集群添加第三方 IDC 計算節點服務，該服務可以讓客戶復用 IDC 計算資源，免去在本地搭建、運維 Kubernetes 集群的成本，最大化提高計算資源使用率。
在這個方案的底層實現中，打通 IDC 和公有雲之間的網絡是重要的一環。一個 Kubernetes 集群中可能包含眾多不同網絡環境的計算節點，比如 IDC 網絡環境和公有雲 VPC 網絡環境的計算節點。為了屏蔽底層不同網絡環境的差異，TKE 提出了混合雲容器網絡方案，在容器層面看到的是統一的網絡平面，使得 Pod 無需感知其是運行在 IDC 的計算節點還是公有雲的計算節點。
TKE 混合雲容器網絡同時支持基於 VxLAN 隧道模式的 Overlay 網絡和基於直接路由的 Underlay 網絡。當客戶不希望改變其 IDC 基礎網絡設施時，可以使用 Overlay 網絡；當客戶對於混合雲容器網絡的性能有很高的要求時，可以使用基於直接路由的 Underlay 網絡。本文將詳述混合雲中容器網絡面臨的挑戰與解決方案，並介紹 TKE 混合雲容器 Overlay 網絡的實現。接下來還會有文章單獨介紹 TKE 混合雲容器 Underlay 網絡的實現，敬請期待。
混合雲容器網絡面臨的挑戰
在混合雲場景下，一個 Kubernetes 集群的各個組件可能分布在不同的網絡平面：
- Master Network：運行着 ApiServer 等控制面組件的網絡平面
- VPC Network：包含有 TKE 公有雲集群計算節點的網絡平面
- IDC Network：包含有客戶 IDC 計算節點的網絡平面
混合雲復雜的場景下，如何打通不同網絡平面的鏈路，對容器網絡設計提出了挑戰：
VPC Network 和 IDC Network 互相訪問
混合雲場景下，一個 Kubernetes 集群可能既包含 VPC Network 下的公有雲計算節點，也包含 IDC Network 下的計算節點。打通這些處於不同網絡環境下的節點網絡，是上層容器網絡互通的基礎。
IDC Network 主動訪問 Master Network
Kubernetes 環境下最常見的一個場景是計算節點的 Kubelet 會連接處於 Master Network 的 ApiServer，用於獲取集群相關的狀態和上報節點信息，這就要求 IDC Network 能夠主動訪問 Master Network。
Master Network 主動訪問 IDC Network
Kubernetes 環境下為了調試，我們常常使用 kubectl logs 和 kubectl exec 等命令實現獲取應用 Pod 的日志和直接登陸到應用 Pod 的運行環境。以 kubectl exec 為例，下圖展示了這類命令的實現原理：執行 kubectl exec 時首先會向 ApiServer 發起請求，由 ApiServer 轉發給 Pod 所在節點上的 kubelet 進程，然后再轉發給 runtime 的 exec 接口。
上述機制如果想要成功運行，要求處於 Master Network 的 ApiServer 與計算節點上的 kubelet 之間存在一條網絡通路，允許 ApiServer 能夠主動訪問 kubelet。除了 kubectl exec 和 kubectl log 等命令，kube-scheduler 的 extender 機制 和 ApiServer 的 Admission Webhook 機制 都依賴於 Master Network 與計算節點的網絡打通。
如何屏蔽底層網絡差異，統一容器網絡
混合雲場景下，一個 Kubernetes 集群可能既包含 VPC Network 下的公有雲節點，也包含 IDC Network 下的 IDC 節點，甚至是其他雲廠商的公有雲節點，乃至環境場景的邊緣節點。客戶有時候並不想改變自己 IDC 環境的基礎網絡設置，卻希望能有一套統一的容器網絡。
TKE 混合雲網絡方案
為了解決混合雲場景下容器網絡所面臨的挑戰，騰訊雲容器團隊設計了以 Cilium 作為集群網絡底座的 TKE 混合雲容器網絡方案。Cilium 基於 eBPF 技術為雲原生網絡重新設計，繞開 iptables，提供了網絡、可觀測性和安全等方面的一整套解決方案。Cilium 能夠支持基於隧道的 Overlay 網絡和基於直接路由的 Underlay 網絡，並且在大規模擴展 Service 等性能上有優越的表現 。騰訊雲容器團隊很早即開始基於 eBPF 技術對 Kubernetes 網絡進行優化，本次將混合雲網絡與 Cilium 結合也是對 eBPF 技術的進一步探索。
TKE 混合雲容器網絡主要特點如下：
- 實現全鏈路容器網絡的打通，屏蔽底層網絡差異
- 同時支持基於 VxLAN 隧道模式的 Overlay 網絡和基於直接路由的 Underlay 網絡
- 基於 eBPF 技術實現 Service 和 NetworkPolicy，優化 Kubernetes 網絡性能
- 支持自定義容器 IPAM，可實現節點多段 PodCIDR 和 PodCIDR 按需動態分配
- 支持網絡鏈路的可觀測性
TKE 混合雲容器網絡使用方法
在 TKE 集群基本信息頁面，點擊開啟「支持導入第三方節點」后，需要選擇混合雲容器網絡模式。這里我們可以選擇 Cilium VxLAN 來使用混合雲 Overlay 容器網絡，也可以選擇 Cilium BGP 來混合雲 Underlay 容器網絡：
TKE 混合雲網絡互通方案
VPC Network 和 IDC Network 互相訪問
為了打通 VPC Network 和 IDC Network，我們推薦使用騰訊雲的雲聯網服務，雲聯網服務能夠實現雲上 VPC 之間、VPC 與 IDC 網絡的互通，具備全網多點互聯、路由自學習、鏈路選優及故障快速收斂等能力。
IDC Network 主動訪問 Master Network
為了打通 IDC Network 主動訪問 Master Network 的網絡鏈路，我們基於騰訊雲 PrivateLink，實現 IDC Network 中的 Kubelet 主動訪問處於 Master Network 的 ApiServer。
Master Network 主動訪問 IDC Network
為了打通 Master Network 主動訪問 IDC Network 的網絡鏈路，我們選擇了基於社區的 apiserver-network-proxy 項目 來實現。具體的原理實現如下：
- 在 Master Network 創建
Konnectivity Server，作為代理服務器 - 在 IDC Network 創建
Konnectivity Agent，通過 PrivateLink 與 Master Network 中的代理服務器創建長連接 - 當 Master Network 中的 ApiServer 主動訪問 IDC Network 的 Kubelet 時，會復用 Agent 與 Server 之間的長連接
至此，Master Network 主動訪問 IDC Network 的網絡打通需求也得到了解決。進一步地，基於相同的方案，我們可以將多雲 VPC 的計算節點和邊緣場景的邊緣節點納管到同一控制平面，實現真正的分布式雲。
TKE 混合雲 Overlay 容器網絡方案
Master Network 與 IDC Network 網絡打通之后，我們即可在此基礎上通過隧道模式來構建 Overlay 網絡。VxLAN 是在數據中心網絡中獲得廣泛使用的隧道封裝協議，它通過 MAC in UDP 對數據包進行封裝，在對端解封。Cilium 的隧道封裝協議支持 VxLAN 和 Geneve，默認采用 VxLAN。基於 VxLAN 的高度可擴展性，只需要打通節點之間的網絡，就可在此之上實現統一的容器網絡。
跨節點 Pod 互相訪問
當數據包從 Pod 的網口發出時，經過 veth pair 到達 lxc00aa 網口。在 lxc00aa 網口上掛載的 eBPF 程序發現數據包目的地址為遠端 endpoint，轉發給 cilium_vxlan 進行封包。封包之后，外層地址為節點的 IP，內層地址為 Pod IP，經過節點上物理網口轉發給對端節點。到達對端節點后，同樣經過 cilium_vxlan 解封包，並將數據包轉發給對端 Pod。
節點訪問遠端 Pod
對於從本地節點訪問遠端節點的 Pod，在本機上會通過節點路由轉發給 cilium_host 網口，在 cilium_host 上掛載的 eBPF 程序會將數據包轉發到 cilium_vxlan 進行隧道封包，然后轉發到對端。可以看到，封包之后，外層地址為節點的 IP，內層源 IP 地址為 CiliumHostIP，目的 IP 地址為目標Pod IP 地址。后面鏈路與前面一致，不再贅述。
Pod訪問非 ClusterCIDR 的網絡
對於計算節點上的 Pod 訪問非容器 ClusterCIDR 的網絡地址時，數據包從 Pod 網口到達 lxc00aa 網口后，eBPF 程序發現目標地址不是容器網絡的 ClusterCIDR，則不會進行 Overlay 封包，而是轉給協議棧走節點路由。通過設置 cilium 的 masquerade 參數，數據包到達節點物理網口后，對於這種目的地址的數據包會執行 masquerade，替換數據包的源地址為節點 IP，從而之后數據包能夠返回到節點，並最終返回給 Pod。
總結與展望
本文介紹了 TKE 混合雲場景下公有雲集群添加第三方 IDC 節點服務下，混合雲容器網絡所面臨的復雜場景和性能的挑戰，並提出了基於 Cilium 的 Overlay 的容器網絡解決方案。可以看到，這套方案不僅適用於添加IDC節點，對於混合雲下的異構集群（多雲、邊緣場景）都適用，可以解決混合雲下集群網絡插件不一帶來的管理問題和體驗問題。由此，混合雲與容器的結合已經不再僅僅是混合雲，而是可以實現多雲場景、IDC 場景以及邊緣場景的統一，是實實在在、無處不在的分布式雲。
Overlay 的混合雲容器網絡可以通過隧道模式屏蔽底層不同網絡環境的差異，實現容器層面看到的是統一的網絡層面。對於另一部分客戶來說，他們對於混合雲容器網絡的性能有很高的要求，不希望引入因為 Overlay 的封解包過程帶來的性能折損。這種情況下，客戶希望直接基於 Underlay 網絡，通過直接路由來打通容器網絡。接下來還會介紹 TKE 混合雲容器網絡基於 BGP 直接路由的 Underlay 網絡的方案實現，敬請期待。
參考資料
- Mind the Gap: Here Comes Hybrid Cloud
- Kubernetes scheduler extender
- Kubernetes addmision controllers
- CNI Benchmark: Understanding Cilium Network Performance
- 騰訊雲繞過 conntrack，使用 eBPF 增強 IPVS 優化 K8s 網絡性能
- 騰訊雲雲聯網服務 CCN
- Kubernetes apiserver-network-proxy
- RFC 7348: Virtual eXtensible Local Area Network (VXLAN)
容器服務 TKE：無需自建，即可在騰訊雲上使用穩定， 安全，高效，靈活擴展的 Kubernetes 容器平台。