劉宏娟，黃 煒，李文吉，邵治濤，胡 倩

(1.自然資源部航空地球物理與遙感地質(zhì)重點實驗室,北京 100083;2.中國自然資源航空物探遙感中心, 北京 100083)

0 引言

衛(wèi)星遙感數(shù)據(jù)的處理及應(yīng)用需要強大的算力支持，目前在用的數(shù)據(jù)處理平臺以單體服務(wù)器和虛擬化平臺為主。隨著我國航天事業(yè)的高速發(fā)展，衛(wèi)星遙感也進入了“大數(shù)據(jù)”時代，一方面，衛(wèi)星遙感行業(yè)按照地質(zhì)調(diào)查整體規(guī)劃要向著一張圖、一站式、平臺化的方向發(fā)展。另一方面，衛(wèi)星遙感數(shù)據(jù)的顯著特點是多元異構(gòu)，除了基本的衛(wèi)星影像之外還包含了時間、空間、頻譜等復(fù)雜的地質(zhì)屬性信息，衛(wèi)星遙感的數(shù)據(jù)類型日漸豐富,數(shù)據(jù)總量呈現(xiàn)海量增長趨勢，對硬件資源動態(tài)分配、彈性擴展、快速部署等方面均提出了更高要求。因此，探索利用云計算、大數(shù)據(jù)等新技術(shù)構(gòu)建更加高效便捷的數(shù)據(jù)處理平臺近年來在衛(wèi)星遙感行業(yè)愈發(fā)重要,并已在地質(zhì)調(diào)查的其他領(lǐng)域內(nèi)取得了進展[1-2]。本文引入了容器概念以及Kubernetes容器集群管理系統(tǒng)，以容器為基本單位代替虛擬機部署應(yīng)用服務(wù)，充分發(fā)揮容器輕便快捷、彈性擴展、便于維護的優(yōu)勢，嘗試構(gòu)建符合衛(wèi)星遙感行業(yè)特點的容器云平臺[3]。利用Kubernetes對容器的調(diào)度管理機制，將計算、網(wǎng)絡(luò)、存儲等服務(wù)器硬件資源虛擬化后動態(tài)分配給容器，為運行在容器內(nèi)的衛(wèi)星遙感應(yīng)用服務(wù)提供高效可靠、輕便統(tǒng)一的“一站式”服務(wù)。

1 容器與虛擬化

1.1 容器技術(shù)

容器(Container)技術(shù)是一種輕量級的操作系統(tǒng)層虛擬化技術(shù)，借鑒了遠洋運輸里“集裝箱”的理念。一般而言，部署一個應(yīng)用需要提前準(zhǔn)備好物理主機、操作系統(tǒng)以及各種中間件等軟硬件環(huán)境，虛擬化部署一定程度上實現(xiàn)了硬件資源復(fù)用,但沒有解決應(yīng)用層問題，針對每一項應(yīng)用部署還是需要單獨搭建一整套依賴的操作系統(tǒng)、應(yīng)用環(huán)境等。容器技術(shù)的原理是基于Linux的Namespace和Cgroup機制，將應(yīng)用打包并虛擬化封裝出了一套內(nèi)核輕量級的操作系統(tǒng)(NameSpace區(qū)分隔離容器，Cgroup管理控制系統(tǒng)資源)[4]，通過容器引擎共享操作系統(tǒng),只需在容器內(nèi)部打包必要的Lib/Bin等操作系統(tǒng)文件，具有極其輕量、秒級部署、易于移植、彈性伸縮等特點，極大提高了部署和運維效率[5]。

Docker是一個基于LXC(Linux Container)的開源容器引擎，將與應(yīng)用相關(guān)的依賴項(包括環(huán)境、程序、文件)打包成鏡像部署在物理機中，主要包括容器(Container)、鏡像(Image)以及倉庫(Repository)3個部分。由于容器是應(yīng)用程序的抽象，將各類應(yīng)用服務(wù)變成模塊化的組件，容器可以在相互隔離的物理環(huán)境中獨立運行，物理機上可以同時運行多個容器，容器之間共享操作系統(tǒng)。利用鏡像倉庫，運維人員可以管理不同的鏡像版本，靈活配置、快速部署。由于Docker標(biāo)準(zhǔn)化、輕量級、易遷移擴展的優(yōu)勢，Docker已發(fā)展成了容器技術(shù)的代名詞，是目前應(yīng)用最廣泛的容器引擎[6]。

