基于Kubernetes的卫星遥感数据容器云平台

刘宏娟，黄 炜，李文吉，邵治涛，胡 倩

(1.自然资源部航空地球物理与遥感地质重点实验室,北京 100083;2.中国自然资源航空物探遥感中心, 北京 100083)

0 引言

卫星遥感数据的处理及应用需要强大的算力支持，目前在用的数据处理平台以单体服务器和虚拟化平台为主。随着我国航天事业的高速发展，卫星遥感也进入了“大数据”时代，一方面，卫星遥感行业按照地质调查整体规划要向着一张图、一站式、平台化的方向发展。另一方面，卫星遥感数据的显著特点是多元异构，除了基本的卫星影像之外还包含了时间、空间、频谱等复杂的地质属性信息，卫星遥感的数据类型日渐丰富,数据总量呈现海量增长趋势，对硬件资源动态分配、弹性扩展、快速部署等方面均提出了更高要求。因此，探索利用云计算、大数据等新技术构建更加高效便捷的数据处理平台近年来在卫星遥感行业愈发重要,并已在地质调查的其他领域内取得了进展[1-2]。本文引入了容器概念以及Kubernetes容器集群管理系统，以容器为基本单位代替虚拟机部署应用服务，充分发挥容器轻便快捷、弹性扩展、便于维护的优势，尝试构建符合卫星遥感行业特点的容器云平台[3]。利用Kubernetes对容器的调度管理机制，将计算、网络、存储等服务器硬件资源虚拟化后动态分配给容器，为运行在容器内的卫星遥感应用服务提供高效可靠、轻便统一的“一站式”服务。

1 容器与虚拟化

1.1 容器技术

容器(Container)技术是一种轻量级的操作系统层虚拟化技术，借鉴了远洋运输里“集装箱”的理念。一般而言，部署一个应用需要提前准备好物理主机、操作系统以及各种中间件等软硬件环境，虚拟化部署一定程度上实现了硬件资源复用,但没有解决应用层问题，针对每一项应用部署还是需要单独搭建一整套依赖的操作系统、应用环境等。容器技术的原理是基于Linux的Namespace和Cgroup机制，将应用打包并虚拟化封装出了一套内核轻量级的操作系统(NameSpace区分隔离容器，Cgroup管理控制系统资源)[4]，通过容器引擎共享操作系统,只需在容器内部打包必要的Lib/Bin等操作系统文件，具有极其轻量、秒级部署、易于移植、弹性伸缩等特点，极大提高了部署和运维效率[5]。

Docker是一个基于LXC(Linux Container)的开源容器引擎，将与应用相关的依赖项(包括环境、程序、文件)打包成镜像部署在物理机中，主要包括容器(Container)、镜像(Image)以及仓库(Repository)3个部分。由于容器是应用程序的抽象，将各类应用服务变成模块化的组件，容器可以在相互隔离的物理环境中独立运行，物理机上可以同时运行多个容器，容器之间共享操作系统。利用镜像仓库，运维人员可以管理不同的镜像版本，灵活配置、快速部署。由于Docker标准化、轻量级、易迁移扩展的优势，Docker已发展成了容器技术的代名词，是目前应用最广泛的容器引擎[6]。

1.2 容器与虚拟化

虚拟化能更好地利用硬件资源，同一台物理主机上可以部署运行多个虚拟机，虚拟机之间资源和进程彼此隔离，解决了传统模式下同一台物理机上的应用服务抢夺资源问题。虚拟机是在物理主机中虚拟出一台完整计算机，在虚拟化的硬件之上运行所有组件(包括自身操作系统)，而容器则是直接将物理主机的操作系统虚拟出独立的用户空间，每个用户空间分配有各自的CPU、内存等计算资源供容器使用，容器之间彼此独立但共享物理主机的操作系统[7]。因而，容器的启动更迅速，创建更加简便快捷，能支持大规模应用服务的快速部署更新。虚拟化与容器的差异对比如图1所示。

图1 虚拟化与容器对比

1.3 Kubernetes核心概念

随着容器化部署的应用不断增多，容器和物理主机的集群规模也随之不断刷新，Docker 逐渐无法满足大规模容器集群的管理需求。Kubernetes是Google公司以Docker为基础、面向无服务场景的开源容器集群管理系统，能够为容器化的应用服务提供资源调度、自动重启、负载均衡、服务发现等基础功能。Kubernetes支持跨物理主机管理容器，大大降低了容器平台的维护难度，同时还为开发人员提供了一套RESTful接口，为后续开发拓展打下了良好基础。鉴于 Kubernetes强大的开源社区支撑以及众多成功应用的案例，是当下较为主流的容器管理平台[8-9]。

2 系统设计

2.1 系统整体框架

基于 Kubernetes卫星遥感数据容器云平台的逻辑功能框图如图 2 所示，包括物理层、Kubernetes 平台层和应用层3部分[10-11]。为保障卫星遥感业务正常运行，容器云平台之外还需要配套相应的支撑服务。本文选择了两个典型支撑服务作为代表：分布式存储和ES(Elastic Search)集群。

图2 容器云平台逻辑架构

物理层主要是指由实体服务器池化虚拟出来的物理资源(包括计算资源、存储资源、网络资源)，这些物理资源会被上层的 Kubernetes调度并分配给不同的容器。Kubernetes层是整个容器云平台的核心，统一管理控制容器及应用层服务的生命周期、资源分配，实时监控管理容器及部署在容器中的应用服务[12]。应用层主要是将卫星遥感应用软件抽象成一个个服务并容器化地部署到容器中，每个容器拥有独立的物理资源，容器彼此之间共享物理主机的操作系统，构成了针对特定应用服务的轻量内核级“虚拟机”[13]。

对于业务支撑功能，分布式存储系统为容器云平台提供统一的外置存储服务，主要用于海量卫星遥感数据的存储、访问、备份，既简化了应用层的数据存储复杂度，也保证了数据的一致性、可靠性。ElasticSearch为卫星遥感应用服务提供数据检索服务，其索引能力强大，且支持多种查询类型，在地理信息数据索引查询方面优势明显。ES集群结合卫星遥感数据特点进行了单独优化设计，能够大幅提高检索效率。由于上层应用服务需要频繁地检索使用卫星遥感数据，因此将检索功能独立部署于容器云平台之外，通过接口提供服务。容器云平台使用多种接口协议进行访问： ES Rest API、ES SQL、Impala SQL、Hive SQL、HBase MapReduce，也充分体现了平台架构的开放性。

2.2 Kubernetes架构

Kubernetes 主要由控制节点(Master node)和工作节点(Worker node)两类节点组成，其系统架构如图 3所示。[14]控制节点包括 API服务器、控制管理器、调度器和 etcd 键值数据库等组件，负责全局决策、调度控制、事件响应等平台管理功能。[15-16]工作节点主要包括 kubelet和 kube-proxy两个组件，用以维护工作节点上运行的每个Pod ，并为每个节点提供必要的运行环境。

图3 kubernetes 架构

本文采用了 Kubernetes1.21 版本,使用了六台物理主机(centos7.9操作系统)构建容器云平台。所有物理主机均需要安装docker，以指定yum 源方式安装kubelet、kubectl 等组件，此处使用阿里云的源，具体硬件配置如表1所示。

表1 容器云平台硬件配置

2.3 高可用集群

应用服务运行在容器之中，需要容器以极高的可靠性保障业务的连续性。Kubernetes 是容器云平台的核心，控制节点是Kubernets管理功能的关键所在，其中最关键是的etcd键值数据库，负责保存各节点的关键数据，用于配置共享和服务发现。针对系统中的关键节点和关键功能，采用“多控制节点+ etcd 集群”的方式，来提高整个系统的高可用性和安全性。[17-18]Kubernetes 高可用集群架构如图4所示。

图4 kubernetes 高可用集群架构

Kubernetes 的工作节点通过内部的负载均衡机制连接到控制节点上，多控制节点模式下只有所有控制节点同时故障才会影响平台运行。多控制节点的实现是在控制管理器、调度器修改leader-elect参数。在多控制节点模式下，系统会自动选举出主控制节点(master leader)，如果主控制节点宕机导致系统异常，则会自动选举出新的主控制节点[19-20]。

etcd集群借鉴了Hadoop中ZooKeeper的设计理念，其核心原理是使用Raft协议保障节点的一致性[21]。etcd集群中只有1个有效的主节点，主节点负责处理所有来自系统的写操作并对状态机进行维护，通过Raft协议保证主节点对状态机的改动会可靠同步到集群中的其他节点。

