使用 Docker+Kubernetes 來(lái)簡(jiǎn)化開(kāi)發(fā)人員的工作流，使應(yīng)用更加快速地迭代，縮短發(fā)布周期，在很多研發(fā)團(tuán)隊(duì)中已經(jīng)是常見(jiàn)的做法。

[[286219]]

如果說(shuō) Docker 提供的是應(yīng)用級(jí)的主機(jī)抽象，那么 Kubernetes 的作用就是應(yīng)用級(jí)的集群抽象，提供容器集群運(yùn)行所需的基礎(chǔ)設(shè)施，旨在解決容器化應(yīng)用的資源調(diào)度、部署運(yùn)行、服務(wù)發(fā)現(xiàn)、擴(kuò)容縮容等問(wèn)題。

一直以來(lái)，容器網(wǎng)絡(luò)設(shè)計(jì)都被認(rèn)為是非常重要，但相對(duì)復(fù)雜的部分。 本文要介紹的 Kubernetes 網(wǎng)絡(luò)，目前主要為馬蜂窩旅游網(wǎng)大多數(shù) Java 業(yè)務(wù)提供開(kāi)發(fā)環(huán)境的底層基礎(chǔ)設(shè)施。隨著團(tuán)隊(duì)的調(diào)整及業(yè)務(wù)需求升級(jí)，整個(gè)系統(tǒng)對(duì)網(wǎng)絡(luò)架構(gòu)的要求也越來(lái)越嚴(yán)苛?；谶@樣的背景，Kubernetes 網(wǎng)絡(luò)過(guò)去一年多經(jīng)歷了兩次比較重要的改造，以期不斷降低運(yùn)維調(diào)試成本，提高研發(fā)效率。

借由本文分享我們的實(shí)踐經(jīng)驗(yàn)，與君共勉。

Part.1.K8S 網(wǎng)絡(luò)原理及挑戰(zhàn)

1. Kubernetes Pod 設(shè)計(jì)

Pod 是 Kubernetes 的基本調(diào)度單元，我們可以將 Pod 認(rèn)為是容器的一種延伸擴(kuò)展，一個(gè) Pod 也是一個(gè)隔離體，而 Pod 內(nèi)部又包含一組共享的容器。

每個(gè) Pod 中的容器由一個(gè)特殊的 Pause 容器，及一個(gè)或多個(gè)緊密相關(guān)的業(yè)務(wù)容器組成。Pause 容器是 Pod 的根容器，對(duì)應(yīng)的鏡像屬于 Kubernetes 平臺(tái)的一部分，以它的狀態(tài)代表整個(gè)容器組的狀態(tài)。同一個(gè) Pod 里的容器之間僅需通過(guò) localhost 就能互相通信。

每個(gè) Pod 會(huì)被 Kubernetes 網(wǎng)絡(luò)組件分配一個(gè)唯一的(在集群內(nèi)的 IP 地址，稱為 Pod IP，這樣就允許不同 Pod 中的服務(wù)可以使用同一端口(同一個(gè) Pod 中端口只能被一個(gè)服務(wù)占用)，避免了發(fā)生端口沖突的問(wèn)題。

2. 挑戰(zhàn)

Pod 的 IP 是在 Kubernetes 集群內(nèi)的，是虛擬且局域的。這就帶來(lái)一個(gè)問(wèn)題，Pod IP 在集群內(nèi)部訪問(wèn)沒(méi)有問(wèn)題，但在實(shí)際項(xiàng)目開(kāi)發(fā)中，難免會(huì)有真實(shí)網(wǎng)絡(luò)環(huán)境下的應(yīng)用需要訪問(wèn) Kubernetes 集群里的容器，這就需要我們做一些額外的工作。

本文將結(jié)合我們開(kāi)發(fā)環(huán)境下基于 K8S 容器網(wǎng)絡(luò)演進(jìn)的過(guò)程，介紹在 Pod IP 為虛擬或真實(shí) IP 情況下的幾種直接訪問(wèn) Pod IP 的解決方案。

Part.2.基于K8S的容器網(wǎng)絡(luò)演進(jìn)

第一階段：K8S + Flannel

最早，我們的網(wǎng)絡(luò)設(shè)計(jì)方案只服務(wù)于大交通業(yè)務(wù)。初期大交通的 Java 應(yīng)用是部署在物理機(jī)上的，團(tuán)隊(duì)內(nèi)部容器相關(guān)的底層基礎(chǔ)設(shè)施幾乎為 0。為了更加平穩(wěn)地實(shí)現(xiàn)容器化的落地，中間我們沒(méi)有直接把服務(wù)全部遷移到 K8S 中去，而是經(jīng)歷了一段混跑。

這個(gè)過(guò)程中必然會(huì)有物理機(jī)上的 Java 應(yīng)用訪問(wèn) K8S 里 Java 容器的情況(一個(gè)注冊(cè)中心)。當(dāng)時(shí)我們選用的網(wǎng)絡(luò)架構(gòu)是 Flannel VXLAN + Kube-proxy，主要是考慮到 Flannel 的簡(jiǎn)潔性。

Flannel 是為 K8S 設(shè)計(jì)的一個(gè)非常簡(jiǎn)潔的多節(jié)點(diǎn)三層網(wǎng)絡(luò)方案，主要用于解決容器的跨主機(jī)通信問(wèn)題，是一個(gè)比較大一統(tǒng)的方案。它的設(shè)計(jì)目的是為集群中的所有節(jié)點(diǎn)重新規(guī)劃 IP 地址的使用規(guī)則，從而使得不同節(jié)點(diǎn)上的容器能夠獲得「同屬一個(gè)內(nèi)網(wǎng)」且「不重復(fù)的」IP地址，并讓屬于不同節(jié)點(diǎn)上的容器能夠直接通過(guò)內(nèi)網(wǎng)IP通信。

Flannel 的原理是為每個(gè) host 分配一個(gè) subnet，容器從此 subnet 中分配 IP，這些 IP 可以在 host 間路由，容器間無(wú)需 NAT 和 port mapping 就可以跨主機(jī)通信。每個(gè) subnet 都是從一個(gè)更大的 IP 池中劃分的，F(xiàn)lannel 會(huì)在每個(gè) host 上面運(yùn)行一個(gè)守護(hù)進(jìn)程 flanneld，其職責(zé)就是從大池子中分配 subnet，為了各個(gè)主機(jī)間共享信息。Flannel 用 ETCD 存放網(wǎng)絡(luò)配置、已分配的 subnet、host 的 IP 等信息。

Flannel 的節(jié)點(diǎn)間有三種通信方式：

• VXLAN：默認(rèn)配置，利用內(nèi)核級(jí)別的 VXLAN 來(lái)封裝 host 之間傳送的包
• Host-gw：二層網(wǎng)絡(luò)配置，不支持云環(huán)境，通過(guò)在 host 的路由表中直接創(chuàng)建到其他主機(jī) subnet 的路由條目
• UDP：通常用于 debug

我們?cè)谒械臉I(yè)務(wù)物理機(jī)上都部署了 Flannel，并且啟動(dòng) Flanneld 服務(wù)，使之加入 K8S 虛擬網(wǎng)絡(luò)，這樣物理機(jī)上的服務(wù)與 K8S 里的容器服務(wù)在互相調(diào)用時(shí)，就可以通過(guò) Flannel+Kube-proxy 的虛擬網(wǎng)絡(luò)。整體結(jié)構(gòu)圖如下：

• 流量 1 是部署在物理機(jī)和 K8S 容器里的應(yīng)用注冊(cè)服務(wù)的線路
• 流量 2 是兩個(gè)物理機(jī)節(jié)點(diǎn)互相調(diào)用時(shí)的線路
• 流量 3 是物理機(jī)節(jié)點(diǎn)調(diào)用 K8S 容器應(yīng)用時(shí)的線路，反之 app3 調(diào)用 app1 時(shí)就會(huì)直接訪問(wèn) app1 所在的物理機(jī) IP

第二階段：K8S + Flannel+ VPN-server

為了加速大交通業(yè)務(wù)微服務(wù)和容器化的落地，我們?cè)趫F(tuán)隊(duì)內(nèi)部完成了開(kāi)發(fā)環(huán)境容器化的改造，并將所有流量全部遷移到 K8S 編排系統(tǒng)上。

