CN109032806A - 容器的服务调度方法和装置 - Google Patents
容器的服务调度方法和装置 Download PDFInfo
- Publication number
- CN109032806A CN109032806A CN201810895010.4A CN201810895010A CN109032806A CN 109032806 A CN109032806 A CN 109032806A CN 201810895010 A CN201810895010 A CN 201810895010A CN 109032806 A CN109032806 A CN 109032806A
- Authority
- CN
- China
- Prior art keywords
- container
- port
- service
- group
- script
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 133
- 238000012545 processing Methods 0.000 claims description 39
- 230000005540 biological transmission Effects 0.000 claims description 13
- 238000001514 detection method Methods 0.000 claims description 2
- 230000006870 function Effects 0.000 description 51
- 230000008569 process Effects 0.000 description 39
- 238000010586 diagram Methods 0.000 description 18
- 230000001815 facial effect Effects 0.000 description 15
- 238000004891 communication Methods 0.000 description 13
- 238000013461 design Methods 0.000 description 7
- 238000004590 computer program Methods 0.000 description 4
- 238000010168 coupling process Methods 0.000 description 4
- 238000005859 coupling reaction Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 230000002093 peripheral effect Effects 0.000 description 4
- 102100033121 Transcription factor 21 Human genes 0.000 description 3
- 101710119687 Transcription factor 21 Proteins 0.000 description 3
- 238000004364 calculation method Methods 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 230000008878 coupling Effects 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 238000002955 isolation Methods 0.000 description 3
- 208000033748 Device issues Diseases 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 238000013135 deep learning Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 230000008447 perception Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000001228 spectrum Methods 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements 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/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements 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/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements 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/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本申请提供了一种容器的服务调度方法、容器的调度装置和管理装置，该容器的服务调度方法包括：首先创建容器组，该容器组中包括至少两个容器，例如，第一容器和第二容器；根据需运行的应用程序，在各容器上分别运行服务，首先启动第一容器，第一容器的第一服务在第一容器启动时启动，第一服务占用所述容器组提供的第一端口，然后启动第二容器，第二容器的第二服务在第二容器启动时启动，第二容器内设置有端口替换脚本，端口替换脚本用于将第一端口替换为所述容器组提供的第二端口。本申请提供的容器的服务调度方法能够避免同一容器组下的各容器启动服务时出现端口冲突。
Description
技术领域
本申请涉及计算机领域，并且更具体地，涉及一种容器的服务调度方法和装置。
背景技术
在计算机系统中，容器(container)可以作为一种轻量级的虚拟机，即容器是一种操作系统层次上的资源的虚拟化，用以隔离进程(process)和资源。根据需运行的应用程序，在各容器上分别运行服务，可以使得应用程序如同在独立的机器上运行一样。容器技术有效地将由单个操作系统管理的资源划分到孤立的组中，以更好地在孤立的组之间平衡有冲突的资源使用需求。常见的容器技术包括Solaris Zones、BSD Jails和Linux操作系统上的容器技术等等。
命名空间(NameSpace)是Linux的一项内核(kernel)技术，是容器技术的基础。其中，网络命名空间(Network NameSpace)是每个容器拥有的网络设备，独享互联网协议(internet protocol，IP)地址和端口号等。
需要多个容器同时运行一个应用程序时，容器系统建立至少一个容器组(pod)，每个容器组包含至少两个容器，每个容器上的服务分别用于运行应用程序。各容器上的服务在运行应用程序时，分别通过网络命名空间上的端口实现外部通信。容器上的服务在通信时所使用的端口通常由服务运行的应用程序指定，那么，当多个容器的服务分别运行同一个应用程序时，各容器上运行的各服务均需通过该应用程序指定的端口通信，又由于同一容器组的各容器共享同一网络命名空间，因此，同一容器组下的各容器的服务分别运行同一个应用程序时，各服务需与同一网络命名空间的同一端口绑定，造成端口冲突。
发明内容
本申请提供一种容器的服务调度方法、容器的调度装置和管理装置，能够避免同一容器组下的各容器的服务分别运行同一个应用程序时出现的端口冲突。
第一方面，提供了一种容器的服务调度方法，该方法包括：创建容器组，该容器组包括第一容器和第二容器；启动该第一容器，其中，该第一容器的第一服务在该第一容器启动时启动，该第一服务占用该容器组提供的第一端口；启动该第二容器，其中，该第二容器的第二服务在该第二容器启动时启动，且该第二容器内设置有端口替换脚本，该端口替换脚本用于将该第一端口替换为该容器组提供的第二端口，该第二服务在检测到该第一端口被占用时根据该端口替换脚本占用该第二端口。
根据本申请实施例提供的容器的服务调度方法，通过在容器中设置端口替换脚本，使得在出现端口冲突时根据端口替换脚本替换冲突的端口，占用空闲状态的端口，避免了端口冲突，使得第一容器和第二容器可以同时运行同一应用程序，提高了应用程序运行的效率。
具体地，上述第一容器和第二容器为一个容器组内的两个独立的容器，其中，第一容器和第二容器属于同一个镜像，并且第一容器和第二容器的服务运行相同的应用程序，即，当第一容器启动第一服务，占用第一端口之后，第二容器启动第二服务时，检测到第一端口被占用，则，根据第二容器中的端口替换脚本，将第一端口替换为未被占用的第二端口，运行该第二服务。
应理解，上述第一容器和第二容器为执行某个应用程序时拉起的两个容器，容器组中还可以包括其他的容器，本申请实施例中对于执行相同应用程序的容器个数不做限制，可以大于两个。
还应理解，上述第一容器中也可能包括端口替换脚本。
结合第一方面，在第一方面的一种实现方式中，上述容器组还包括第三容器，创建容器组后，该方法还包括：启动该第三容器，其中该第三容器的管理服务在该第三容器启动时启动，该第三容器的管理服务用于记录该第二服务在检测到该第一端口被占用时该第二服务发送的该第二端口与该第二服务的第一对应关系。
根据本申请实施例提供的容器的服务调度方法，通过启动容器组中的第三容器，应用第三容器中的管理服务记录第二服务与第二端口的第一对应关系，能够为其他需要获取第二服务与第二端口的对应关系的容器或应用程序调度器提供获取方法。
应理解，还可以应用第三容器中的管理服务记录第一服务与第一端口的第二对应关系。
结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，第二容器内设置的该端口替换脚本由该第三容器发送至该第二容器。
根据本申请实施例提供的容器的服务调度方法，第二容器中的端口替换脚本可以是由第三容器发送的，为第二容器中的端口替换脚本提供一种可能的获取方式。
具体地，第二容器中的端口替换脚本可以是由第三容器中的管理服务发送的。
结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，该第三容器的管理服务还用于记录该第一服务发送的该第一端口与该第一服务的第二对应关系，该第二服务在检测到该第一端口被占用时根据该端口替换脚本占用该第二端口，具体包括：该第二服务接收包含该第一端口的端口绑定申请，查询该第三容器的管理服务中的该第二对应关系，检测到该第一端口被占用，根据该端口替换脚本占用该第二端口；或者，该第二服务根据接收的该端口绑定申请，绑定该第一端口失败，根据该端口替换脚本占用该第二端口。
根据本申请实施例提供的容器的服务调度方法，第二服务在检测到该第一端口被占用时根据该端口替换脚本占用该第二端口可以是以下两种方法中的任意一种：
第一种：当第三容器的管理服务记录了第一端口与第一服务的第二对应关系的情况下，第二服务接收包含第一端口的端口绑定申请，查询第三容器的管理服务中的第二对应关系，检测到第一端口被占用，根据端口替换脚本占用该第二端口。
第二种：第二服务接收包含第一端口的端口绑定申请，绑定第一端口失败，根据端口替换脚本占用该第二端口。
结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，该容器组还包括被处理对象，该方法还包括：应用程序调度器查询该第三容器的管理服务记录的该第一对应关系和该第二对应关系，根据该第一对应关系获取该第二服务占用的第二端口，根据该第二对应关系获取该第一服务占用的第一端口；
该应用程序调度器将针对该被处理对象的第一处理规则通过该第一端口发送至该第一服务；
该应用程序调度器将针对该被处理对象的第二处理规则通过该第二端口发送至该第二服务。
该应用程序调度器根据本申请实施例提供的容器的服务调度方法，根据第三容器中记录的第一对应关系和第二对应关系，能够向第一服务和第二服务分别下发处理待处理对象的第一处理规则和第二处理规则。
该应用程序调度器可以部署在容器组内或者容器组外的任意容器上。
结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，该容器组还包括被处理对象，该方法还包括：该第二服务通过该第一端口确定该第一服务处理该被处理对象的进度。
根据本申请实施例提供的容器的服务调度方法，第二服务能够通过第一端口确定第一服务处理该被处理对象的进度，同理，第一服务能够通过第二端口确定第二服务处理该被处理对象的进度。能够及时获取处理同一个被处理对象的服务的处理进程，从而确定是否完成处理，当对方已经完成处理时及时停止，可以避免资源浪费。
第二方面，提供了一种容器的服务调度方法，该方法应用于第三容器，该第三容器设置于容器组，该容器组还包括第一容器和第二容器，该第一容器包括第一服务，该第一服务占用该容器组提供的第一端口，该第二容器包括第二服务；该方法包括：向该第二容器发送包含端口替换脚本的调度信息，该端口替换脚本用于将该第一端口替换为第二端口，该调度信息用于指示在该第二容器中设置该端口替换脚本，以使该第二服务在检测到该第一端口被占用时根据该端口替换脚本占用该容器组提供的该第二端口。
根据本申请实施例提供的容器的服务调度方法，通过第三容器向同一个容器组中的其他容器发送端口替换脚本，能够在发生端口冲突时进行端口替换。
结合第二方面，在第二方面的一种实现方式中，该方法还包括：记录该第二服务在检测到该第一端口被占用时该第二服务发送的该第二端口与该第二服务的第一对应关系。
根据本申请实施例提供的容器的服务调度方法，通过使第三容器记录第二端口与该第二服务的第一对应关系，能够为其他需要获取第二服务与第二端口的对应关系的容器或应用程序调度器提供获取方法。
结合第二方面及其上述实现方式，在第二方面的另一种实现方式中，记录该第一服务发送的该第一端口与该第一服务的第二对应关系，以使该第二服务接收包含该第一端口的端口绑定申请后，查询该管理服务中的该第二对应关系，检测该第一端口是否被占用。
根据本申请实施例提供的容器的服务调度方法，通过使第三容器记录第一端口与该第一服务的第二对应关系，当第三容器的管理服务记录了第一端口与第一服务的第二对应关系的情况下，第二服务接收包含第一端口的端口绑定申请，查询第三容器的管理服务中的第二对应关系，检测到第一端口被占用，根据端口替换脚本占用该第二端口。
结合第二方面及其上述实现方式，在第二方面的另一种实现方式中，该容器组还包含被处理对象，该方法还包括：记录该第二服务发送的该第二端口与该第二服务的第一对应关系，以使该第一服务通过该第二端口确定该第二服务处理该被处理对象的进度。
根据本申请实施例提供的容器的服务调度方法，第一服务能够通过第二端口确定第二服务处理该被处理对象的进度，同理，第二服务能够通过第一端口确定第一服务处理该被处理对象的进度。能够及时获取处理同一个被处理对象的服务的处理进程，从而确定是否完成处理，当对方已经完成处理时及时停止，可以避免资源浪费。
第三方面，提供了一种容器的调度装置，该容器的调度装置可以用来执行第一方面及第一方面的任意可能的实现方式中的容器的调度装置的操作。具体地，容器的调度装置包括用于执行上述第一方面所描述的步骤或功能相对应的部件(means)可以是第一方面的容器的调度服务。该步骤或功能可以通过软件实现，或硬件实现，或者通过硬件和软件结合来实现。
第四方面，提供了一种管理装置，该管理装置可以用来执行第二方面及第二方面的任意可能的实现方式中的管理服务的操作。具体地，管理装置包括用于执行上述第二方面所描述的步骤或功能相对应的部件(means)可以是第二方面的管理服务。该步骤或功能可以通过软件实现，或硬件实现，或者通过硬件和软件结合来实现。
第五方面，提供了一种数据中心，数据中心包括至少一个计算设备，每个计算设备包括处理器和存储器，至少一个计算设备的处理器运行调度装置用于执行第一方面及第一方面的任意可能的实现方式中的功能。
在一个可能的设计中，该计算设备还可以包括收发组件，用于支持计算设备接收或发送信息。
在一个可能的设计中，该计算设备还可以包括存储器，该存储器用于与处理器耦合，保存计算设备必要的程序指令和数据。或者说，该计算设备包括存储器和处理器，该存储器用于存储计算机程序，该处理器用于从存储器中调用并运行该计算机程序，使得处理器执行第一方面及第一方面的任意可能的实现方式中的任一种容器的服务调度方法。
第六方面，提供了一种数据中心，数据中心包括至少一个计算设备，每个计算设备包括处理器和存储器，至少一个计算设备的处理器运行管理装置用于执行第二方面及第二方面的任意可能的实现方式中的功能。
在一个可能的设计中，该计算设备还可以包括收发组件，用于支持计算设备接收或发送信息。
在一个可能的设计中，该计算设备还可以包括存储器，该存储器用于与处理器耦合，保存计算设备必要的程序指令和数据。或者说，该计算设备包括存储器和处理器，该存储器用于存储计算机程序，该处理器用于从存储器中调用并运行该计算机程序，使得处理器执行第二方面及第二方面的任意可能的实现方式中的任一种容器的服务调度方法。
本申请实施例的容器的服务调度方法、容器的调度装置和管理装置，通过在容器中设置端口替换脚本，能够避免同一容器组下的各容器的服务分别运行同一个应用程序时出现的端口冲突。
附图说明
图1是本申请实施例适用的一种容器系统100的示意图；
图2是Kubernetes的一种示意图；
图3是一种容器共享相同的Network NameSpace示意图；
图4是另一种容器共享相同的Network NameSpace示意图；
图5是一种本申请实施例提供的容器的服务调度方法流程图；
图6是另一种本申请实施例提供的容器的服务调度方法流程图；
图7是一种端口替换示意图；
图8是一种容器处理待处理对象的流程图；
图9是本申请提供的一种具体实施例示意图；
图10是一种容器的调度装置示意图；
图11是一种管理装置示意图；
图12是一种数据中心中的物理服务器的示意图。
具体实施方式
下面将结合附图，对本申请中的技术方案进行描述。
本申请实施例提供的容器的服务调度方法、容器的调度装置和管理装置可以应用于各种大规模计算场景，例如：大数据处理、深度学习等。
图1是本申请实施例适用的一种容器系统100的示意图。包括调度节点110、服务节点120以及容器组121。下面详细介绍这几个部分。
调度节点110：为容器系统中的中枢控制节点，控制整个容器系统的资源调度和任务执行。
具体地，该调度节点110上运行的调度服务，能够完成整个容器系统的资源调度和任务执行。
服务节点120：是具体承载容器的计算单元，用于承载容器组。
具体地，一个服务节点内包含一个或多个容器组(pod)，每个容器组内又包含一个或多个容器(container)。容器系统中可以包括多个服务节点。
应理解，服务节点120可以是物理机或者虚拟机，本申请实施例对此并不限制。
容器组121：是容器系统创建或部署的最小(最简单)的基本单位，一个容器组代表容器系统上正在运行的一个进程。
具体地，容器组代表部署的一个单位，容器系统中单个应用的实例，可能由单个容器或者多个容器共享组成的资源运行。
如图1中所示的容器组包括容器1、容器2以及容器3，分别运行服务1、服务2以及管理服务。
应理解，上述容器组包括的容器个数只是一种举例形式，可能包括3个以上的容器，其中，至少一个容器上运行管理服务。
还应理解，上述将pod称为容器组是从pod的实际意义出发命名的，并不能限制本申请的保护范围，可以称pod为其他的名称。例如，直译为豆荚也可以。
还应理解，上述调度节点上运行的调度服务可以通过在调度节点上运行调度相关的进程实现，也可以通过在调度节点上部署的调度装置实现，后文中具体介绍调度装置；
容器1上运行的服务1可以通过在容器1上运行服务1相关的进程实现；
容器2上运行的服务2可以通过在容器1上运行服务2相关的进程实现；
容器3上运行的管理服务可以通过在容器3上运行运行管理服务相关的进程实现，也可以通过在容器3上部署的管理装置实现。后文中具体介绍管理装置。
应理解，进程(process)是计算机中的程序关于某数据集合上的一次运行活动，是系统进行资源分配和调度的基本单位，是操作系统结构的基础。在早期面向进程设计的计算机结构中，进程是程序的基本执行实体；在当代面向线程设计的计算机结构中，进程是线程的容器。程序是指令、数据及其组织形式的描述，进程是程序的实体。
具体地，本申请中所涉及的容器系统可以是Kubernetes系统，下面结合图2简单介绍Kubernetes系统。
图2是Kubernetes系统的一种示意图。Kubernetes系统为图1中所示容器系统100的一种具体实施方式，本申请实施例中的方法及装置均可以在Kubernetes系统上实现，以下将Kubernetes系统简称为Kubernetes。
Kubernetes是谷歌(Google)开源的容器集群管理系统。Kubernetes提供应用部署、维护、扩展机制等功能。Kubernetes里最核心的概念是节点和容器组(pod)。
具体地，节点包括主节点，与图1中的调度节点类似。
主节点(Master)：是中枢控制节点，控制整个容器集群的资源调度和容器集群中的任务执行。
Master节点上主要有以下介绍的三个模块：
1、应用程序界面服务器(application program interface server，APIServer)，用于暴露出Kubernetes的应用程序界面(application program interface，API)，可以被终端设备或者其他系统操作。
2、高可用的键值(key value，KV)存储系统，Kubernetes上所有信息都被存到KV存储系统中。
3、调度和控制管理模块，用于管理容器以及调度容器。
具体地，节点还包括Node(或者，称为minion)节点(如图2中所示的Node节点1、Node节点2以及Node节点3)，与图1中的服务节点类似。
Node节点：是具体承载容器的计算单元。
每个Node节点上有以下介绍的三个主要进程：
1、Kubelet，为Node节点上的进程，该进程用于处理Master节点下发到本Node节点的任务，管理pod及pod中的容器。
每个Kubelet进程会在API Server上注册本Node节点自身信息，定期向Master节点汇报节点资源的使用情况。
2、代理(Proxy)进程，用于通过IP和服务器名字(server name)把请求转发到正确的容器(container)上。
具体地，上述Master节点和Node节点，均可以由物理机部署，或由虚拟机部署，一台服务器对应一个节点。
从图2中可以看出每个Node节点内包含一个或多个pod。每个pod内又包含一个或多个容器。
下面简单介绍Kubernetes中的pod，pod与图1中的容器组是同样的概念。一个pod封装一个应用容器(也可以有多个容器)，存储资源、一个独立的网络IP以及管理控制容器运行方式的策略选项。
Kubernetes中的pod使用可分两种主要方式：
1、pod中运行一个容器。一个容器一个pod(one-container-per-pod)模式是Kubernetes最常见的用法；在这种情况下，可以将pod视为单个封装的容器，但是Kubernetes是直接管理pod而不是pod内的容器。
2、pod中运行多个需要一起工作的容器。pod可以封装紧密耦合的应用，该应用需要由多个容器组成，多个容器之间能够共享资源。
具体地，Kubernetes不仅仅是减轻了线上集群运维的压力，还能够提升机器资源的利用率。
上述图1或图2中所示的容器是轻量级的操作系统虚拟化，可以在一个资源隔离的服务中运行应用程序及其依赖项。
运行应用程序所必需的组件都将打包成一个镜像并可以复用。执行镜像时，它运行在一个隔离环境中，并且不会共享宿主机的内存、CPU以及磁盘，这就保证了容器内运行服务不能监控容器外的任何进程。
容器技术是一种被广泛认可的基础资源共享方式，通过命名空间分割基础资源，能够为资源管理员提供极大的操作灵活性。
随着容器技术的持续发展，由于容器技术的灵活性，想要很好地管理可扩展的容器环境，很大程度上依赖于容器编排工具。容器编排工具为容器环境提供集群和调度能力，直接决定容器的运行方式。通过容器编排工具，使得容器可以在基础资源上层高效调度，进而确保容器能够快速扩展，以适应承载压力的波动。
由上述可知容器技术是操作系统级别的轻量级虚拟化技术，而且它底层依赖的技术是Linux操作系统的命名空间(Namespace)。
NameSpace是Linux的一项内核技术，是容器技术的基础。NameSpace对某个特定的系统资源进行抽象隔离，使得NameSpace内的进程可以拥有一套独立的系统资源实例。
在容器系统中，运行在同一个pod内的多个容器，共享相同的Network NameSpace。
具体地，Network NameSpace包括端口，也就是说在容器系统中，运行在同一个pod内的多个容器共享一个服务端口。其中，服务端口用于与该pod外部通信。
下面结合图3介绍现有技术中，pod内的容器如何与pod外部通信的。
图3是一种容器共享相同的Network NameSpace示意图。
从图2中可以看出，一个pod中的多个容器共享Network NameSpace与该pod外部网络通信。可以理解为，每个pod被分配一个独立的IP地址，pod中的多个容器共享网络命名空间，包括多个容器共享IP地址和网络端口。
pod内的容器可以使用本地主机(localhost)相互通信。当pod内的容器与pod外部通信时，多个容器必须协调如何使用共享网络资源，该网络资源包括端口资源。也就是说在多个容器共享端口资源时，为了避免发生端口冲突需要多个容器协调使用端口资源。
在容器系统中，pod内多个容器共享端口(port)，会导致根据需运行的应用程序，在多个容器上分别运行服务时出现故障，而出现故障的主要原因是端口冲突。因为先启动服务的容器占据端口后，其他容器内的服务将无法绑定到该端口上，而导致其他容器内的服务启动失败。
下面结合图4说明端口冲突。
图4是另一种容器共享相同的Network NameSpace示意图。
从图3中可以看出，一个pod中的多个容器共享Network NameSpace与该pod外部网络通信时，容器1先行启动第一服务，假设该第一服务占用pod提供的80端口。则，当容器2启动第二服务时，第二服务在检测到该第一端口被占用，而导致容器2无法正常启动第二服务。
应理解，服务占用端口指的是，容器启动该服务时，容器通过该端口与容器外部通信。
还应理解，图3和图4所示的只是一种举例的形式，在一个pod内可以包括两个以上的容器。
为了解决上述图4中出现的问题，本申请提出一种容器的服务调度方法，能够避免一个pod中的多个容器分别启动服务时，出现如图4中所示的端口冲突。
下面结合图5-图9详细介绍本申请实施例提供的容器的服务调度方法。
图5是一种本申请实施例提供的容器的服务调度方法流程图。本申请提供的容器的服务调度方法可以应用于上述的容器系统中(例如，图1所示的容器系统或图2所示的Kubernetes)。
图5包括S510-S530三个步骤，下面详细介绍这三个步骤。
S510，容器系统创建容器组，该容器组包括第一容器和第二容器。
具体地，可以理解当容器系统需要运行某个应用程序(运行应用处理某个任务)，为了并行处理该任务，容器系统创建至少一个容器组，且每个容器组中包括至少两个容器，该至少两个容器运行该应用程序，并行处理该任务。其中，该至少两个容器运行该应用程序实际是在该至少两个容器内运行进程，即，该至少两个容器上分别运行由该应用程序生成的进程。
可选地，上述容器系统为图2所示的Kubernetes时，容器系统创建容器组包括：利用暂停(pause)容器镜像和容器镜像，创建上述容器组，并在容器组内创建上述第一容器和第二容器。
具体上，Kubernetes是先创建容器组中的一个pause容器，然后创建同一个容器组中的其他容器，共享pause容器的命名空间。即，pause容器在容器组中担任命名空间共享的基础。
应理解，在Kubernetes中上述pause容器不执行实际的业务逻辑，只是对容器组的网络、输入输出(input/output，IO)等进行控制。
还应理解，本申请中容器系统并不限制为Kubernetes，可以为其他容器系统，实现上述各种功能。
S520，启动第一容器。
其中，该第一容器的第一服务在该第一容器启动时启动，该第一服务占用该容器组提供的第一端口。
本实施例中，容器组中的第一容器根据容器系统中需要运行的应用程序，在第一容器上运行第一服务，上述第一服务占用容器组提供的第一端口。其中，第一端口指的是该应用程序预设的端口，可以理解为该需要运行的应用程序与第一端口绑定。
可选地，本申请实施例中的容器的服务调度方法还可以包括如图5所示的S521，第一容器向第三容器发送第二消息。
其中，第二消息是第一容器启动第一服务之后，向第三容器发送的消息，该第二消息用于指示第一端口与第一服务的第二对应关系。
S530，启动第二容器。
其中，该第二容器的第二服务在该第二容器启动时启动，且该第二容器内设置有端口替换脚本，该端口替换脚本用于将该第一端口替换为该容器组提供的第二端口，该第二服务在检测到该第一端口被占用时根据该端口替换脚本占用该第二端口。其中，第二端口为器组提供的未被占用的任意端口。
具体地，容器组中的第二容器根据容器系统中需要运行的应用程序，在第二容器上运行第二服务，该需要运行的应用程序与第一端口绑定。而第一容器运行第一服务先于第二容器运行第二服务，且第一服务占用容器组提供的第一端口。也就是说，第二容器启动第二服务时，第二服务检测到该第一端口被占用。
为了保证第二容器能够根据容器系统中需要运行的应用程序成功运行第二服务，第二服务在检测到该第一端口被占用时根据端口替换脚本占用该第二端口。
应理解，第二容器为容器组内多个容器中的任意一个容器，第一容器为多个容器中根据容器系统中需要运行的应用程序已启动第一服务的容器，且第一容器和第二容器属于同一个镜像，用于处理同样的被处理对象，被处理对象为上述的需要运行的应用程序。可以理解第一容器启动的第一服务和第二容器启动的第二服务为同一个容器系统中需要运行的应用程序创建的进程。
还应理解，第一容器和第二容器属于同一个镜像，指的是第一容器和第二容器处理同样的被处理对象时，不需要为第一容器和第二容器分别制作专用的镜像。
可选地，本申请实施例中的容器的服务调度方法还可以包括如图5所示的S531，第二容器向第三容器发送第一消息。
其中，第一消息是第二容器启动第二服务之后，向第三容器发送的消息，该第一消息用于指示第二端口与第二服务的第一对应关系。
具体地，启动该第三容器，其中该第三容器的管理服务在该第三容器启动时启动，该第三容器的管理服务用于记录该第二服务在检测到该第一端口被占用时该第二服务发送的该第二端口与该第二服务的第一对应关系。
下面以第三容器的管理服务为，该pod内pause容器中的管理进程(remember)为例，第二容器向第三容器的管理服务发送第一消息具体可以是：
第二容器向pause容器中的remember上报应用真实绑定的端口信息，remember将真实绑定的端口信息记录在remember中。
可选地，在一些实施例中，第一消息包括：该第二容器指示信息、以及该第一端口指示信息或该第二端口指示信息中的至少一个。
例如，第一消息中包括第二容器的容器名称、端口绑定申请指定的原始端口(第一端口)名称以及调度之后的应用真实绑定的端口(第二端口)名称。
应理解，上述第一容器指示信息为第一容器的容器名称、第一端口指示信息为第一端口名称以及第二端口指示信息为第二端口名称，只是举例的形式。还可以通过其他的指示方式指示对应的容器或端口，例如，容器ID、端口标识等。本申请对此并不限制。
为了便于理解，下面举例说明本申请实施例中的容器的服务调度方法。
例如，上述第二容器为图1中所示的容器2，第一容器为图1中所示的容器1，第三容器为图1中所示的容器3。
当容器1和容器2属于同一个镜像，用于处理同样的被处理对象。并且容器1已经启动服务1，服务1占用第一端口。
可选地，容器1向容器3发送第二消息，指示服务1与第一端口的第二对应关系。
容器2与容器1处理同样的被处理对象时，即，容器2启动服务2，服务2检测第一端口被占用。由于容器2内设置有端口替换脚本，当第一端口被占用时根据该端口替换脚本占用该第二端口。其中，第二端口未被任何容器占用。
可选地，容器2向容器3发送第一消息，指示服务2与第二端口的第一对应关系。
可选地，在一些实施例中，第二服务在检测到该第一端口被占用时根据该端口替换脚本占用该第二端口，包括以下两种方法：
方法一：该第二服务接收包含该第一端口的端口绑定申请，查询该第三容器的管理服务中的第二对应关系，检测到该第一端口被占用，根据该端口替换脚本占用该第二端口。
其中，可选地，该第三容器为Kubernetes中的pod内的暂停(pause)容器。
具体地，第三容器的管理服务为暂停容器中的管理进程(remember)，用于记录该第一服务发送的该第一端口与该第一服务的第二对应关系。
例如，第二容器为图1中所示的容器2，第一容器为图1中所示的容器1，第三容器为图1中所示的容器3。
第三容器的管理服务记录服务1发送的该第一端口与服务1的第二对应关系。容器2启动服务2时，服务2通过查询第三容器的管理服务确定第一端口已经被占用了。
其中，第三容器的管理服务记录服务1发送的该第一端口与服务1的第二对应关系，可以是容器1启动服务1之后，向第三容器的管理服务发送第二消息，该第二消息用于指示第一端口与服务1的第二对应关系。
应理解，上述第三容器为Kubernetes中的pod内pause容器，第三容器的管理服务为pause容器中的remember，只是一种举例的形式。第三容器还可以是容器系统的pod内的其他容器，管理服务用于管理容器中运行的服务与对应的端口的对应关系。本申请对此并不限定。
方法二：该第二服务根据接收的该端口绑定申请，绑定该第一端口失败，根据该端口替换脚本占用该第二端口。
应理解，第二服务在接收到端口绑定申请时，可以直接根据端口绑定申请，绑定到该端口绑定申请指定的端口上，不需要提前在第三容器的管理服务中查询该端口绑定申请指定的端口是否与被其他服务占用。其中，端口绑定申请为容器系统中需要运行的应用程序的绑定端口申请。
如果，第二服务直接根据端口绑定申请，占用该端口绑定申请指定的端口失败了，则证明该端口绑定申请指定的端口已经被占用，第二服务根据该端口替换脚本占用该第二端口。
例如，上述第二容器为图1中所示的容器2，第一容器为图1中所示的容器1。容器1启动服务1，服务1占用第一端口。
容器2启动服务2时，服务2直接根据端口绑定申请占用第一端口，但是服务2占用第一端口失败，则容器2确定第一端口已经被服务1占用了。
应理解，可以有多个第一容器，即在一个pod中可以包括两个以上的容器处理相同的被处理对象，则每个容器启动服务时均会处理端口绑定申请指定的端口是否被占用，当端口被占用时，替换端口。使得多个容器之间不会发生端口冲突，影响各个容器上服务的启动。
进一步地，本申请实施例中对于该端口绑定申请指定的端口(第一端口)未被占用的情况不做限制，可以使用现有技术中启动服务的方法，直接通过该端口绑定到申请指定的端口与该pod外部通信，启动服务。
可选地，本申请实施例中的容器的服务调度方法还可以包括如图5所示的S540，第三容器向第二容器发送调度信息。该调度信息包括上述端口替换脚本，可以理解为，该第二容器内设置的该端口替换脚本由该第三容器发送至该第二容器。
进一步地，该第二容器内设置的该端口替换脚本由第三容器的管理服务发送至第二容器。
具体地，上述端口替换脚本可以是第二容器的系统C函数(glibc)库中的新的端口绑定函数(bind)的脚本，与现有技术中的第二容器中的绑定函数功能不同的是：
在第二服务在检测到该第一端口被占用时，能够根据该端口替换脚本占用该第二端口。
具体地，新的端口绑定函数可以是：在原来的glibc库中的端口(socket)组件的绑定(bind)函数中加入一段代码。
该加入代码之后的bind函数能够使得当该第一端口被占用时，调度该第二端口，使得该第二容器上成功启动第二服务。
上述glibc库是GNU发布的glibc库，即c函数运行库。
glibc是linux系统中最底层的应用程序界面(application program interface，API)，几乎其它任何运行库都会依赖于glibc库。glibc库除了封装linux操作系统所提供的系统服务外，它本身也提供了许多其它一些必要功能服务的实现。由于glibc囊括了几乎所有的UNIX通行的标准，可以想见其内容包罗万象。而就像其他的UNIX系统一样，其内含的档案群分散于系统的树状目录结构中，像一个支架一般撑起整个操作系统。在GNU/Linux系统中，其c函数库发展史点出了GNU/Linux演进的几个重要里程碑，用glibc作为系统的c函数库，是GNU/Linux演进的一个重要里程碑。
其中，第二容器的系统C函数(glibc)库中原始的端口绑定函数，与现有技术中的第二容器中的绑定函数功能一致。
原始的端口绑定函数在第二服务接收到端口绑定申请时，根据端口绑定申请绑定到该端口绑定申请指定的端口上，不能在端口绑定申请指定的端口被占用的情况下执行端口变更，这里不详细说明。
具体地，第二容器内设置的该端口替换脚本由第三容器的管理服务发送至第二容器包括：该第二容器接收第三容器的管理服务发送的包含端口替换脚本的调度信息。
即，上述第二容器内设置的端口替换脚本包括：
第二容器根据接收的包含端口替换脚本的调度信息，替换原始的端口绑定函数为新的端口绑定函数；或者，第二容器根据接收的包含端口替换脚本的调度信息，替换原始的glibc库为包括新的端口绑定函数(bind)的新的glibe库。
也就是第三容器的管理服务发送的包含端口替换脚本的调度信息可以是仅仅包括用于替换原始的端口绑定函数的新的端口绑定函数，或者，第三容器的管理服务发送的包含端口替换脚本的调度信息可以是新的glibc库，直接替换原始的glibc库。
该调度信息用于指示将该第二容器内的原始的端口绑定函数更新为新的端口绑定函数，该调度信息包括新的端口绑定函数。
下面以第三容器的管理服务为，该pod内pause容器中的管理进程(remember)为例，介绍本申请实施例中的第二容器内的原始的端口绑定函数更新为新的端口绑定函数具体为：
在第二容器启动第二服务之前，通过remember调度，更新第二容器内的系统C函数(glibc)库。其中，通过remember调度可以理解为接收到remember发送的调度信息。
进一步地，可以将加入代码之后的glibc库存储在pause容器中。更新第二容器内的glibc库可以是，在第二容器启动第二服务之前，由remember触发替换glibc库，将第二容器内原始的glibc库替换为pause容器中存储的加入代码之后的glibc库。用户对于该替换流程感知不到。其中，由remember触发替换glibc库可以理解为接收到remember发送的调度信息。
下面结合图6详细介绍第三容器的具体作用。
图6是另一种本申请实施例提供的容器的服务调度方法流程图。
S610，第三容器向第二容器下发调度信息。
具体地，第三容器设置于容器组，容器组还包括第一容器和第二容器，第一容器包括第一服务，第一服务占用该容器组提供的第一端口，第二容器包括第二服务；
第三容器向第二容器发送包含端口替换脚本的调度信息，端口替换脚本用于将第一端口替换为第二端口，调度信息用于指示在该第二容器中设置该端口替换脚本，以使该第二服务在检测到该第一端口被占用时根据该端口替换脚本占用该容器组提供的该第二端口。
可选地，本实施例中的容器的服务调度方法还可以包括如图6所示的S611，第三容器接收第二容器发送的第一对应关系。
可选地，上述第一对应关系可以是包括在图5中该的第一消息中，由第二容器发送给第三容器，其中，第一对应关系是第二容器启动第二服务之后，向第三容器发送的第二端口与第二服务的第一对应关系。
可选地，本实施例中的容器的服务调度方法还可以包括如图6所示的S620，第三容器记录第一对应关系。以使该第一服务通过该第二端口确定该第二服务处理该被处理对象的进度。
可选地，本实施例中的容器的服务调度方法还可以包括如图6所示的S612，第三容器接收第一容器发送的第二对应关系。
可选地，上述第二对应关系可以是包括在图5中该的第二消息中，由第一容器发送给第三容器，其中，第二对应关系是第一容器启动第一服务之后，向第三容器发送的第一端口与第一服务的第二对应关系。
可选地，本实施例中的容器的服务调度方法还可以包括如图6所示的S621，第三容器记录第二对应关系。以使该第二服务接收包含该第一端口的端口绑定申请后，查询该管理服务中的该第二对应关系，检测该第一端口是否被占用，以及以使该第二服务通过该第一端口确定该第一服务处理该被处理对象的进度。
为了便于理解，下面以第三容器为Kubernetes创建的容器组中的pause容器，以及上述图6中第三容器下发调度信息、记录第一对应关系以及记录第二对应关系由pause容器中的remember实现，详细介绍图6中的端口替换脚本以及对应关系记录。
图7是一种端口替换方法的示意图。包括S710-S730。
S710，第一服务占用服务器端口80。
启动第一容器，其中，该第一容器的第一服务在该第一容器启动时启动，该第一服务占用服务器端口80。
应理解，第一容器中的bind函数也可以插入上述代码，使得加入代码之后的bind函数能够当服务器端口80被其他容器占用时，调度其他未被占用的端口供第一服务占用。
第一容器中的bind函数也可以不插入上述代码，因为第一容器并未进行端口替换。但是为了方案的统一性，可以将pod内所用运行服务的容器内的glibc库中的bind函数均嵌入上述代码。
S720，第一容器上报第二对应关系。
第一服务占用服务器端口80之后，第一容器启动的第一服务将服务器端口80与第一服务的第二对应关系上报remember。即，将真实的端口信息记录于remember中。
S730，第二容器替换端口。
启动该第二容器，其中，该第二容器的第二服务在该第二容器启动时启动，且该第二容器内设置有端口替换脚本通过端口替换脚本(即remember)更新bind函数，后启动第二服务。
第二服务在检测到该服务器端口80被占用时根据更新后的bind函数占用端口10080。
S740，第二容器上报第一对应关系。
第二服务占用服务器端口10080之后，第二容器启动的第二服务将服务器端口10080与第二服务的第一对应关系上报remember。即，将真实的端口信息记录于remember中。
第二容器启动第二服务，第二服务占用服务器端口10080之后，第二容器启动的第二服务。
具体地，在该第二容器启动的第二服务之前，该容器组还包括被处理对象，该方法还包括：
应用程序调度器查询该第三容器的管理服务记录的上述第二端口与该第二服务的第一对应关系；
应用程序调度器查询该第三容器的管理服务记录的上述第一端口与该第一服务的第二对应关系；
应用程序调度器根据该第一对应关系获取该第二服务占用的第二端口，根据该第二对应关系获取该第一服务占用的第一端口；
应用程序调度器将针对该被处理对象的第一处理规则通过该第一端口发送至该第一服务；
应用程序调度器将针对该被处理对象的第二处理规则通过该第二端口发送至该第二服务。
例如，第二服务接收应用程序调度器通过该第二端口发送的处理被处理对象的第二处理规则为：从前往后处理被处理对象，或者从后往前处理被处理对象；
第一服务接收应用程序调度器通过该第一端口发送的处理被处理对象的第一处理规则为：从前往后处理被处理对象，或者从后往前处理被处理对象。
进一步地，该第二服务通过该第一端口确定该第一服务处理该被处理对象的进度，当该被处理对象完成处理时，该第二容器停止处理该被处理对象；
该第一服务通过该第二端口确定该第二服务处理该被处理对象的进度，当该被处理对象完成处理时，该第一容器停止处理该被处理对象。
具体地，在该第二服务通过该第一端口确定该第一服务处理该被处理对象的进度之前，该方法还包括：该第二容器访问第三容器的管理服务，获取第一端口与该第一服务的第二对应关系。
下面结合图8详细介绍第二容器运行应用的流程。
图8是一种容器处理待处理对象的流程图。包括S810-S850五个步骤，下面详细介绍这五个步骤。
图8以上述第三容器的管理服务为pod内的pause容器中的管理进程为例。
S810，应用程序调度器访问pause容器中的管理进程，获取端口信息。
应理解，应用程序调度器能够通过pod的原始端口，访问pause容器中的管理进程。因为管理进程中存储容器上运行的服务对应的真实端口信息。
例如，应用程序调度器获取第一端口与该第一服务的第二对应关系，以及获取第二端口与该第二服务的第一对应关系。
S820，应用程序调度器下发处理规则。
应用程序调度器已知每个容器上运行的服务占用的真实端口之后，通过每个服务对应的真实端口，分别下发处理待处理对象的处理规则。
应用程序调度器将针对该被处理对象的第一处理规则通过该第一端口发送至该第一服务；
应用程序调度器将针对该被处理对象的第二处理规则通过该第二端口发送至该第二服务。
S830，第一容器启动的第一服务根据第一处理规则处理待处理对象；
第二容器启动的第二服务根据第二处理规则处理待处理对象。
S840，第一容器和第二容器协商处理进度。
第一容器启动的第一服务通过访问pause容器中的管理进程，获取第二端口与该第二服务的第一对应关系，第一服务通过该第二端口确定该第二服务处理该被处理对象的进度；
第二容器启动的第二服务通过访问pause容器中的管理进程，获取第一端口与该第一服务的第二对应关系，第二服务通过该第一端口确定该第一服务处理该被处理对象的进度。
S850，通知应用程序调度器处理结束。
第一容器启动的第一服务在处理待处理对象结束之后，向应用程序调度器发送指示信息，指示应用执行完成；
第二容器启动的第二服务在处理待处理对象结束之后，向应用程序调度器发送指示信息，指示应用执行完成。
图5-图8主要介绍本申请提供的容器的服务调度方法流程。下面结合具体的实施例详细介绍本申请实施例提供的容器的服务调度方法的具体实现。
图9是本申请提供的一种具体实施例示意图。包括应用程序调度器、至少一个容器组以及每个容器组中包括至少两个容器。
应用程序调度器：负责调度各个容器组间的协作，以及单个容器组内各个容器的协作。
首先，应用程序调度器调度至少一个容器组，处理同一个待处理对象。并将待处理对象按照预设规则分配给建立好的至少一个容器组内。则，每个容器组需要运行相同的应用程序处理待处理对象。
其中，预设的规则可以是均匀分配给建立好的至少一个容器组内，也可以是非均匀地分配给建立好的至少一个容器组内，本申请实施例对此并不限制。
例如，上述待处理对象为一百万张照片的人脸匹配，应用程序调度器调度100个容器组处理该一百万张照片的人脸匹配，每个容器组处理一万张照片的人脸匹配。则，该100个容器组中的多个容器需要运行相同的应用程序处理人脸匹配。
可选地，在每个容器组内建立两个容器，如图9所示的第一容器和第二容器。
可选地，应用程序调度器下发处理待处理对象的处理规则给第一容器和第二容器。
应理解，图9中的第一容器和第二容器内的glibc库中的，bind函数嵌入上述的代码，能够在运行该应用程序的时候，判断该应用程序绑定的端口是否被占用。当端口被占用的时候调度未被占用的端口运行该应用程序。
还应理解，图9中的第三容器的管理服务，用于远程在第一容器和第二容器上执行glibc库替换。
第三容器的管理服务可以为Kubernetes中的暂停容器的remembe。
例如，上述应用程序绑定的端口为80端口。
启动第一容器，该第一容器在该第一容器启动时运行该应用程序，该应用程序通过bind函数占用该容器组提供的80端口。
因为第一容器早于第二容器运行该应用程序，所以第一容器运行该应用程序能够成功占用80端口。
可选地，第一容器将应用程序占用80端口的信息上报给第三容器的管理服务。
第二容器根据该应用程序的绑定端口中请，通过bind函数绑定80端口。因为第一容器早于第二容器运行该应用程序，80端口已经被占用，所以第二容器内的bind函数自动调度未被占用的端口，变更该应用程序绑定的端口为10080端口。
可选地，第二容器将应用程序占用10080端口的信息上报给第三容器的管理服务。
经过上述端口成功绑定，pod 1中的第一容器和第二容器，均成功运行该应用程序。
可选地，应用程序调度器访问第三容器的管理服务，通过原始端口80，查询第一容器和第二容器中运行该应用程序的实际端口号。
应用程序调度器能够获取第一容器中运行该应用程序的实际端口号为原始端口80端口，而第二容器中运行该应用程序的实际端口号为10080端口。
应用程序调度器获取到第一容器和第二容器中运行该应用程序的实际端口号之后，能够通过第一容器和第二容器中运行该应用程序的实际端口号，下发运行该应用程序的规则。
应用程序调度器可以部署在容器组内或者容器组外的任意容器上。例如，当上述第一容器和第二容器中运行的应用程序，为人脸图像匹配任务时。应用程序调度器下发运行该应用程序的规则包括：对比待匹配照片与目标照片的五官特征，或比待匹配照片与目标照片的发型特征，或比待匹配照片与目标照片的发色特征，或比待匹配照片与目标照片的五官以及发型特征。
还例如，第一容器和第二容器执行人脸图像匹配任务的规则包括：第一容器和第二容器对向运行该应用程序，即，第一容器在执行人脸图像匹配任务时从前往后对比，而第二容器执行人脸图像匹配任务时从后往前对比。
具体地，当pod 1需要完成1万张待对比照片的匹配时，第一容器执行第1-5000张待对比照片的匹配；第一容器执行第10000-5001张待对比照片的匹配。
应理解，本申请实施例中对于应用程序的具体任务并不限制，上述人脸图像匹配任务只是一种举例形式。
还应理解，本申请实施例中对于运行该应用程序的规则具体并不限制，上述人脸图像匹配规则只是一种举例形式，不能限制本申请的保护范围。
可选地，在一些实施例中，在运行该应用程序的过程中第一容器和第二容器协商运行该应用程序进度。
具体地，第二容器访问第三容器的管理服务，获取第一容器运行该应用程序的实际端口号为原始端口80端口；
同理，第一容器访问第三容器的管理服务，获取第二容器运行该应用程序的实际端口号为10080端口。
在第一容器和第二容器获取对方运行该应用程序的实际端口号之后，能够访问对方运行该应用程序的进度。
例如，当上述第一容器和第二容器中运行的应用程序，为人脸图像匹配任务时。第一容器执行完100张(第1-100张)待对比照片的匹配之后，访问第二容器的执行人脸图像匹配任务的进度，并判断第二容器是否已经完成人脸图像匹配任务。
如果，第二容器已经完成人脸图像匹配任务，则第一容器停止执行人脸图像匹配任务，并上报已停止执行任务的信息给应用程序调度器。
如果，第二容器未完成人脸图像匹配任务，则第一容器再执行100张(第101-201张)待对比照片的匹配，再去访问第二容器的执行人脸图像匹配任务的进度，并判断第二容器是否已经完成人脸图像匹配任务。
如此循环，直至pod 1中的人脸图像匹配任务完成。
应理解，上述所示的第一容器访问第二容器的过程，第二容器也能够同样访问第一容器的执行人脸图像匹配任务的进度，过程与上述的类似，这里不再赘述。
上面结合图5-图9介绍了本申请实施例提供的容器的服务调度方法，下面结合图10-图12详细介绍本申请实施例提供容器的调度装置、管理装置以及数据中心。
图10是一种容器的调度装置示意图。该调度服务可以部署在容器组中的容器上，例如部署在容器系统100的调度节点110的容器上，用于创建容器以运行应用程序，且为容器组中运行应用程序的容器提供端口调度装置。该调度装置包括创建单元1120和启动单元1110；
创建单元1120，用于创建容器组，该容器组包括第一容器和第二容器；
启动单元1110，用于启动该第一容器，其中，该第一容器的第一服务在该第一容器启动时启动，该第一服务占用该容器组提供的第一端口；
启动该第二容器，其中，该第二容器的第二服务在该第二容器启动时启动，且该第二容器内设置有端口替换脚本，该端口替换脚本用于将该第一端口替换为该容器组提供的第二端口，该第二服务在检测到该第一端口被占用时根据该端口替换脚本占用该第二端口。
具体地，该创建单元1120，还用于创建该第三容器；
该启动单元1110，还用于启动该第三容器，其中该第三容器的管理服务在该第三容器启动时启动，该第三容器的管理服务用于记录该第二服务在检测到该第一端口被占用时该第二服务发送的该第二端口与该第二服务的第一对应关系。
其中，该第三容器的管理服务还用于向该第二容器发送包含该端口替换脚本的调度信息，该调度信息用于指示在该第二容器中设置该端口替换脚本。
进一步地，该第三容器的管理服务还用于记录该第一服务发送的该第一端口与该第一服务的第二对应关系，且在收到对应端口查询请求时，根据该第一对应关系或者该第二对应关系返回查询结果。
图11是一种管理装置示意图。该管理装置可以部署在容器组中的容器上，例如，该管理装置可设置在容器组中的第三容器上，以提供前述在第三容器上启动的管理服务的功能。该容器组还包括第一容器和第二容器，该第一服务占用该容器组提供的第一端口，该第二容器包括第二服务。例如部署在容器系统100的容器组121中的容器上，用于为容器组112中运行应用程序的容器提供端口调度服务。
该管理服务包括调度单元1220，该调度单元1220，用于向该第二容器发送包含端口替换脚本的调度信息，该端口替换脚本用于将该第一端口替换为第二端口，该调度信息用于指示在该第二容器中设置该端口替换脚本，以使该第二服务在检测到该第一端口被占用时根据该端口替换脚本占用该容器组提供的该第二端口。
具体地，该管理装置还包括记录单元1210，
该记录单元1210，用于记录该第二服务在检测到该第一端口被占用时该第二服务发送的该第二端口与该第二服务的第一对应关系。
记录单元1210，还用于记录该第一服务发送的该第一端口与该第一服务的第二对应关系，以使该第二服务接收包含该第一端口的端口绑定申请后，查询该管理装置中的该第二对应关系，检测该第一端口是否被占用。
进一步地，该容器组还包含被处理对象；
该记录单元1210，还用于记录该第二服务发送的该第二端口与该第二服务的第一对应关系，以使该第一服务通过该第一端口接收针对该被处理对象的第一处理规则、通过该第二端口确定该第二服务处理该被处理对象的进度，该第二服务通过该第二端口接收针对该被处理对象的第二处理规则。
图12是一种数据中心中的物理服务器1300的示意图。前文中所述的容器系统可以部署在数据中心中的至少一个物理服务器1300上。物理服务器1300可以包括处理单元1301和通信接口1302，处理单元1301用于执行物理服务器上运行的操作系统以及各种软件程序所定义的功能，例如，容器系统的服务节点、调度节点及服务节点和调度节点上部署的容器、容器组和服务，也包括图10中的调度装置和图11中的管理装置。通信接口1302用于与其他计算节点进行通信交互，其他设备可以是其它物理服务器，具体地，通信接口1302可以是网络适配卡。可选地，该物理服务器还可以包括输入/输出接口1303，输入/输出接口1303连接有输入/输出设备，用于接收输入的信息，输出操作结果。输入/输出接口1303可以为鼠标、键盘、显示器、或者光驱等。可选地，该物理服务器还可以包括辅助存储器1304，一般也称为外存，辅助存储器1304的存储介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如光盘)、或者半导体介质(例如固态硬盘)等。处理单元1301可以有多种具体实现形式，例如处理单元1301可以包括处理器13011和内存13012，处理器13011根据内存13012中存储的程序单元执行相关的操作，处理器13011可以为中央处理器(CPU)或图像处理器(英文：graphics processing unit，GPU)，处理器13011可以是单核处理器或多核处理器。处理单元1301也可以单独采用内置处理逻辑的逻辑器件来实现，例如现场可编程门阵列(英文全称：Field Programmable Gate Array，缩写：FPGA)或数字信号处理器(英文：digitalsignal processor，DSP)等。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的数据中心、容器的调度装置、管理装置和方法，可以通过其它的方式实现。例如，以上所描述的容器的调度装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。
Claims (19)
1.一种容器的服务调度方法，其特征在于，所述方法包括：
创建容器组，所述容器组包括第一容器和第二容器；
启动所述第一容器，其中，所述第一容器的第一服务在所述第一容器启动时启动，所述第一服务占用所述容器组提供的第一端口；
启动所述第二容器，其中，所述第二容器的第二服务在所述第二容器启动时启动，且所述第二容器内设置有端口替换脚本，所述端口替换脚本用于将所述第一端口替换为所述容器组提供的第二端口，所述第二服务在检测到所述第一端口被占用时根据所述端口替换脚本占用所述第二端口。
2.根据权利要求1所述的方法，其特征在于，所述容器组还包括第三容器，所述创建容器组后，所述方法还包括：
启动所述第三容器，其中所述第三容器的管理服务在所述第三容器启动时启动，所述第三容器的管理服务用于记录所述第二服务在检测到所述第一端口被占用时所述第二服务发送的所述第二端口与所述第二服务的第一对应关系。
3.根据权利要求2所述的方法，其特征在于，所述第二容器内设置的所述端口替换脚本由所述第三容器发送至所述第二容器。
4.根据权利要求2或3所述的方法，其特征在于，所述第三容器的管理服务还用于记录所述第一服务发送的所述第一端口与所述第一服务的第二对应关系，所述第二服务在检测到所述第一端口被占用时根据所述端口替换脚本占用所述第二端口，具体包括：
所述第二服务接收包含所述第一端口的端口绑定申请，查询所述第三容器的管理服务中的所述第二对应关系，检测到所述第一端口被占用，根据所述端口替换脚本占用所述第二端口；
或者，
所述第二服务根据接收的所述端口绑定申请，绑定所述第一端口失败，根据所述端口替换脚本占用所述第二端口。
5.根据权利要求1-4中任一所述的方法，其特征在于，所述容器组还包括被处理对象，所述方法还包括：
所述第二服务通过所述第一端口确定所述第一服务处理所述被处理对象的进度。
6.一种容器的服务调度方法，其特征在于，所述方法应用于第三容器，所述第三容器设置于容器组，所述容器组还包括第一容器和第二容器，所述第一容器包括第一服务，所述第一服务占用所述容器组提供的第一端口，所述第二容器包括第二服务；
所述方法包括：
向所述第二容器发送包含端口替换脚本的调度信息，所述端口替换脚本用于将所述第一端口替换为第二端口，所述调度信息用于指示在所述第二容器中设置所述端口替换脚本，以使所述第二服务在检测到所述第一端口被占用时根据所述端口替换脚本占用所述容器组提供的所述第二端口。
7.根据权利要求6所述的方法，其特征在于，所述方法还包括：
记录所述第二服务在检测到所述第一端口被占用时所述第二服务发送的所述第二端口与所述第二服务的第一对应关系。
8.根据权利要求6或7所述的方法，其特征在于，所述方法还包括：
记录所述第一服务发送的所述第一端口与所述第一服务的第二对应关系，以使所述第二服务接收包含所述第一端口的端口绑定申请后，查询所述管理服务中的所述第二对应关系，检测所述第一端口是否被占用。
9.根据权利要求6-8中任一项所述的方法，其特征在于，所述容器组还包含被处理对象，所述方法还包括：
记录所述第二服务发送的所述第二端口与所述第二服务的第一对应关系，以使所述第一服务通过所述第二端口确定所述第二服务处理所述被处理对象的进度。
10.一种容器的调度装置，其特征在于，所述调度装置包括创建单元和启动单元；
所述创建单元用于：创建容器组，所述容器组包括第一容器和第二容器；
所述启动单元用于：
启动所述第一容器，其中，所述第一容器的第一服务在所述第一容器启动时启动，所述第一服务占用所述容器组提供的第一端口；
启动所述第二容器，其中，所述第二容器的第二服务在所述第二容器启动时启动，且所述第二容器内设置有端口替换脚本，所述端口替换脚本用于将所述第一端口替换为所述容器组提供的第二端口，所述第二服务在检测到所述第一端口被占用时根据所述端口替换脚本占用所述第二端口。
11.根据权利要求10所述的调度装置，其特征在于，
所述创建单元还用于：创建所述第三容器；
所述启动单元还用于：启动所述第三容器，其中所述第三容器的管理服务在所述第三容器启动时启动，所述第三容器的管理服务用于记录所述第二服务在检测到所述第一端口被占用时所述第二服务发送的所述第二端口与所述第二服务的第一对应关系。
12.根据权利要求11所述的调度装置，其特征在于，所述第三容器的管理服务还用于向所述第二容器发送包含所述端口替换脚本的调度信息，所述调度信息用于指示在所述第二容器中设置所述端口替换脚本。
13.根据权利要求11或12所述的调度装置，其特征在于，所述第三容器的管理服务还用于记录所述第一服务发送的所述第一端口与所述第一服务的第二对应关系，且在收到对应端口查询请求时，根据所述第一对应关系或者所述第二对应关系返回查询结果。
14.一种管理装置，其特征在于，所述管理装置设置在第三容器上，所述第三容器设置于容器组，所述容器组还包括第一容器和第二容器，所述第一服务占用所述容器组提供的第一端口，所述第二容器包括第二服务；所述管理设备包括调度单元，所述调度单元用于：
向所述第二容器发送包含端口替换脚本的调度信息，所述端口替换脚本用于将所述第一端口替换为第二端口，所述调度信息用于指示在所述第二容器中设置所述端口替换脚本，以使所述第二服务在检测到所述第一端口被占用时根据所述端口替换脚本占用所述容器组提供的所述第二端口。
15.根据权利要求14所述的管理装置，其特征在于，还包括记录单元，所述记录单元用于：
记录所述第二服务在检测到所述第一端口被占用时所述第二服务发送的所述第二端口与所述第二服务的第一对应关系。
16.根据权利15中所述的管理装置，其特征在于，所述记录单元还用于：记录所述第一服务发送的所述第一端口与所述第一服务的第二对应关系，以使所述第二服务接收包含所述第一端口的端口绑定申请后，查询所述管理装置中的所述第二对应关系，检测所述第一端口是否被占用。
17.根据权利16中所述的管理装置，其特征在于，所述容器组还包含被处理对象；所述记录单元还用于：记录所述第二服务发送的所述第二端口与所述第二服务的第一对应关系，以使所述第一服务通过所述第一端口接收针对所述被处理对象的第一处理规则、通过所述第二端口确定所述第二服务处理所述被处理对象的进度，所述第二服务通过所述第二端口接收针对所述被处理对象的第二处理规则。
18.一种计算设备，其特征在于，所述计算设备包括：
存储单元，用于存储指令；以及
至少一台处理器，与所述存储单元耦合；
其中，当所述至少一台处理器执行所述指令时，所述指令致使所述处理器执行权利要求1-5中任一项所述的方法。
19.一种计算设备，其特征在于，所述计算设备包括：
存储单元，用于存储指令；以及
至少一台处理器，与所述存储单元耦合；
其中，当所述至少一台处理器执行所述指令时，所述指令致使所述处理器执行权利要求6-9中任一项所述的方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810895010.4A CN109032806B (zh) | 2018-07-30 | 2018-07-30 | 容器的服务调度方法和装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810895010.4A CN109032806B (zh) | 2018-07-30 | 2018-07-30 | 容器的服务调度方法和装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109032806A true CN109032806A (zh) | 2018-12-18 |
| CN109032806B CN109032806B (zh) | 2021-05-14 |
Family
ID=64649961
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810895010.4A Active CN109032806B (zh) | 2018-07-30 | 2018-07-30 | 容器的服务调度方法和装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109032806B (zh) |
Cited By (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109617995A (zh) * | 2018-12-29 | 2019-04-12 | 北京金山云网络技术有限公司 | 对租户集群vpc内部容器的管理系统、方法及电子设备 |
| CN110266679A (zh) * | 2019-06-14 | 2019-09-20 | 腾讯科技(成都)有限公司 | 容器网络隔离方法及装置 |
| CN110647332A (zh) * | 2019-09-30 | 2020-01-03 | 北京百度网讯科技有限公司 | 基于容器云的软件部署方法和装置 |
| CN111078356A (zh) * | 2019-11-22 | 2020-04-28 | 北京达佳互联信息技术有限公司 | Gpu集群资源控制系统、方法、装置、设备及存储介质 |
| CN111177160A (zh) * | 2019-11-06 | 2020-05-19 | 腾讯云计算（北京）有限责任公司 | 服务更新方法、装置、服务器及介质 |
| CN111176788A (zh) * | 2019-12-24 | 2020-05-19 | 优刻得科技股份有限公司 | Kubernetes集群的主节点的部署方法及系统 |
| WO2020155987A1 (zh) * | 2019-02-01 | 2020-08-06 | 华为技术有限公司 | 一种网络功能虚拟化nfv架构的调度管理方法及装置 |
| CN111835684A (zh) * | 2019-04-19 | 2020-10-27 | 厦门网宿有限公司 | 一种haproxy设备的网络隔离监控方法及系统 |
| CN111835544A (zh) * | 2019-04-19 | 2020-10-27 | 厦门网宿有限公司 | 一种基于用户态协议栈的虚拟路由器的监控方法及系统 |
| CN112511611A (zh) * | 2020-11-19 | 2021-03-16 | 腾讯科技（深圳）有限公司 | 节点集群的通信方法、装置、系统及电子设备 |
| CN112839239A (zh) * | 2020-12-30 | 2021-05-25 | 广州虎牙科技有限公司 | 一种音视频加工的方法、装置及服务器 |
| CN113268337A (zh) * | 2021-07-20 | 2021-08-17 | 杭州朗澈科技有限公司 | Kubernetes集群中Pod调度的方法和系统 |
| CN113364821A (zh) * | 2020-03-04 | 2021-09-07 | 腾讯科技（深圳）有限公司 | 一种功能服务访问方法、设备及存储介质 |
| CN115174644A (zh) * | 2022-06-28 | 2022-10-11 | 武汉烽火技术服务有限公司 | 容器集群服务启停控制方法、装置、设备及存储介质 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106301889A (zh) * | 2016-07-28 | 2017-01-04 | Tcl移动通信科技（宁波）有限公司 | 一种端口号快速设置方法及系统 |
| CN106445585A (zh) * | 2016-08-30 | 2017-02-22 | 中国民生银行股份有限公司 | 基于容器技术的应用部署方法和系统 |
| CN107315605A (zh) * | 2017-06-14 | 2017-11-03 | 上海青橙实业有限公司 | Jack Server端口动态匹配的方法和装置 |
| CN108287723A (zh) * | 2016-12-30 | 2018-07-17 | 华为技术有限公司 | 一种应用交互方法、装置、物理机及系统 |
-
2018
- 2018-07-30 CN CN201810895010.4A patent/CN109032806B/zh active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106301889A (zh) * | 2016-07-28 | 2017-01-04 | Tcl移动通信科技（宁波）有限公司 | 一种端口号快速设置方法及系统 |
| CN106445585A (zh) * | 2016-08-30 | 2017-02-22 | 中国民生银行股份有限公司 | 基于容器技术的应用部署方法和系统 |
| CN108287723A (zh) * | 2016-12-30 | 2018-07-17 | 华为技术有限公司 | 一种应用交互方法、装置、物理机及系统 |
| CN107315605A (zh) * | 2017-06-14 | 2017-11-03 | 上海青橙实业有限公司 | Jack Server端口动态匹配的方法和装置 |
Non-Patent Citations (1)
| Title |
|---|
| JONY456123: "k8spodrc与service实践", 《HTTPS://WWW.JIANSHU.COM/P/E83D7964D41F简书》 * |
Cited By (24)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109617995A (zh) * | 2018-12-29 | 2019-04-12 | 北京金山云网络技术有限公司 | 对租户集群vpc内部容器的管理系统、方法及电子设备 |
| CN109617995B (zh) * | 2018-12-29 | 2022-02-25 | 北京金山云网络技术有限公司 | 对租户集群vpc内部容器的管理系统、方法及电子设备 |
| WO2020155987A1 (zh) * | 2019-02-01 | 2020-08-06 | 华为技术有限公司 | 一种网络功能虚拟化nfv架构的调度管理方法及装置 |
| CN111526168B (zh) * | 2019-02-01 | 2021-09-07 | 华为技术有限公司 | 一种网络功能虚拟化nfv架构的调度管理方法及装置 |
| CN111526168A (zh) * | 2019-02-01 | 2020-08-11 | 华为技术有限公司 | 一种网络功能虚拟化nfv架构的调度管理方法及装置 |
| CN111835684B (zh) * | 2019-04-19 | 2023-01-20 | 厦门网宿有限公司 | 一种haproxy设备的网络隔离监控方法及系统 |
| CN111835684A (zh) * | 2019-04-19 | 2020-10-27 | 厦门网宿有限公司 | 一种haproxy设备的网络隔离监控方法及系统 |
| CN111835544A (zh) * | 2019-04-19 | 2020-10-27 | 厦门网宿有限公司 | 一种基于用户态协议栈的虚拟路由器的监控方法及系统 |
| CN111835544B (zh) * | 2019-04-19 | 2022-10-25 | 厦门网宿有限公司 | 一种基于用户态协议栈的虚拟路由器的监控方法及系统 |
| CN110266679B (zh) * | 2019-06-14 | 2023-02-28 | 腾讯科技(成都)有限公司 | 容器网络隔离方法及装置 |
| CN110266679A (zh) * | 2019-06-14 | 2019-09-20 | 腾讯科技(成都)有限公司 | 容器网络隔离方法及装置 |
| CN110647332A (zh) * | 2019-09-30 | 2020-01-03 | 北京百度网讯科技有限公司 | 基于容器云的软件部署方法和装置 |
| CN111177160A (zh) * | 2019-11-06 | 2020-05-19 | 腾讯云计算（北京）有限责任公司 | 服务更新方法、装置、服务器及介质 |
| CN111177160B (zh) * | 2019-11-06 | 2023-08-04 | 腾讯云计算（北京）有限责任公司 | 服务更新方法、装置、服务器及介质 |
| CN111078356A (zh) * | 2019-11-22 | 2020-04-28 | 北京达佳互联信息技术有限公司 | Gpu集群资源控制系统、方法、装置、设备及存储介质 |
| CN111176788A (zh) * | 2019-12-24 | 2020-05-19 | 优刻得科技股份有限公司 | Kubernetes集群的主节点的部署方法及系统 |
| CN111176788B (zh) * | 2019-12-24 | 2023-08-25 | 优刻得科技股份有限公司 | Kubernetes集群的主节点的部署方法及系统 |
| CN113364821A (zh) * | 2020-03-04 | 2021-09-07 | 腾讯科技（深圳）有限公司 | 一种功能服务访问方法、设备及存储介质 |
| CN113364821B (zh) * | 2020-03-04 | 2024-03-05 | 腾讯科技（深圳）有限公司 | 一种功能服务访问方法、设备及存储介质 |
| CN112511611A (zh) * | 2020-11-19 | 2021-03-16 | 腾讯科技（深圳）有限公司 | 节点集群的通信方法、装置、系统及电子设备 |
| CN112839239A (zh) * | 2020-12-30 | 2021-05-25 | 广州虎牙科技有限公司 | 一种音视频加工的方法、装置及服务器 |
| CN113268337A (zh) * | 2021-07-20 | 2021-08-17 | 杭州朗澈科技有限公司 | Kubernetes集群中Pod调度的方法和系统 |
| CN115174644A (zh) * | 2022-06-28 | 2022-10-11 | 武汉烽火技术服务有限公司 | 容器集群服务启停控制方法、装置、设备及存储介质 |
| CN115174644B (zh) * | 2022-06-28 | 2023-09-12 | 武汉烽火技术服务有限公司 | 容器集群服务启停控制方法、装置、设备及存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109032806B (zh) | 2021-05-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109032806A (zh) | 容器的服务调度方法和装置 | |
| US10701139B2 (en) | Life cycle management method and apparatus | |
| WO2019184967A1 (zh) | 一种网络切片的部署方法及装置 | |
| WO2019233273A1 (zh) | 管理容器服务的方法和装置 | |
| US11947697B2 (en) | Method and system to place resources in a known state to be used in a composed information handling system | |
| CN106790660B (zh) | 一种实现分布式存储系统的部署方法及装置 | |
| US10397132B2 (en) | System and method for granting virtualized network function life cycle management | |
| CN111542064A (zh) | 一种用于无线接入网的容器编排管理系统及编排方法 | |
| CN108255497A (zh) | 一种应用的部署方法及装置 | |
| CN110032413A (zh) | 一种桌面虚拟化方法、相关设备及计算机存储介质 | |
| WO2020103925A1 (zh) | 一种容器化虚拟网络功能的部署方法和装置 | |
| CN105323282A (zh) | 一种面向多租户的企业应用部署与管理系统 | |
| US9584440B1 (en) | Real-time distributed tree | |
| US9804882B2 (en) | Configuration manager and method for configuring a host system for processing a processing job in a virtual data-processing environment | |
| CN112637304B (zh) | 一种跨云资源处理系统和资源管理方法 | |
| CN111835679B (zh) | 多租户场景下的租户资源管理方法和装置 | |
| CN108400898A (zh) | 云数据管理平台中资源的管理方法和装置 | |
| JP7377965B2 (ja) | ネットワークリソース管理方法、システム、ネットワーク機器と可読記憶媒体 | |
| CN102611754A (zh) | 一种基于iSCSI的云存储中客户端管理方法 | |
| CN107305505A (zh) | 虚拟化平台的运行方法及虚拟化平台 | |
| WO2019001140A1 (zh) | 一种管理vnf实例化的方法和设备 | |
| CN104283910A (zh) | 云计算环境下的资源管理系统 | |
| JP2024501005A (ja) | コンテナクラスタのための管理方法および装置 | |
| CN116346963A (zh) | 网络通信方法、设备、介质和程序产品 | |
| CN107967165B (zh) | 基于lvm的虚拟机离线迁移方法 |
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 | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20220207 Address after: 550025 Huawei cloud data center, jiaoxinggong Road, Qianzhong Avenue, Gui'an New District, Guiyang City, Guizhou Province Patentee after: Huawei Cloud Computing Technologies Co.,Ltd. Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen Patentee before: HUAWEI TECHNOLOGIES Co.,Ltd. |
|
| TR01 | Transfer of patent right |