数据包的传输方法及装置与流程

本发明涉及通信技术领域，尤其涉及一种数据包的传输方法及装置。

背景技术：

相关技术中，随着容器技术的发展，在容器中部署大数据环境和运行大数据程序成为近年来引起热门讨论的话题，在集群规模不大的场景下，使用容器作为载体来部署大数据环境，可以在有限的物理资源环境下同时提供多个具有较高隔离性的大数据集群供用户使用。

docker容器技术是基于linuxlxc技术衍生的一种新型虚拟化技术，从2013年诞生之日起便持续得到开发者和企业的关注和青睐。使用docker技术，开发者可以轻松的在容器上部署和运行应用，并通过配置文件轻松实现应用的自动化安装、部署和升级，也可以很方便的将生产环境和开发环境分离，互不影响。

kubernetes是一个全新的基于容器技术的分布式架构领先方案。kubernetes是google开源的容器集群管理系统。在docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。

针对相关技术中由于容器变更导致的集群进行调整的流程复杂的问题，目前还没有有效的解决方案。

技术实现要素：

本发明提供的数据包的传输方法及装置，能够解决相关技术中由于容器变更导致的集群进行调整的流程复杂的问题。

根据本发明的一个实施例，提供了一种数据包的传输方法，包括：接收到第一应用程序发送的数据包，其中，所述第一应用程序运行于第一pod中的第一容器中；通过dns将所述数据包携带的servicename，解析为对应的第二podip；将所述数据包传输至所述第二podip对应的第二pod，由所述第二pod中第二容器中的应用程序进行处理；其中，所述第一pod和所述第二pod均运行于kubernetes。

根据本发明的另一个实施例，还提供了一种数据包的传输装置，包括：第一接收模块，用于接收到第一应用程序发送的数据包，其中，所述第一应用程序运行于第一pod中的第一容器中；第一解析模块，用于通过dns将所述数据包携带的servicename，解析为对应的第二podip；第一传输模块，用于将所述数据包传输至所述第二podip对应的第二pod，由所述第二pod中第二容器中的应用程序进行处理；其中，所述第一pod和所述第二pod均运行于kubernetes。

根据本发明的另一个实施例，还提供了一种存储介质，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行上述实施例中任一项所述的方法。

根据本发明的另一个实施例，还提供了一种电子装置，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述实施例任一项中所述的方法。

通过上述步骤，接收到第一应用程序发送的数据包，其中，所述第一应用程序运行于第一pod中的第一容器中；通过dns将所述数据包携带的servicename，解析为对应的第二podip；将所述数据包传输至所述第二podip对应的第二pod，由所述第二pod中第二容器中的应用程序进行处理；其中，所述第一pod和所述第二pod均运行于kubernetes，采用上述方案，由servicename替换相关技术中的ip地址，因此不再需要配置/etc/hosts文件，在容器出现故障或者新增等变更时，kubernetes会自动调整，从而不需要改写其他容器上的/etc/hosts文件，解决了相关技术中由于容器变更导致的集群进行调整的流程复杂的问题，避免了容器在重新调度之后的配置修改，减少了开发和运维工作。

附图说明

图1是根据本发明实施例中的数据包的传输方法流程图；

图2是根据相关技术中的集群部署环境示意图；

图3是根据本发明另一个实施例的大数据集群部署结构示意图；

图4是根据基于kubernetes的容器大数据集群逻辑结构图；

图5是根据本发明另一个实施例的数据包发送流程示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

下面对本发明文件中的技术术语进行说明：

kubernetes由谷歌公司开源的一种容器编排系统；

kubernetesservicekubernetes核心资源之一，负责代理容器间的网络访问；

kubernetespodkubernetes核心资源之一，是容器的封装环境；

dockerdocker是一个开源的应用容器引擎；

dns域名系统，负责将域名解析为ip；

hadoop开源的分布式存储和计算框架；

spark开源的分布式大数据通用计算框架；

storm开源的分布式实时流计算框架；

cassandra一套开源分布式nosql数据库系统。

本发明实施例提供一种数据包的传输方法，图1是根据本发明实施例中的数据包的传输方法流程图，如图1所示，所述方法包括：

s11、接收到第一应用程序发送的数据包，其中，所述第一应用程序运行于第一pod中的第一容器中；

第一容器中运行大数据业务，可以是分布式存储业务hdfs。

s12、通过dns将所述数据包携带的servicename，解析为对应的第二podip；

s13、将所述数据包传输至所述第二podip对应的第二pod，由所述第二pod中第二容器中的应用程序进行处理；其中，所述第一pod和所述第二pod均运行于kubernet。

通过上述步骤，接收到第一应用程序发送的数据包，其中，所述第一应用程序运行于第一pod中的第一容器中；通过dns将所述数据包携带的servicename，解析为对应的第二podip；将所述数据包传输至所述第二podip对应的第二pod，由所述第二pod中第二容器中的应用程序进行处理；其中，所述第一pod和所述第二pod均运行于kubernetes，采用上述方案，由servicename替换相关技术中的ip地址，因此不再需要配置/etc/hosts文件，在容器出现故障或者新增等变更时，kubernetes会自动调整，从而不需要改写其他容器上的/etc/hosts文件，解决了相关技术中由于容器变更导致的集群进行调整的流程复杂的问题，避免了容器在重新调度之后的配置修改，减少了开发和运维工作。

可选地，通过dns将所述数据包的servicename，解析为对应的第二podip，包括：通过kube-dns将所述数据包的servicename，解析为对应的serviceip；获取所述serviceip对应的所述第二podip。采用该方案，可以通过kube-dns将servicename解析为serviceip。

可选地，获取所述serviceip对应的第二podip之前，通过kubernetes的标签机制将serviceip和pod进行绑定。或者，将service与pod进行绑定。

可选地，通过dns将所述数据包携带的servicename，解析为对应的第二podip，包括：通过dns获取与所述数据包的servicename一致的容器hostname，其中，预先设置servicename与hostname保持一致，并采用无头服务headlessservice不设置serviceip；获取所述容器hostname对应的容器所在pod的所述第二podip。采用该方案，基于kubernetes的特性，实现了headlessservice与pod主机名的映射，优化了网络模型，使得dns在解析servicename的时候，可以直接将podip返回，减少了容器之间网络数据包的i/o次数。

可选地，所述kubernetes中的servicename和serviceip均维持不变，在所述kubernetes中运行的容器发生变更时，所述kubernetes将新生成的容器的容器ip对应至已有的servicename或serviceip。采用该方案，可以保证在容器变更的情况下，通过业务上规则的通过业务上规定的kubernetesservicename即可完成相互的通信，而不需要因为容器变更进行大幅修改。并由主节点修改从节点列表。

可选地，所述kubernetes中的每个pod中仅运行一个容器。

下面结合本发明另一个实施例进行说明。

相关技术中部署大数据集群(包括hadoop,spark,storm等)最常见的场景是基于物理机或者基于公有云服务。在此类场景下，物理机或者是云服务中提供的虚拟机都有一个在集群内唯一并且不会改变的ip地址，集群节点之间通过配置/etc/hosts文件来进行主机名和节点ip的解析，并通过ssh免密登录来实现节点间的服务自启动，图2是根据相关技术中的集群部署环境示意图，使用图2描述的集群部署方式，即基于/etc/hosts文件来进行主机名\ip映射来进行集群服务间的相互通信和服务发现，优点是部署简单，只需要部署前在集群中提前规划好主机名和ip即可。但是缺点同样也比较明显，这种部署方式比较适合于稳定的物理集群环境，即网络相对固定，物理ip不存在变动的环境。这种部署方式虽然简单，但是也面临一些问题：1)如果有一台集群节点宕机，直接的影响是大数据集群规模减少，直到运维人员察觉问题并重新恢复宕机的节点。2)

当集群规模较大时，扩容工作比较繁琐，需要在每一台集群节点上加入新的节点主机名和ip的映射关系。在容器内部署大数据集群也同样存在上述问题。虽然容器编排工具能够自动发现容器故障并重新调度生成新的容器，但是因为容器的生成是动态的，新容器的ip已经发生变化，如果不修改其他容器上的/etc/hosts文件，这个新调度的容器是无法加入到之前的大数据集群的。

本发明提出一种基于容器环境的大数据集群的去ip部署方法，通过利用容器及容器编排技术的高可用特性来保证其上运行的大数据集群的高可用。

本方案采用dns和kubernetesservice结合的方式来配置容器大数据集群，可实现容器环境发生异常重新调度后的大数据环境自动加入，减少了人为配置。

本方案实现了headlessservice与pod主机名的映射，减少了dns解析后的网络i/o。

本发明实施例对传统的大数据集群部署方案进行改进，结合容器的运行环境和容器编排工具kubernetes的高级特性，进行容器大数据集群的去ip化部署，即不依赖于/etc/hosts文件,去掉大数据集群对物理ip和主机名的强依赖。在本方案中，大数据集群内所有组件的配置不出现任何ip。

本方案中涉及到的部署环境如图3所示，图3是根据本发明另一个实施例的大数据集群部署结构示意图，如图3所示，正常情况下，node1上的container1-1和node2上的container1-2及node3上的container1-3组成一个逻辑大数据集群(蓝色背景所示)。当node1物理节点宕机后，其上面运行的容器由kubernetes自动调度到其他可用物理节点，这时container1-1的ip已经发生变化，但是和1-2、1-3容器组成的大数据集群并没有收到影响，集群的规模并没有发生变化。

下面以hadoophdfs集群搭建为例进行详细说明如何通过去ip化的方式(不配置/etc/hosts来解决容器内大数据集群的高可用问题)。

通常在部署hadoophdfs集群的时候，要配置如下几个关键配置文件的关键参数。

(1)core-site.xml

<property>

<name>fs.defaultfs</name>

<value>hdfs://master:8020</value>

</property>

此参数指定默认的文件系统为hdfs。

(2)hdfs-site.xml

<property>

<name>dfs.namenode.rpc-address</name>

<value>master:8020</value>

</property>

此参数指定hdfs主节点namenode绑定的启动地址和端口

<property>

<name>dfs.namenode.http-address</name>

<value>master:50070</value>

</property>

此参数指定hdfs主节点namenode开启的http服务的端口，用于web界面展示hdfs详细信息。

(3)slaves

node1

node2

此文件(3)指定了集群内从节点列表。

相关技术中的方式下，大数据组件读取到这些配置文件里的主机名后会去/etc/hosts里查找与之对应的ip，而在我们的方案里，主机名到地址的映射则交给dns完成，通过dns的a地址查询返回与主机名对应的ip地址。dns的地址不需要人为维护，从而有效的避免了对/etc/hosts的人为修改，实现了大数据集群的自动加入。

基于kubernetes部署的容器大数据集群逻辑结构图如图4所示，图4是根据基于kubernetes的容器大数据集群逻辑结构图，如图4所示，kubernetes提供了pod来做容器环境的封装，也就是说，在本方案中每个容器都运行在pod当中，并且每个pod只运行一个容器，容器中安装并运行特定的大数据服务，如hdfs。kubernetes提供service对象来代理外界对pod发起的请求，也就是发到指定service的指定端口的网络数据包，会被service转发到其代理的pod的指定端口，service与pod的通过kubernetes提供的标签机制进行绑定，从而实现将podip代理为service名称，也就是上文提到的主机名。从而容器集群内的大数据服务即可使用servicename替代ip来相互通信，从而既避免了/etc/hosts文件的修改，也去掉了配置文件中的ip地址，而统一改为使用kubernetesservicename。

如上文所说，在大数据服务的配置信息中我们采用了servicename来代替主机名做ip地址的映射，而操作系统解析主机名采用/etc/hosts文件，本方案不再采用修改/etc/hosts文件的方式，而是增加一个dns服务器来负责主机名的解析。这里采用的是kubernetes提供的dns服务kube-dns。kube-dns在整个kubernetes管理的集群中起到的作用就是负责将servicename解析成为serviveip，从而将请求转发到特定的pod上，从而完成大数据集群各节点的互通，示意图如图5所示，图5是根据本发明另一个实施例的数据包发送流程示意图，由图5可见，当某个容器的某个应用向其他应用发送数据包时，其内部的执行过程如下：

步骤1、解析servicename(查询dns)；

步骤2、将数据包发送到serviceip的对应端口；

步骤3、数据包由service转发到后端的对应pod的对应端口。

所以，通过以上的一系列配置和优化，可以实现去ip化的大数据集群配置，并且实现了容器集群的高可用，即当容器集群的某个容器意外终止并重新调度时，尽管其ip发生变化，但是由于不需要配置/etc/hosts文件，所以不需要在容器重新调度时修改/etc/hosts，集群中不变的是servicename和serviceip,尽管容器的ip发生了变化，kubernetes会动态的将新生成的容器ip绑定到对应的service之上，这一切对于容器内部的大数据服务是透明的。大数据服务仍然采用servicename相互访问，并不关心也不需要关心集群内其他节点的真实ip和其他节点是否发生了ip变化。

