容器化VPN在K8S環(huán)境下的應(yīng)用與研究

張入文，羅俊，胡曉勤，龔勛

(四川大學(xué)網(wǎng)絡(luò)空間安全學(xué)院，成都 610065)

0 引言

云計(jì)算是一種將云端物理資源以虛擬資源池的方式供租戶使用的模式，在云計(jì)算模式下可以通過(guò)網(wǎng)絡(luò)實(shí)現(xiàn)租戶的資源按需分配與獲取[1]。其具有的高可用性、彈性伸縮、便宜性和部署靈活等特點(diǎn)，能在提高人們工作效率的同時(shí)，在各個(gè)行業(yè)帶創(chuàng)新[2]。云計(jì)算模式下，用戶只需要通過(guò)網(wǎng)絡(luò)向云服務(wù)提供商申請(qǐng)并支付相應(yīng)的費(fèi)用，即可方便快捷地獲取所需要的計(jì)算、存儲(chǔ)等資源，相比于購(gòu)買(mǎi)并部署昂貴的硬件設(shè)備，資源的按需購(gòu)買(mǎi)更為經(jīng)濟(jì)便捷。經(jīng)過(guò)多年的發(fā)展，云計(jì)算技術(shù)已經(jīng)越來(lái)越被人們廣泛使用。

盡管有云計(jì)算有眾多優(yōu)勢(shì)，但仍存在數(shù)據(jù)丟失、數(shù)據(jù)破壞和流量劫持等方面的安全問(wèn)題[3]。因此，需要在云環(huán)境下有效的VPN解決方案?？梢酝ㄟ^(guò)虛擬專用網(wǎng)絡(luò)即服務(wù)(VPNaaS)提供與租戶網(wǎng)絡(luò)的連接。通過(guò)加密可以確保云環(huán)境中敏感信息的數(shù)據(jù)保護(hù)和機(jī)密性，這可以通過(guò)在云中部署VPN服務(wù)來(lái)實(shí)現(xiàn)。傳統(tǒng)意義的VPN主要以硬件為主，將VPN功能集成到特定的專用硬件中，實(shí)現(xiàn)軟硬一體的VPN系統(tǒng)[4]，但這樣也存在許多問(wèn)題，例如：可用性差、不易于擴(kuò)展、部署困難等。將VPN服務(wù)遷移到云環(huán)境中，可以有效解決這些問(wèn)題，在云環(huán)境下，VPN系統(tǒng)應(yīng)滿足：組件快速部署；VPN資源的動(dòng)態(tài)分配與快速擴(kuò)展，支持多租戶、多VPN實(shí)例；租戶VPN系統(tǒng)的相互隔離等諸多要求。

目前國(guó)內(nèi)外的研究主要集中在傳統(tǒng)VPN，對(duì)云環(huán)境下VPN服務(wù)的研究仍然較少，Goethals等人對(duì)云上VPN軟件的可伸縮性進(jìn)行了評(píng)估，對(duì)VPN軟件是否以及如何應(yīng)用于包含邊緣節(jié)點(diǎn)的大規(guī)模集群中進(jìn)行了研究[5]，本文主要研究Kubernetes環(huán)境下的VPN服務(wù)的應(yīng)用；選擇合適的開(kāi)源VPN，制作VPN鏡像；利用Multus-CNI插件實(shí)現(xiàn)Kubernetes的多網(wǎng)絡(luò)平面。

1 相關(guān)技術(shù)

1.1 傳統(tǒng)VPN

傳統(tǒng)VPN通常以設(shè)備的形式部署在網(wǎng)絡(luò)邊界處。VPN的關(guān)鍵技術(shù)包括隧道技術(shù)、密鑰管理技術(shù)、加密技術(shù)和身份認(rèn)證技術(shù)[6]。其中，隧道技術(shù)是VPN最為關(guān)鍵的一項(xiàng)技術(shù)，其實(shí)質(zhì)是在傳輸兩點(diǎn)之間通過(guò)相同的隧道協(xié)議建立安全的傳輸信道；加密技術(shù)的主要用于傳輸過(guò)程中的信息保護(hù)，以防止非授權(quán)用戶獲取真實(shí)數(shù)據(jù)；密鑰管理技術(shù)主要用于實(shí)現(xiàn)在公用數(shù)據(jù)網(wǎng)上安全地傳遞密鑰而不被竊??；通常在隧道連接開(kāi)始前還要進(jìn)行用戶身份認(rèn)證，保證只有擁有合法身份的用戶能夠通過(guò)VPN訪問(wèn)網(wǎng)絡(luò)內(nèi)部資源。