大交通整體的微服務(wù)改造基于 Dubbo。了解的朋友都知道，Dubbo 服務(wù)中 Consumer 和 Provider 的通訊很常見(jiàn)，對(duì)應(yīng)到我們的場(chǎng)景就有了本地 Dubbo 服務(wù) (Consumer) 消費(fèi)開(kāi)發(fā)環(huán)境微服務(wù) (Provider) ，以及本地遠(yuǎn)程 debug 開(kāi)發(fā)環(huán)境的情況。但是 Dubbo consumer 從注冊(cè)中心拿到的都是容器的虛擬網(wǎng)絡(luò) IP，在集群外的真實(shí)網(wǎng)絡(luò)環(huán)境里根本訪問(wèn)不通。

為了解決這個(gè)問(wèn)題，提高開(kāi)發(fā)與聯(lián)調(diào)效率，我們開(kāi)始了第一次 K8S 容器網(wǎng)絡(luò)方案的改造。

我們?cè)O(shè)想，既然一個(gè)公司的員工可以通過(guò)撥通 VPN，從公網(wǎng)進(jìn)入到公司的內(nèi)網(wǎng)，那如果在 K8S 集群內(nèi)部署一個(gè) OpenVPN 的 Server，是不是也可以從集群外進(jìn)入到集群的內(nèi)網(wǎng)之中?實(shí)現(xiàn)思路如下圖所示：

• 我們?cè)诩旱?middleware 空間下以 nodeport 的方式部署了 VPN Server，并給客戶端分配了 10.140 的網(wǎng)段
• 當(dāng)客戶端通過(guò) 172.18.12.21:30030 撥通 VPN時(shí)，客戶端與 VPN Server 間的網(wǎng)絡(luò)被打通
• 因?yàn)?VPN Server 本身處于集群虛擬網(wǎng)絡(luò)環(huán)境中，所以其他容器的 IP 對(duì)于 vpn server 是可見(jiàn)的，因此撥通 VPN 后，VPN 客戶端就可以直接對(duì)集群內(nèi)的 Pod 進(jìn)行訪問(wèn)

改造后開(kāi)發(fā)環(huán)境與機(jī)房 K8S 集群之間的網(wǎng)絡(luò)架構(gòu)圖如下所示：

通過(guò)在 K8S 集群里架設(shè) OpenVPN，我們暫時(shí)解決了辦公區(qū)對(duì)機(jī)房 K8S 集群的 RPC 通訊問(wèn)題。該方案的優(yōu)缺點(diǎn)如下：

優(yōu)點(diǎn)：

• 快速實(shí)現(xiàn)
• 工程量小
• 網(wǎng)絡(luò)隔離，證書(shū)驗(yàn)證更安全

不足：

• 操作略繁瑣，如使用時(shí)需要申請(qǐng)證書(shū)，安裝客戶端軟件;每次使用前需要先打開(kāi) OpenVPN
• 是一種中間方案，沒(méi)有從本質(zhì)上解決問(wèn)題

第三階段：基于 MAC-VLAN 的 K8S CNI

為了更好地支持 Java 業(yè)務(wù)的微服務(wù)改造，避免重復(fù)造輪子，我們構(gòu)建了統(tǒng)一的 Java 基礎(chǔ)平臺(tái)，之前的網(wǎng)絡(luò)方案也面向更多的部門提供服務(wù)。

隨著服務(wù)的業(yè)務(wù)和人員越來(lái)越多，由人工操作帶來(lái)的不便和問(wèn)題越來(lái)越明顯，我們決定對(duì) K8S 網(wǎng)絡(luò)進(jìn)行再一次改造。從之前的經(jīng)驗(yàn)中我們感到，如果 K8S 的虛擬網(wǎng)絡(luò)不去除，容器服務(wù)的 IP 是不可能直接由集群外的真實(shí)網(wǎng)絡(luò)到達(dá)的。

為了快速滿足不同業(yè)務(wù)場(chǎng)景下對(duì)于 K8S 網(wǎng)絡(luò)功能的需求，我們開(kāi)始深入研究 CNI。

關(guān)于 CNI