1.2 容器與虛擬化

虛擬化能更好地利用硬件資源，同一臺物理主機上可以部署運行多個虛擬機，虛擬機之間資源和進程彼此隔離，解決了傳統(tǒng)模式下同一臺物理機上的應(yīng)用服務(wù)搶奪資源問題。虛擬機是在物理主機中虛擬出一臺完整計算機，在虛擬化的硬件之上運行所有組件(包括自身操作系統(tǒng))，而容器則是直接將物理主機的操作系統(tǒng)虛擬出獨立的用戶空間，每個用戶空間分配有各自的CPU、內(nèi)存等計算資源供容器使用，容器之間彼此獨立但共享物理主機的操作系統(tǒng)[7]。因而，容器的啟動更迅速，創(chuàng)建更加簡便快捷，能支持大規(guī)模應(yīng)用服務(wù)的快速部署更新。虛擬化與容器的差異對比如圖1所示。

圖1 虛擬化與容器對比

1.3 Kubernetes核心概念

隨著容器化部署的應(yīng)用不斷增多，容器和物理主機的集群規(guī)模也隨之不斷刷新，Docker 逐漸無法滿足大規(guī)模容器集群的管理需求。Kubernetes是Google公司以Docker為基礎(chǔ)、面向無服務(wù)場景的開源容器集群管理系統(tǒng)，能夠為容器化的應(yīng)用服務(wù)提供資源調(diào)度、自動重啟、負載均衡、服務(wù)發(fā)現(xiàn)等基礎(chǔ)功能。Kubernetes支持跨物理主機管理容器，大大降低了容器平臺的維護難度，同時還為開發(fā)人員提供了一套RESTful接口，為后續(xù)開發(fā)拓展打下了良好基礎(chǔ)。鑒于 Kubernetes強大的開源社區(qū)支撐以及眾多成功應(yīng)用的案例，是當(dāng)下較為主流的容器管理平臺[8-9]。

2 系統(tǒng)設(shè)計

2.1 系統(tǒng)整體框架

基于 Kubernetes衛(wèi)星遙感數(shù)據(jù)容器云平臺的邏輯功能框圖如圖 2 所示，包括物理層、Kubernetes 平臺層和應(yīng)用層3部分[10-11]。為保障衛(wèi)星遙感業(yè)務(wù)正常運行，容器云平臺之外還需要配套相應(yīng)的支撐服務(wù)。本文選擇了兩個典型支撐服務(wù)作為代表：分布式存儲和ES(Elastic Search)集群。

圖2 容器云平臺邏輯架構(gòu)

物理層主要是指由實體服務(wù)器池化虛擬出來的物理資源(包括計算資源、存儲資源、網(wǎng)絡(luò)資源)，這些物理資源會被上層的 Kubernetes調(diào)度并分配給不同的容器。Kubernetes層是整個容器云平臺的核心，統(tǒng)一管理控制容器及應(yīng)用層服務(wù)的生命周期、資源分配，實時監(jiān)控管理容器及部署在容器中的應(yīng)用服務(wù)[12]。應(yīng)用層主要是將衛(wèi)星遙感應(yīng)用軟件抽象成一個個服務(wù)并容器化地部署到容器中，每個容器擁有獨立的物理資源，容器彼此之間共享物理主機的操作系統(tǒng)，構(gòu)成了針對特定應(yīng)用服務(wù)的輕量內(nèi)核級“虛擬機”[13]。

