CN112860427A - 容器集群的负载均衡方法、装置与容器集群 - Google Patents

容器集群的负载均衡方法、装置与容器集群 Download PDF

Info

Publication number
CN112860427A
CN112860427A CN201911197642.4A CN201911197642A CN112860427A CN 112860427 A CN112860427 A CN 112860427A CN 201911197642 A CN201911197642 A CN 201911197642A CN 112860427 A CN112860427 A CN 112860427A
Authority
CN
China
Prior art keywords
node
container cluster
master node
target
connection
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.)
Pending
Application number
CN201911197642.4A
Other languages
English (en)
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.)
Beijing Kingsoft Cloud Network Technology Co Ltd
Beijing Kingsoft Cloud Technology Co Ltd
Original Assignee
Beijing Kingsoft Cloud Network Technology Co Ltd
Beijing Kingsoft Cloud Technology 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 Beijing Kingsoft Cloud Network Technology Co Ltd, Beijing Kingsoft Cloud Technology Co Ltd filed Critical Beijing Kingsoft Cloud Network Technology Co Ltd
Priority to CN201911197642.4A priority Critical patent/CN112860427A/zh
Publication of CN112860427A publication Critical patent/CN112860427A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083Techniques for rebalancing the load in a distributed system
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects

Abstract

本发明提供了一种容器集群的负载均衡方法、装置与容器集群,该方法包括获取与上述node节点连接的目标master节点之间的通信状态;该通信状态包括:从目标master节点接收到的预设的指定信号的数量,或者该目标master节点与node节点之间的持续连接时长;如果该通信状态满足预设条件,从上述容器集群重新选择master节点并建立连接。本发明通过限制容器集群中单个master节点可连接node节点的节点数量,或者,通过node节点定期主动断开与master节点的连接,并重新与集群中的master节点建立连接,可以维持容器集群中各master节点上的请求负载处于均衡状态,提高容器集群的服务性能。

Description

