王華偉

（1．北京全路通信信號(hào)研究設(shè)計(jì)院集團(tuán)有限公司，北京 100070；2．北京市高速鐵路運(yùn)行控制系統(tǒng)工程技術(shù)研究中心，北京 100070）

1 概述

鐵路信息系統(tǒng)是以運(yùn)輸組織、客貨營(yíng)銷、經(jīng)營(yíng)管理為信息化建設(shè)重點(diǎn)，以實(shí)現(xiàn)調(diào)度指揮智能化、客貨營(yíng)銷社會(huì)化、經(jīng)營(yíng)管理現(xiàn)代化為目標(biāo)的人機(jī)系統(tǒng)。

隨著市場(chǎng)經(jīng)濟(jì)的持續(xù)高速發(fā)展、國(guó)家產(chǎn)業(yè)的結(jié)構(gòu)不斷優(yōu)化調(diào)整，鐵路信息系統(tǒng)已開始為越來(lái)越多的領(lǐng)域提供服務(wù)，如何以最小成本、最快速度滿足鐵路及周邊領(lǐng)域日益增長(zhǎng)的業(yè)務(wù)需求，是業(yè)內(nèi)人不斷研究的技術(shù)方向之一。

在傳統(tǒng)的鐵路信息系統(tǒng)的建設(shè)模式下，為滿足系統(tǒng)的運(yùn)行性能及運(yùn)行高可用，往往使完成某項(xiàng)特定任務(wù)的應(yīng)用程序組獨(dú)占兩臺(tái)高可用集群的服務(wù)器，使系統(tǒng)在日常運(yùn)行中，大部分服務(wù)器負(fù)載很低，造成硬件資源的嚴(yán)重浪費(fèi)；另一方面，每個(gè)系統(tǒng)在建設(shè)時(shí)，都需要進(jìn)行設(shè)備集成、操作系統(tǒng)安裝、軟件平臺(tái)實(shí)施、業(yè)務(wù)系統(tǒng)軟件部署、功能測(cè)試等多個(gè)步驟，導(dǎo)致建設(shè)周期較長(zhǎng)。

為解決上述問(wèn)題，多個(gè)建設(shè)單位引入了虛擬機(jī)云平臺(tái)，將業(yè)務(wù)部署在云平臺(tái)上的虛擬機(jī)，以達(dá)到提高硬件資源利用率、業(yè)務(wù)系統(tǒng)快速發(fā)布的目的。但虛擬機(jī)云平臺(tái)依然較重，且對(duì)比物理服務(wù)器，在運(yùn)行速度上有所損耗，原因如下。

1）為能對(duì)資源統(tǒng)一管理，云平臺(tái)依然需要在物理服務(wù)器上部署獨(dú)立的專用操作系統(tǒng)。然后在其上發(fā)布虛擬機(jī)，為虛擬機(jī)安裝操作系統(tǒng)。云平臺(tái)本身會(huì)占用不少的硬件資源。

2）一般單獨(dú)的一臺(tái)虛擬機(jī)仍然需占用幾GB至幾十GB的空間，依然會(huì)有資源浪費(fèi)在虛擬機(jī)的操作系統(tǒng)上。

3）云平臺(tái)為虛擬機(jī)增加了一層虛擬硬件層，導(dǎo)致應(yīng)用程序運(yùn)行時(shí)性能有所損失。

容器技術(shù)的出現(xiàn)很好地解決了上述問(wèn)題。容器相比虛擬機(jī)，守護(hù)進(jìn)程可以直接與主操作系統(tǒng)進(jìn)行通信，為各個(gè)容器分配本來(lái)屬于主操作系統(tǒng)的資源，保證了性能；另外由于沒有臃腫的從操作系統(tǒng)，容器可以節(jié)省大量的磁盤空間以及其他系統(tǒng)資源。

同時(shí)，容器幾乎可以在任意平臺(tái)上運(yùn)行，包括虛擬機(jī)、物理機(jī)、公有云、私有云、個(gè)人電腦、服務(wù)器等，可移植性非常好。

由于容器的優(yōu)異性，出現(xiàn)了很多致力于優(yōu)化容器使用的技術(shù)，K8S就是其中最有代表性的技術(shù)。K8S是一個(gè)容器集群管理系統(tǒng)，主要職責(zé)是容器編排，包括啟動(dòng)容器、自動(dòng)化部署、擴(kuò)展和管理容器應(yīng)用、回收容器等。

本文重點(diǎn)研究基于K8S平臺(tái)實(shí)現(xiàn)鐵路信息系統(tǒng)工程化的網(wǎng)絡(luò)。

