CN109525590A - 数据包的传输方法及装置 - Google Patents

数据包的传输方法及装置 Download PDF

Info

Publication number
CN109525590A
CN109525590A CN201811512476.8A CN201811512476A CN109525590A CN 109525590 A CN109525590 A CN 109525590A CN 201811512476 A CN201811512476 A CN 201811512476A CN 109525590 A CN109525590 A CN 109525590A
Authority
CN
China
Prior art keywords
pod
service
container
data packet
kubernetes
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201811512476.8A
Other languages
English (en)
Other versions
CN109525590B (zh
Inventor
吕晨涛
宋怀明
郭庆
谢莹莹
蒋丹东
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Zhongke Dawning International Information Industry Co Ltd
Original Assignee
Zhongke Dawning International Information Industry Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Zhongke Dawning International Information Industry Co Ltd filed Critical Zhongke Dawning International Information Industry Co Ltd
Priority to CN201811512476.8A priority Critical patent/CN109525590B/zh
Publication of CN109525590A publication Critical patent/CN109525590A/zh
Application granted granted Critical
Publication of CN109525590B publication Critical patent/CN109525590B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Abstract

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

Description

数据包的传输方法及装置
技术领域
本发明涉及通信技术领域，尤其涉及一种数据包的传输方法及装置。
背景技术
相关技术中，随着容器技术的发展，在容器中部署大数据环境和运行大数据程序成为近年来引起热门讨论的话题，在集群规模不大的场景下，使用容器作为载体来部署大数据环境，可以在有限的物理资源环境下同时提供多个具有较高隔离性的大数据集群供用户使用。
Docker容器技术是基于Linux LXC技术衍生的一种新型虚拟化技术，从2013年诞生之日起便持续得到开发者和企业的关注和青睐。使用Docker技术，开发者可以轻松的在容器上部署和运行应用，并通过配置文件轻松实现应用的自动化安装、部署和升级，也可以很方便的将生产环境和开发环境分离，互不影响。
Kubernetes是一个全新的基于容器技术的分布式架构领先方案。Kubernetes是Google开源的容器集群管理系统。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。
针对相关技术中由于容器变更导致的集群进行调整的流程复杂的问题，目前还没有有效的解决方案。
发明内容
本发明提供的数据包的传输方法及装置，能够解决相关技术中由于容器变更导致的集群进行调整的流程复杂的问题。
根据本发明的一个实施例，提供了一种数据包的传输方法，包括：接收到第一应用程序发送的数据包，其中，所述第一应用程序运行于第一Pod中的第一容器中；通过DNS将所述数据包携带的Service Name，解析为对应的第二Pod IP；将所述数据包传输至所述第二Pod IP对应的第二Pod，由所述第二Pod中第二容器中的应用程序进行处理；其中，所述第一Pod和所述第二Pod均运行于Kubernetes。
根据本发明的另一个实施例，还提供了一种数据包的传输装置，包括：第一接收模块，用于接收到第一应用程序发送的数据包，其中，所述第一应用程序运行于第一Pod中的第一容器中；第一解析模块，用于通过DNS将所述数据包携带的Service Name，解析为对应的第二Pod IP；第一传输模块，用于将所述数据包传输至所述第二Pod IP对应的第二Pod，由所述第二Pod中第二容器中的应用程序进行处理；其中，所述第一Pod和所述第二Pod均运行于Kubernetes。
根据本发明的另一个实施例，还提供了一种存储介质，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行上述实施例中任一项所述的方法。
根据本发明的另一个实施例，还提供了一种电子装置，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述实施例任一项中所述的方法。
通过上述步骤，接收到第一应用程序发送的数据包，其中，所述第一应用程序运行于第一Pod中的第一容器中；通过DNS将所述数据包携带的Service Name，解析为对应的第二Pod IP；将所述数据包传输至所述第二Pod IP对应的第二Pod，由所述第二Pod中第二容器中的应用程序进行处理；其中，所述第一Pod和所述第二Pod均运行于Kubernetes，采用上述方案，由Service Name替换相关技术中的IP地址，因此不再需要配置/etc/hosts文件，在容器出现故障或者新增等变更时，Kubernetes会自动调整，从而不需要改写其他容器上的/etc/hosts文件，解决了相关技术中由于容器变更导致的集群进行调整的流程复杂的问题，避免了容器在重新调度之后的配置修改，减少了开发和运维工作。
附图说明
图1是根据本发明实施例中的数据包的传输方法流程图；
图2是根据相关技术中的集群部署环境示意图；
图3是根据本发明另一个实施例的大数据集群部署结构示意图；
图4是根据基于Kubernetes的容器大数据集群逻辑结构图；
图5是根据本发明另一个实施例的数据包发送流程示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
下面对本发明文件中的技术术语进行说明：
Kubernetes由谷歌公司开源的一种容器编排系统；
Kubernetes Service Kubernetes核心资源之一，负责代理容器间的网络访问；
Kubernetes Pod Kubernetes核心资源之一，是容器的封装环境；
Docker Docker是一个开源的应用容器引擎；
DNS域名系统，负责将域名解析为IP；
Hadoop开源的分布式存储和计算框架；
Spark开源的分布式大数据通用计算框架；
Storm开源的分布式实时流计算框架；
Cassandra一套开源分布式NoSQL数据库系统。
本发明实施例提供一种数据包的传输方法，图1是根据本发明实施例中的数据包的传输方法流程图，如图1所示，所述方法包括：
S11、接收到第一应用程序发送的数据包，其中，所述第一应用程序运行于第一Pod中的第一容器中；
第一容器中运行大数据业务，可以是分布式存储业务HDFS。
S12、通过DNS将所述数据包携带的Service Name，解析为对应的第二Pod IP；
S13、将所述数据包传输至所述第二Pod IP对应的第二Pod，由所述第二Pod中第二容器中的应用程序进行处理；其中，所述第一Pod和所述第二Pod均运行于Kubernet。
通过上述步骤，接收到第一应用程序发送的数据包，其中，所述第一应用程序运行于第一Pod中的第一容器中；通过DNS将所述数据包携带的Service Name，解析为对应的第二Pod IP；将所述数据包传输至所述第二Pod IP对应的第二Pod，由所述第二Pod中第二容器中的应用程序进行处理；其中，所述第一Pod和所述第二Pod均运行于Kubernetes，采用上述方案，由Service Name替换相关技术中的IP地址，因此不再需要配置/etc/hosts文件，在容器出现故障或者新增等变更时，Kubernetes会自动调整，从而不需要改写其他容器上的/etc/hosts文件，解决了相关技术中由于容器变更导致的集群进行调整的流程复杂的问题，避免了容器在重新调度之后的配置修改，减少了开发和运维工作。
可选地，通过DNS将所述数据包的Service Name，解析为对应的第二Pod IP，包括：通过Kube-DNS将所述数据包的Service Name，解析为对应的Service IP；获取所述ServiceIP对应的所述第二Pod IP。采用该方案，可以通过Kube-DNS将Service Name解析为ServiceIP。
可选地，获取所述Service IP对应的第二Pod IP之前，通过Kubernetes的标签机制将Service IP和Pod进行绑定。或者，将Service与Pod进行绑定。
可选地，通过DNS将所述数据包携带的Service Name，解析为对应的第二Pod IP，包括：通过DNS获取与所述数据包的Service Name一致的容器HostName，其中，预先设置Service Name与HostName保持一致，并采用无头服务Headless Service不设置ServiceIP；获取所述容器HostName对应的容器所在Pod的所述第二Pod IP。采用该方案，基于Kubernetes的特性，实现了Headless Service与Pod主机名的映射，优化了网络模型，使得DNS在解析Service Name的时候，可以直接将Pod IP返回，减少了容器之间网络数据包的I/O次数。
可选地，所述Kubernetes中的Service Name和Service IP均维持不变，在所述Kubernetes中运行的容器发生变更时，所述Kubernetes将新生成的容器的容器IP对应至已有的Service Name或Service IP。采用该方案，可以保证在容器变更的情况下，通过业务上规则的通过业务上规定的Kubernetes Service Name即可完成相互的通信，而不需要因为容器变更进行大幅修改。并由主节点修改从节点列表。
可选地，所述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和Kubernetes Service结合的方式来配置容器大数据集群，可实现容器环境发生异常重新调度后的大数据环境自动加入，减少了人为配置。
本方案实现了Headless Service与Pod主机名的映射，减少了DNS解析后的网络I/O。
本发明实施例对传统的大数据集群部署方案进行改进，结合容器的运行环境和容器编排工具Kubernetes的高级特性，进行容器大数据集群的去IP化部署，即不依赖于/etc/hosts文件,去掉大数据集群对物理IP和主机名的强依赖。在本方案中，大数据集群内所有组件的配置不出现任何IP。
本方案中涉及到的部署环境如图3所示，图3是根据本发明另一个实施例的大数据集群部署结构示意图，如图3所示，正常情况下，Node1上的Container1-1和Node2上的Container 1-2及Node3上的Container 1-3组成一个逻辑大数据集群(蓝色背景所示)。当Node1物理节点宕机后，其上面运行的容器由Kubernetes自动调度到其他可用物理节点，这时Container 1-1的IP已经发生变化，但是和1-2、1-3容器组成的大数据集群并没有收到影响，集群的规模并没有发生变化。
下面以Hadoop HDFS集群搭建为例进行详细说明如何通过去IP化的方式(不配置/etc/hosts来解决容器内大数据集群的高可用问题)。
通常在部署Hadoop HDFS集群的时候，要配置如下几个关键配置文件的关键参数。
(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提供的标签机制进行绑定，从而实现将Pod IP代理为Service名称，也就是上文提到的主机名。从而容器集群内的大数据服务即可使用Service Name替代IP来相互通信，从而既避免了/etc/hosts文件的修改，也去掉了配置文件中的IP地址，而统一改为使用Kubernetes Service Name。
如上文所说，在大数据服务的配置信息中我们采用了Service Name来代替主机名做IP地址的映射，而操作系统解析主机名采用/etc/hosts文件，本方案不再采用修改/etc/hosts文件的方式，而是增加一个DNS服务器来负责主机名的解析。这里采用的是Kubernetes提供的DNS服务Kube-DNS。Kube-DNS在整个Kubernetes管理的集群中起到的作用就是负责将Service Name解析成为Servive IP，从而将请求转发到特定的Pod上，从而完成大数据集群各节点的互通，示意图如图5所示，图5是根据本发明另一个实施例的数据包发送流程示意图，由图5可见，当某个容器的某个应用向其他应用发送数据包时，其内部的执行过程如下：
步骤1、解析Service Name(查询DNS)；
步骤2、将数据包发送到Service IP的对应端口；
步骤3、数据包由Service转发到后端的对应Pod的对应端口。
所以，通过以上的一系列配置和优化，可以实现去IP化的大数据集群配置，并且实现了容器集群的高可用，即当容器集群的某个容器意外终止并重新调度时，尽管其IP发生变化，但是由于不需要配置/etc/hosts文件，所以不需要在容器重新调度时修改/etc/hosts，集群中不变的是Service Name和Service IP,尽管容器的IP发生了变化，Kubernetes会动态的将新生成的容器IP绑定到对应的Service之上，这一切对于容器内部的大数据服务是透明的。大数据服务仍然采用Service Name相互访问，并不关心也不需要关心集群内其他节点的真实IP和其他节点是否发生了IP变化。
在具体的实现过程中，采用了Kubenetes提供的API来操作和构造相关Service和Pod资源，并且刻意的让Service Name与容器的HostName保持一致，并且采用了HeadlessService特性，也就是去掉了Service IP，使得DNS在解析Service Name的时候，可以直接将Pod IP返回，从而减少网络I/O。
除此之外，在大数据集群需要扩容时，此方案提供的配置方式将大大减少运维工作，因为对于大多数大数据服务，尤其是类似于Cassandra这类去中心化的分布式大数据服务，其服务内每个节点都需相互通信，所以每个节点都需要保存其他所有节点的主机名解析方式。而本方案的配置方式，在集群扩容时可以实现动态感知新增节点的功能，当新增的数据节点加入集群之后，通过业务上规定的Kubernetes Service Name即可完成相互的通信。同理可类比于HDFS集群扩容，当新增数据节点时，新增节点无需做任何额外配置即可上线，而主节点仅需要修改从节点列表slaves文件，加入从节点主机名即可，从而大大的减少了集群扩容时对于集群内部容器的侵入和修改。
采用上述方案，实现了以下技术效果：a.本方案对传统的基于/etc/hosts文件、使用IP和主机名来配置大数据集群的方案进行了革新，尤其适合在容器环境中进行较大规模的大数据环境部署，实现了容器重新调度后的大数据集群高可用。b.本方案减少了容器内部的配置选项，避免了容器在重新调度之后的配置修改，减少了开发和运维工作，并且基于Kubernetes的特性，优化了网络模型，减少了容器之间网络数据包的I/O次数，提升了用户体验和容器大数据集群的运行效率。
可选地，依然可以使用/etc/hosts文件的配置来构建容器大数据集群，但是需要应用自己捕捉容器的重新调度事件，并且侵入到每个容器中重写集群内每个节点的/etc/hosts文件。实现的难度和复杂度较本发明有所增大，但是其优点在于hosts文件的解析速度会略高于DNS服务，使用/etc/hosts文件的主机名解析，大数据节点间通信的效率会有所提升。但是对于本方案中涉及到的容器大数据集群场景，这一点并不十分重要。
本发明实施例还提供一种数据包的传输装置，所述装置包括：
第一接收模块，用于接收到第一应用程序发送的数据包，其中，所述第一应用程序运行于第一Pod中的第一容器中；
第一解析模块，用于通过DNS将所述数据包携带的Service Name，解析为对应的第二Pod IP；
第一传输模块，用于将所述数据包传输至所述第二Pod IP对应的第二Pod，由所述第二Pod中第二容器中的应用程序进行处理；
其中，所述第一Pod和所述第二Pod均运行于Kubernetes。
通过上述方案，接收到第一应用程序发送的数据包，其中，所述第一应用程序运行于第一Pod中的第一容器中；通过DNS将所述数据包携带的Service Name，解析为对应的第二Pod IP；将所述数据包传输至所述第二Pod IP对应的第二Pod，由所述第二Pod中第二容器中的应用程序进行处理；其中，所述第一Pod和所述第二Pod均运行于Kubernetes，采用上述方案，由Service Name替换相关技术中的IP地址，因此不再需要配置/etc/hosts文件，在容器出现故障或者新增等变更时，Kubernetes会自动调整，从而不需要改写其他容器上的/etc/hosts文件，解决了相关技术中由于容器变更导致的集群进行调整的流程复杂的问题，避免了容器在重新调度之后的配置修改，减少了开发和运维工作。
可选地，所述第一解析模块还用于通过Kube-DNS将所述数据包的Service Name，解析为对应的Service IP；以及用于获取所述Service IP对应的所述第二Pod IP。
可选地，所述第一解析模块还用于通过DNS获取与所述数据包的Service Name一致的容器HostName，其中，预先设置Service Name与HostName保持一致，并采用无头服务Headless Service不设置Service IP；以及用于获取所述容器HostName对应的容器所在Pod的所述第二Pod IP。
本实施例的装置，可以用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。
根据本发明的另一个实施例，还提供了一种存储介质，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行上述实施例中任一项所述的方法。
根据本发明的另一个实施例，还提供了一种电子装置，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述实施例任一项中所述的方法。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random AccessMemory，RAM)等。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应该以权利要求的保护范围为准。

Claims (10)

1.一种数据包的传输方法，其特征在于，包括：
接收到第一应用程序发送的数据包，其中，所述第一应用程序运行于第一Pod中的第一容器中；
通过DNS将所述数据包携带的Service Name，解析为对应的第二Pod IP；
将所述数据包传输至所述第二Pod IP对应的第二Pod，由所述第二Pod中第二容器中的应用程序进行处理；
其中，所述第一Pod和所述第二Pod均运行于Kubernetes。
2.根据权利要求1所述的方法，其特征在于，通过DNS将所述数据包的Service Name，解析为对应的第二Pod IP，包括：
通过Kube-DNS将所述数据包的Service Name，解析为对应的Service IP；
获取所述Service IP对应的所述第二Pod IP。
3.根据权利要求2所述的方法，其特征在于，获取所述Service IP对应的第二Pod IP之前，所述方法还包括：
通过Kubernetes的标签机制将Service IP和Pod进行绑定。
4.根据权利要求1所述的方法，其特征在于，通过DNS将所述数据包携带的ServiceName，解析为对应的第二Pod IP，包括：
通过DNS获取与所述数据包的Service Name一致的容器HostName，其中，预先设置Service Name与HostName保持一致，并采用无头服务Headless Service不设置ServiceIP；
获取所述容器HostName对应的容器所在Pod的所述第二Pod IP。
5.根据权利要求2或3所述的方法，其特征在于，所述Kubernetes中的Service Name和Service IP均维持不变，在所述Kubernetes中运行的容器发生变更时，所述Kubernetes将新生成的容器的容器IP对应至已有的Service Name或Service IP。
6.根据权利要求1所述的方法，其特征在于，所述Kubernetes中的每个Pod中仅运行一个容器。
7.一种数据包的传输装置，其特征在于，包括：
第一接收模块，用于接收到第一应用程序发送的数据包，其中，所述第一应用程序运行于第一Pod中的第一容器中；
第一解析模块，用于通过DNS将所述数据包携带的Service Name，解析为对应的第二Pod IP；
第一传输模块，用于将所述数据包传输至所述第二Pod IP对应的第二Pod，由所述第二Pod中第二容器中的应用程序进行处理；
其中，所述第一Pod和所述第二Pod均运行于Kubernetes。
8.根据权利要求7所述的装置，其特征在于，所述第一解析模块还用于通过Kube-DNS将所述数据包的Service Name，解析为对应的Service IP；
以及用于获取所述Service IP对应的所述第二Pod IP。
9.根据权利要求7所述的装置，其特征在于，所述第一解析模块还用于通过DNS获取与所述数据包的Service Name一致的容器HostName，其中，预先设置Service Name与HostName保持一致，并采用无头服务Headless Service不设置Service IP；
以及用于获取所述容器HostName对应的容器所在Pod的所述第二Pod IP。
10.一种电子装置，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行所述权利要求1至6任一项中所述的方法。
CN201811512476.8A 2018-12-11 2018-12-11 数据包的传输方法及装置 Active CN109525590B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201811512476.8A CN109525590B (zh) 2018-12-11 2018-12-11 数据包的传输方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811512476.8A CN109525590B (zh) 2018-12-11 2018-12-11 数据包的传输方法及装置

Publications (2)

Publication Number Publication Date
CN109525590A true CN109525590A (zh) 2019-03-26
CN109525590B CN109525590B (zh) 2021-12-07

Family

ID=65795987

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811512476.8A Active CN109525590B (zh) 2018-12-11 2018-12-11 数据包的传输方法及装置

Country Status (1)

Country Link
CN (1) CN109525590B (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111182089A (zh) * 2019-12-31 2020-05-19 北京金山云网络技术有限公司 容器集群系统和访问大数据组件的方法、装置及服务器
CN111343007A (zh) * 2020-02-13 2020-06-26 卓望数码技术（深圳）有限公司 一种集群部署方法、装置和计算机可读介质
CN111522636A (zh) * 2020-04-03 2020-08-11 安超云软件有限公司 应用容器的调整方法、调整系统、计算机可读介质及终端设备
CN112202940A (zh) * 2020-10-27 2021-01-08 杭州朗澈科技有限公司 一种kubernetes对外暴露Pod服务方式

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105897946A (zh) * 2016-04-08 2016-08-24 北京搜狐新媒体信息技术有限公司 一种访问地址的获取方法及系统
CN106302771A (zh) * 2016-08-23 2017-01-04 浪潮电子信息产业股份有限公司 一种基于Docker容器创建的应用的域名配置方法
US20180013618A1 (en) * 2016-07-11 2018-01-11 Aruba Networks, Inc. Domain name system servers for dynamic host configuration protocol clients
CN107707688A (zh) * 2017-10-19 2018-02-16 杭州数梦工场科技有限公司 一种kubernetes集群解析宿主机主机名的方法及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105897946A (zh) * 2016-04-08 2016-08-24 北京搜狐新媒体信息技术有限公司 一种访问地址的获取方法及系统
US20180013618A1 (en) * 2016-07-11 2018-01-11 Aruba Networks, Inc. Domain name system servers for dynamic host configuration protocol clients
CN106302771A (zh) * 2016-08-23 2017-01-04 浪潮电子信息产业股份有限公司 一种基于Docker容器创建的应用的域名配置方法
CN107707688A (zh) * 2017-10-19 2018-02-16 杭州数梦工场科技有限公司 一种kubernetes集群解析宿主机主机名的方法及装置

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ALLCLOUD: "kubernetes 简介：kube-dns 和服务发现", 《HTTPS://WWW.CNBLOGS.COM/ALLCLOUD/P/7614123.HTML》 *
王淼鑫: "基于IaaS的大数据容器集群关键技术研究", 《中国优秀硕士学位论文全文数据库（信息科技辑）》 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111182089A (zh) * 2019-12-31 2020-05-19 北京金山云网络技术有限公司 容器集群系统和访问大数据组件的方法、装置及服务器
CN111343007A (zh) * 2020-02-13 2020-06-26 卓望数码技术（深圳）有限公司 一种集群部署方法、装置和计算机可读介质
CN111343007B (zh) * 2020-02-13 2022-12-13 卓望数码技术（深圳）有限公司 一种集群部署方法、装置和计算机可读介质
CN111522636A (zh) * 2020-04-03 2020-08-11 安超云软件有限公司 应用容器的调整方法、调整系统、计算机可读介质及终端设备
CN111522636B (zh) * 2020-04-03 2023-03-14 安超云软件有限公司 应用容器的调整方法、调整系统、计算机可读介质及终端设备
CN112202940A (zh) * 2020-10-27 2021-01-08 杭州朗澈科技有限公司 一种kubernetes对外暴露Pod服务方式

Also Published As

Publication number Publication date
CN109525590B (zh) 2021-12-07

Similar Documents

Publication Publication Date Title
US10778798B2 (en) Remote service access in a container management system
CN109525590A (zh) 数据包的传输方法及装置
CN113596110B (zh) 一种面向异构云的云原生微服务平台
CN105393220B (zh) 用于在集群系统中部署点状虚拟服务器的系统和方法
US11928514B2 (en) Systems and methods providing serverless DNS integration
CN109194502B (zh) 多租户容器云计算系统的管理方法
CN102902780B (zh) 一种统一资源定位符url动态匹配方法及装置
US11924240B2 (en) Mechanism for identifying differences between network snapshots
CN107210924B (zh) 用于配置通信系统的方法和设备
CN104011701A (zh) 内容传送网络
CN110784360A (zh) 一种实现Kong声明式配置热更新的方法及系统
CN111124589B (zh) 一种服务发现系统、方法、装置及设备
CN110311948B (zh) 容器/容器组间的通信方法及基于此的容器云网络系统
WO2020108443A1 (zh) 一种虚拟化管理方法及装置
CN110581893B (zh) 数据传输方法、装置、路由设备、服务器及存储介质
CN105208090A (zh) 一种基于Zookeeper实现Leader选举的方法
CN110166507A (zh) 多资源调度方法和装置
CN110019539A (zh) 一种数据仓库的数据同步的方法和装置
CN107634849A (zh) 一种全局区块链环境构建方法
CN110196843A (zh) 一种基于容器集群的文件分发方法及容器集群
AU2015404396B2 (en) Federated marketplace portal
CN110377399A (zh) HBase容器化方法、装置、设备及可读存储介质
CN112804313B (zh) 基于跨域边缘节点的数据同步方法、装置、设备及介质
CN112583740B (zh) 网络通信方法及装置
CN110809047B (zh) 一种外网单域名连接内网kafka集群的实现方法及系统

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant