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