2 K8S網(wǎng)絡(luò)模型分析

在K8S中，最小的管理單元是Pod，一個(gè)主機(jī)可以運(yùn)行多個(gè)Pod，一個(gè)Pod里面可以運(yùn)行多個(gè)容器。

每個(gè)pod都擁有一個(gè)獨(dú)立的IP地址，而且所有pod都在一個(gè)可以直接連通的、扁平的網(wǎng)絡(luò)空間中。所以不管這些pod是否運(yùn)行在同一個(gè)主機(jī)中，都可以直接通過(guò)對(duì)方的IP進(jìn)行訪問(wèn)。

在K8S的管理下，Pod故障后可以自動(dòng)重啟恢復(fù)，但重啟的位置有可能不在原來(lái)的主機(jī)上，且IP會(huì)發(fā)生變化。因此，K8S中衍生出Service。Service管理了一系列的Pods，每個(gè)Service有一個(gè)虛擬的IP，要訪問(wèn)Service管理的Pod上的服務(wù)只需要訪問(wèn)這個(gè)虛擬IP即可，這個(gè)虛擬IP固定不變。

綜上所述，對(duì)K8S網(wǎng)絡(luò)模型的分析可以從以下4方面分析。

2.1 Pod中容器的通信

如圖1所示，在Pod中，會(huì)自動(dòng)生成一個(gè)Pause容器，它有獨(dú)立的網(wǎng)絡(luò)命名空間（Network NameSpace），每在Pod中創(chuàng)建一個(gè)容器，該容器就會(huì)加入到Pause擁有的網(wǎng)絡(luò)命名空間中。

圖1 Pod中容器通信Fig.1 Container communication in Pod

新創(chuàng)建的容器不會(huì)創(chuàng)建自己的網(wǎng)卡，而是和Pause容器共享IP、端口范圍，同一個(gè)Pod中的容器由于共享網(wǎng)絡(luò)命名空間，之間可以通過(guò)localhost+端口的方式來(lái)互相訪問(wèn)。

2.2 相同主機(jī)中Pod的通信

每個(gè)Pod都會(huì)有自己的獨(dú)立IP，Pod之間的通信就可以像物理主機(jī)一樣通過(guò)IP進(jìn)行。

相同主機(jī)中的Pod通過(guò)主機(jī)系統(tǒng)中的虛擬網(wǎng)橋設(shè)備進(jìn)行通信。虛擬網(wǎng)橋設(shè)備可以通過(guò)由兩個(gè)虛擬接口組成的veth將不同的網(wǎng)絡(luò)命名空間鏈接起來(lái)，就像二層交換機(jī)一樣。

如圖2所示，每個(gè)Pod中的eth虛擬網(wǎng)卡與主機(jī)的veth設(shè)備組成veth對(duì)，就像一根網(wǎng)線一樣接入docker0虛擬網(wǎng)橋設(shè)備，同一主機(jī)上的Pod通過(guò)docker0進(jìn)行通信。他們的IP由docker0來(lái)分配，屬于同一網(wǎng)段，可以通過(guò)二層進(jìn)行交互。

圖2 相同主機(jī)Pod通信Fig.2 Pod communication in same host

2.3 不同主機(jī)中Pod的通信

在主機(jī)中，Pod與docker0網(wǎng)橋?qū)儆谕痪W(wǎng)段，而docker0網(wǎng)段與主機(jī)網(wǎng)卡是不同網(wǎng)段。不同主機(jī)之間的通信通過(guò)主機(jī)網(wǎng)卡進(jìn)行，因此，K8S會(huì)將所有正在運(yùn)行的Pod的IP分配信息等記錄在etcd（K8S采用分布式kv存儲(chǔ)系統(tǒng)）中，保證各節(jié)點(diǎn)主機(jī)可以對(duì)各個(gè)Pod進(jìn)行尋址。但如何保證在不使用NAT的情況下，不同主機(jī)上的Pod能互相跨網(wǎng)段通信仍是需要解決的問(wèn)題。

針對(duì)這個(gè)問(wèn)題，K8S有多種不同的技術(shù)實(shí)現(xiàn)方案，但總體框架較為相似。

如圖3所示，proxy是代理模塊，在不同的網(wǎng)絡(luò)實(shí)現(xiàn)方案中有不同的形式，有可能是TUN虛擬網(wǎng)絡(luò)設(shè)備，也有可能是數(shù)據(jù)處理模塊。

