容器雲平臺網絡架構設計及優化

**【導讀】**本文重點分享了容器雲平臺實踐中網絡架構的設計，以及優化實踐的經驗總結，爲讀者今後的容器雲網絡架構實踐提供了參考。

**【作者】****顧文俊，**某互聯網公司，金融行業架構師。2008 年南京郵電大學電路與系統專業研究生畢業，12 + 年職業生涯主要從事 IT 基礎設施、雲計算、容器、大數據、AI、金融科技相關領域的解決方案工作。

1.1 Kubernetes 網絡框架 CNI

基於 Docker 的 Kubernetes 平臺爲什麼沒有選擇 CNM 作爲其網絡設計框架？畢竟大部分容器平臺肯定會支持 Docker 的網絡組件，爲什麼不使用相同的組件呢？這就要從 Kubernetes 平臺設計初衷說起，Kubernetes 是一個支持多容器的運行環境，而 Docker 只是其中一個容器而已。Docker 網絡驅動設計中，做了很多和 Kubernetes 不兼容的假設。

例如，Docker 中有 “本地” 驅動和 “全局” 驅動概念，“本地”驅動實現單機版，無法實現跨節點協作，“全局”驅動 libkv 可實現跨節點協作。但是，libkv 接口太過於底層，而且架構模式也是 Docker 內部的量身定製版本，對於 Kubernetes 的應用會帶來性能、可擴展性和安全性方面的問題。

CNI（Container Networking Interface）提供了一種 Linux 的應用容器的插件化網絡解決方案。最初是由 rkt Networking Proposal 發展而來。也就是說，CNI 本身並不是完全針對 Docker 的容器，而是提供一種普適的容器網絡解決方案。模型涉及兩個概念：

容器：擁有獨立 Linux 網絡命名空間的獨立單元。比如 rkt/docker 創建出來的容器。

網絡（Networking）：網絡指代了可以相互聯繫的一組實體。這些實體擁有各自獨立唯一的 IP。這些實體可以是容器，是物理機，或者是其他網絡設備（比如路由器）等。

CNI 的接口設計非常簡潔，不需要守護進程，只有兩個接口 ADD/DELETE，通過一個簡單的 shell 腳本就可以完成。相對於 CNM 的複雜設計，CNI 更加適合快速開發和迭代。

1.2 CNI 支持的開源組件

1.2.1 Flannel

Flannel 之所以可以搭建 Kubernetes 依賴的底層網絡，是因爲它可以實現以下兩點：

Flannel 是 CoreOS 團隊針對 Kubernetes 設計的一個網絡規劃服務，簡單來說，它的功能是讓集羣中的不同節點主機創建的 Docker 容器都具有全集羣唯一的虛擬 IP 地址。

在默認的 Docker 配置中，每個節點上的 Docker 服務會分別負責所在節點容器的 IP 分配。

這樣導致的一個問題是，不同節點上容器可能獲得相同的內外 IP 地址。並使這些容器之間能夠之間通過 IP 地址相互找到，也就是相互 ping 通。

Flannel 的設計目的就是爲集羣中的所有節點重新規劃 IP 地址的使用規則，從而使得不同節點上的容器能夠獲得 “同屬一個內網” 且“不重複的”IP 地址，並讓屬於不同節點上的容器能夠直接通過內網 IP 通信。

Flannel 實質上是一種 “覆蓋網絡 (Overlay Network)”，也就是將 TCP 數據包裝在另一種網絡包裏面進行路由轉發和通信，默認的節點間數據通信方式是 UDP 轉發。

▲Flannel 跨節點 Pod 通信圖

舉個例子，上圖是跨節點 Pod 通信。

可以看到，Flannel 首先創建了一個名爲 flannel0 的網橋，而且這個網橋的一端連接 Docker0 網橋，另一端連接一個叫作 flanneld 的服務進程。flanneld 進程並不簡單，它上連 etcd，利用 etcd 來管理可分配的 IP 地址段資源，同時監控 etcd 中每個 Pod 的實際地址，並在內存中建立了一個 Pod 節點路由表；它下連 Docker0 和物理網絡，使用內存中的 Pod 節點路由表，將 Docker0 發給它的數據包包裝起來，利用物理網絡的連接將數據包投遞到目標 flanneld 上，從而完成 Pod 到 Pod 之間的直接地址通信。

