點擊上方“馬蜂窩技術”，關注訂閱更多優質內容
使用 Docker+Kubernetes 來簡化開發人員的工作流，使應用更加快速地迭代，縮短髮布週期，在很多研發團隊中已經是常見的做法。
如果說 Docker 提供的是應用級的主機抽象，那麼 Kubernetes 的作用就是應用級的集羣抽象，提供容器集羣運行所需的基礎設施，旨在解決容器化應用的資源調度、部署運行、服務發現、擴容縮容等問題。
一直以來，容器網絡設計都被認爲是非常重要，但相對複雜的部分。 本文要介紹的 Kubernetes 網絡，目前主要爲馬蜂窩旅遊網大多數 Java 業務提供開發環境的底層基礎設施。隨着團隊的調整及業務需求升級，整個系統對網絡架構的要求也越來越嚴苛。基於這樣的背景，Kubernetes 網絡過去一年多經歷了兩次比較重要的改造，以期不斷降低運維調試成本，提高研發效率。
藉由本文分享我們的實踐經驗，與君共勉。
Part.1
K8S 網絡原理及挑戰
1. Kubernetes Pod 設計
Pod 是 Kubernetes 的基本調度單元，我們可以將 Pod 認爲是容器的一種延伸擴展，一個 Pod 也是一個隔離體，而 Pod 內部又包含一組共享的容器。
每個 Pod 中的容器由一個特殊的 Pause 容器，及一個或多個緊密相關的業務容器組成。Pause 容器是 Pod 的根容器，對應的鏡像屬於 Kubernetes 平臺的一部分，以它的狀態代表整個容器組的狀態。同一個 Pod 裏的容器之間僅需通過 localhost 就能互相通信。
每個 Pod 會被 Kubernetes 網絡組件分配一個唯一的（在集羣內的 IP 地址，稱爲 Pod IP，這樣就允許不同 Pod 中的服務可以使用同一端口(同一個 Pod 中端口只能被一個服務佔用)，避免了發生端口衝突的問題。
2. 挑戰
Pod 的 IP 是在 Kubernetes 集羣內的，是虛擬且局域的。這就帶來一個問題，Pod IP 在集羣內部訪問沒有問題，但在實際項目開發中，難免會有真實網絡環境下的應用需要訪問 Kubernetes 集羣裏的容器，這就需要我們做一些額外的工作。
本文將結合我們開發環境下基於 K8S 容器網絡演進的過程，介紹在 Pod IP 爲虛擬或真實 IP 情況下的幾種直接訪問 Pod IP 的解決方案。
Part.2
基於K8S的容器網絡演進
第一階段：K8S + Flannel
最早，我們的網絡設計方案只服務於大交通業務。初期大交通的 Java 應用是部署在物理機上的，團隊內部容器相關的底層基礎設施幾乎爲 0。爲了更加平穩地實現容器化的落地，中間我們沒有直接把服務全部遷移到 K8S 中去，而是經歷了一段混跑。
這個過程中必然會有物理機上的 Java 應用訪問 K8S 裏 Java 容器的情況(一個註冊中心)。當時我們選用的網絡架構是 Flannel VXLAN + Kube-proxy，主要是考慮到 Flannel 的簡潔性。
Flannel 是爲 K8S 設計的一個非常簡潔的多節點三層網絡方案，主要用於解決容器的跨主機通信問題，是一個比較大一統的方案。它的設計目的是爲集羣中的所有節點重新規劃 IP 地址的使用規則，從而使得不同節點上的容器能夠獲得「同屬一個內網」且「不重複的」IP地址，並讓屬於不同節點上的容器能夠直接通過內網IP通信。
Flannel 的原理是爲每個 host 分配一個 subnet，容器從此 subnet 中分配 IP，這些 IP 可以在 host 間路由，容器間無需 NAT 和 port mapping 就可以跨主機通信。每個 subnet 都是從一個更大的 IP 池中劃分的，Flannel 會在每個 host 上面運行一個守護進程 flanneld，其職責就是從大池子中分配 subnet，爲了各個主機間共享信息。Flannel 用 ETCD 存放網絡配置、已分配的 subnet、host 的 IP 等信息。
Flannel 的節點間有三種通信方式：
VXLAN：默認配置，利用內核級別的 VXLAN 來封裝 host 之間傳送的包
Host-gw：二層網絡配置，不支持雲環境，通過在 host 的路由表中直接創建到其他主機 subnet 的路由條目
UDP：通常用於 debug
我們在所有的業務物理機上都部署了 Flannel，並且啓動 Flanneld 服務，使之加入 K8S 虛擬網絡，這樣物理機上的服務與 K8S 裏的容器服務在互相調用時，就可以通過 Flannel+Kube-proxy 的虛擬網絡。整體結構圖如下：
流量 1 是部署在物理機和 K8S 容器裏的應用註冊服務的線路
流量 2 是兩個物理機節點互相調用時的線路
流量 3 是物理機節點調用 K8S 容器應用時的線路，反之 app3 調用 app1 時就會直接訪問 app1 所在的物理機 IP
第二階段：K8S + Flannel+ VPN-server
爲了加速大交通業務微服務和容器化的落地，我們在團隊內部完成了開發環境容器化的改造，並將所有流量全部遷移到 K8S 編排系統上。
大交通整體的微服務改造基於 Dubbo。瞭解的朋友都知道，Dubbo 服務中 Consumer 和 Provider 的通訊很常見，對應到我們的場景就有了本地 Dubbo 服務 (Consumer) 消費開發環境微服務 (Provider) ，以及本地遠程 debug 開發環境的情況。但是 Dubbo consumer 從註冊中心拿到的都是容器的虛擬網絡 IP，在集羣外的真實網絡環境里根本訪問不通。
爲了解決這個問題，提高開發與聯調效率，我們開始了第一次 K8S 容器網絡方案的改造。
我們設想，既然一個公司的員工可以通過撥通 VPN，從公網進入到公司的內網，那如果在 K8S 集羣內部署一個 OpenVPN 的 Server，是不是也可以從集羣外進入到集羣的內網之中？實現思路如下圖所示：
我們在集羣的 middleware 空間下以 nodeport 的方式部署了 VPN Server，並給客戶端分配了 10.140 的網段
當客戶端通過 172.18.12.21:30030 撥通 VPN時，客戶端與 VPN Server 間的網絡被打通
因爲 VPN Server 本身處於集羣虛擬網絡環境中，所以其他容器的 IP 對於 vpn server 是可見的，因此撥通 VPN 後，VPN 客戶端就可以直接對集羣內的 Pod 進行訪問
改造後開發環境與機房 K8S 集羣之間的網絡架構圖如下所示：
通過在 K8S 集羣裏架設 OpenVPN，我們暫時解決了辦公區對機房 K8S 集羣的 RPC 通訊問題。該方案的優缺點如下：
優點：
快速實現
工程量小
網絡隔離，證書驗證更安全
不足：
操作略繁瑣，如使用時需要申請證書，安裝客戶端軟件；每次使用前需要先打開 OpenVPN
是一種中間方案，沒有從本質上解決問題
第三階段：基於 MAC-VLAN 的 K8S CNI
爲了更好地支持 Java 業務的微服務改造，避免重複造輪子，我們構建了統一的 Java 基礎平臺，之前的網絡方案也面向更多的部門提供服務。
隨着服務的業務和人員越來越多，由人工操作帶來的不便和問題越來越明顯，我們決定對 K8S 網絡進行再一次改造。從之前的經驗中我們感到，如果 K8S 的虛擬網絡不去除，容器服務的 IP 是不可能直接由集羣外的真實網絡到達的。
爲了快速滿足不同業務場景下對於 K8S 網絡功能的需求，我們開始深入研究 CNI。
關於 CNI
CNI (Conteinre Network Interface) 旨在爲容器平臺提供統一的網絡標準，由 Google 和 CoreOS 主導制定。它本身並不是一個完整的解決方案或者程序代碼，而是綜合考慮了靈活性、擴展性、IP 分配、多網卡等因素後，在 RKT 的基礎上發展起來的一種容器網絡接口協議。
CNI 的網絡分類和主流的實現工具主要包括：
第⼀類：與宿主機平⾏⽹絡（2 層⽹絡或 3 層⽹絡），⽹絡插件主要包括 Bridge、MAC-VLAN 、IP-VLAN、Calico BGP、Flannel host-GW 等
第⼆類：利⽤ SDN 技術的虛擬⽹絡，⽹絡插件主要有：Flannel vxlan、Calico ipip、Weave 等
MAC-VLAN 及其帶來的問題
通過對比測試，考慮到當下需求，我們最終決定基於網絡改造、運維成本和複雜度都較低的 MAC-VLAN 方案：
MAC-VLAN 具有 Linux Kernal 的特性，用於給一個物理網絡接口（parent）配置虛擬化接口。虛擬化接口與 parent 網絡接口擁有不同的 mac 地址，但 parent 接口上收到發給其對應的虛擬化接口的 mac 包時，會分發給對應的虛擬化接口，有點像將虛擬化接口和 parent 接口進行了「橋接」，使虛擬化網絡接口在配置了 IP 和路由後就能互相訪問。
在 MAC-VLAN 場景下，K8S 容器訪問可能會遇到一些問題，比如配置 MAC-VLAN 後，容器不能訪問 parent 接口的 IP。
通過調研，發現有以下兩種解決方案：
1. 虛擬網卡：打開網卡混雜模式，通過在宿主機上虛擬出一個虛擬網卡，將虛擬網卡與宿主機真實網卡聚合綁定
2. PTP 方案：類似 Bridge 的簡化版，但是網絡配置更復雜，並且有一些配置在自測過程中發現並沒有太大用處。與 Bridge 主要的不同是 PTP 不使用網橋，而是直接使用 vethpair+路由配置。
通過對比兩種方案的可實施性，最終我們選擇了第一種方案，但是第一種方案在虛擬機環境中經過測試發現偶爾會有宿主機與本機容器不通的現象，建議採用第一種方案的同學儘量不要使用虛擬機環境（懷疑還是網卡混雜設置的問題）。
「分區而治」的網絡改造
K8S 的核心組件 KubeDNS 在啓動時默認會訪問 ClusterIP 段的第一個 IP；如果繼續使用原有的 Nginx-ingress，那麼 Nginx-ingress 的容器在啓動時也是使用 ClusterIP 去連接 KubeDNS 。而使用 MAC-VLAN 給 KubeDNS 和 Nginx-ingress 分配的都是真實網絡 IP，他們是無法聯通 ClusterIP 的，所以 KubeDNS 和 Nginx-ingress 容器又不能使用 MAC-VLAN 方案，否則容器服務的域名訪問能力將喪失。
綜合考慮之下，最終我們採取了「分區而治」的措施，將不同類別的容器調度到不同的區域，使用不同的網絡方案，大致的圖解如下：
採用 MAC-VLAN 方案時容器 IP 的分配方案有兩種：DHCP 和 host-local。考慮到公司目前沒有統一的 DHCP 和 IPAM 服務器爲容器分配 IP，開發環境的機器數量不多，我們就採用了人工參與每個節點的網絡 IP 段分配。
綜上，此次改造後的網絡架構圖大致如下：
效果
可以看到與第一次網絡改造的架構圖對比：
宿主機 1 和宿主機 2 上已經拋棄了 Kube-proxy 和 Flannel 這些虛擬網絡的組件
宿主機 1 和宿主機 2 這些業務容器節點直接使用了公司公共 DNS 設施
辦公區本地 consumer 服務在註冊中心拿到 provider 的 IP 後，可以直接連接消費，反之亦可
K8S 集羣分爲了虛擬網絡區 (運行 K8S 集羣管理組件) 和真實網絡區 (運行業務容器)
此次改造的優勢和不足總結爲：
優點：
遠程 debug
辦公網與集羣內服務間的 RPC,TCP 通訊在二層網絡中打通
網絡延遲大大降低
支持多機房容災部署
缺點：
工程量大
需要耗費大量真實 IP 地址
集羣規模很大時，存在 ARP 廣播風暴和交換機 MAC 表超限風險
Part.3
近期優化方向
每一次挑戰都是進步的基石。K8S 網絡系統自上線以來，極大提高了 Java 業務容器化的運維效率，降低了運維成本，同時提供了更靈活、更穩定的服務運行環境。
在使用和改造 K8S 網絡的過程中, 我們也遇到了很多問題，比如服務的優雅上下線、容器 HPA 的設定規則、容器模版的多樣化支持等等，近期我們將重點針對以下幾方面近一步優化和改進：
1. 生產環境逐步進行網絡改造，並實現集羣多機房部署，提高容災能力
2. 對第二次網絡改造中的虛擬網絡區中的 Nginx-ingress 二次開發，使其支持使用公司公共 DNS，並且廢棄 SVC，徹底拋棄虛擬網絡的使用
本文作者：張小伍，馬蜂窩旅遊網交酒平臺研發工程師。
（責任編輯：於雪）
End
你可能還想看：
你「在看」我嗎？