CNI (Conteinre Network Interface) 旨在為容器平臺(tái)提供統(tǒng)一的網(wǎng)絡(luò)標(biāo)準(zhǔn)，由 Google 和 CoreOS 主導(dǎo)制定。它本身并不是一個(gè)完整的解決方案或者程序代碼，而是綜合考慮了靈活性、擴(kuò)展性、IP 分配、多網(wǎng)卡等因素后，在 RKT 的基礎(chǔ)上發(fā)展起來(lái)的一種容器網(wǎng)絡(luò)接口協(xié)議。

CNI 的網(wǎng)絡(luò)分類和主流的實(shí)現(xiàn)工具主要包括：

第一類：與宿主機(jī)平行網(wǎng)絡(luò)(2 層網(wǎng)絡(luò)或 3 層網(wǎng)絡(luò))，網(wǎng)絡(luò)插件主要包括 Bridge、MAC-VLAN 、IP-VLAN、Calico BGP、Flannel host-GW 等 

第二類：利用SDN 技術(shù)的虛擬網(wǎng)絡(luò)，網(wǎng)絡(luò)插件主要有：Flannel vxlan、Calico ipip、Weave 等

MAC-VLAN 及其帶來(lái)的問(wèn)題

通過(guò)對(duì)比測(cè)試，考慮到當(dāng)下需求，我們最終決定基于網(wǎng)絡(luò)改造、運(yùn)維成本和復(fù)雜度都較低的 MAC-VLAN 方案：

MAC-VLAN 具有 Linux Kernal 的特性，用于給一個(gè)物理網(wǎng)絡(luò)接口(parent)配置虛擬化接口。虛擬化接口與 parent 網(wǎng)絡(luò)接口擁有不同的 mac 地址，但 parent 接口上收到發(fā)給其對(duì)應(yīng)的虛擬化接口的 mac 包時(shí)，會(huì)分發(fā)給對(duì)應(yīng)的虛擬化接口，有點(diǎn)像將虛擬化接口和 parent 接口進(jìn)行了「橋接」，使虛擬化網(wǎng)絡(luò)接口在配置了 IP 和路由后就能互相訪問(wèn)。

在 MAC-VLAN 場(chǎng)景下，K8S 容器訪問(wèn)可能會(huì)遇到一些問(wèn)題，比如配置 MAC-VLAN 后，容器不能訪問(wèn) parent 接口的 IP。

通過(guò)調(diào)研，發(fā)現(xiàn)有以下兩種解決方案：

1. 虛擬網(wǎng)卡：打開(kāi)網(wǎng)卡混雜模式，通過(guò)在宿主機(jī)上虛擬出一個(gè)虛擬網(wǎng)卡，將虛擬網(wǎng)卡與宿主機(jī)真實(shí)網(wǎng)卡聚合綁定

2. PTP 方案：類似 Bridge 的簡(jiǎn)化版，但是網(wǎng)絡(luò)配置更復(fù)雜，并且有一些配置在自測(cè)過(guò)程中發(fā)現(xiàn)并沒(méi)有太大用處。與 Bridge 主要的不同是 PTP 不使用網(wǎng)橋，而是直接使用 vethpair+路由配置。

通過(guò)對(duì)比兩種方案的可實(shí)施性，最終我們選擇了第一種方案，但是第一種方案在虛擬機(jī)環(huán)境中經(jīng)過(guò)測(cè)試發(fā)現(xiàn)偶爾會(huì)有宿主機(jī)與本機(jī)容器不通的現(xiàn)象，建議采用第一種方案的同學(xué)盡量不要使用虛擬機(jī)環(huán)境(懷疑還是網(wǎng)卡混雜設(shè)置的問(wèn)題)。

「分區(qū)而治」的網(wǎng)絡(luò)改造

K8S 的核心組件 KubeDNS 在啟動(dòng)時(shí)默認(rèn)會(huì)訪問(wèn) ClusterIP 段的第一個(gè) IP;如果繼續(xù)使用原有的 Nginx-ingress，那么 Nginx-ingress 的容器在啟動(dòng)時(shí)也是使用 ClusterIP 去連接 KubeDNS 。而使用 MAC-VLAN 給 KubeDNS 和 Nginx-ingress 分配的都是真實(shí)網(wǎng)絡(luò) IP，他們是無(wú)法聯(lián)通 ClusterIP 的，所以 KubeDNS 和 Nginx-ingress 容器又不能使用 MAC-VLAN 方案，否則容器服務(wù)的域名訪問(wèn)能力將喪失。