1.2 容器技術(shù)與Kubernetes

容器是一個(gè)輕量級(jí)的操作系統(tǒng)級(jí)別的虛擬化技術(shù)，它允許應(yīng)用程序在資源隔離的環(huán)境下，運(yùn)行應(yīng)用程序及其各種依賴項(xiàng)，通過(guò)將應(yīng)用程序所需的所有必要組件都打包為鏡像，運(yùn)行在獨(dú)立環(huán)境中，相比于虛擬機(jī)而言，容器不需要整個(gè)操作系統(tǒng)，從而節(jié)省出大量資源，同時(shí)容器運(yùn)行也更加快速，性能更好。此外不需要在虛擬機(jī)上安裝配套的軟件環(huán)境，更便于業(yè)務(wù)的遷移。

Kubernetes是Google開(kāi)源的容器集群管理系統(tǒng)，它基于docker技術(shù)，提供資源調(diào)度、部署運(yùn)行、服務(wù)發(fā)現(xiàn)、縮擴(kuò)容等一整套功能，本質(zhì)上可看做是基于容器技術(shù)的Micro-PaaS平臺(tái)，即第三代PaaS的代表性項(xiàng)目[8]。其整體架構(gòu)如圖1所示。

圖1 Kubernetes總體架構(gòu)圖

如圖1所示，Kubernetes的核心組件，主要有以下幾個(gè)：

etcd：保存整個(gè)集群的各種狀態(tài)信息；

apiserver：提供了資源操作的唯一入口，并提供認(rèn)證、授權(quán)、訪問(wèn)控制、API注冊(cè)和發(fā)現(xiàn)等機(jī)制；

controller manager：負(fù)責(zé)維護(hù)集群的狀態(tài)，例如故障檢測(cè)、自動(dòng)擴(kuò)展、滾動(dòng)更新等；

scheduler：負(fù)責(zé)資源的調(diào)度，按照預(yù)定的調(diào)度策略將Pod調(diào)度到相應(yīng)的機(jī)器上；

kubelet：負(fù)責(zé)維護(hù)容器的生命周期，同時(shí)也負(fù)責(zé)Volume(CVI)和網(wǎng)絡(luò)(CNI)的管理；

kube-proxy：負(fù)責(zé)為Service提供cluster內(nèi)部的服務(wù)發(fā)現(xiàn)和負(fù)載均衡。

為便于理解，下面將對(duì)Kubernetes的重要概念進(jìn)行簡(jiǎn)單介紹。

Pod：Pod是Kubernetes中一個(gè)抽象化概念，是一組共享資源(包括存儲(chǔ)、網(wǎng)絡(luò)等)的容器，Pod內(nèi)的容器在同一個(gè)namespace命名空間。master節(jié)點(diǎn)通過(guò)controler組件把Pod調(diào)度到合適的node工作節(jié)點(diǎn)上，并與容器運(yùn)行時(shí)協(xié)調(diào)以啟動(dòng)容器在Kubernetes中，Pod是調(diào)度的最小元素。

Master：集群控制節(jié)點(diǎn)，負(fù)責(zé)整個(gè)集群的管理控制，在master節(jié)點(diǎn)上運(yùn)行這集群的關(guān)鍵組件，如apiserver、controller manager、scheduler等。Master節(jié)點(diǎn)通常占據(jù)整個(gè)服務(wù)器，由于master的重要性，高可用方案建議部署3臺(tái)服務(wù)器以保證整個(gè)集群的安全穩(wěn)定。