對于業(yè)務(wù)支撐功能，分布式存儲系統(tǒng)為容器云平臺提供統(tǒng)一的外置存儲服務(wù)，主要用于海量衛(wèi)星遙感數(shù)據(jù)的存儲、訪問、備份，既簡化了應(yīng)用層的數(shù)據(jù)存儲復(fù)雜度，也保證了數(shù)據(jù)的一致性、可靠性。ElasticSearch為衛(wèi)星遙感應(yīng)用服務(wù)提供數(shù)據(jù)檢索服務(wù)，其索引能力強大，且支持多種查詢類型，在地理信息數(shù)據(jù)索引查詢方面優(yōu)勢明顯。ES集群結(jié)合衛(wèi)星遙感數(shù)據(jù)特點進行了單獨優(yōu)化設(shè)計，能夠大幅提高檢索效率。由于上層應(yīng)用服務(wù)需要頻繁地檢索使用衛(wèi)星遙感數(shù)據(jù)，因此將檢索功能獨立部署于容器云平臺之外，通過接口提供服務(wù)。容器云平臺使用多種接口協(xié)議進行訪問： ES Rest API、ES SQL、Impala SQL、Hive SQL、HBase MapReduce，也充分體現(xiàn)了平臺架構(gòu)的開放性。

2.2 Kubernetes架構(gòu)

Kubernetes 主要由控制節(jié)點(Master node)和工作節(jié)點(Worker node)兩類節(jié)點組成，其系統(tǒng)架構(gòu)如圖 3所示。[14]控制節(jié)點包括 API服務(wù)器、控制管理器、調(diào)度器和 etcd 鍵值數(shù)據(jù)庫等組件，負責(zé)全局決策、調(diào)度控制、事件響應(yīng)等平臺管理功能。[15-16]工作節(jié)點主要包括 kubelet和 kube-proxy兩個組件，用以維護工作節(jié)點上運行的每個Pod ，并為每個節(jié)點提供必要的運行環(huán)境。

圖3 kubernetes 架構(gòu)

本文采用了 Kubernetes1.21 版本,使用了六臺物理主機(centos7.9操作系統(tǒng))構(gòu)建容器云平臺。所有物理主機均需要安裝docker，以指定yum 源方式安裝kubelet、kubectl 等組件，此處使用阿里云的源，具體硬件配置如表1所示。

表1 容器云平臺硬件配置

2.3 高可用集群

應(yīng)用服務(wù)運行在容器之中，需要容器以極高的可靠性保障業(yè)務(wù)的連續(xù)性。Kubernetes 是容器云平臺的核心，控制節(jié)點是Kubernets管理功能的關(guān)鍵所在，其中最關(guān)鍵是的etcd鍵值數(shù)據(jù)庫，負責(zé)保存各節(jié)點的關(guān)鍵數(shù)據(jù)，用于配置共享和服務(wù)發(fā)現(xiàn)。針對系統(tǒng)中的關(guān)鍵節(jié)點和關(guān)鍵功能，采用“多控制節(jié)點+ etcd 集群”的方式，來提高整個系統(tǒng)的高可用性和安全性。[17-18]Kubernetes 高可用集群架構(gòu)如圖4所示。

圖4 kubernetes 高可用集群架構(gòu)

Kubernetes 的工作節(jié)點通過內(nèi)部的負載均衡機制連接到控制節(jié)點上，多控制節(jié)點模式下只有所有控制節(jié)點同時故障才會影響平臺運行。多控制節(jié)點的實現(xiàn)是在控制管理器、調(diào)度器修改leader-elect參數(shù)。在多控制節(jié)點模式下，系統(tǒng)會自動選舉出主控制節(jié)點(master leader)，如果主控制節(jié)點宕機導(dǎo)致系統(tǒng)異常，則會自動選舉出新的主控制節(jié)點[19-20]。

etcd集群借鑒了Hadoop中ZooKeeper的設(shè)計理念，其核心原理是使用Raft協(xié)議保障節(jié)點的一致性[21]。etcd集群中只有1個有效的主節(jié)點，主節(jié)點負責(zé)處理所有來自系統(tǒng)的寫操作并對狀態(tài)機進行維護，通過Raft協(xié)議保證主節(jié)點對狀態(tài)機的改動會可靠同步到集群中的其他節(jié)點。

2.4 外接分布式存儲