綜合考慮之下，最終我們采取了「分區(qū)而治」的措施，將不同類別的容器調(diào)度到不同的區(qū)域，使用不同的網(wǎng)絡(luò)方案，大致的圖解如下：

采用 MAC-VLAN 方案時(shí)容器 IP 的分配方案有兩種：DHCP 和 host-local。考慮到公司目前沒(méi)有統(tǒng)一的 DHCP 和 IPAM 服務(wù)器為容器分配 IP，開(kāi)發(fā)環(huán)境的機(jī)器數(shù)量不多，我們就采用了人工參與每個(gè)節(jié)點(diǎn)的網(wǎng)絡(luò) IP 段分配。

綜上，此次改造后的網(wǎng)絡(luò)架構(gòu)圖大致如下：

效果

可以看到與第一次網(wǎng)絡(luò)改造的架構(gòu)圖對(duì)比：

• 宿主機(jī) 1 和宿主機(jī) 2 上已經(jīng)拋棄了 Kube-proxy 和 Flannel 這些虛擬網(wǎng)絡(luò)的組件
• 宿主機(jī) 1 和宿主機(jī) 2 這些業(yè)務(wù)容器節(jié)點(diǎn)直接使用了公司公共 DNS 設(shè)施
• 辦公區(qū)本地 consumer 服務(wù)在注冊(cè)中心拿到 provider 的 IP 后，可以直接連接消費(fèi)，反之亦可
• K8S 集群分為了虛擬網(wǎng)絡(luò)區(qū) (運(yùn)行 K8S 集群管理組件) 和真實(shí)網(wǎng)絡(luò)區(qū) (運(yùn)行業(yè)務(wù)容器)

此次改造的優(yōu)勢(shì)和不足總結(jié)為：

優(yōu)點(diǎn)：

• 遠(yuǎn)程 debug
• 辦公網(wǎng)與集群內(nèi)服務(wù)間的 RPC,TCP 通訊在二層網(wǎng)絡(luò)中打通
• 網(wǎng)絡(luò)延遲大大降低
• 支持多機(jī)房容災(zāi)部署

缺點(diǎn)：

• 工程量大
• 需要耗費(fèi)大量真實(shí) IP 地址
• 集群規(guī)模很大時(shí)，存在 ARP 廣播風(fēng)暴和交換機(jī) MAC 表超限風(fēng)險(xiǎn)

Part.3.近期優(yōu)化方向

每一次挑戰(zhàn)都是進(jìn)步的基石。K8S 網(wǎng)絡(luò)系統(tǒng)自上線以來(lái)，極大提高了 Java 業(yè)務(wù)容器化的運(yùn)維效率，降低了運(yùn)維成本，同時(shí)提供了更靈活、更穩(wěn)定的服務(wù)運(yùn)行環(huán)境。

在使用和改造 K8S 網(wǎng)絡(luò)的過(guò)程中, 我們也遇到了很多問(wèn)題，比如服務(wù)的優(yōu)雅上下線、容器 HPA 的設(shè)定規(guī)則、容器模版的多樣化支持等等，近期我們將重點(diǎn)針對(duì)以下幾方面近一步優(yōu)化和改進(jìn)：

1. 生產(chǎn)環(huán)境逐步進(jìn)行網(wǎng)絡(luò)改造，并實(shí)現(xiàn)集群多機(jī)房部署，提高容災(zāi)能力

2. 對(duì)第二次網(wǎng)絡(luò)改造中的虛擬網(wǎng)絡(luò)區(qū)中的 Nginx-ingress 二次開(kāi)發(fā)，使其支持使用公司公共 DNS，并且廢棄 SVC，徹底拋棄虛擬網(wǎng)絡(luò)的使用

【本文是51CTO專欄作者馬蜂窩技術(shù)的原創(chuàng)文章，作者微信公眾號(hào)馬蜂窩技術(shù)(ID：mfwtech)】 

戳這里，看該作者更多好文