Node：除了master，集群其他的機(jī)器均為node節(jié)點(diǎn)，node是集群的工作負(fù)載節(jié)點(diǎn)，由master分配工作負(fù)載，其上運(yùn)行著kubelet、kube-proxy、Docker Engine等關(guān)鍵進(jìn)程。當(dāng)某個(gè)node宕機(jī)時(shí)，其上的工作負(fù)載會(huì)自動(dòng)轉(zhuǎn)移到其他節(jié)點(diǎn)。

2 K8S環(huán)境下的VPN服務(wù)設(shè)計(jì)

2.1 容器化VPN服務(wù)的基本架構(gòu)

Kubernetes網(wǎng)絡(luò)被設(shè)計(jì)為一個(gè)扁平化的網(wǎng)絡(luò)中，集群外部訪問(wèn)只能通過(guò)以下幾種方式：

(1)通過(guò)port-forward轉(zhuǎn)發(fā)，這種方式最為方便快捷，但只適合調(diào)試時(shí)使用，不適用于生產(chǎn)環(huán)境。

(2)通過(guò)NodePort，NodePort方式為集群中每一個(gè)節(jié)點(diǎn)(Node)指定對(duì)應(yīng)的監(jiān)聽(tīng)端口，通過(guò)任意節(jié)點(diǎn)的端口即可訪問(wèn)到指定服務(wù)。

(3)通過(guò)LoadBalance來(lái)暴露服務(wù)，LoadBalance(負(fù)載均衡LB)通常由云服務(wù)商提供，如果云環(huán)境中不提供LB服務(wù)，通常直接使用Ingress，或使用MetalLB來(lái)自行配置LB。

(4)通過(guò)Ingress公開(kāi)多個(gè)服務(wù)，Ingress Controller基于Ingress規(guī)則將客戶端請(qǐng)求直接轉(zhuǎn)發(fā)到Service對(duì)應(yīng)的后端pod上。

這些服務(wù)暴露方式使集群內(nèi)部服務(wù)可以對(duì)外訪問(wèn)，但這些方式?jīng)]有任何安全驗(yàn)證機(jī)制，且外部網(wǎng)絡(luò)中的各類(lèi)客戶端皆可訪問(wèn)，對(duì)于需要建立可信的安全連接，而又不希望外部網(wǎng)絡(luò)隨意訪問(wèn)的服務(wù)，使用VPN服務(wù)是非常必要的。

以傳統(tǒng)VPN與常見(jiàn)的開(kāi)源VPN Strongswan作為參考，將傳統(tǒng)VPN與K8S環(huán)境相結(jié)合，將Strongswan制作為容器鏡像，部署到Kubernetes容器集群，其整體架構(gòu)如圖2所示。

圖2 容器化VPN總體架構(gòu)圖

以三個(gè)節(jié)點(diǎn)搭建的Kubernetes集群為例，其中節(jié)點(diǎn)1為master節(jié)點(diǎn)，為集群控制節(jié)點(diǎn)，負(fù)責(zé)整個(gè)集群的管理與控制，是整個(gè)集群的核心，在其上通常不運(yùn)行工作負(fù)載，也可以通過(guò)特殊命令使其作為工作節(jié)點(diǎn)使用，master節(jié)點(diǎn)上運(yùn)行著API server、Controller Manager、Scheduler等重要進(jìn)程。節(jié)點(diǎn)2與節(jié)點(diǎn)3為Node工作節(jié)點(diǎn)，每個(gè)Node節(jié)點(diǎn)可運(yùn)行多個(gè)pod，pod是Kubernetes中最基本的單元，其中包含多個(gè)與業(yè)務(wù)相關(guān)的容器，為Kubernetes調(diào)度的最小單元，VPN服務(wù)運(yùn)行在node節(jié)點(diǎn)，負(fù)責(zé)容器內(nèi)服務(wù)與外部通信。

其中，VPN pod有兩個(gè)網(wǎng)絡(luò)接口，外部網(wǎng)絡(luò)訪問(wèn)的數(shù)據(jù)由flannel網(wǎng)絡(luò)負(fù)責(zé)轉(zhuǎn)發(fā)，內(nèi)部訪問(wèn)的數(shù)據(jù)由calico網(wǎng)絡(luò)轉(zhuǎn)發(fā)，Kubernetes可以是公有云上由租戶搭建的集群或是異地的數(shù)據(jù)中心，本地?cái)?shù)據(jù)中心采用傳統(tǒng)的方式，在網(wǎng)絡(luò)邊界處部署VPN設(shè)備，集群中的VPN封裝在容器中，通過(guò)kubelet作為pod啟動(dòng)，IPSec隧道建立在本地網(wǎng)關(guān)與Kubernetes中VPN pod之間，本地中心與Kubernetes集群建立連接時(shí)首先通過(guò)互聯(lián)網(wǎng)將數(shù)據(jù)發(fā)送到云上彈性公網(wǎng)ip或真實(shí)物理ip，master節(jié)點(diǎn)上運(yùn)行的ingress controller組件負(fù)責(zé)將數(shù)據(jù)轉(zhuǎn)發(fā)到Node工作節(jié)點(diǎn)上的VPN服務(wù)pod上，再通過(guò)VPN pod將數(shù)據(jù)轉(zhuǎn)發(fā)到相應(yīng)的pod，通過(guò)在本地?cái)?shù)據(jù)中心的VPN網(wǎng)關(guān)與VPN pod間建立安全隧道，實(shí)現(xiàn)對(duì)集群內(nèi)部的安全訪問(wèn)。

2.2 雙網(wǎng)絡(luò)平面的實(shí)現(xiàn)

由于VPN服務(wù)同時(shí)需要內(nèi)網(wǎng)與外網(wǎng)網(wǎng)卡，而Kubernetes設(shè)計(jì)之初，一直遵循One Pod One IP的策略，即一個(gè)Pod分配一個(gè)網(wǎng)卡，一個(gè)IP地址，在這種情況下顯然不滿足要求，為了支持多網(wǎng)絡(luò)平面，本文以Multus-CNI為例進(jìn)行了多網(wǎng)絡(luò)平面實(shí)踐。目前Kubernetes中最常用的跨主機(jī)容器之間的通信組件為flannel與calico，flannel在主機(jī)網(wǎng)絡(luò)之上創(chuàng)建了覆蓋網(wǎng)絡(luò)(overlay網(wǎng)絡(luò))，通過(guò)這個(gè)覆蓋網(wǎng)絡(luò)，將數(shù)據(jù)包原封不動(dòng)地傳遞到目標(biāo)容器內(nèi)，calico使用BGP路由協(xié)議配置一個(gè)3層網(wǎng)絡(luò)在主機(jī)之間路由數(shù)據(jù)包。為實(shí)現(xiàn)多網(wǎng)絡(luò)平面，首先需要在Kubernetes集群中安裝flannel與calico網(wǎng)絡(luò)插件，并安裝Multus-CNI插件，通過(guò)創(chuàng)建與calico和flannel組件同名的NetworkAttachmentDefinition類(lèi)型的CRD自定義資源，并注冊(cè)到kubernetes的apiserver，創(chuàng)建方式如下：

可以通過(guò)kubectl get命令查看自定義資源是否創(chuàng)建成功，在multus的cni讀取目錄下，新建并編寫(xiě)calico和flannel的cni配置文件，以便multus能獲取到calico和flannel的組件信息，動(dòng)態(tài)進(jìn)行網(wǎng)絡(luò)的配置。創(chuàng)建pod時(shí)可以通過(guò)添加annotations參數(shù)選擇默認(rèn)網(wǎng)絡(luò)或創(chuàng)建雙網(wǎng)卡pod。

本文中，以calico網(wǎng)絡(luò)作為內(nèi)網(wǎng)網(wǎng)絡(luò)，負(fù)責(zé)Kubernetes內(nèi)部pod與pod，service與pod或各節(jié)點(diǎn)之間的通信，flannel作為外網(wǎng)網(wǎng)絡(luò)，負(fù)責(zé)集群外部數(shù)據(jù)接收后通過(guò)VPN Service內(nèi)網(wǎng)網(wǎng)口轉(zhuǎn)發(fā)到集群內(nèi)部通信。多網(wǎng)絡(luò)平面下的數(shù)據(jù)流圖如圖3所示。

