隨着 Kubernetes 社區的發展，實際生產環境中使用 Kubernetes 越來越多，用戶對 CNI (Container Network Interface) 的要求也越來越多。Fabric 作爲博雲自研的一款成熟的 CNI 產品，旨在提供能適應多種場景，功能豐富易用且性能卓越的容器網絡管理平臺，從而有效的迴應用戶對於 CNI 的期待。
本期我們將着重介紹 Fabric 的一些常用基礎功能。
一、IP/MAC 固定
1.1 使用場景
-
保證 Pod IP/MAC 不變
Kubernetes 具有很高的容錯性，例如，當集羣中的某一節點發生故障時，pod 會自動漂移到其它正常的節點，這樣就保證了業務的可用性，不再需要手動到對應的節點啓動容器。但是 pod 在其它節點啓動的過程中會重新申請 IP/MAC 地址，如果不支持 IP/MAC 固定的 CNI, pod 的 IP 地址很容易發生改變，這對很多強依賴 IP/MAC 的業務（如: 數據庫服務, 微服務網關等）來說是不可接受的。
固定 IP/MAC 使漂移後的 pod 可以保持原有的身份發生網絡訪問，提高了業務可用性，保證了關聯業務都能正常與之發生訪問。
-
簡化相關網絡策略的配置
在一些安全策略把控嚴格的企業中，針對特定的業務 pod 開通外圍的網絡策略就變得稍顯複雜。此時，如果業務 pod 的身份信息無法固定，則意味着 pod 重建或者發生漂移後對應的網絡策略都要發生變更， 這對於運維工程師來說無疑是極爲頭疼的。因此，固定 IP/MAC 應運而生，這大大簡化了網絡策略的配置，並降低了維護成本。
1.2 產品特點
Fabric 固定 IP/MAC 的功能有如下特點：
(1) 更靈活的 IP/MAC 預約池，只要 IP/MAC 未被使用就能加入預約池。
(2) CRD 設計，更符合 Kubernetes 的設計原則。
(3) 支持常見的 Kubernetes Workload。
(4) Namespace 級別的安全隔離，不同的租戶可以使用不同的 IP/MAC 預約池。
(5) 預約池可以根據使用需求動態擴縮容。
(6) 對於無狀態服務，每次分配會從 IP 池中隨機分配；對於有狀態的 Statefulset 類型應用，每個 Pod 實例會獲取整個生命週期固定的 IP 地址。
1.3 實現原理
集羣中的 Pod 在某一節點被創建時，Kubelet 都會通過 CNI 去請求分配 IP，Fabric CNI 會通過 http 請求的方式向 fabric api-server 發送申請 IP 的請求。當 fabric api-server 收到申請 IP 的請求之後，首先會根據請求中的 pod 信息去查看 pod 對應的 annotation，判斷 annotation 是否綁定 IP/MAC 預約池（即判斷是否需要固定 IP/MAC）。如果沒有綁定 IP/MAC 預約池則正常分配 IP，如果存在 IP/MAC 預約池，則使用 IP/MAC 預約池中的 IP/MAC，即完成固定 IP/MAC。
基本固定 IP/MAC 流程如圖 1 所示：
圖 1：fabric 固定 IP/MAC 流程
二、流量出口 - EgressIp
2.1 使用場景
-
集羣流量審計
當在集羣中想要做流量審計工作時，統計集羣中每條對外的流量是一件十分麻煩的事情，因爲集羣中的每個節點都能成爲對外流量的出口。當集羣的節點數量較多時，工作量更是會成倍的上漲。但是，通過 Fabric，我們可以藉助配置 EgressIP 來完美解決這個問題，所有的對外流量均從一組節點流出，工作人員從之前對集羣的每個節點都進行統計，到只需要統計一組節點的流量記錄，這大大降低了工作量。
-
安全運維
在實際生產環境中，基於安全生產的原則，集羣中只有個別的節點可以連接外網，集羣管理員只需要爲個別節點開通對外策略。Pod 如果想要訪問外網，可以通過配置 EgressIP 來實現。
-
固定出口 IP
某些應用（如數據庫）只能接受指定源 IP 地址的流量，其它地址的連接均不予接受。如果集羣中所有需要訪問應用的流量都需要集羣管理人員手動配置的話，這明顯是一個巨大的工作量。對此我們可以通過配置 EgressIP，來配置專門的流量出口，大大減輕工作人員的運維壓力。
2.2 特點
Fabric EgressIP 功能的設計有如下特點：
(1) 配置靈活：EgressIP 可以配置爲 namespace 級別，也可以設置爲 pod 級別，滿足不同級別的配置需求。
(2) 高可用性：當 fabric 重啓之後，會自動重新分配 EgressIP。當正在使用的 EgressIP 掛掉之後，fabric 會自動在配置列表中選擇一個最優且可用的 EgressIP 進行替換。
(3) EgressIP 優選，在 EgressIP 可用列表中優先會選擇 pod 所在節點做爲 EgressIP，從而減少網絡損耗。
2.3 實現原理
-
Egress IP 選擇原理
(1) 獲取可用 EgressIP 列表。
(2) 判斷可用 EgressIP 中是否有當前 pod 所在節點，如果存在則選擇當前節點 IP 爲 EgressIP。
(3) 如果不存在則選擇當前 pod 之前被分配過的 EgressIP。
(4) 如果 pod 之前使用的 EgressIP 也不存在，則使用可用 EgerssIP 列表的最後一位。
-
網絡傳輸原理
當 pod 數據訪問目的地址被判定爲外部網絡時，數據會發往 EgressIP 所在的節點，然後從 EgressIP 所在節點傳輸到外部網絡。
具體網絡傳輸過程如圖 2 所示：
圖 2：設置 pod 通過 EgressIP 訪問外部網絡數據傳輸流程
注：Fabric overlay 網絡支持多種封裝協議(vxlan、gre、geneve)，圖 2 僅以 vxlan 作爲示例，不代表僅支持 vxlan。
三、QoS (Quality of Service) 服務質量
3.1 使用場景
-
業務 Pod 雙向限速
當集羣網絡資源有限時，某一時刻發生的大文件傳輸過程，或者其它需要佔用大規模網絡資源的情況，極易造成集羣網絡的崩潰。通過 QoS 配置，可以限制某些容易發生大規模傳輸的網絡資源配額，給予其正常的網絡帶寬，從而保證集羣整體網絡的正常。
3.2 特點
(1) 使用簡單，直接通過的註解（annotation）進行雙向的 Qos 配置。
(2) 支持雙棧，IPV4 和 IPV6 都有很好的支持。
(3) 支持多網絡，在多網絡的環境下，支持對每個網卡分別進行 QoS 配置。
3.3 實現原理
Fabric 的容器網絡架構基於 OpenvSwitch，pod 通過 veth peer 連接在 ovs bridge 的 port 上，主機側的 veth 等同於 ovs 的 interface (網卡)，interface 插在 ovs port 裏，所以我們控制 pod 的 QoS 就等同於控制對應 ovs interface/port 的 QoS。因此，配置 pod 出棧的 Qos 實際上是配置主機側 veth 對應的 interface 的 ingress 屬性，配置 pod 入棧的 QoS 實際是配置主機側 veth 對應的 port (interface 插入的地方) 的 QoS 屬性。
Fabric 配置 QoS 的原理如圖 3 所示：
圖 3：Fabric 配置 QoS 原理
四、租戶隔離
4.1 使用場景
-
多租戶之間的網絡隔離
多租戶是一種軟件設計架構，指的是單個軟件實例可以爲不同的用戶提供服務。多租戶架構在雲計算領域也有廣泛的應用，在雲計算領域多租戶除了指共享軟件服務之外，也可以指服務器資源，服務器資源在不同的租戶之間進行分配。多租戶的特性就是要解決租戶間的隔離問題，不同的租戶之間不能互相訪問數據，以此達到安全隔離的效果。
4.2 特點
Fabric 租戶隔離功能設計有如下特點：
(1) 使用方便，直接添加註解（annotation）信息，即可爲容器配置多租戶隔離。
(2) 配置靈活，除了基本的租戶之間的隔離之外，同時還可以配置兄弟租戶之間的互通，可以適應多種使用場景。
(3) 租戶白名單設計，幾個系統級別的 namespace (kube-system, kube-public, default, kube-node-lease, monitoring, ingerss-nginx) 是任意租戶可達的。
4.3 實現原理
當集羣中已經配置多租戶時，pod 如果訪問集羣網絡會首先進行網絡策略驗證，即驗證網絡訪問源地址和目的地址網絡是否符合多租戶網絡隔離策略。主要判斷的是否在同一 namespace 下、源地址或目的地址是否在白名單內、租戶是否存在、是否配置了兄弟租戶（租戶之間互通）。
簡要的多租戶網絡隔離驗證策略如圖 4 所示：
圖 4：多租戶網絡隔離驗證策略
五、總結與展望
目前，Fabric 有着非常豐富且強大的功能，但由於篇幅所限，本文只能介紹一些常用且基礎的功能。後續 Fabric 會持續優化已有的功能，並積極開發更多實用的新功能。在此之後，我們還會分享一些 Fabric 的進階的功能的設計方案和相關特性。