容器中的數(shù)據(jù)是非永久保存的，當(dāng)容器宕機崩潰時，kubelet會以鏡像的初始狀態(tài)重新啟動容器，容器中的數(shù)據(jù)將丟失。為保障容器數(shù)據(jù)的存儲安全，Kubernetes提供了兩套機制：一是為容器分配臨時存儲卷，二是通過容器存儲接口Container Storage Interface(CSI)提供外部存儲服務(wù)[22-23]。衛(wèi)星遙感數(shù)據(jù)總量大需要長期保存，本文采用第二種方法，利用分布式存儲的核心組件之一HDFS NFS Gateway，將HDFS存儲空間通過CSI機制以NFS的形式掛載至Kubernetes，為容器云平提供外部獨立的分布式存儲服務(wù)。外部存儲接口主要依靠PV和PVC實現(xiàn)，其中PV是底層網(wǎng)絡(luò)共享存儲的抽象，將共享存儲定義為一種供容器消費使用的資源對象，而PVC是對存儲資源的申請，容器可以通過PVC的形式申請?zhí)囟ǖ拇鎯臻g和訪問模式。

衛(wèi)星遙感數(shù)據(jù)單幅數(shù)據(jù)量大且有其獨特的數(shù)據(jù)格式，因此在接入容器云平臺時需要進行適當(dāng)改造。以GF7號衛(wèi)星為例，原始數(shù)據(jù)以tar.gz壓縮包形式保存約為2G，其中衛(wèi)星拍攝的影像數(shù)據(jù)(jpg格式)占單幅數(shù)據(jù)總量的90%以上，僅在數(shù)據(jù)處理時才進行讀寫操作，而相關(guān)的衛(wèi)星數(shù)據(jù)參數(shù)以xml格式保存，在數(shù)據(jù)存儲、查詢、篩選、讀寫、處理時需要頻繁訪問。從讀取效率、備份安全、存儲擴展等方面考慮，衛(wèi)星遙感數(shù)據(jù)不適合直接存儲在容器云平臺內(nèi)。因此在采用外接分布式存儲的解決方案下，衛(wèi)星遙感影像數(shù)據(jù)經(jīng)處理后存入獨立部署的HDFS分布式存儲系統(tǒng)，通過定義PV、PVC實現(xiàn)存儲系統(tǒng)與容器云平臺的對接。

為了提高查詢效率，xml衛(wèi)星數(shù)據(jù)參數(shù)存入HFDS分布式存儲系統(tǒng)中的HBase數(shù)據(jù)庫中，jpg衛(wèi)星影像則直接存入HDFS分布式存儲系統(tǒng)，存儲路徑保存在對應(yīng)的HBase數(shù)據(jù)庫中。HBase數(shù)據(jù)庫目錄直接加載至Kubernets的臨時存儲卷中供相關(guān)容器訪問，需要讀寫衛(wèi)星影像數(shù)據(jù)時，首先從HBase中查詢到保存路徑，再調(diào)用HFDS分布式存儲的接口進行操作。定義PV、PVC并關(guān)聯(lián)至Kubernetes的主要配置命令如下：

[root@master～] mount -f nfs -0 ver=3, proto=tcp,nolock,noacl, sync 10.82.8.92:/

[root@master～] oc describe pv mypv1

[root@master～] oc get pv mypv1 -o json

[root@master～] cat newpv.json

[root@master～] oc creat -f newpv.json

[root@master～] oc creat -f newpvc1.json

[root@master～] oc get pv

3 分析展望

本章重點對容器云平臺的性能效率進行了簡要測試比較，并進一步結(jié)合當(dāng)前衛(wèi)星遙感行業(yè)現(xiàn)狀以及虛擬化平臺的應(yīng)用特性，分析了容器云平臺的應(yīng)用前景以及面臨的實際困難。

3.1 容器性能測試

容器相較與虛擬機最大的優(yōu)勢在于輕量化內(nèi)核、快速化部署。以常用容器官方鏡像版本為測試對象，單一容器測試列表如表2所列。

表2 單一容器測試

其中啟動時間是指容器由 Penning 狀態(tài)轉(zhuǎn)變?yōu)?Running 狀態(tài)所需的時間，測試時容器云平臺上沒有運行其他非測試容器。根據(jù)測試結(jié)果可知,測試容器均能正常啟動，耗時均在3秒內(nèi)啟動速度非常快。多容器并行測試選擇把表2中的鏡像均啟動100個容器，測試結(jié)果如表3所列。

表3 多容器測試