容器集群的负载均衡方法、装置与容器集群
技术领域
本发明涉及网络技术领域,尤其是涉及一种容器集群的负载均衡方法、装置与容器集群。
背景技术
在为集群升级kube-apiserver版本时,集群中的多个kube-apiserver服务会进行滚动升级,多个kube-apiserver服务逐个升级版本,并在升级后重启。当kube-apiserver进行版本升级时,会主动断开与其建立长连接的kubelet,被断开连接的kubelet与集群中的其他kube-apiserver重新建立长连接,以保证节点状态上报正常。
这样,在容器集群版本升级过程中,会造成集群内大部分节点上的kubelet都会与最晚升级的kube-apiserver建立长连接,而较早进行重启的kube-apiserver服务,只有少量或者没有节点的kubelet与其重新建立连接;而在集群版本升级完成之后,集群内大部分节点上的kubelet都会与较早升级的kube-apiserver建立长连接,而最晚重启的kube-apiserver服务没有节点的kubelet与其建立连接。最终,造成整个集群层面的kube-apiserver负载不均衡,从而降低整个集群对外提供服务的能力。
发明内容
有鉴于此,本发明的目的在于提供一种容器集群的负载均衡方法、装置与容器集群,可以维持容器集群中各master节点上的请求负载处于均衡状态,并提高容器集群的服务性能。
第一方面,本发明实施例提供了一种容器集群的负载均衡方法,应用于容器集群的node节点,该node节点与容器集群中的至少一个master节点连接,该方法包括:获取与上述node节点连接的目标master节点之间的通信状态;该通信状态包括:从目标master节点接收到的预设的指定信号的数量,或者该目标master节点与node节点之间的持续连接时长;如果该通信状态满足预设条件,从上述容器集群重新选择master节点并建立连接。
在本发明较佳的实施例中,上述如果该通信状态满足预设条件,从上述容器集群重新选择master节点并建立连接的步骤,包括:如果该通信状态为从目标master节点接收到的预设的指定信号的数量,判断在预设时间段内,从该目标master节点接收到的指定信号的数量,是否达到预设的信号数量阈值;如果是,从该容器集群重新选择master节点并建立连接。
在本发明较佳的实施例中,上述从容器集群重新选择master节点并建立连接的步骤,包括:断开与目标master节点的连接;从该容器集群除目标master节点之外的master节点中,确定一个master节点;与确定的该master节点建立连接。
在本发明较佳的实施例中,上述如果通信状态满足预设条件,从该容器集群重新选择master节点并建立连接的步骤,包括:如果该通信状态为目标master节点与该node节点之间的持续连接时长,判断该持续连接时长是否达到预设的时长阈值;如果是,从该容器集群重新选择master节点并建立连接。
在本发明较佳的实施例中,上述从该容器集群重新选择master节点并建立连接的步骤,包括:断开与该目标master节点的连接;通过轮询的方式,按预设顺序从该容器集群的master节点中确定一个master节点;与确定的master节点建立连接。
在本发明较佳的实施例中,在node节点设置有定时任务,该定时任务按预设的任务周期启动;上述获取与该node节点连接的目标master节点之间的通信状态的步骤,包括:当定时任务启动时,获取与该node节点连接的目标master节点之间的通信状态。
在本发明较佳的实施例中,上述node节点上运行有kubelet服务;上述目标master节点上运行有kube-apiserver服务;上述获取与node节点连接的目标master节点之间的通信状态的步骤,包括:通过该node节点上运行的kubelet服务,获取与该kubelet服务连接的目标master节点上的kube-apiserver服务之间的通信状态。
第二方面,本发明实施例还提供了一种容器集群的负载均衡方法,该方法应用于容器集群的master节点,该方法包括:获取与该master节点连接的目标node节点的节点数量;如果该节点数量满足预设的节点数量阈值,从该目标node节点中确定待断开node节点,向待断开node节点发送预设的指定信号,以使该待断开node节点在预设时间段内,从该master节点接收到的指定信号的数量达到预设的信号数量阈值时,从该容器集群重新选择master节点并建立连接。
在本发明较佳的实施例中,上述从目标node节点中确定待断开node节点的步骤,包括:根据该节点数量阈值和该目标node节点的节点数量,确定待断开node节点的数目;根据该目标node节点的创建时间或者该目标node节点发送的服务请求数量,从该目标node节点中确定待断开node节点的数目对应的待断开的node节点。
第三方面,本发明实施例还提供了一种容器集群的负载均衡装置,应用于容器集群的node节点,该node节点与上述容器集群中的至少一个master节点连接,该装置包括:通信状态获取模块,用于获取与该node节点连接的目标master节点之间的通信状态;该通信状态包括:从该目标master节点接收到的预设的指定信号的数量,或者该目标master节点与该node节点之间的持续连接时长;重建连接模块,用于如果该通信状态满足预设条件,从该容器集群重新选择master节点并建立连接。
第四方面,本发明实施例还提供了一种容器集群的负载均衡装置,应用于容器集群的master节点,该装置包括:节点数量获取模块,用于获取与该master节点连接的目标node节点的节点数量;指定信号发送模块,用于如果该节点数量满足预设的节点数量阈值,从该目标node节点中确定待断开node节点,向该待断开node节点发送预设的指定信号,以使该待断开node节点在预设时间段内,从该master节点接收到的指定信号的数量达到预设的信号数量阈值时,从该容器集群重新选择master节点并建立连接。
第五方面,本发明实施例还提供了一种容器集群,包括处理器和存储器,该存储器存储有能够被该处理器执行的机器可执行指令,该处理器执行该机器可执行指令,以实现上述第一方面及其较佳的实施例之一提供的容器集群集群的负载均衡方法。
本发明实施例带来了以下有益效果:
本发明实施例提供的一种容器集群的负载均衡方法、装置与容器集群,获取与上述node节点连接的目标master节点之间的通信状态;该通信状态包括:从目标master节点接收到的预设的指定信号的数量,或者该目标master节点与node节点之间的持续连接时长;如果该通信状态满足预设条件,从上述容器集群重新选择master节点并建立连接。该方式中,容器集群中的node节点通过从目标master节点接收指定信号触发主动断开连接,或者,通过与目标master节点的持续连接时长触发主动断开连接,然后再与容器集群中的master节点重新建立连接,可以维持容器集群中各master节点上的请求负载处于均衡状态,从而提高容器集群的服务性能。
本公开的其他特征和优点将在随后的说明书中阐述,或者,部分特征和优点可以从说明书推知或毫无疑义地确定,或者通过实施本公开的上述技术即可得知。
为使本公开的上述目的、特征和优点能更明显易懂,下文特举较佳实施例,并配合所附附图,作详细说明如下。
附图说明
为了更清楚地说明本发明具体实施方式或现有技术中的技术方案,下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图是本发明的一些实施方式,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明实施例提供的一种容器集群升级过程中的负载分配示意图;
图2为本发明实施例提供的一种容器集群的负载均衡方法的流程示意图;
图3为本发明实施例提供的另一种容器集群的负载均衡方法的流程示意图;
图4为本发明实施例提供的另一种容器集群的负载均衡方法的流程示意图;
图5为本发明实施例提供的另一种容器集群的负载均衡方法的流程示意图;
图6为本发明实施例提供的一种采用本发明负载均衡方法进行集群升级的效果示意图;
图7为本发明实施例提供的一种容器集群的负载均衡装置的结构示意图;
图8为本发明实施例提供的另一种容器集群的负载均衡装置的结构示意图;
图9为本发明实施例提供的一种容器集群的结构示意图。
图标:71-通信状态获取模块;72-重建连接模块;81-节点数量获取模块;82-指定信号发送模块;91-处理器;92-存储器;93-总线;94-通信接口。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合附图对本发明的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
Kubernetes(k8s)是Google开源的容器集群管理系统,k8s在Docker技术的基础上,为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能,提高了大规模容器集群管理的便捷性。一个k8s集群是由分布式存储(etcd)、服务节点(node)和控制节点(master)构成的。其中,所有的集群状态都保存在etcd中,master节点上则运行集群的管理控制模块。node节点是真正运行应用容器的主机节点,在每个node节点上都会运行一个kubelet代理,控制该节点上的容器、镜像和存储卷等。
在k8s中,master节点上通常运行有api server进程,controller manager服务进程及scheduler服务进程,并且还关联工作节点node。而node节点是k8s集群操作的单元,用来承载被分配pod的运行,是pod运行的宿主机。这里,pod是若干相关容器的组合,它也是k8s进行创建、调度和管理的最小单位,它提供了比容器更高层次的抽象,使得部署和管理更加灵活。通常,一个pod可以包含一个容器或者多个相关容器。
参见图1,其为本发明实施例提供的容器集群升级过程中的负载分配示意图,在图1示出的实施方式中,该容器集群中包含3个master节点,以及5个node节点,且在各个master节点上运行有相应的api server进程。当需要对该容器集群上的api server版本进行升级时,该集群中的多个api server服务通常会进行滚动升级,也即,多个api server服务逐个升级版本并重启。由图1可见,master1节点、master2节点和master3节点依次升级并重启,图1中step1、step2和step3分别对应master1节点升级重启后、master2节点升级重启后和master3节点升级重启后的负载分配状态,反映出各个node节点与master节点的连接状况。这里,可以看到,在对各个master节点上的api server进行升级的过程中,以及所有的master节点升级重启结束后,整个集群层面的apiserver负载都不均衡,这也导致整个集群对外提供服务的能力被降低。
基于此,本发明实施例提供一种容器集群的负载均衡方法、装置与容器集群,该技术可以应用于master节点和node节点进行通信连接的各种场景中。为便于对本实施例进行理解,首先对本发明实施例所公开的一种容器集群的负载均衡方法进行详细介绍。
图2所示为一种容器集群的负载均衡方法的流程示意图,其中,该方法应用于容器集群的node节点,且该node节点与容器集群中的至少一个master节点连接,由图2可见,该方法包括以下步骤:
步骤S202:获取与node节点连接的目标master节点之间的通信状态;该通信状态包括:从目标master节点接收到的预设的指定信号的数量,或者该目标master节点与node节点之间的持续连接时长。
这里,集群是一组协同工作的服务实体,用以提供比单一服务实体更具扩展性与可用性的服务平台。在客户端看来,一个集群就像是一个服务实体,而实际上它是由一组服务实体组成。其中,容器集群用于运行Docker应用,在创建Docker应用前,需要先创建容器集群,并且,容器集群是私有集群,对其他用户不可见,从而可以保证其上的容器应用与其他用户的应用之间更安全的隔离。
通常,一个容器集群上有多个master节点以及多个node节点,在本实施例中,node节点与容器集群中的至少一个master节点连接,对于单个的node节点,首先,获取该node节点连接的目标master节点之间的通信状态。其中,目标master节点为与该node节点有长连接的master节点,这里,长连接是指在一个连接上可以连续发送多个数据包,并且在连接保持期间,如果没有数据包发送,需要双方发链路检测包。
对于上述通信状态,其可以是从目标master节点接收到的预设的指定信号的数量,这里,目标master节点不但与该node节点通信连接,而且还在某些特定的情况下向该node节点发送指定信号,例如,当该目标master节点上的node节点连接数过多时,可以向连接较晚的node节点发送指定信号。其中,该指定信号可以是http协议中的返回码,例如“409”、“407”等等,这些返回码用于向node节点返回请求可能出错的信息。在实际操作中,可以在node节点对接收到的上述指定信号进行计数,从而得到接收到的该指定信号的数量。
例如,假设预设的指定信号为“409”返回码,在目标master节点与node节点的通信过程中,目标master节点会向node节点发送“409”返回码。假如node节点接收到从目标master节点发送的5个“409”返回码,则指定信号的数量计数为5。如果期间还接收到其他返回码,例如“502”等,因其并不是预设的指定信号,不对其进行计数。
另外,上述通信状态还可以是该目标master节点与node节点之间的持续连接时长,这里,该持续连接时长表示目标master节点与node节点之间保持通信连接且未中断的时间,例如,假设目标master节点与node节点建立通信连接的时间为11:00am,该node节点在11:08am获取持续连接时长,假设在11:08am之前,它们之间持续通信,则该持续连接时长为8分钟;假设目标master节点与node节点之间的通信连接在期间断开,并于11:04am重新建立连接,则该node节点在11:08am获取的持续连接时长为4分钟。
步骤S204:如果该通信状态满足预设条件,从上述容器集群重新选择master节点并建立连接。
在本实施例中,如果从目标master节点接收到的预设的指定信号的数量满足预设条件,则从上述容器集群重新选择master节点并建立连接。例如,假设预设条件为:接收到“409”返回码的数量达到3条,那么,当该node节点对接收到“409”返回码进行计数达到3条时,断开与上述目标master节点的通信连接,并从该容器集群中重新选择master节点,并与重新选择的master节点建立连接。并且,当该node节点对接收到“409”返回码进行计数未达到3条时,仍然保持与目标master节点的通信连接。
在实际操作中,可以设置相应地触发条件,使得目标master节点在满足该触发条件时,向对应的node节点发送指定信号。例如,可以设置触发条件为:当master节点上连接的node节点数量超出预设节点连接数时,向连接较晚的node节点发送指定信号。这里,假设master节点预设的节点连接数为3个,则当目标master节点的节点连接数为4个时,向通信连接的这4个node节点中建立连接较晚的node节点发送预设的指定信号,并且,持续向该node节点发送指定信号,直到该node节点接收到的指定信号数量达到预设值,并断开与目标master节点连接,从而使得该目标master节点的节点连接数动态保持在预设的节点连接数范围内。
另外,如果该目标master节点与node节点之间的持续连接时长满足预设条件,该node节点也从上述容器集群重新选择master节点并建立连接。例如,假设预设条件为:目标master节点与node节点之间的持续连接时长达到10分钟,那么,当该node节点对其与目标master节点的通信时间进行计时,且持续时间达到10分钟时,断开与上述目标master节点的通信连接,从该容器集群中重新选择master节点,并且与重新选择的master节点建立连接。
这样,本实施例提供的容器集群的负载均衡方法,node节点在接收目标master节点发送的指定信号达到预设数量阈值时,主动断开与目标master节点的通信连接,或者,node节点在与目标master节点的持续连接时长达到预设时长阈值时,主动断开与目标master节点的通信连接,并且该node节点在与目标master节点断开连接后,重新与容器集群中的master节点建立连接,使得容器集群中每个master节点上的node节点连接数处于动态调整中,从而实现该容器集群中多个master节点之间的工作负载动态平衡。
本发明实施例提供的一种容器集群的负载均衡方法,获取与上述node节点连接的目标master节点之间的通信状态;该通信状态包括:从目标master节点接收到的预设的指定信号的数量,或者该目标master节点与node节点之间的持续连接时长;如果该通信状态满足预设条件,从上述容器集群重新选择master节点并建立连接。该方式中,容器集群中的node节点,通过从目标master节点接收指定信号触发主动断开连接,或者,通过与目标master节点的持续连接时长触发主动断开连接,然后再与容器集群中的master节点重新建立连接,可以维持容器集群中各master节点上的请求负载处于均衡状态,从而提高容器集群的服务性能。
在图2所示容器集群的负载均衡方法的基础上,本实施例提供了另一种容器集群的负载均衡方法,该方法重点描述了从上述容器集群重新选择master节点并建立连接的具体实现过程,如图3所示,其为该方法的流程示意图,由图3可见,该方法包括以下步骤:
步骤S302:获取与node节点连接的目标master节点之间的通信状态;该通信状态为从目标master节点接收到的预设的指定信号的数量。
在本实施例中,node节点首先获取与其连接的目标master节点之间的通信状态,也即:该node节点从目标master节点接收到的预设的指定信号的数量。
步骤S304:判断在预设时间段内,从该目标master节点接收到的指定信号的数量,是否达到预设的信号数量阈值;如果是,执行步骤S306;如果否,返回执行步骤S302。
这里,如果在预设时间段内从该目标master节点接收到的指定信号的数量,达到预设的信号数量阈值,则从该容器集群重新选择master节点,并与选择的master节点建立连接;如果在预设时间段内从该目标master节点接收到的指定信号的数量,没有达到预设的信号数量阈值,则继续执行获取与node节点连接的目标master节点之间的通信状态的步骤。
例如,假设指定的信号为http协议中的返回码“407”,预设的信号数量阈值为2条,且预设的时间段为20秒,那么,如果node节点在接收到第一条“407”信号的20秒内,再次从目标master节点接收到“407”信号,则断开与目标master节点的连接,并从该容器集群重新选择master节点再建立连接。否则,node节点仍与目标master节点保持通信连接,并继续获取其与目标master节点之间的通信状态。
步骤S306:从该容器集群重新选择master节点并建立连接。
在本实施例中,按以下步骤(11)-(13)从该容器集群重新选择master节点并建立连接:
(11)断开该node节点与目标master节点的连接。
(12)从该容器集群除目标master节点之外的master节点中,确定一个master节点。
(13)与确定的该master节点建立连接。
这样,当node节点与目标master节点保持通信连接时,持续获取其从目标master节点接收到的预设的指定信号的数量,并且,当接收到的指定信号的数量达到预设的信号数量阈值时,断开与该目标master节点的连接,并从该容器集群重新选择master节点再建立连接。
通过上述方式,目标master节点可以主动向node节点发送指定信号,以使该node节点断开连接,从而减少目标master节点上连接的node节点的数量。在实际操作中,可以通过设定master节点上可连接的node节点的数量上限,并且,当master节点上连接的node节点的数量超过上限时,可以向超出的node节点主动发出指定信号,以使这些node节点断开连接,从而维持该master节点上的node节点的数量在设定的范围内,进而使该容器集群中各个master节点上的负载处于均衡状态。
本实施例提供的容器集群的负载均衡方法,容器集群中的node节点通过从目标master节点接收指定信号触发主动断开连接,然后再与容器集群中的master节点重新建立连接,可以维持容器集群中各master节点上的请求负载处于均衡状态,从而提高容器集群的服务性能。
另外,在图2所示容器集群的负载均衡方法的基础上,本实施例还提供了另一种容器集群的负载均衡方法,该方法描述了从上述容器集群重新选择master节点并建立连接的另一种实现过程,如图4所示,其为该方法的流程示意图,由图4可见,该方法包括以下步骤:
步骤S402:获取与node节点连接的目标master节点之间的通信状态;该通信状态为目标master节点与该node节点之间的持续连接时长。
在本实施例中,node节点首先获取其与目标master节点之间的持续连接时长。在其中一种可能的实施方式中,可以在node节点设置定时任务,该定时任务按预设的任务周期启动,并且,当该定时任务启动时,获取与该node节点连接的目标master节点之间的持续连接时长。
例如,假设node节点上定时任务的任务周期为10分钟,则该定时任务每10分钟启动一次,因而,每隔10分钟,node节点获取其与目标master节点之间的持续连接时长。
步骤S404:判断该持续连接时长是否达到预设的时长阈值;如果是,执行步骤S406;如果否,返回执行步骤S402。
这里,如果该持续连接时长达到预设的时长阈值,则从该容器集群重新选择master节点并建立连接;如果该持续连接时长没有达到预设的时长阈值,则继续执行获取与node节点连接的目标master节点之间的通信状态的步骤。
步骤S406:从该容器集群重新选择master节点并建立连接。
在本实施例中,按以下步骤(21)-(23)从该容器集群重新选择master节点并建立连接:
(21)断开与该目标master节点的连接。
(22)通过轮询的方式,按预设顺序从该容器集群的master节点中确定一个master节点。这里,假设容器集群中有3个master节点,分别为A、B和C,且预先设置轮询的顺序为:C→B→A→C,那么,当任一个node节点断开与目标master节点之间的连接后,按预设的顺序C→B→A→C询问集群中的各个master节点,以确定出一个与该node节点重新建立连接的master节点。
(23)与确定的master节点建立连接。
这样,当node节点与目标master节点保持通信连接时,持续获取其与目标master节点之间的持续连接时长,并且,当该持续连接时长达到预设的时长阈值时,断开与该目标master节点的连接,并从该容器集群重新选择master节点再建立连接。
通过上述方式,node节点与master节点之间的连接始终处于动态调整中,从而避免某些master节点上的node节点数量长期处于较多或较少的状态,从而使该容器集群中各个master节点上的负载整体上处于均衡状态。
本实施例提供的容器集群的负载均衡方法,容器集群中的node节点通过与目标master节点的持续连接时长触发主动断开连接,然后再与容器集群中的master节点重新建立连接,同样可以维持容器集群中各master节点上的请求负载处于均衡状态,从而提高容器集群的服务性能。
此外,本实施例还提供了另一种容器集群的负载均衡方法,该方法应用于容器集群的master节点,参见图5,其为该容器集群的负载均衡方法的流程示意图,由图5可见,该方法包括以下步骤:
步骤S502:获取与该master节点连接的目标node节点的节点数量。
在实际操作中,容器集群中的master节点通常连接有多个node节点,这里,与master节点通信连接的node节点均为目标node节点。在本实施例中,首先获取与该master节点连接的目标node节点的节点数量。
步骤S504:如果该节点数量满足预设的节点数量阈值,从该目标node节点中确定待断开node节点,向待断开node节点发送预设的指定信号,以使该待断开node节点在预设时间段内,从该master节点接收到的指定信号的数量达到预设的信号数量阈值时,从该容器集群重新选择master节点并建立连接。
这里,节点数量阈值是指单个master节点上可以连接的node节点的数量上限。
在获取与该master节点连接的目标node节点的节点数量之后,判断该节点数量是否满足预设的节点数量阈值,如果是,则从该目标node节点中确定待断开node节点,并且向待断开node节点发送预设的指定信号,当待断开的node节点在预设时间段内接收到的指定信号的数量达到预设的信号数量阈值时,从该容器集群重新选择master节点并建立连接;如果否,则继续获取与该master节点连接的目标node节点的节点数量。
在其中一种可能的实施方式中,按以下步骤(31)-(33)从目标node节点中确定待断开node节点:
(31)根据该节点数量阈值和该目标node节点的节点数量,确定待断开node节点的数目。
例如,假设容器集群M中,预先设置每个master节点的节点数量阈值为5个,而当前与该master节点通信连接的目标node节点的节点数量为7个,则通过计算二者差值得到待断开node节点的数目为2个。
(32)根据该目标node节点的创建时间或者该目标node节点发送的服务请求数量,从该目标node节点中确定待断开node节点的数目对应的待断开的node节点。
这里,可以根据该目标node节点的创建时间,从该目标node节点中确定待断开的node节点。例如,可以将与master节点连接的各个node节点的创建时间进行排序,并将创建时间较晚的node节点确定为待断开的node节点。
仍以上述容器集群M为例说明,假设与该master节点连接的7个node节点的创建时间分别为:10:10am、9:30am、10:15am、10:00am、11:20am、11:22am和08:40am;则可以根据它们的创建时间进行排序,排序后为:08:40am、9:30am、10:00am、10:10am、10:15am、11:20am和11:22am,这样,由于已经计算出需要断开的node节点的数量为2个,因而可以将创建时间较晚的11:20am和11:22am对应的node节点确定为待断开node节点。
另外,还可以根据该目标node节点发送的服务请求数量,从该目标node节点中确定待断开的node节点。例如,可以将各个目标node节点向master发送的服务请求的数量进行排序,将服务请求的数量较少的node节点确定为待断开的node节点。
仍以上述容器集群M为例说明,假设7个目标node节点向master发送的服务请求的数量分别为:12、8、15、7、6、9和14,则根据它们的数值大小由大到小进行排序,排序后为:15、14、12、9、8、7和6,这样,因为需要断开的node节点的数量为2个,因而可以将服务请求数量较少的7和6对应的node节点确定为待断开node节点。
本发明实施例提供的容器集群的负载均衡方法,通过限制容器集群中单个master节点可连接node节点的节点数量,在可连接的node节点的数量超过预设节点数量阈值时,master节点主动向待断开的node节点发送指定信号,以使待断开的node节点断开连接,从而维持master节点上的node节点数目在合理的范围内,进而实现master节点上的请求负载处于均衡状态,提高容器集群的服务性能。
为了更清楚理解上述实施例中的容器集群的负载均衡方法,本实施例还介绍了一个容器集群负载均衡的应用实例。在本实施例中,容器集群上的每个node节点上运行有kubelet服务,并且,每个master节点上运行有kube-apiserver服务。
其中,kube-apiserver是Kubernetes API服务器,它为API对象验证和配置数据,这些对象包括pod、service和replication controller等等。API服务器服务REST操作,并提供集群共享状态的前端,所有其他组件都可以通过此共享状态进行交互。
另外,kubelet是在每个节点上运行的主要“节点代理”,它可以使用主机名、覆盖主机名的标志或者云提供商的特定逻辑向apiserver注册节点。kubelet根据PodSpec工作,其中,PodSpec是描述pod的YAML或JSON对象。kubelet接受一组通过各种机制(主要是通过apiserver)提供的podspec,并确保这些podspec中描述的容器运行正常,并且,kubelet不管理不是由Kubernetes创建的容器。
在实际操作中,在kubelet服务启动后,其与kube-apiserver建立长连接,并通过kube-apiserver将所在node节点的状态上报到etcd存储服务中。kubelet作为客户端不会主动断开连接,除非作为服务端的kube-apiserver主动断开连接。
在本实施例中,为kube-apiserver增加了启动参数,其中,该启动参数为最大连接数。这样,当kube-apiserver服务启动时,如果与其连接的kubelet服务的数量超过该参数指定的值,就主动向超出部分的kubelet服务发送指定信号。这里,该最大连接数为2,也即,每个kube-apiserver服务允许连接2个kubelet服务。
另外,在kubelet启动服务时,还以协程的方式启动一个定时任务,该定时任务只有在kubelet主进程退出时才退出。该定时任务在每个任务周期判断kubelet服务与kube-apiserver建立的长连接的状态,如果kubelet服务连续收到多个由kube-apiserver发送过来的指定信号,则断开当前连接,并选择其他kube-apiserver重新建立连接,从而使集群的多个kube-apiserver之间的工作负载达到动态平衡。
参见图6,其为采用本发明负载均衡方法进行集群升级的效果示意图,其中,由于设定了每个kube-apiserver服务的最大连接数为2,这样,当任一个master节点上的node节点数量超过2时,master节点会向超出的node节点发送指定信号,以使其断开连接,并且断开的node节点,将在集群中的其他master节点中确定新的目标master节点,以重新建立连接。由图6可见,通过本发明的负载均衡方法,该容器集群中各个master节点的负载重新回到均衡状态。
对应于上述实施例中的容器集群的负载均衡方法,本实施例还提供了一种容器集群的负载均衡装置,该装置应用于容器集群的node节点,且该node节点与上述容器集群中的至少一个master节点连接,如图7所示,其为该装置的结构示意图,由图7可见,该装置包括彼此相连的通信状态获取模块71和重建连接模块72,其中,各个模块的功能如下:
通信状态获取模块71,用于获取与该node节点连接的目标master节点之间的通信状态;该通信状态包括:从该目标master节点接收到的预设的指定信号的数量,或者该目标master节点与该node节点之间的持续连接时长;
重建连接模块72,用于如果该通信状态满足预设条件,从该容器集群重新选择master节点并建立连接。
本发明实施例提供的一种容器集群的负载均衡装置,获取与上述node节点连接的目标master节点之间的通信状态;该通信状态包括:从目标master节点接收到的预设的指定信号的数量,或者该目标master节点与node节点之间的持续连接时长;如果该通信状态满足预设条件,从上述容器集群重新选择master节点并建立连接。该装置通过限制容器集群中单个master节点可连接node节点的节点数量,或者,通过控制node节点定期主动断开与master节点的连接,并重新建立连接,可以维持容器集群中各master节点上的请求负载处于均衡状态,从而提高容器集群的服务性能。
在其中一种可能的实施方式中,上述重建连接模块72还用于:如果该通信状态为从目标master节点接收到的预设的指定信号的数量,判断在预设时间段内,从该目标master节点接收到的指定信号的数量,是否达到预设的信号数量阈值;如果是,从该容器集群重新选择master节点并建立连接。
在另一种可能的实施方式中,上述重建连接模块72还用于:断开与目标master节点的连接;从该容器集群除目标master节点之外的master节点中,确定一个master节点;与确定的该master节点建立连接。
在另一种可能的实施方式中,上述重建连接模块72还用于:如果该通信状态为目标master节点与该node节点之间的持续连接时长,判断该持续连接时长是否达到预设的时长阈值;如果是,从该容器集群重新选择master节点并建立连接。
在另一种可能的实施方式中,上述重建连接模块72还用于:断开与该目标master节点的连接;通过轮询的方式,按预设顺序从该容器集群的master节点中确定一个master节点;与确定的master节点建立连接。
在另一种可能的实施方式中,在node节点设置有定时任务,该定时任务按预设的任务周期启动,且上述通信状态获取模块71还用于:当定时任务启动时,获取与该node节点连接的目标master节点之间的通信状态。
在另一种可能的实施方式中,上述node节点上运行有kubelet服务,上述目标master节点上运行有kube-apiserver服务,且上述通信状态获取模块71还用于:通过该node节点上运行的kubelet服务,获取与该kubelet服务连接的目标master节点上的kube-apiserver服务之间的通信状态。
本发明实施例提供的容器集群的负载均衡装置,其实现原理及产生的技术效果和前述容器集群的负载均衡方法实施例相同,为简要描述,容器集群的负载均衡装置的实施例部分未提及之处,可参考前述容器集群的负载均衡方法实施例中相应内容。
另外,本实施例还提供了另一种容器集群的负载均衡装置,该装置应用于容器集群的master节点,如图8所示,其为该装置的结构示意图,其中,该装置包括彼此相连的节点数量获取模块81和指定信号发送模块82。
并且,各个模块的功能如下:
节点数量获取模块81,用于获取与该master节点连接的目标node节点的节点数量;
指定信号发送模块82,用于如果该节点数量满足预设的节点数量阈值,从该目标node节点中确定待断开node节点,向该待断开node节点发送预设的指定信号,以使该待断开node节点在预设时间段内,从该master节点接收到的指定信号的数量达到预设的信号数量阈值时,从该容器集群重新选择master节点并建立连接。
在其中一种可能的实施方式中,上述指定信号发送模块82还用于:根据该节点数量阈值和该目标node节点的节点数量,确定待断开node节点的数目;根据该目标node节点的创建时间或者该目标node节点发送的服务请求数量,从该目标node节点中确定待断开node节点的数目对应的待断开的node节点。
本实施例提供的容器集群的负载均衡装置,与前述实施例提供的容器集群的负载均衡方法具有相同的技术特征,所以也能解决相同的技术问题,达到相同的技术效果。
本发明实施例还提供了一种容器集群,如图9所示,为该容器集群的结构示意图,其中,该容器集群包括处理器91和存储器92,该存储器92存储有能够被该处理器91执行的机器可执行指令,该处理器91执行该机器可执行指令以实现上述容器集群的负载均衡方法。
在图9示出的实施方式中,该容器集群还包括总线93和通信接口94,其中,处理器91、通信接口94和存储器92通过总线连接。
其中,存储器92可能包含高速随机存取存储器(RAM,Random Access Memory),也可能还包括非不稳定的存储器(non-volatile memory),例如至少一个磁盘存储器。通过至少一个通信接口94(可以是有线或者无线)实现该系统网元与至少一个其他网元之间的通信连接,可以使用互联网,广域网,本地网,城域网等。总线可以是ISA总线、PCI总线或EISA总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示,图9中仅用一个双向箭头表示,但并不表示仅有一根总线或一种类型的总线。
处理器91可能是一种集成电路芯片,具有信号的处理能力。在实现过程中,上述方法的各步骤可以通过处理器91中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器91可以是通用处理器,包括中央处理器(Central Processing Unit,简称CPU)、网络处理器(Network Processor,简称NP)等;还可以是数字信号处理器(Digital SignalProcessing,简称DSP)、专用集成电路(Application Specific Integrated Circuit,简称ASIC)、现成可编程门阵列(Field-Programmable Gate Array,简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成,或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器,处理器91读取存储器92中的信息,结合其硬件完成前述实施例的容器集群的负载均衡方法的步骤。
本发明实施例还提供了一种机器可读存储介质,该机器可读存储介质存储有机器可执行指令,该机器可执行指令在被处理器调用和执行时,该机器可执行指令促使处理器实现上述容器集群的负载均衡方法,具体实现可参见前述方法实施例,在此不再赘述。
本发明实施例所提供的容器集群的负载均衡方法、容器集群的负载均衡装置与容器集群的计算机程序产品,包括存储了程序代码的计算机可读存储介质,所述程序代码包括的指令可用于执行前面方法实施例中所述的容器集群的负载均衡方法,具体实现可参见方法实施例,在此不再赘述。
除非另外具体说明,否则在这些实施例中阐述的部件和步骤的相对步骤、数字表达式和数值并不限制本发明的范围。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是:以上所述实施例,仅为本发明的具体实施方式,用以说明本发明的技术方案,而非对其限制,本发明的保护范围并不局限于此,尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化,或者对其中部分技术特征进行等同替换;而这些修改、变化或者替换,并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应以所述权利要求的保护范围为准。

Claims (12)

1.一种容器集群的负载均衡方法,其特征在于,应用于容器集群的node节点,所述node节点与所述容器集群中的至少一个master节点连接,所述方法包括:
获取与所述node节点连接的目标master节点之间的通信状态;所述通信状态包括:从所述目标master节点接收到的预设的指定信号的数量,或者所述目标master节点与所述node节点之间的持续连接时长;
如果所述通信状态满足预设条件,从所述容器集群重新选择master节点并建立连接。
2.根据权利要求1所述的容器集群的负载均衡方法,其特征在于,如果所述通信状态满足预设条件,从所述容器集群重新选择master节点并建立连接的步骤,包括:
如果所述通信状态为从所述目标master节点接收到的预设的指定信号的数量,判断在预设时间段内,从所述目标master节点接收到的所述指定信号的数量,是否达到预设的信号数量阈值;
如果是,从所述容器集群重新选择master节点并建立连接。
3.根据权利要求2所述的容器集群的负载均衡方法,其特征在于,所述从所述容器集群重新选择master节点并建立连接的步骤,包括:
断开与所述目标master节点的连接;
从所述容器集群除所述目标master节点之外的master节点中,确定一个master节点;
与确定的所述master节点建立连接。
4.根据权利要求1所述的容器集群的负载均衡方法,其特征在于,如果所述通信状态满足预设条件,从所述容器集群重新选择master节点并建立连接的步骤,包括:
如果所述通信状态为所述目标master节点与所述node节点之间的持续连接时长,判断所述持续连接时长是否达到预设的时长阈值;
如果是,从所述容器集群重新选择master节点并建立连接。
5.根据权利要求4所述的容器集群的负载均衡方法,其特征在于,所述从所述容器集群重新选择master节点并建立连接的步骤,包括:
断开与所述目标master节点的连接;
通过轮询的方式,按预设顺序从所述容器集群的master节点中确定一个master节点;
与确定的所述master节点建立连接。
6.根据权利要求1所述的容器集群的负载均衡方法,其特征在于,在所述node节点设置有定时任务,所述定时任务按预设的任务周期启动;
所述获取与所述node节点连接的目标master节点之间的通信状态的步骤,包括:
当所述定时任务启动时,获取与所述node节点连接的目标master节点之间的通信状态。
7.根据权利要求1-6任一项所述的容器集群的负载均衡方法,所述node节点上运行有kubelet服务;所述目标master节点上运行有kube-apiserver服务;
所述获取与所述node节点连接的目标master节点之间的通信状态的步骤,包括:通过所述node节点上运行的kubelet服务,获取与所述kubelet服务连接的所述目标master节点上的kube-apiserver服务之间的通信状态。
8.一种容器集群的负载均衡方法,其特征在于,所述方法应用于容器集群的master节点,所述方法包括:
获取与所述master节点连接的目标node节点的节点数量;
如果所述节点数量满足预设的节点数量阈值,从所述目标node节点中确定待断开node节点,向所述待断开node节点发送预设的指定信号,以使所述待断开node节点在预设时间段内,从所述master节点接收到的所述指定信号的数量达到预设的信号数量阈值时,从所述容器集群重新选择master节点并建立连接。
9.根据权利要求8所述的容器集群的负载均衡方法,其特征在于,从所述目标node节点中确定待断开node节点的步骤,包括:
根据所述节点数量阈值和所述目标node节点的节点数量,确定所述待断开node节点的数目;
根据所述目标node节点的创建时间或者所述目标node节点发送的服务请求数量,从所述目标node节点中确定所述待断开node节点的数目对应的待断开的node节点。
10.一种容器集群的负载均衡装置,其特征在于,应用于容器集群的node节点,所述node节点与所述容器集群中的至少一个master节点连接,所述装置包括:
通信状态获取模块,用于获取与所述node节点连接的目标master节点之间的通信状态;所述通信状态包括:从所述目标master节点接收到的预设的指定信号的数量,或者所述目标master节点与所述node节点之间的持续连接时长;
重建连接模块,用于如果所述通信状态满足预设条件,从所述容器集群重新选择master节点并建立连接。
11.一种容器集群的负载均衡装置,其特征在于,应用于容器集群的master节点,所述装置包括:
节点数量获取模块,用于获取与所述master节点连接的目标node节点的节点数量;
指定信号发送模块,用于如果所述节点数量满足预设的节点数量阈值,从所述目标node节点中确定待断开node节点,向所述待断开node节点发送预设的指定信号,以使所述待断开node节点在预设时间段内,从所述master节点接收到的所述指定信号的数量达到预设的信号数量阈值时,从所述容器集群重新选择master节点并建立连接。
12.一种容器集群,其特征在于,包括处理器和存储器,所述存储器存储有能够被所述处理器执行的机器可执行指令,所述处理器执行所述机器可执行指令以实现权利要求1至7任一项所述的容器集群集群的负载均衡方法。
CN201911197642.4A 2019-11-27 2019-11-27 容器集群的负载均衡方法、装置与容器集群 Pending CN112860427A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911197642.4A CN112860427A (zh) 2019-11-27 2019-11-27 容器集群的负载均衡方法、装置与容器集群

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911197642.4A CN112860427A (zh) 2019-11-27 2019-11-27 容器集群的负载均衡方法、装置与容器集群

Publications (1)

Publication Number Publication Date
CN112860427A true CN112860427A (zh) 2021-05-28

Family

ID=75996000

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911197642.4A Pending CN112860427A (zh) 2019-11-27 2019-11-27 容器集群的负载均衡方法、装置与容器集群

Country Status (1)

Country Link
CN (1) CN112860427A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114003378A (zh) * 2021-10-26 2022-02-01 深圳证券信息有限公司 容器集群负载均衡方法、装置、设备及存储介质
CN114039982A (zh) * 2021-09-28 2022-02-11 杭州博盾习言科技有限公司 Node服务器、基于Node服务器实现多Master负载均衡的方法和系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160050262A1 (en) * 2014-08-13 2016-02-18 Microsoft Corporation Scalable fault resilient communications within distributed clusters
CN106575247A (zh) * 2014-08-13 2017-04-19 微软技术许可有限责任公司 计算集群的容错联盟
CN108965485A (zh) * 2018-09-30 2018-12-07 北京金山云网络技术有限公司 容器资源的管理方法、装置和云平台
CN109445802A (zh) * 2018-09-25 2019-03-08 众安信息技术服务有限公司 基于容器的私有化Paas平台及其发布应用的方法
CN109586969A (zh) * 2018-12-13 2019-04-05 平安科技(深圳)有限公司 内容分发网络容灾方法、装置、计算机设备及存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160050262A1 (en) * 2014-08-13 2016-02-18 Microsoft Corporation Scalable fault resilient communications within distributed clusters
CN106575247A (zh) * 2014-08-13 2017-04-19 微软技术许可有限责任公司 计算集群的容错联盟
CN106663030A (zh) * 2014-08-13 2017-05-10 微软技术许可有限责任公司 在分布式集群中的可扩展故障恢复通信
CN109445802A (zh) * 2018-09-25 2019-03-08 众安信息技术服务有限公司 基于容器的私有化Paas平台及其发布应用的方法
CN108965485A (zh) * 2018-09-30 2018-12-07 北京金山云网络技术有限公司 容器资源的管理方法、装置和云平台
CN109586969A (zh) * 2018-12-13 2019-04-05 平安科技(深圳)有限公司 内容分发网络容灾方法、装置、计算机设备及存储介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
杨杭;张昕;赵建平;: "基于动态反馈的负载均衡方法研究", 长春理工大学学报(自然科学版), no. 06, pages 141 - 147 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114039982A (zh) * 2021-09-28 2022-02-11 杭州博盾习言科技有限公司 Node服务器、基于Node服务器实现多Master负载均衡的方法和系统
CN114003378A (zh) * 2021-10-26 2022-02-01 深圳证券信息有限公司 容器集群负载均衡方法、装置、设备及存储介质
CN114003378B (zh) * 2021-10-26 2022-12-13 深圳证券信息有限公司 容器集群负载均衡方法、装置、设备及存储介质

Similar Documents

Publication Publication Date Title
CN109379774B (zh) 智能调度方法、终端设备、边缘节点集群与智能调度系统
WO2018152919A1 (zh) 一种路径选取方法及系统、网络加速节点及网络加速系统
CN109104483B (zh) 一种基于事件通知的微服务动态负载均衡的方法及装置
CN110832826B (zh) 区块链网络中概率中继的流量控制的方法和系统
CN109905259B (zh) 通信连接维持方法、系统和相关设备
CN116547958A (zh) 用于网络功能选择的排名处理的方法、系统和计算机可读介质
CN111459750A (zh) 基于非扁平网络的私有云监控方法、装置、计算机设备及存储介质
US8260930B2 (en) Systems, methods and computer readable media for reporting availability status of resources associated with a network
US10389801B2 (en) Service request processing method, related apparatus, and system
EP3547625B1 (en) Method and system for sending request for acquiring data resource
CN111787069A (zh) 业务接入请求的处理方法、装置、设备及计算机存储介质
KR101938455B1 (ko) 동적인 에지 컴퓨팅을 수행하는 방법 및 장치
CN110855792A (zh) 一种消息推送方法、装置、设备及介质
CN109660624B (zh) 内容分发网络资源的规划方法、服务器及存储介质
CN112860427A (zh) 容器集群的负载均衡方法、装置与容器集群
CN112527544B (zh) 一种服务器、触发熔断的方法及装置
CN109981412B (zh) 集群中数据迁移方法、装置及存储介质
CN112838989A (zh) 一种数据流管理方法、网络设备及存储介质
CN109697117B (zh) 终端控制方法、装置以及计算机可读存储介质
CN112671813B (zh) 服务器确定方法、装置、设备及存储介质
CN110597631B (zh) 资源管理方法、监控服务器、代理服务器以及存储介质
CN113992685B (zh) 一种服务控制器确定方法、系统及装置
CN114125023B (zh) 数据连接的确定方法及装置、存储介质及电子装置
CN114143019A (zh) 针对通信网络中安全更新的增强
CN111371675A (zh) 智能寻址方法、装置、设备及其存储介质

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