1.2.2 OVS

Open vSwitch 是一個開源的虛擬交換機軟件，有點像 Linux 中的 bridge，但是功能要複雜的多。OpenvSwitch 的網橋可以直接建立多種通信通道（隧道）。這些通道的簡歷可以很容易地通過 OVS 的配置命令實現。在 Kubernetes、Docker 場景下，主要是建立 L3 到 L3 點隧道。如下圖所示。

▲OVS with GRE 原理圖

首先，爲了避免 Docker 創建的 Docker0 地址產生衝突（因爲 Docker Daemon 啓動且給 Docker0 選擇子網地址時只有幾個備選列表，很容易產生衝突），我們可以將 Docker0 網橋刪除，手動建立一個 Linux 網橋，然後手動給這個網橋配置 IP 地址範圍。

其次，建立 Open vSwitch 的網橋 OVS，使用 ovs-vsctl 命令給 OVS 網橋增加 GRE 端口，在添加 GRE 端口時要將目標連接的 NodeIP 地址設置爲對端的 IP 地址。對每一個對端 IP 地址都需要這麼操作（對於大型集羣網絡，這可是個體力活，要做自動化腳本來完成）。最後，將 OVS 的網橋作爲網絡接口，加入 Docker 的網橋上（Docker0 或者自己手工建立的新網橋）。

重啓 OVS 網橋和 Docker 的網橋，並添加一個 Docker 的地址段到 Docker 網橋的路由規則項，就可以將兩個容器的網絡連接起來了。

OVS 的優勢是，作爲開源虛擬交換機軟件，它相對比較成熟和穩定，而且支持各類網絡隧道協議，經過了 OpenStack 等項目的考驗。另一方面，在前面介紹 Flannel 的時候可知 Flannel 除了支持建立 Overlay 網絡，保證 Pod 到 Pod 的無縫通信，還和 Kubernetes、Docker 架構體系結合緊密。Flannel 能夠感知 Kubernetes 的 Service，動態維護自己的路由表，還通過 etcd 來協助 Docker 對整個 Kubernetes 集羣中 Docker0 的子網地址分配。而我們在使用 OVS 的時候，很多事情就需要手工完成了。無論是 OVS 還是 Flannel，通過 Overlay 網絡提供的 Pod 到 Pod 通信都會引入一些額外的通信開銷，如果是對網絡依賴特別重的應用，則需要評估對業務的影響。

1.2.3 Calico

Calico 是一個純三層的數據中心網絡方案（不需要 Overlay），並且與 OpenStack、Kubernetes、AWS、GCE 等 IaaS 和容器平臺都有良好的集成。Calico 在每一個計算節點利用 Linux Kernel 實現了一個高效的 vRouter 來負責數據轉發，而每個 vRouter 通過 BGP 協議負責把自己上運行的 workload 的路由信息像整個 Calico 網絡內傳播——小規模部署可以直接互聯，大規模下可通過指定的 BGP route reflector 來完成。這樣保證最終所有的 workload 之間的數據流量都是通過 IP 路由的方式完成互聯的。Calico 節點組網可以直接利用數據中心的網絡結構（無論是 L2 或者 L3），不需要額外的 NAT，隧道或者 Overlay Network。此外，Calico 基於 iptables 還提供了豐富而靈活的網絡 Policy，保證通過各個節點上的 ACLs 來提供 Workload 的多租戶隔離、安全組以及其他可達性限制等功能。下圖是 Calico 的架構圖。

▲Calico 架構圖

在滿足系統要求的新配置的 Kubernetes 集羣上，用戶可以通過應用單個 manifest 文件快速部署 Calico。

如果您對 Calico 的可選網絡策略功能感興趣，可以向集羣應用其他 manifest，來啓用這些功能。

儘管部署 Calico 所需的操作看起來相當簡單，但它創建的網絡環境同時具有簡單和複雜的屬性。與 Flannel 不同，Calico 不使用 Overlay 網絡。相反，Calico 配置第 3 層網絡，該網絡使用 BGP 路由協議在主機之間路由數據包。這意味着在主機之間移動時，不需要將數據包包裝在額外的封裝層中。BGP 路由機制可以本地引導數據包，而無需額外在流量層中打包流量。