通過對比表2和表3的測試結(jié)果可以得知,隨著容器規(guī)模的擴大,容器的啟動速度并沒有顯著下降,平均啟動時間都在3秒內(nèi),啟動速度遠超過虛擬機達到了快速部署的預(yù)期,為高并行應(yīng)用的開發(fā)部署創(chuàng)造了有利條件。

3.2 容器功能測試

本項測試這要通過為衛(wèi)星遙感業(yè)務(wù)流程來驗證容器云平臺的功能性，同時對比相同條件下虛擬機的性能效率。測試環(huán)境里HDFS分布式存儲系統(tǒng)中已導(dǎo)入260景GF7衛(wèi)星影像數(shù)據(jù)作為測試對象，分別在容器環(huán)境和虛擬環(huán)境下部署了基于Web的衛(wèi)星影像共享查詢系統(tǒng)，查詢系統(tǒng)運行后調(diào)用ElasticSearch查詢位于HDFS分布式存儲系統(tǒng)中的GF7衛(wèi)星影像數(shù)據(jù)，具體測試內(nèi)容為以下兩項：

1)遍歷查詢整個GF7測試數(shù)據(jù)庫中的所有衛(wèi)星影像數(shù)據(jù)。

(1) 試驗礦樣中的主要金屬礦物為黃銅礦、孔雀石、自然銅、藍銅礦、褐鐵礦等；主要脈石礦物為石英，其次有碳酸鹽礦物和綠泥石、絹云母等。含銀礦物包括銀黝銅礦、輝銀礦、深紅銀礦及少量自然銀，銀大部分產(chǎn)于銅礦物中，而脈石礦物中含銀較少。

2)查詢GF7數(shù)據(jù)庫中左上角經(jīng)度在(40,49)，且傳感器類型為mux的衛(wèi)星影像數(shù)據(jù)(即rt_lat為(40,49)，且傳感器類型為sensorid='MUX')。

表4 業(yè)務(wù)測試

通過表4的測試結(jié)果可以看出，衛(wèi)星影像共享查詢系統(tǒng)部署在容器，并能夠正常調(diào)用且訪問外接分布式存儲系統(tǒng)內(nèi)的衛(wèi)星遙感影像數(shù)據(jù)，充分證明容器云平臺功能正常，已經(jīng)可以初步實現(xiàn)對衛(wèi)星遙感數(shù)據(jù)的加工處理。對比衛(wèi)星影像共享查詢系統(tǒng)在容器與虛擬機中部署后，容器中的衛(wèi)星影像共享查詢系統(tǒng)在衛(wèi)星遙感影像數(shù)據(jù)查詢和讀寫速度略優(yōu)于虛擬化平臺。

3.3 應(yīng)用前景

1)微服務(wù):

微服務(wù)架構(gòu)是將單體應(yīng)用拆分成多個不同功能的微服務(wù)模塊，從而降低系統(tǒng)的耦合性、復(fù)雜度，更加便于開發(fā)人員部署維護。每個微服務(wù)部署到單獨容器中，服務(wù)之間可獨立開發(fā)部署，支持不同的開發(fā)語言，易于后期維護和功能拓展。目前最常見的微服務(wù)案例是Web服務(wù)，基于B/S架構(gòu)的衛(wèi)星遙感應(yīng)用服務(wù)可以優(yōu)先考慮改造遷移至容器云平臺。

2)深度學(xué)習(xí):

深度學(xué)習(xí)在衛(wèi)星遙感方向上有著廣闊的應(yīng)用前景，比如基于影像的地質(zhì)災(zāi)害自動識別、山體滑坡自動監(jiān)測等。容器可以輕松解決機器訓(xùn)練過程中環(huán)境配置、資源分配等一系列問題，是當(dāng)前進行深度學(xué)習(xí)算法研究所用的主流架構(gòu)。目前容器已支持TensorFlow、Caffe、Caffe2、PyTorch等主流深度學(xué)習(xí)的訓(xùn)練框架，能夠為衛(wèi)星遙感數(shù)據(jù)的深度學(xué)習(xí)研究提供平臺與技術(shù)支持。

3)彈性伸縮:

對于一次性執(zhí)行運算任務(wù)，傳統(tǒng)模式單一任務(wù)占據(jù)整個服務(wù)器，造成了極大資源浪費，容器快速創(chuàng)建、靈活銷毀的特點更適用于這種按需使用的場景。需要運算時創(chuàng)建容器執(zhí)行任務(wù)，運算完成后容器退出釋放其占有的硬件資源。