K8S網(wǎng)絡(luò)插件會(huì)根據(jù)不同的網(wǎng)段生成對(duì)應(yīng)的路由信息，在Pod1與Pod4通信時(shí)，數(shù)據(jù)包走到docker0后，會(huì)根據(jù)路由信息將包發(fā)送至proxy代理模塊，proxy代理模塊根據(jù)源地址、目的地址的關(guān)系對(duì)數(shù)據(jù)進(jìn)行封裝或修改，發(fā)送到主機(jī)網(wǎng)卡進(jìn)入物理網(wǎng)絡(luò)。在目的主機(jī)收到數(shù)據(jù)包后，也會(huì)優(yōu)先將數(shù)據(jù)包發(fā)送至proxy代理模塊進(jìn)行數(shù)據(jù)拆包或解析，根據(jù)路由信息送至docker0網(wǎng)橋。

2.4 Pod與Service的通信

在K8S中，Pod的IP不是持久不變的，當(dāng)集群中Pod故障或主機(jī)故障重啟后，Pod會(huì)進(jìn)行重啟，IP可能會(huì)發(fā)生變化。K8S通過(guò)Service來(lái)解決這個(gè)問(wèn)題，Service可以為其關(guān)聯(lián)的Pod提供負(fù)載均衡服務(wù)，且IP不變。

當(dāng)數(shù)據(jù)包到達(dá)Service的虛擬IP后，數(shù)據(jù)包會(huì)通過(guò)Service的負(fù)載均衡器路由到與其關(guān)聯(lián)的Pod中的容器。

如圖4所示，K8S根據(jù)Service的IP段在iptables上生成流量規(guī)則，在數(shù)據(jù)包從docker0發(fā)往eth0時(shí)，iptables會(huì)根據(jù)規(guī)則將目的IP由Service的IP地址隨機(jī)換成其Service下關(guān)聯(lián)的Pod的IP地址。

圖4 Pod向Service發(fā)送數(shù)據(jù)Fig.4 Pod sending data to Service

在數(shù)據(jù)包到達(dá)目的主機(jī)Pod，目的Pod進(jìn)行回包時(shí)，將源IP設(shè)為自己，目的IP設(shè)為Pod1的IP發(fā)送至源主機(jī)，源主機(jī)會(huì)進(jìn)行一個(gè)反向操作。

如圖5所示，數(shù)據(jù)包進(jìn)入源主機(jī)后，流經(jīng)iptables時(shí)，將數(shù)據(jù)包的源IP重寫為Service的IP，因此，在Pod1收到數(shù)據(jù)包時(shí)，依然認(rèn)為自己在和srv1進(jìn)行通信。

圖5 Service向Pod回包Fig.5 Service sending data back to Pod

3 K8S網(wǎng)絡(luò)工程化設(shè)計(jì)

通過(guò)第二節(jié)分析，可以看到，K8S的網(wǎng)絡(luò)模型融合了網(wǎng)絡(luò)命名空間、虛擬網(wǎng)絡(luò)設(shè)備、三層路由、NAT轉(zhuǎn)換、覆蓋網(wǎng)絡(luò)、負(fù)載均衡等多種技術(shù)，在這些技術(shù)保證下，可以構(gòu)建一個(gè)健壯、靈活的信息化工程網(wǎng)絡(luò)。接下來(lái)以構(gòu)建一個(gè)具備工程級(jí)應(yīng)用的K8S網(wǎng)絡(luò)為目的進(jìn)行設(shè)計(jì)，該網(wǎng)絡(luò)具有如下特點(diǎn)：

1）集群管理節(jié)點(diǎn)高可用；

2）業(yè)務(wù)服務(wù)可實(shí)現(xiàn)節(jié)點(diǎn)故障自動(dòng)恢復(fù)；

3）實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)；

4）能夠?qū)崿F(xiàn)業(yè)務(wù)服務(wù)對(duì)外部網(wǎng)絡(luò)提供接口。

3.1 整體設(shè)計(jì)

如圖6所示，為滿足K8S平臺(tái)的高可用，保證平臺(tái)管理系統(tǒng)的持續(xù)運(yùn)行，整體采用3+N的設(shè)計(jì)，即由3臺(tái)主機(jī)做管理Master節(jié)點(diǎn)，其余主機(jī)做Node工作節(jié)點(diǎn)，管理Master節(jié)點(diǎn)上也可以運(yùn)行容器服務(wù)。

圖6 K8S網(wǎng)絡(luò)工程化整體設(shè)計(jì)Fig.6 Overall design of K8S network engineering