2.4 外接分布式存储

容器中的数据是非永久保存的，当容器宕机崩溃时，kubelet会以镜像的初始状态重新启动容器，容器中的数据将丢失。为保障容器数据的存储安全，Kubernetes提供了两套机制：一是为容器分配临时存储卷，二是通过容器存储接口Container Storage Interface(CSI)提供外部存储服务[22-23]。卫星遥感数据总量大需要长期保存，本文采用第二种方法，利用分布式存储的核心组件之一HDFS NFS Gateway，将HDFS存储空间通过CSI机制以NFS的形式挂载至Kubernetes，为容器云平提供外部独立的分布式存储服务。外部存储接口主要依靠PV和PVC实现，其中PV是底层网络共享存储的抽象，将共享存储定义为一种供容器消费使用的资源对象，而PVC是对存储资源的申请，容器可以通过PVC的形式申请特定的存储空间和访问模式。

卫星遥感数据单幅数据量大且有其独特的数据格式，因此在接入容器云平台时需要进行适当改造。以GF7号卫星为例，原始数据以tar.gz压缩包形式保存约为2G，其中卫星拍摄的影像数据(jpg格式)占单幅数据总量的90%以上，仅在数据处理时才进行读写操作，而相关的卫星数据参数以xml格式保存，在数据存储、查询、筛选、读写、处理时需要频繁访问。从读取效率、备份安全、存储扩展等方面考虑，卫星遥感数据不适合直接存储在容器云平台内。因此在采用外接分布式存储的解决方案下，卫星遥感影像数据经处理后存入独立部署的HDFS分布式存储系统，通过定义PV、PVC实现存储系统与容器云平台的对接。

为了提高查询效率，xml卫星数据参数存入HFDS分布式存储系统中的HBase数据库中，jpg卫星影像则直接存入HDFS分布式存储系统，存储路径保存在对应的HBase数据库中。HBase数据库目录直接加载至Kubernets的临时存储卷中供相关容器访问，需要读写卫星影像数据时，首先从HBase中查询到保存路径，再调用HFDS分布式存储的接口进行操作。定义PV、PVC并关联至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 分析展望

本章重点对容器云平台的性能效率进行了简要测试比较，并进一步结合当前卫星遥感行业现状以及虚拟化平台的应用特性，分析了容器云平台的应用前景以及面临的实际困难。

3.1 容器性能测试

容器相较与虚拟机最大的优势在于轻量化内核、快速化部署。以常用容器官方镜像版本为测试对象，单一容器测试列表如表2所列。

表2 单一容器测试

其中启动时间是指容器由 Penning 状态转变为 Running 状态所需的时间，测试时容器云平台上没有运行其他非测试容器。根据测试结果可知,测试容器均能正常启动，耗时均在3秒内启动速度非常快。多容器并行测试选择把表2中的镜像均启动100个容器，测试结果如表3所列。

表3 多容器测试

通过对比表2和表3的测试结果可以得知,随着容器规模的扩大,容器的启动速度并没有显著下降,平均启动时间都在3秒内,启动速度远超过虚拟机达到了快速部署的预期,为高并行应用的开发部署创造了有利条件。

3.2 容器功能测试

本项测试这要通过为卫星遥感业务流程来验证容器云平台的功能性，同时对比相同条件下虚拟机的性能效率。测试环境里HDFS分布式存储系统中已导入260景GF7卫星影像数据作为测试对象，分别在容器环境和虚拟环境下部署了基于Web的卫星影像共享查询系统，查询系统运行后调用ElasticSearch查询位于HDFS分布式存储系统中的GF7卫星影像数据，具体测试内容为以下两项：

1)遍历查询整个GF7测试数据库中的所有卫星影像数据。

(1) 试验矿样中的主要金属矿物为黄铜矿、孔雀石、自然铜、蓝铜矿、褐铁矿等；主要脉石矿物为石英，其次有碳酸盐矿物和绿泥石、绢云母等。含银矿物包括银黝铜矿、辉银矿、深红银矿及少量自然银，银大部分产于铜矿物中，而脉石矿物中含银较少。

2)查询GF7数据库中左上角经度在(40,49)，且传感器类型为mux的卫星影像数据(即rt_lat为(40,49)，且传感器类型为sensorid='MUX')。

表4 业务测试

