馬蜂窩技術原創文章，更多干貨請搜索公眾號：mfwtech

使用 Docker+Kubernetes 來簡化開發人員的作業流，使應用更加快速地迭代，縮短發布周期，在很多研發團隊中已經是常見的做法，

如果說 Docker 提供的是應用級的主機抽象，那么 Kubernetes 的作用就是應用級的集群抽象，提供容器集群運行所需的基礎設施，旨在解決容器化應用的資源調度、部署運行、服務發現、擴容縮容等問題，

一直以來，容器網路設計都被認為是非常重要，但相對復雜的部分， 本文要介紹的 Kubernetes 網路，目前主要為馬蜂窩旅游網大多數 Java 業務提供開發環境的底層基礎設施，隨著團隊的調整及業務需求升級，整個系統對網路架構的要求也越來越嚴苛，基于這樣的背景，Kubernetes 網路過去一年多經歷了兩次比較重要的改造，以期不斷降低運維除錯成本，提高研發效率，

借由本文分享我們的實踐經驗，與君共勉，

Part.1 Kubernetes 網路原理及挑戰

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 基于 Kubernetes 的容器網路演進

第一階段：Kubernetes + 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

第二階段：Kubernetes + 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 的 Kubernetes 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，徹底拋棄虛擬網路的使用

本文作者：張小伍，馬蜂窩旅游網交酒平臺研發工程師，

標籤：其他

上一篇：AWS re:Invent 2019參會有感

下一篇：記錄：一次使用私有LoadBalance provider，工具metallb的故障排除