3臺(tái)管理節(jié)點(diǎn)采用Haproxy實(shí)現(xiàn)四層負(fù)載均衡，滿足多節(jié)點(diǎn)訪問(wèn)需求，同時(shí)采用Keepalived實(shí)現(xiàn)服務(wù)的高可用，保證K8S平臺(tái)的不間斷運(yùn)行。

網(wǎng)絡(luò)方面，采用Flannel CNI網(wǎng)絡(luò)插件實(shí)現(xiàn)K8S的網(wǎng)絡(luò)模型。Flannel支持host-gw網(wǎng)關(guān)模式與VxLan隧道模式，也支持兩者混合的模式，同時(shí)能夠滿足同網(wǎng)段主機(jī)的高效率傳輸和跨網(wǎng)段主機(jī)的數(shù)據(jù)交換。

在實(shí)現(xiàn)上，規(guī)劃網(wǎng)絡(luò)平面如下：

1）物理主機(jī)網(wǎng)絡(luò)平面：192.168.0.0/24；

2）Service網(wǎng)絡(luò)平面：172.16.0.0/16；

3）Pod網(wǎng)絡(luò)平面：172.17.0.0/16。

利用K8S中Service資源對(duì)象實(shí)現(xiàn)業(yè)務(wù)服務(wù)之間的互相訪問(wèn)及負(fù)載均衡。

利用K8S中的CoreDns組件，實(shí)現(xiàn)業(yè)務(wù)之間的服務(wù)發(fā)現(xiàn)，增強(qiáng)靈活性。

3.2 管理節(jié)點(diǎn)的高可用

在K8S中，管理節(jié)點(diǎn)至關(guān)重要，是進(jìn)行容器編排、業(yè)務(wù)擴(kuò)容、服務(wù)HA、網(wǎng)絡(luò)訪問(wèn)的核心，在工程化應(yīng)用上，必須對(duì)其實(shí)現(xiàn)高可用。

K8S本身已具有了etcd、controller manager、scheduler等核心組件的高可用機(jī)制，只需要實(shí)現(xiàn)api server的高可用機(jī)制即可，保證各節(jié)點(diǎn)不間斷的調(diào)用管理節(jié)點(diǎn)的api。

五是走進(jìn)重點(diǎn)行業(yè)，到群眾關(guān)注的熱門領(lǐng)域宣傳。踐行以人民為中心的發(fā)展思想，以堅(jiān)決有力的態(tài)度和措施，對(duì)群眾反響強(qiáng)烈、深惡痛絕的黑惡勢(shì)力掀起了凌厲攻勢(shì)。組織旅發(fā)委、文化委、衛(wèi)計(jì)委、建交委等9個(gè)重點(diǎn)行業(yè)，深入3A級(jí)旅游景區(qū)——鵝嶺公園、解放碑得意世界廣場(chǎng)、重慶中醫(yī)骨科醫(yī)院等場(chǎng)所向景區(qū)游客、群眾宣傳掃黑除惡，倡議大家共同創(chuàng)建平安和諧的社會(huì)環(huán)境。進(jìn)一步營(yíng)造行業(yè)系統(tǒng)“人人參與掃黑除惡，人人共建平安渝中”的濃厚氛圍。

如圖7所示，在三臺(tái)管理節(jié)點(diǎn)上首先部署Haproxy實(shí)現(xiàn)三節(jié)點(diǎn)的負(fù)載均衡，以應(yīng)對(duì)大規(guī)模集群。Haproxy可以實(shí)現(xiàn)四層及七層的負(fù)載均衡，非常適合用在這里。其次，部署Keepalived實(shí)現(xiàn)高可用，在無(wú)法偵測(cè)到監(jiān)聽端口時(shí)實(shí)現(xiàn)VIP的漂移，保證服務(wù)的可持續(xù)性。

圖7 管理節(jié)點(diǎn)的高可用Fig.7 High availability of management nodes

3.3 業(yè)務(wù)服務(wù)Pod故障的自動(dòng)恢復(fù)

Pod故障的自動(dòng)恢復(fù)策略從兩點(diǎn)進(jìn)行考慮。

1）重啟策略

Always：當(dāng)容器終止退出后，總是重啟容器，這是默認(rèn)策略。

OnFailure：當(dāng)容器異常退出（退出狀態(tài)碼非0）時(shí)，才重啟容器。

Never：當(dāng)容器終止退出，從不重啟容器。