圖3 集群內(nèi)pod與本地?cái)?shù)據(jù)中心通信的數(shù)據(jù)流圖

通過(guò)本地?cái)?shù)據(jù)中心VPN網(wǎng)關(guān)和VPN pod之間建立安全隧道，本地?cái)?shù)據(jù)中心內(nèi)網(wǎng)的服務(wù)器與集群內(nèi)pod的通信過(guò)程大致如下：

(1)本地?cái)?shù)據(jù)中心內(nèi)網(wǎng)的服務(wù)器發(fā)出源IP為本機(jī)(內(nèi)網(wǎng)網(wǎng)段)，目的IP為集群內(nèi)pod IP的數(shù)據(jù)包，根據(jù)本機(jī)路由策略發(fā)送到本地?cái)?shù)據(jù)中心的VPN網(wǎng)關(guān)。

(2)VPN網(wǎng)關(guān)根據(jù)其目的地址查找相應(yīng)的VPN安全策略，將數(shù)據(jù)包重新封裝后，發(fā)送到互聯(lián)網(wǎng)。

(3)數(shù)據(jù)包通過(guò)公共網(wǎng)絡(luò)傳輸?shù)郊旱墓W(wǎng)ip后，由master節(jié)點(diǎn)的ingress組件將數(shù)據(jù)轉(zhuǎn)發(fā)到flannel0設(shè)備。

(4)flannel網(wǎng)絡(luò)的flannel0根據(jù)存儲(chǔ)在etcd上的網(wǎng)絡(luò)配置信息，將數(shù)據(jù)包轉(zhuǎn)發(fā)給VPN pod。

(5)數(shù)據(jù)包到達(dá)VPN pod，根據(jù)數(shù)據(jù)包源地址，查找安全策略，對(duì)其進(jìn)行相應(yīng)的解包工作，并根據(jù)安全策略，由內(nèi)網(wǎng)接接口發(fā)送到calico網(wǎng)絡(luò)的canal0設(shè)備。

(6)calico網(wǎng)絡(luò)根據(jù)其路由規(guī)則，將數(shù)據(jù)包轉(zhuǎn)發(fā)到對(duì)應(yīng)的node節(jié)點(diǎn)的canal0設(shè)備。

(7)數(shù)據(jù)包到達(dá)pod所在的node節(jié)點(diǎn)，canal0根據(jù)路由規(guī)則將數(shù)據(jù)包發(fā)送到對(duì)應(yīng)的pod，至此，整個(gè)通信流程結(jié)束。

創(chuàng)建兩個(gè)網(wǎng)絡(luò)接口的pod的大致流程如下：

(1)當(dāng)用戶在Kubernetes的master節(jié)點(diǎn)執(zhí)行pod創(chuàng)建命令后，kublet觀察到新pod的創(chuàng)建，于是首先調(diào)用CRI(容器運(yùn)行時(shí)接口)，創(chuàng)建pod內(nèi)的若干容器，包括pause系統(tǒng)容器和其他用戶容器

(2)首先會(huì)創(chuàng)建pause系統(tǒng)容器，它是由Kubernetes系統(tǒng)默認(rèn)創(chuàng)建的第一個(gè)容器，里面運(yùn)行一個(gè)功能簡(jiǎn)單的C程序，pause容器一經(jīng)創(chuàng)建即把自己永遠(yuǎn)阻塞。這個(gè)邏輯簡(jiǎn)單的容器主要用于在pod創(chuàng)建過(guò)程中完成一系列容器初始化過(guò)程，并占用一個(gè)Linux的network namespace，不同的pod通過(guò)Linux的namespace機(jī)制實(shí)現(xiàn)隔離功能。

(3)pod內(nèi)的其他容器與系統(tǒng)pause容器共享network namespace，在創(chuàng)建階段加入這個(gè)namespace，因此，在CRI調(diào)用容器運(yùn)行時(shí)時(shí)，其默認(rèn)網(wǎng)絡(luò)模式都為none模式，不會(huì)初始化網(wǎng)絡(luò)協(xié)議棧。