通过表4的测试结果可以看出，卫星影像共享查询系统部署在容器，并能够正常调用且访问外接分布式存储系统内的卫星遥感影像数据，充分证明容器云平台功能正常，已经可以初步实现对卫星遥感数据的加工处理。对比卫星影像共享查询系统在容器与虚拟机中部署后，容器中的卫星影像共享查询系统在卫星遥感影像数据查询和读写速度略优于虚拟化平台。

3.3 应用前景

1)微服务:

微服务架构是将单体应用拆分成多个不同功能的微服务模块，从而降低系统的耦合性、复杂度，更加便于开发人员部署维护。每个微服务部署到单独容器中，服务之间可独立开发部署，支持不同的开发语言，易于后期维护和功能拓展。目前最常见的微服务案例是Web服务，基于B/S架构的卫星遥感应用服务可以优先考虑改造迁移至容器云平台。

2)深度学习:

深度学习在卫星遥感方向上有着广阔的应用前景，比如基于影像的地质灾害自动识别、山体滑坡自动监测等。容器可以轻松解决机器训练过程中环境配置、资源分配等一系列问题，是当前进行深度学习算法研究所用的主流架构。目前容器已支持TensorFlow、Caffe、Caffe2、PyTorch等主流深度学习的训练框架，能够为卫星遥感数据的深度学习研究提供平台与技术支持。

3)弹性伸缩:

对于一次性执行运算任务，传统模式单一任务占据整个服务器，造成了极大资源浪费，容器快速创建、灵活销毁的特点更适用于这种按需使用的场景。需要运算时创建容器执行任务，运算完成后容器退出释放其占有的硬件资源。

对于大规模并行计算任务，容器云平台能够根据资源的负载情况进行动态调节，避免了流量激增扩容不及时资源耗宕机，也避免了平时大量闲置资源浪费，提高了硬件资源利用率。

4)高效运维:

通过镜像管理运维人员可以轻松地对平台内的容器及部署在容器内的业务进行部署管理。需要升级容器内的业务时，运维人员只需选择相应镜像版本和副本数量，即可实现自动升级且业务平滑不中断，升级后若有问题还可选择回滚至旧版本。

3.4 面临问题

1)速率瓶颈:

虚拟化与容器提升了物理主机的硬件资源利用率，代价则是更多的数据交互与网络开销。当业务高峰期并行数量大时，物理主机用来支撑容器的服务资源就会紧张，造成队列堵塞，前端用户的感受就是应用卡顿。由于卫星遥感单幅影像数据量大，总数据量可达到PB级，不可避免需要采取独立部署的分布式或集中存储系统，单独管理数据存储。无论是虚拟化平台还是容器云平台，都是通过内部网络进行访问读写操作，网络带宽与数据吞吐速率始终是制约卫星遥感数据处理能力上限的瓶颈。

2)应用容器化:

容器的优势在于轻量化的内核、便捷的封装部署，但并不是所有的应用服务都适合或者能够被容器化，比如说IO交互密集的数据库、某些license绑定固定硬件的软件。此外，将应用服务迁移至容器部署需要对代码进行容器化改造，也需要人力和时间成本付出，比如地质行业最常用的专业软件ArgGIS、GXL等，短期内都无法实现容器化部署，这也制约了容器技术在整个行业中的推广应用。

3)隔离安全:

容器由于共享操作系统内核及驱动，容器内某应用服务的非法运行或者故障报错，可能会导致物理主机的操作系统异常，进而影响到其他容器及容器内的应用服务。此外，也更容易被外部攻击通过安全漏洞攻击操作系统，进而影响上层应用服务。因而，在当前的应用场景下，容器还不太适合公有云的运行环境，如有外部接入还需配套设计严格的安全防护机制。

4 结束语

基于Kubernetes的容器云平台是容器技术在卫星遥感行业的应用探索，已能够初步实现对卫星遥感数据的处理加工,提高了物理主机的硬件资源利用率，降低了后期运维管理成本，并在微服务、深度学习等方向上展现出现了巨大潜力。随着容器技术的进一步发展普及，其所面临的问题和对应的解决方案也会越来越多。基于Kubernetes的容器云平台为进一步建设功能更为丰富、实用性更强的容器云平台打下了良好的基础，对推进卫星遥感行业后续传统业务上云改造具有较大借鉴意义。