可以根據(jù)不同的應(yīng)用類型選擇不同的重啟策略，Always適合需要持續(xù)運(yùn)行的應(yīng)用，這也是信息系統(tǒng)中絕大部分應(yīng)用需要的，OnFailure適合短周期運(yùn)行的任務(wù)，如數(shù)據(jù)庫(kù)備份等。

2）健康檢查

選擇好存儲(chǔ)策略后，可以針對(duì)Pod中運(yùn)行服務(wù)進(jìn)行健康檢查，讓Pod根據(jù)服務(wù)的狀態(tài)決定是否處于running狀態(tài)。如果K8S檢查到Pod的狀態(tài)非running，會(huì)根據(jù)重啟策略對(duì)Pod執(zhí)行操作。

健康檢查支持3種檢查方法。

httpGet：發(fā)送HTTP請(qǐng)求，返回200～400范圍以內(nèi)的狀態(tài)碼，超過(guò)400就是錯(cuò)誤狀態(tài)碼。

exec：執(zhí)行shell命令來(lái)判斷狀態(tài)碼是0位成功。

tcpSocket：判斷TCP的端口狀態(tài)。

無(wú)端口監(jiān)聽的應(yīng)用可選擇使用exec進(jìn)行檢查，有端口監(jiān)聽的應(yīng)用可選擇使用tcpSocket進(jìn)行檢查。

3.4 服務(wù)發(fā)現(xiàn)

容器在K8S中進(jìn)行重啟、遷移等操作時(shí)，IP地址可能發(fā)生變化，通過(guò)Service資源代理后端的Pod，可以將IP固定下來(lái)。但I(xiàn)P地址難以記憶，且在生產(chǎn)環(huán)境中，可能需要對(duì)Service的IP重新進(jìn)行配置。為了不對(duì)正常運(yùn)行的業(yè)務(wù)造成影響，就需要通過(guò)服務(wù)發(fā)現(xiàn)功能讓應(yīng)用之間能互相定位。

K8S推薦采用Coredns來(lái)實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)功能。將Coredns采用Service方式部署在管理節(jié)點(diǎn)上，Pod副本數(shù)設(shè)置為2。

3.5 對(duì)外部網(wǎng)絡(luò)提供接口

K8S中的Pod網(wǎng)絡(luò)平面和Service網(wǎng)絡(luò)平面對(duì)于外部網(wǎng)絡(luò)來(lái)說(shuō)是未知的，無(wú)法訪問(wèn)，外部網(wǎng)絡(luò)只能訪問(wèn)到主機(jī)網(wǎng)絡(luò)平面。K8S可以通過(guò)將Service端口映射的方法給外部網(wǎng)絡(luò)訪問(wèn)。

本設(shè)計(jì)將主機(jī)專網(wǎng)中的兩臺(tái)主機(jī)配置成高可用負(fù)載均衡服務(wù)器為各接口Service提供代理，將接口Servcie暴露給外部網(wǎng)絡(luò)，如圖8所示。

圖8 對(duì)外部網(wǎng)絡(luò)提供接口Fig.8 Interfaces to external networks

重點(diǎn)如下：

1）兩臺(tái)主機(jī)采用Keepalived實(shí)現(xiàn)高可用，使外部系統(tǒng)訪問(wèn)的IP保持不變；

2）兩臺(tái)主機(jī)采用haproxy提供負(fù)載均衡服務(wù)代理，將訪問(wèn)內(nèi)部接口服務(wù)的流量進(jìn)行轉(zhuǎn)發(fā)；

3）Service采用NodePort類型，使運(yùn)行后端關(guān)聯(lián)Pod的主機(jī)都打開對(duì)應(yīng)的服務(wù)映射端口；

4）外部系統(tǒng)訪問(wèn)負(fù)載均衡服務(wù)器的VIP及相關(guān)服務(wù)的代理端口即可訪問(wèn)內(nèi)網(wǎng)接口服務(wù)。

4 結(jié)束語(yǔ)

由于K8S的可移動(dòng)、可擴(kuò)展、自修復(fù)的諸多特點(diǎn)，在越來(lái)越多的領(lǐng)域得到廣泛的應(yīng)用。本文結(jié)合鐵路信息系統(tǒng)的特點(diǎn)，對(duì)K8S在系統(tǒng)中具體應(yīng)用的網(wǎng)絡(luò)設(shè)計(jì)做出了研究及闡述，對(duì)高可用、自修復(fù)、服務(wù)發(fā)現(xiàn)、與外部系統(tǒng)接口等技術(shù)難點(diǎn)提出解決方案，對(duì)工程應(yīng)用具有指導(dǎo)價(jià)值。