在具体的实现过程中，采用了kubenetes提供的api来操作和构造相关service和pod资源，并且刻意的让servicename与容器的hostname保持一致，并且采用了headlessservice特性，也就是去掉了serviceip，使得dns在解析servicename的时候，可以直接将podip返回，从而减少网络i/o。

除此之外，在大数据集群需要扩容时，此方案提供的配置方式将大大减少运维工作，因为对于大多数大数据服务，尤其是类似于cassandra这类去中心化的分布式大数据服务，其服务内每个节点都需相互通信，所以每个节点都需要保存其他所有节点的主机名解析方式。而本方案的配置方式，在集群扩容时可以实现动态感知新增节点的功能，当新增的数据节点加入集群之后，通过业务上规定的kubernetesservicename即可完成相互的通信。同理可类比于hdfs集群扩容，当新增数据节点时，新增节点无需做任何额外配置即可上线，而主节点仅需要修改从节点列表slaves文件，加入从节点主机名即可，从而大大的减少了集群扩容时对于集群内部容器的侵入和修改。

采用上述方案，实现了以下技术效果：a.本方案对传统的基于/etc/hosts文件、使用ip和主机名来配置大数据集群的方案进行了革新，尤其适合在容器环境中进行较大规模的大数据环境部署，实现了容器重新调度后的大数据集群高可用。b.本方案减少了容器内部的配置选项，避免了容器在重新调度之后的配置修改，减少了开发和运维工作，并且基于kubernetes的特性，优化了网络模型，减少了容器之间网络数据包的i/o次数，提升了用户体验和容器大数据集群的运行效率。

可选地，依然可以使用/etc/hosts文件的配置来构建容器大数据集群，但是需要应用自己捕捉容器的重新调度事件，并且侵入到每个容器中重写集群内每个节点的/etc/hosts文件。实现的难度和复杂度较本发明有所增大，但是其优点在于hosts文件的解析速度会略高于dns服务，使用/etc/hosts文件的主机名解析，大数据节点间通信的效率会有所提升。但是对于本方案中涉及到的容器大数据集群场景，这一点并不十分重要。

本发明实施例还提供一种数据包的传输装置，所述装置包括：

第一接收模块，用于接收到第一应用程序发送的数据包，其中，所述第一应用程序运行于第一pod中的第一容器中；

第一解析模块，用于通过dns将所述数据包携带的servicename，解析为对应的第二podip；

第一传输模块，用于将所述数据包传输至所述第二podip对应的第二pod，由所述第二pod中第二容器中的应用程序进行处理；

其中，所述第一pod和所述第二pod均运行于kubernetes。

通过上述方案，接收到第一应用程序发送的数据包，其中，所述第一应用程序运行于第一pod中的第一容器中；通过dns将所述数据包携带的servicename，解析为对应的第二podip；将所述数据包传输至所述第二podip对应的第二pod，由所述第二pod中第二容器中的应用程序进行处理；其中，所述第一pod和所述第二pod均运行于kubernetes，采用上述方案，由servicename替换相关技术中的ip地址，因此不再需要配置/etc/hosts文件，在容器出现故障或者新增等变更时，kubernetes会自动调整，从而不需要改写其他容器上的/etc/hosts文件，解决了相关技术中由于容器变更导致的集群进行调整的流程复杂的问题，避免了容器在重新调度之后的配置修改，减少了开发和运维工作。

可选地，所述第一解析模块还用于通过kube-dns将所述数据包的servicename，解析为对应的serviceip；以及用于获取所述serviceip对应的所述第二podip。

可选地，所述第一解析模块还用于通过dns获取与所述数据包的servicename一致的容器hostname，其中，预先设置servicename与hostname保持一致，并采用无头服务headlessservice不设置serviceip；以及用于获取所述容器hostname对应的容器所在pod的所述第二podip。

本实施例的装置，可以用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

根据本发明的另一个实施例，还提供了一种存储介质，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行上述实施例中任一项所述的方法。

根据本发明的另一个实施例，还提供了一种电子装置，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述实施例任一项中所述的方法。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(read-onlymemory，rom)或随机存储记忆体(randomaccessmemory，ram)等。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应该以权利要求的保护范围为准。