對于大規(guī)模并行計算任務(wù)，容器云平臺能夠根據(jù)資源的負載情況進行動態(tài)調(diào)節(jié)，避免了流量激增擴容不及時資源耗宕機，也避免了平時大量閑置資源浪費，提高了硬件資源利用率。

4)高效運維:

通過鏡像管理運維人員可以輕松地對平臺內(nèi)的容器及部署在容器內(nèi)的業(yè)務(wù)進行部署管理。需要升級容器內(nèi)的業(yè)務(wù)時，運維人員只需選擇相應(yīng)鏡像版本和副本數(shù)量，即可實現(xiàn)自動升級且業(yè)務(wù)平滑不中斷，升級后若有問題還可選擇回滾至舊版本。

3.4 面臨問題

1)速率瓶頸:

虛擬化與容器提升了物理主機的硬件資源利用率，代價則是更多的數(shù)據(jù)交互與網(wǎng)絡(luò)開銷。當(dāng)業(yè)務(wù)高峰期并行數(shù)量大時，物理主機用來支撐容器的服務(wù)資源就會緊張，造成隊列堵塞，前端用戶的感受就是應(yīng)用卡頓。由于衛(wèi)星遙感單幅影像數(shù)據(jù)量大，總數(shù)據(jù)量可達到PB級，不可避免需要采取獨立部署的分布式或集中存儲系統(tǒng)，單獨管理數(shù)據(jù)存儲。無論是虛擬化平臺還是容器云平臺，都是通過內(nèi)部網(wǎng)絡(luò)進行訪問讀寫操作，網(wǎng)絡(luò)帶寬與數(shù)據(jù)吞吐速率始終是制約衛(wèi)星遙感數(shù)據(jù)處理能力上限的瓶頸。

2)應(yīng)用容器化:

容器的優(yōu)勢在于輕量化的內(nèi)核、便捷的封裝部署，但并不是所有的應(yīng)用服務(wù)都適合或者能夠被容器化，比如說IO交互密集的數(shù)據(jù)庫、某些license綁定固定硬件的軟件。此外，將應(yīng)用服務(wù)遷移至容器部署需要對代碼進行容器化改造，也需要人力和時間成本付出，比如地質(zhì)行業(yè)最常用的專業(yè)軟件ArgGIS、GXL等，短期內(nèi)都無法實現(xiàn)容器化部署，這也制約了容器技術(shù)在整個行業(yè)中的推廣應(yīng)用。

3)隔離安全:

容器由于共享操作系統(tǒng)內(nèi)核及驅(qū)動，容器內(nèi)某應(yīng)用服務(wù)的非法運行或者故障報錯，可能會導(dǎo)致物理主機的操作系統(tǒng)異常，進而影響到其他容器及容器內(nèi)的應(yīng)用服務(wù)。此外，也更容易被外部攻擊通過安全漏洞攻擊操作系統(tǒng)，進而影響上層應(yīng)用服務(wù)。因而，在當(dāng)前的應(yīng)用場景下，容器還不太適合公有云的運行環(huán)境，如有外部接入還需配套設(shè)計嚴格的安全防護機制。

4 結(jié)束語

基于Kubernetes的容器云平臺是容器技術(shù)在衛(wèi)星遙感行業(yè)的應(yīng)用探索，已能夠初步實現(xiàn)對衛(wèi)星遙感數(shù)據(jù)的處理加工,提高了物理主機的硬件資源利用率，降低了后期運維管理成本，并在微服務(wù)、深度學(xué)習(xí)等方向上展現(xiàn)出現(xiàn)了巨大潛力。隨著容器技術(shù)的進一步發(fā)展普及，其所面臨的問題和對應(yīng)的解決方案也會越來越多?；贙ubernetes的容器云平臺為進一步建設(shè)功能更為豐富、實用性更強的容器云平臺打下了良好的基礎(chǔ)，對推進衛(wèi)星遙感行業(yè)后續(xù)傳統(tǒng)業(yè)務(wù)上云改造具有較大借鑒意義。