除了性能優勢之外，在出現網絡問題時，用戶還可以用更常規的方法進行故障排除。雖然使用 VXLAN 等技術進行封裝也是一個不錯的解決方案，但該過程處理數據包的方式同場難以追蹤。使用 Calico，標準調試工具可以訪問與簡單環境中相同的信息，從而使更多開發人員和管理員更容易理解行爲。

除了網絡連接外，Calico 還以其先進的網絡功能而聞名。網絡策略是其最受追捧的功能之一。此外，Calico 還可以與服務網格 Istio 集成，以便在服務網格層和網絡基礎架構層中解釋和實施集羣內工作負載的策略。這意味着用戶可以配置強大的規則，描述 Pod 應如何發送和接受流量，提高安全性並控制網絡環境。

如果對你的環境而言，支持網絡策略是非常重要的一點，而且你對其他性能和功能也有需求，那麼 Calico 會是一個理想的選擇。此外，如果您現在或未來有可能希望得到技術支持，那麼 Calico 是提供商業支持的。一般來說，當您希望能夠長期控制網絡，而不是僅僅配置一次並忘記它時，Calico 是一個很好的選擇。

▲Calico 功能模塊圖

Calico 主要由 Felix、etcd、BGP client 以及 BGP Route Reflector 組成：

1.3 總結對比

Calico BGP 方案最好，不能用 BGP 也可以考慮 Calico IPIP Tunnel 方案；如果是 CoreOS 系又能開 UDPOffload，Flannel 是不錯的選擇；Docker 原生 Overlay 還有很多需要改進的地方。

2 容器平臺的網絡架構實踐

2.1 某金融企業使用 OpenShift（基於 Kubernetes 的商業版本）實現其業務上雲

2.1.1 整體網絡架構圖

▲整體網絡架構圖

在 DMZ 和內網分別部署彼此獨立的 2 套 OpenShift，分別爲內網和 DMZ 區兩個網段，兩套環境彼此隔離。

DMZ 區的 OpenShift 部署對外發布的應用，負責處理外網的訪問。內網的 OpenShift 部署針對內網的應用，僅負責處理內網的訪問。

2.1.2 傳統應用訪問策略

方案推薦通過 NodePort 類型的 Service 爲某個應用對外暴露一個服務端口。NodePort 類型的 Service 會在集羣中的所有節點上監聽一個特定的端口，訪問任意一個計算機節點的端口，即可訪問內部容器中的服務。

在集羣的所有節點的這個端口都會預留給該應用所用。在 F5VS 的 Pool Member 中配置所有節點，通過 Kee-palived 來實現 HA。應用系統和用戶不用改變現有的訪問方式。

2.1.3 數據庫訪問方案及防火牆策略

內網計算節點可以直接訪問數據庫，DMZ 區計算節點訪問數據庫有 2 種方案：

（1）計算節點直接通過內網防火牆訪問該應用數據庫內網防火牆僅開通應用所在節點訪問內部數據庫的端口，例如本期方案中應用僅使用 2 個節點，則防火牆僅開通這 2 個節點訪問數據庫的權限。

▲計算節點直接通過內網防火牆訪問該應用數據庫

（2）計算節點經 Outbound 路由通過內網防火牆訪問內網數據

這 Outbound 路由在 OpenShift 中稱之爲 Egress Router

▲經 Outbound 路由通過內網防火牆訪問內網數據

因此，內網防火牆僅開通應用所在節點訪問內部數據庫的端口，例如，應用 A 僅通過路由節點 A 和 B 訪問內部數據庫，則防火牆僅開通這 2 個節點訪問 A 數據庫的權限。

▲通過 OutBound Router 訪問數據庫

2.2 某金融企業兩地三中心容器雲網絡架構

▲某企業兩地三中心容器雲架構