(4)在pause創(chuàng)建階段，會(huì)通過(guò)CNI插件完成容器網(wǎng)絡(luò)初始化的過(guò)程，包括容器網(wǎng)絡(luò)接口創(chuàng)建，IP分配等，CNI有多種實(shí)現(xiàn)，官方自帶的插件有p2p、bridge等，一般常用的CNI網(wǎng)絡(luò)插件有flannel、calico等，用以解決容器之間跨機(jī)通信問(wèn)題。

(5)Kubelet調(diào)用Multus-CNI插件通過(guò)cmdAdd創(chuàng)建容器網(wǎng)絡(luò)并根據(jù)pod創(chuàng)建時(shí)的annotations參數(shù)，再調(diào)用相關(guān)的第三方網(wǎng)絡(luò)插件如calico、weave等完成網(wǎng)絡(luò)初始化，從而完成雙網(wǎng)絡(luò)接口pod的創(chuàng)建。

3 測(cè)試與分析3.1 實(shí)驗(yàn)環(huán)境

本實(shí)驗(yàn)通過(guò)一臺(tái)本地物理機(jī)與兩臺(tái)公有云租用的ESC搭建測(cè)試如圖4所示的測(cè)試環(huán)境，物理機(jī)1通過(guò)路由器連接至互聯(lián)網(wǎng)，在其上運(yùn)行三個(gè)虛擬機(jī)VM1、VM2和VM3，將VM1作為集群的master節(jié)點(diǎn)，VM2和VM3作為工作節(jié)點(diǎn)，搭建了Kubernetes集群，VPN pod通過(guò)annotation參數(shù)為flannel和calico的yaml文件，以命令方式創(chuàng)建，具有兩個(gè)網(wǎng)絡(luò)接口，分別連接至flannel和calico網(wǎng)絡(luò)，公有云上租用的ECS1上運(yùn)行strongswan，創(chuàng)建了兩個(gè)網(wǎng)絡(luò)接口，ESC2的默認(rèn)網(wǎng)關(guān)為ECS1，通過(guò)云管理平臺(tái)對(duì)VPC網(wǎng)絡(luò)進(jìn)行配置，物理機(jī)1可以通過(guò)EIP(彈性公網(wǎng)ip)訪問(wèn)到ECS1，ECS1的eth1 ip與ECS2 ip處于同一子網(wǎng)，可以直接訪問(wèn)，容器鏡像選擇strongswan-5.9.0。

圖4 測(cè)試環(huán)境網(wǎng)絡(luò)拓?fù)鋱D

3.2 VPN功能有效性測(cè)試

使用ping命令對(duì)IPSec VPN功能有效性進(jìn)行測(cè)試，測(cè)試結(jié)果為：在創(chuàng)建IPSec隧道前，ECS2與pod1無(wú)法通信，創(chuàng)建IPSec隧道后，ECS2與pod1能進(jìn)行正常通信，能實(shí)現(xiàn)VPN功能。

3.3 性能測(cè)試

通過(guò)ping命令測(cè)試VPN的通信延遲，作為對(duì)比，分別在IPSec VPN連接建立前，測(cè)試物理機(jī)1與ECS1的通信延遲與IPSec VPN連接建立成功后，測(cè)試pod1與ECS2通信時(shí)延，測(cè)試結(jié)果如圖5和圖6所示，pod1與ECS2通信時(shí)延和物理機(jī)1與ECS1通信時(shí)延均在40ms左右波動(dòng)，其中pod1與ECS2的平均時(shí)延為：42.3ms，物理機(jī)1與ECS1的平均時(shí)延為40.1ms，結(jié)果表明，VPN隧道建立后的通信時(shí)延與物理機(jī)到云端經(jīng)過(guò)互聯(lián)網(wǎng)訪問(wèn)的通信時(shí)延相差不大，在可接受的范圍內(nèi)。

圖5 VPN時(shí)延測(cè)試

圖6 互聯(lián)網(wǎng)連接時(shí)延測(cè)試

4 結(jié)語(yǔ)

本文針對(duì)容器VPN在Kubernetes環(huán)境下的應(yīng)用進(jìn)行研究，下一步的研究可以擴(kuò)展到VPN服務(wù)的網(wǎng)絡(luò)性能與提升上。