平臺基於多集羣管理和聯邦集羣特性，對兩地三中心、同城雙活、異地災備等業務場景提供了原生的支持。平臺以統一多集羣管理爲核心，可對接穩定快速的物理機服務器、資源利用率高的虛擬機、不同雲環境下的雲主機創建 Kubernetes 集羣。支持運行多集羣，保證集羣的高可用。提供跨雲的多集羣統一管理，解決多雲災備問題，實現統一部署、統一發布以及統一運維。通過 mirror 聯邦集羣，爲已經存在的集羣進行組件聯邦集羣。可以在聯邦內選擇在一個或多個集羣創建。

3 優化實踐

網絡優化是一個非常複雜的話題，現實場景中，如果出現服務不可用的情況，往往都會懷疑到網絡上面——網絡不可達，網絡擁塞，網絡設備失效等等。一個容器平臺網絡的高效穩定安全，涉及方方面面的設計考量。這裏將我們在實踐中的一些優化措施作了一些總結：

（1）主節點優化

在集羣中，除了 Pod 之間的網絡通信外，最大的開銷就是 master 和 etcd 之間的通信了，因此：

Master 側可以優化：

Node 側可以優化：

Node 節點的配置主要在 /etc/origin/node/node-config.yaml 裏，可以優化：iptables,synchronization period,MTU 值，代理模式。配合自文件裏還可以配置 Kubelet 的啓動參數，主要關注亮點 pods-per-core 和 max-pods，這兩個決定了 Node 節點的 Pod 數，兩者不一致時，取小。如果數值過大（嚴重超讀）會導致：

etcd 節點：儘量和 Master 部署在一起，或者提供專網連接。

（2）主機節點萬兆網卡性能優化

如果主機用萬兆或者 40Gbps，那麼可以優化的方面：

（3）IPIP 模式的 Flannel 性能提升

汲取了 Flannel/Calico 容器網絡開源項目的優點，實現了基於 IPIP 和 Host Gateway 的 Overlay 網絡，具體性能—短鏈接 VXLAN 比 host 差 33%，IPIP 比 host 差 23%，Gateway 比 host 只差 6%。具體參見下圖：

▲IPIP 模式 Flannel 性能提升

（4）使用指定的 Underlay IP 優化

FloatingIP 指定宿主機提供的 IP，將 IP 直接配置到容器中，有別於 OpenStack（將 Floating IP 配置到宿主機的網絡空間再通過 NAT 轉發）的實現，其性能更好，容器與物理機可以直接路由。Tunnel 網卡在容器中創建，避免了使用 NodePort 帶來的性能損耗。具體參見下圖：

▲使用指定的 Underlay IP 優化

（5）cgroup 實現資源隔離

在 cgroup 提供的能力之上，實現了網絡出入帶寬、資源隔離的能力，並提供所有硬件資源的可彈性配置，使得容器硬件資源全維度可彈性配置，大度提升了應用的隔離性與穩定性。在實際的運營過程中，我們發現，用戶往往不能很好的預先設置最急 limit 值，設置過大會導致資源浪費，設置過小又會導致業務性能損失甚至業務進程頻繁 OOM，彈性的優勢在於，用戶不需要配置 limit 值，系統可以自動將空閒資源交給業務容器使用。使得容器的穩定性、集羣資源利用率均得到提升。

▲cgroup 對網絡資源的優化

如上圖，某個 cgroup 網絡繁忙時，能保證其設定配額不會被其他 cgroup 擠佔；某個 cgroup 沒有用滿其配額時，其他 cgroup 可以自動使用其空閒的部分帶寬；多個 cgroup 分享空閒帶寬時，優先級高的優先佔用，優先級相同時，配額大的佔用多，配額小的佔用少，減少爲了流控而主動丟包。

（6）基於 DPDK 技術實現對 DDos 攻擊防護

（7）網絡帶寬 QoS 相關

網絡帶寬 QoS 主要是爲了保證用戶所申請的帶寬資源，以及有效利用空閒的網絡資源，儘可能提升用戶帶寬體驗。那麼我們可以做的事：

基於 Linux Traffic Control 並修改 OVS，實現保證速率，最大速率；

將小包按照 MPU（Minimum Packet Unit）大小來處理

同時，針對 VXLAN 小包處理性能不好，網絡小包過多導致宿主機 CPU 過載，影響網絡性能和穩定性的問題，通過限制容器網絡的 PPS（Packet Per Second）來處理。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Doia6GQokUQGZH4sZFn_wQ

猜你喜歡