CN117453380B - 集群的容器组调度方法、系统以及计算机设备 - Google Patents

集群的容器组调度方法、系统以及计算机设备 Download PDF

Info

Publication number
CN117453380B
CN117453380B CN202311791135.XA CN202311791135A CN117453380B CN 117453380 B CN117453380 B CN 117453380B CN 202311791135 A CN202311791135 A CN 202311791135A CN 117453380 B CN117453380 B CN 117453380B
Authority
CN
China
Prior art keywords
service
node
target service
target
information
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.)
Active
Application number
CN202311791135.XA
Other languages
English (en)
Other versions
CN117453380A (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.)
Alibaba Cloud Computing Ltd
Original Assignee
Alibaba Cloud Computing 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 Alibaba Cloud Computing Ltd filed Critical Alibaba Cloud Computing Ltd
Priority to CN202311791135.XA priority Critical patent/CN117453380B/zh
Publication of CN117453380A publication Critical patent/CN117453380A/zh
Application granted granted Critical
Publication of CN117453380B publication Critical patent/CN117453380B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • 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
    • 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
    • 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/45562—Creating, deleting, cloning virtual machine instances
    • 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

Abstract

本申请提供了一种集群的容器组调度方法、系统以及计算机设备，其中，该方法包括：接收针对目标服务的访问请求；在确定所述目标服务不是已访问服务的情况下，基于所述访问请求从服务节点获取所述目标服务的转发信息；其中，所述已访问服务用于指示非首次向所述工作节点请求访问的服务，和/或，历史时刻向所述工作节点请求访问的服务中未超过有效时间的服务；基于获取到的所述目标服务的转发信息确定所述目标服务对应的服务容器组，并向所述服务容器组发送所述访问请求。

Description

集群的容器组调度方法、系统以及计算机设备
技术领域
本申请涉及计算机的技术领域，具体而言，涉及一种集群的容器组调度方法、系统以及计算机设备。
背景技术
Kubernetes（简称K8s），是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效，Kubernetes提供了应用部署，规划，更新，维护的一种机制。
相关技术中，Kubernetes集群中的工作节点可以自动发现K8s集群中的服务，并在工作节点上添加到集群中服务的转发配置。针对工作节点中Pod所需要使用的每个服务的转发配置，以及不需要使用服务的转发配置，工作节点均会在本地配置上述转发配置。如果集群中的工作节点和服务较多，就会导致工作节点上存储大量的转发配置，从而增大对K8s集群中kube-apiserver的压力，进而影响K8s集群的稳定性。
发明内容
本申请实施例至少提供一种集群的容器组调度方法、系统以及计算机设备。
第一方面，本申请实施例提供了一种集群的容器组调度方法，所述集群包括工作节点和服务节点，所述工作节点中包含至少一个容器组，所述服务节点用于存储所述工作节点中容器组所使用服务的转发信息，所述方法应用于工作节点，包括：
接收针对目标服务的访问请求；
在确定所述目标服务不是已访问服务的情况下，基于所述访问请求从服务节点获取所述目标服务的转发信息；其中，所述已访问服务用于指示非首次向所述工作节点请求访问的服务，和/或，历史时刻向所述工作节点请求访问的服务中未超过有效时间的服务；
基于获取到的所述目标服务的转发信息确定所述目标服务对应的服务容器组，并向所述服务容器组发送所述访问请求。
一种可选的实施方式中，所述确定所述目标服务不是已访问服务，包括：
获取预先设置的服务拦截规则；其中，所述服务拦截规则用于拦截需要从所述服务节点获取转发信息的服务；
在确定所述目标服务与所述服务拦截规则相匹配的情况下，确定所述目标服务不是已访问服务。
一种可选的实施方式中，所述确定所述目标服务与所述服务拦截规则相匹配，包括：
获取目标服务列表；其中，所述目标服务列表包括对所述集群内已访问服务的服务标识信息；
在确定所述目标服务列表中不包含所述目标服务的服务标识信息的情况下，确定所述目标服务与所述服务拦截规则相匹配。
一种可选的实施方式中，所述方法还包括：
在确定所述目标服务不是已访问服务的情况下，在所述目标服务列表中添加所述目标服务的服务标识信息。
一种可选的实施方式中，所述方法还包括：
在基于所述访问请求从服务节点获取所述目标服务的转发信息之后，在本地存储空间存储所述目标服务的转发信息；
检测所述目标服务的转发信息的变更信息；其中，所述变更信息用于指示所述目标服务所对应的服务容器组的地址变更信息；
基于所述检测到的变更信息更新所述本地存储空间中所述目标服务的转发信息。
一种可选的实施方式中，所述方法还包括：
在确定所述目标服务不是已访问服务的情况下，获取所述目标服务的服务使用信息；其中，所述服务使用信息用于指示所述目标服务的最近使用时间；
向所述服务节点发送所述服务使用信息；其中，所述服务节点用于基于所述服务使用信息对所述目标服务的生存状态进行管理。
一种可选的实施方式中，所述方法还包括：
在向所述服务节点发送所述服务使用信息之后，获取所述服务节点所管理的服务中检测所述最近使用时间和当前时间之间的时间间隔超过有效时间的失效服务的服务信息；
基于所述服务信息，在本地存储空间中删除所述失效服务的转发信息。
一种可选的实施方式中，所述方法还包括：
在确定所述目标服务是所述已访问服务的情况下，在本地存储空间中查找所述目标服务的转发信息，并执行基于获取到的所述目标服务的转发信息确定所述目标服务对应的服务容器组，并向所述服务容器组发送所述访问请求的步骤。
第二方面，本申请实施例提供了一种集群的容器组调度方法，所述集群包括工作节点和服务节点，所述工作节点中包含至少一个容器组，所述服务节点用于存储所述工作节点中容器组所使用服务的转发信息，所述方法应用于服务节点，包括：
接收工作节点发送的获取请求；其中，所述获取请求为所述工作节点在确定出所请求访问的目标服务不是已访问服务的情况下发送的获取所述目标服务的转发信息的请求；
基于所述获取请求查找所述目标服务的转发信息；
在查找到所述转发信息的情况下，向所述工作节点发送所述目标服务的转发信息。
一种可选的实施方式中，所述方法还包括：
获取所述工作节点发送的所述已访问服务的服务使用信息；其中，所述服务使用信息用于指示工作负载对所述已访问服务的最近使用时间；
基于所述已访问服务的服务使用信息，确定所述已访问服务的生存状态。
一种可选的实施方式中，所述基于所述标服务的服务使用信息，确定所述目标服务的生存状态，包括：
确定当前时刻和所述服务使用信息之间的时间间隔；
在确定所述时间间隔超过所述已访问服务的有效时间的情况下，确定所述已访问服务的生存状态为异常生存状态。
一种可选的实施方式中，所述方法还包括：
接收所述工作节点的检测请求；其中，所述检测请求用于请求检测所述最近使用时间和当前时间之间的时间间隔超过有效时间的失效服务；
基于所述检测请求，查找所述失效服务，并向所述工作节点反馈查找到的所述失效服务的服务标识信息。
第三方面，本申请实施例提供了一种集群的容器组调度系统，包括：工作节点和服务节点；
所述工作节点，被配置成接收针对目标服务的访问请求；在确定所述目标服务不是已监听服务的情况下，向所述服务节点发送获取请求；以及基于获取到的所述目标服务的转发信息确定所述目标服务对应的服务容器组，并向所述服务容器组发送所述访问请求；其中，所述获取请求用于请求所述目标服务的转发信息的信息；
所述服务节点，被配置成接收所述获取请求，并基于所述获取请求查找所述目标服务的转发信息；在查找到所述转发信息的情况下，向所述工作节点发送所述目标服务的转发信息。
第四方面，本申请实施例还提供一种计算机设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当计算机设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行上述第一方面，或第一方面中任一种可能的实施方式中的步骤。
第五方面，本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述第一方面，或第一方面中任一种可能的实施方式中的步骤。
为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，此处的附图被并入说明书中并构成本说明书中的一部分，这些附图示出了符合本申请的实施例，并与说明书一起用于说明本申请的技术方案。应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
图1示出了本申请实施例所提供的一种集群的容器组调度方法的流程图；
图2示出了本申请实施例所提供的第二种集群的容器组调度方法的流程图；
图3示出了本申请实施例所提供的第三种集群的容器组调度方法的流程图；
图4示出了本申请实施例所提供的一种工作节点和服务节点之间的交互流程图；
图5示出了本申请实施例所提供的一种集群的容器组调度系统的示意图；
图6示出了本申请实施例所提供的另一种集群的容器组调度系统的示意图；
图7示出了本申请实施例所提供的一种集群的容器组调度装置的示意图；
图8示出了本申请实施例所提供的另一种集群的容器组调度装置的示意图；
图9示出了本申请实施例所提供的一种计算机设备的示意图；
图10示出了本申请实施例所提供的一种计算机可读存储介质的示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。
Kubernetes（简称K8s），是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效，Kubernetes提供了应用部署、规划、更新和维护的一种机制。
在Kubernetes中，容器组Pod是一种基本功能单元，一个Pod通常由一个或者多个相关的容器组成。将具有相同功能集的Pods抽象成集合，就称为服务Service。这些服务Service接受基于Kubernetes搭建的应用程序客户端访问。
kube-proxy是Kubernetes的核心组件，部署在每个Node工作节点上，它是实现Kubernetes Service的通信与负载均衡机制的重要组件；kube-proxy负责为Pod创建代理服务，从Kubernetes apiserver获取所有Service的转发配置，并根据转发配置创建代理服务，实现Service到Pod的请求路由和转发，从而实现K8s层级的虚拟转发网络。
相关技术中，Kubernetes集群中的工作节点可以自动发现K8s集群中的服务service，并在工作节点上添加到集群中服务Service的转发配置。不管工作节点中的Pod是否会使用上述Service的转发配置，工作节点都会在本地配置上述转发配置。如果集群中的工作节点和服务较多，就会导致工作节点上存储大量的转发配置，从而增大对K8s集群中kube-apiserver的压力，进而影响K8s集群的稳定性。这种效应在serverless Kubernete中更是明显，serverless kubernetes kube-proxy是部署在Pod中的，一个虚拟节点管理几万个Pod，就会有几万个kube-proxy到kube-apiserver上面获取Service的转发配置，对集群稳定性带来了很大的大挑战。
在相关技术中，可以通过以下实现容器组调度：
（1）、微服务方案：传统的微服务方案通过注册中心的方式管理服务的调用。微服务方案需要用户感知，现有网络平台无法自动化的对用户透明上述操作，从而增加了维护应用的负担。
（2）、kube-apiserver扩容或者加一层cache：Kubernetes场景下可以给kube-apiserver扩容，或者kube-apiserver增加缓存。这种方案没有降低集群管理的资源成本，还额外增加了资源。同时，如果集群规模比较大，集群里有很多Service，那么转发配置（endpoints）更新的时候kube-proxy会占用很多资源，通过kube-apiserver扩容的方式也无法解决上述问题。
（3）、中心化：去掉kube-proxy，将Kubernetes集群service cidr都转换到一个中心上，通过中心化的网关统一实现代理转发的功能。这增加了集群的爆炸半径。
基于上述研究，本申请提供了一种集群的容器组调度方法、系统以及计算机设备。在本申请实施例中，首先，工作节点接收对目标服务的访问请求，并确定目标服务是否为已访问服务；其中，如果确定目标服务不是已访问服务，那么可以基于访问请求从服务节点获取目标服务的转发信息，并基于该转发信息确定目标服务对应的服务容器组，从而向服务容器组发送访问请求。
通过上述描述可知，相关技术中，针对工作节点中Pod所需要使用的每个服务，都需要在本地配置对应的转发配置，从而获得该服务的转发信息。
基于此，为了降低转发配置对K8s集群的处理压力，在本公开技术方案中，针对工作节点中Pod所需要访问使用的目标服务，可以设置在目标服务不是已访问服务的情况下，从服务节点获取所请求目标服务的转发信息。通过上述处理方式，实现设定需要从服务节点获取转发信息的服务，例如，可以设定需要从服务节点获取转发信息的服务不是针对该工作节点的已访问服务。在此基础上，针对每个目标服务，可以不需要向服务节点获取全部目标服务的转发信息，可以对需要获取转发信息的目标服务向服务节点请求转发信息，该处理方式可以降低对K8s集群中kube-apiserver的压力，提高K8s集群的稳定性。
针对以上方案所存在的缺陷，均是发明人在经过实践并仔细研究后得出的结果，因此，上述问题的发现过程以及下文中本申请针对上述问题所提出的解决方案，都应该是发明人在本申请过程中对本申请做出的贡献。
应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。
为便于对本实施例进行理解，首先对本申请实施例所公开的一种集群的容器组调度方法进行详细介绍，本申请实施例所提供的集群的容器组调度方法的执行主体一般为具有一定计算能力的计算机设备。在一些可能的实现方式中，该集群的容器组调度方法可以通过处理器调用存储器中存储的计算机可读指令的方式来实现。
下面将对本申请实施例提供的集群的容器组调度方法加以说明。
参见图1所示，为本申请实施例提供的一种集群的容器组调度方法的流程图，所述方法包括步骤S101至S103，其中：
S101：接收针对目标服务的访问请求。
通过上述描述可知，每个工作节点上可以设置多个Pod，每个Pod可以包含多个或单个容器。在每个工作节点中部署有kube-proxy，kube-proxy主要用于服务Service功能的实现。具体来说，kube-proxy可以实现K8s集群内的Pod访问服务Service，或者是集群外的主机通过NodePort等方式访问服务Service。服务Service是一组Pod的服务抽象。
这里，可以响应于Pod中的容器container对Service目标服务的访问请求，或者，响应于K8s集群外主机对Service目标服务的访问请求，确定该目标服务是否为工作节点自身的已访问服务。
这里，已访问服务可以理解为工作节点已成功拦截的Service服务。其中，工作节点可以通过检测进程检测服务的转发信息，例如，该转发信息包括namespace（命名空间）、service Name（服务名称）和endpoints（目的点）等信息。
这里，可以将非首次向工作节点请求访问的Service服务确定为已访问服务；和/或，可以将历史时刻向工作节点请求访问的Service服务中未超过有效时间的确定为已访问服务。
S102：在确定所述目标服务不是已访问服务的情况下，基于所述访问请求从服务节点获取所述目标服务的转发信息；其中，所述服务节点中存储有所述集群内已创建服务的转发信息。
工作节点在确定出该目标服务不是该工作节点自身的已访问服务的情况下，可以从服务节点获取目标服务的转发信息。
这里，服务节点又可以称为服务发现节点，该服务发现节点可以理解为K8s集群中维护K8s集群中全量Service服务的转发信息的节点。例如，该服务发现节点可以为设置有kube-apiserver进程的节点。除此之外，在本申请中，还可以在K8s集群中设置一组服务发现（Service Discovery）组件，每个组件用于维护一组Service服务的转发信息，此时，服务发现节点可以理解为设置有用于维护已创建服务的转发信息的Service Discovery组件所在节点。
这里，工作节点可以基于该访问请求向服务节点发送转发信息的获取请求，服务节点在获取到该获取请求之后，在服务节点的本地存储空间中查找该目标服务的转发信息，并向当前的工作节点返回该目标服务的转发信息。其中，目标服务的转发信息包括目标服务的namespace、service Name和endpoints；通过endpoints可以确定目标服务对应的一个或多个服务容器组。
本申请所涉及的转发信息均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。
S103：基于获取到的所述目标服务的转发信息确定所述目标服务对应的服务容器组，并向所述服务容器组发送所述访问请求。
在获取到目标服务的转发信息之后，可以基于该转发信息确定目标服务对应的一个或多个服务容器组，并在一个或多个服务容器组中确定服务容器组。例如，可以将一个或多个服务容器组中任意一个服务容器组作为服务容器组。
在本公开技术方案中，针对工作节点中Pod所需要访问使用的目标服务，可以设置在目标服务不是已访问服务的情况下，从服务节点获取所请求目标服务的转发信息。通过上述处理方式，实现设定需要从服务节点获取转发信息的服务，例如，可以设定需要从服务节点获取转发信息的服务不是针对该工作节点的已访问服务。在此基础上，针对每个目标服务，可以不需要向服务节点获取全部目标服务的转发信息，可以对需要获取转发信息的目标服务向服务节点请求转发信息，该处理方式可以降低对K8s集群中kube-apiserver的压力，提高K8s集群的稳定性。
下面将结合具体实施方式对上述步骤进行详细介绍。
通过上述描述可知，在本申请实施例中，在接收到对目标服务的访问请求之后，可以在确定出目标服务不是工作节点自身的已访问服务的情况下，基于所述访问请求从服务节点获取所述目标服务的转发信息。
如图2所示，该方法还包括如下步骤：
步骤S104：在确定所述目标服务是已访问服务的情况下，在本地存储空间中查找所述目标服务的转发信息。
在本申请实施例中，在工作节点启动时，kube-proxy并未学习到任何的服务Service。此时，该工作节点的kube-proxy可以从同角色的其他工作节点获取已经学习到的Service列表。其中，同角色的其他工作节点可以理解为与当前的工作节点对应相同类型的工作负载Workload的节点。
在获取到Service列表之后，可以将该Service列表作为自身已访问服务的目标服务列表（也即，Watch列表）。之后，工作节点可以获取Watch列表中已访问服务的转发信息，并在本地存储空间中存储该转发信息。这里，当前的工作节点还可以通过检测进程检测该Watch列表中已访问服务的转发信息的变更信息，并基于该变更信息在本地存储空间更新已访问服务的转发信息。
在确定出目标服务是该工作节点的已访问服务的情况下，可以在该工作节点的本地存储空间中查找该目标服务的转发信息，并在查找到该转发信息的情况下，执行基于获取到的所述目标服务的转发信息确定所述目标服务对应的服务容器组，并向所述服务容器组发送所述访问请求的步骤。
通过上述处理方式，针对已访问服务的访问请求，可以在本地存储空间查找转发信息；针对未访问服务的访问请求，可以向服务节点请求该服务的转发信息；通过该处理方式，可以不必向服务节点获取服务的全量转发信息，从而可以降低对K8s集群中kube-apiserver的压力，提高K8s集群的稳定性。
在一个可选的实施方式中，上述步骤S101确定所述目标服务是否为所述工作节点自身的已访问服务，具体包括如下步骤：
步骤S11：获取预先设置的服务拦截规则；其中，所述服务拦截规则用于拦截需要从所述服务节点获取转发信息的服务；
步骤S12：在确定所述目标服务与所述服务拦截规则相匹配的情况下，确定所述目标服务不是已访问服务。
在本申请实施例中，预先在每个工作节点的内核中添加了拦截功能，通过添加该拦截功能，可以实现工作节点的内核在获取到对目标服务的访问请求之后，确定目标服务是否为该工作节点的已访问服务。
在一个可选的实施方式中，可以在每个工作节点中设置服务拦截组件；当工作节点启动时，服务拦截组件ServiceIntercept启动。服务拦截组件ServiceIntercept启动后，向工作节点的内核配置Service Cidr 拦截规则。其中，Service Cidr可以理解为K8s集群中服务Service的虚拟ip网段。
在另一个可选的实施方式中，还可以通过Sidecar设计模式在工作节点中设置服务拦截功能，这里，Sidecar设计模式允许为工作节点添加许多功能，而无需额外第三方组件的配置和代码。
这里，针对所添加的拦截功能，可以获取预先设置的服务拦截规则，其中，如果确定目标服务命中该服务拦截规则，则可以确定目标服务不是已访问服务；否则，可以确定目标服务是已访问服务。
在一个可选的实施方式中，确定所述目标服务与所述服务拦截规则相匹配，包括：
获取目标服务列表；其中，所述目标服务列表包括对所述集群内已访问服务的服务标识信息；
在确定所述目标服务列表中不包含所述目标服务的服务标识信息的情况下，确定所述目标服务与所述服务拦截规则相匹配。
通过上述描述可知，在工作节点启动时，kube-proxy可以从同角色的其他工作节点获取已经学习到的Service列表，并将获取到的Service列表作为自身已访问服务的目标服务列表。
其中，该目标服务列表中包含各已访问服务的服务标识信息，比如，该服务标识信息可以为已访问服务的namespace和service Name等信息。
在本申请实施例中，在获取到该访问请求之后，可以在访问请求中解析得到目标服务的服务标识信息，例如，解析得到目标服务的namespace和service Name。之后，在Watch列表中查找目标服务的服务标识信息。如果在Watch列表中查找到目标服务的服务标识信息，则确定目标服务是该工作节点自身的已访问服务；如果在Watch列表中未查找到目标服务的服务标识信息，则确定该目标服务不是该工作节点自身的已访问服务。
通过在内核中配置拦截规则，可以实现工作节点的内核在获取到对目标服务的访问请求之后，首先确定该目标服务是否为该工作节点的已访问服务，进而实现获取实际需要的服务Service的转发信息，以降低对kube-proxy对kube-apiserver的请求压力，保证集群的运行稳定性。
在一个可选的实施方式中，本申请实施例所提供的技术方案还还包括如下步骤：
在确定所述目标服务不是已访问服务的情况下，在所述目标服务列表中添加所述目标服务的服务标识信息。
在本申请实施例中，如果确定出目标服务不是工作节点自身的已访问服务，那么可以确定Watch列表中不包含该目标服务的服务标识信息，此时，可以在Watch列表中添加该目标服务的服务标识信息，例如，可以在Watch列表中添加目标服务的namespace和service Name等信息。
如果再次接收到针对该目标服务的访问请求，就可以在Watch列表中查找到该目标服务的服务标识信息，表明该目标服务为该工作节点的已访问服务，此时，可以在工作节点的本地存储空间中查找该目标服务的转发信息，并基于查找到的所述目标服务的转发信息确定所述目标服务对应的服务容器组，并向所述服务容器组发送所述访问请求。
通过在Watch列表中添加该目标服务的服务标识信息的方式，可以实现对实际需要的服务Service进行拦截设置，从而获取所访问服务的转发信息，以降低对kube-proxy对kube-apiserver的请求压力，保证集群的运行稳定性。
在一个可选的实施方式中，本申请实施例所提供的技术方案还还包括如下步骤：
步骤S21：在基于所述访问请求从服务节点获取所述目标服务的转发信息之后，在本地存储空间存储所述目标服务的转发信息；
步骤S22：检测所述目标服务的转发信息的变更信息；其中，所述变更信息用于指示所述目标服务所对应的服务容器组的地址变更信息；
步骤S23：基于所述检测到的变更信息更新所述本地存储空间中所述目标服务的转发信息。
在本申请实施例中，如果确定出目标服务不是工作节点自身的已访问服务，那么可以确定Watch列表中不包含该目标服务的服务标识信息，以及可以确定在该工作节点的本地存储空间中并未存储该目标服务的转发信息。此时，为了再次获取到对该目标服务的访问请求时，能够快速的获取到该目标服务的转发信息，还可以在该工作节点的本地存储空间中存储该目标服务的转发信息。
这里，还可以通过检测进程检测目标服务的转发信息的变更信息，其中，变更信息可以为目标服务所对应服务容器组的地址变更信息，例如，服务容器组的迁移、新增、删除等变更信息。
在通过检测进程检测到目标服务的转发信息的变更信息之后，可以在本地存储空间中更新该转发信息。
通过上述处理方式，可以实现对实际需要的服务Service的转发信息进行记录，保证服务Service的转发信息的准确性和实时性，以提高访问请求的处理效率。
在一个可选的实施方式中，上述步骤S103基于所述访问请求从服务节点获取所述目标服务的转发信息，具体包括如下步骤：
步骤S31：对访问请求进行解析，解析得到目标服务的地址信息；
步骤S32：向所述服务节点发送携带所述地址信息的获取请求；
步骤S33：获取所述服务节点基于所述获取请求返回的所述转发信息。
在本申请实施例中，工作节点在获取到访问请求之后，可以对访问请求进行解析，从而解析得到目标服务的地址信息，例如，该地址信息可以为ClusterIP和Port等信息。
其中，Cluster IP为Service的IP地址，此为虚拟IP地址。Kubernetes集群内部的节点访问该服务时，可以通过Cluster IP获取该服务的虚拟IP地址。port是k8s集群内部访问Service的端口(Service暴露在Cluster IP上的端口)，即通过clusterIP:port可以访问到某个Service。
在解析得到地址信息之后，可以向服务节点发送携带上述地址信息的获取请求，以请求目标服务的转发信息。
服务节点在获取到该地址信息之后，可以在预先创建的关联列表中查找该地址信息，并在关联列表中查找与该地址信息相关联的转发信息，并向该工作节点返回该转发信息，其中，关联列表中用于记录每个Service的地址信息，以及与该地址信息相对应的Service的转发信息。
通过上述描述可知，在本申请实施例中，预先在每个工作节点中设置了服务拦截组件；当工作节点启动时，服务拦截组件ServiceIntercept启动。工作节点的内核在获取到访问请求之后，如果确定目标服务不是所述工作节点自身的已访问服务，那么内核可以向服务拦截组件ServiceIntercept发送该访问请求。服务拦截组件ServiceIntercept在获取到该访问请求之后，在访问请求中解析得到目标服务的ClusterIP和Port等地址信息，并向服务节点发送该ClusterIP和Port等地址信息，例如，可以向Service Discovery组件发送上述地址信息。Service Discovery组件可以根据该地址信息查找该目标服务的转发信息，并向服务拦截组件ServiceIntercept返回该转发信息。服务拦截组件ServiceIntercept可以将接收到的转发信息发送给内核，以使内核基于获取到的目标服务的转发信息确定目标服务对应的服务容器组，并向服务容器组发送所述访问请求。
在一个可选的实施方式中，本申请实施例所提供的技术方案还还包括如下步骤：
步骤S41：在确定所述目标服务不是已访问服务的情况下，获取所述目标服务的服务使用信息；其中，所述服务使用信息用于指示所述目标服务的最近使用时间；
步骤S42：向所述服务节点发送所述服务使用信息；其中，所述服务节点用于基于所述服务使用信息对所述目标服务的生存状态进行管理。
通过上述描述可知，在本申请实施例中，可以在工作节点中配置服务拦截功能，以通过该服务拦截功能发现需要拦截的服务Service；除此之外，还可以通过该服务拦截功能定期将工作节点已经学习的Service的服务（例如，目标服务）使用信息汇报给服务节点，以通过该服务节点对目标服务的生存状态进行管理。
这里，在检测到服务Service创建之后，可以通过服务节点管理该服务的转发信息，例如，可以通过kube-apiserver管理该服务的转发信息；又例如，可以通过ServiceDiscovery组件管理该服务的转发信息。
除此之外，还可以通过服务节点中的状态管理节点Service Group CR（ServiceGroup Cluster Resources），对目标服务的生存状态进行管理。其中，该生存状态包括：正常生存状态、异常生存状态。其中，正常生存状态用于指示可以维护该服务的转发信息；异常生存状态表示停止维护该服务的转发信息，以及不在检测该转发信息的变更信息。
在本申请实施例中，工作节点可以定期获取目标服务的服务使用信息，并在获取到目标服务的服务使用信息之后，可以向状态管理节点Service Group CR同步该服务使用信息，进而通过状态管理节点Service Group CR对该目标服务的服务使用信息进行管理。
这里，服务使用信息可以为最近一次请求访问目标服务的请求时间，也即，工作负载对目标服务的最近使用时间。
这里，可以为目标服务设置有效时间（TTL，Time To Live）；其中，可以为不同的目标服务设置相同的有效时间，或者，可以为不同的目标服务设置不同的有效时间，这里，对有效时间的设置不做具体限定。
状态管理节点Service Group CR，可以根据该目标服务的服务使用时间，判断该目标服务是否已经超过有效时间。如果基于该服务使用时间确定该目标服务超出有效时间，则设置该目标服务的监听状态为“异常生存状态”。这里，“异常生存状态”可以理解为不再维护该目标服务的转发信息，以及不在检测该转发信息的变更信息。
在一个可选的实施方式中，工作节点可以向服务发现节点发送服务使用信息，服务发现节点可以向状态管理节点发送所述服务使用信息。
这里，服务发现节点和状态管理节点可以为集群中的同一个节点，还可以为集群中的不同节点。
在一个可选的实施方式中，本申请实施例所提供的技术方案还还包括如下步骤：
步骤S51：在向所述服务节点发送所述服务使用信息之后，获取所述服务节点所管理的服务中检测所述最近使用时间和当前时间之间的时间间隔超过有效时间的失效服务的服务信息；
步骤S52：基于服务信息，在本地存储空间中删除所述失效服务的转发信息。
在本申请实施例中，状态管理节点可以定期检测所管理的每个服务的最近使用时间和当前时间之间的时间间隔，并确定该时间间隔是否超过该服务的有效时间。其中，如果确定该时间间隔超过该服务的有效时间，则确定该服务的生存状态为“异常生存状态”。在此情况下，可以在状态管理节点所维护的服务中删除该失效服务，或者，可以为该服务设置失效标识，以通过该失效标识该服务处于“异常生存状态”。
工作节点在向服务节点（例如，状态管理节点Service Group CR）发送所述服务使用信息之后，还可以在定期在该服务节点所管理的服务中检测失效服务，并在检测到失效服务的情况下，在本地存储空间中删除失效服务的转发信息。
这里，可以将设置有失效标识的服务确定为失效服务；还可以将状态管理节点所管理服务的服务标识信息，与工作节点中已访问服务的服务标识信息进行比较。如果比较出工作节点中的已访问服务并未包含在状态管理节点所管理的服务中，则确定该已访问服务为失效服务。
通过上述处理方式，可以删除访问频率较低的服务的转发信息，从而进一步降低对K8s集群中kube-apiserver的压力，保证集群的稳定性。
参见图3所示，为本申请实施例提供的一种集群的容器组调度方法的流程图，所述方法包括步骤S301至S303，其中：
S301：接收工作节点发送的获取请求；其中，所述获取请求为所述工作节点在确定出所请求访问的目标服务不是已访问服务的情况下发送的获取所述目标服务的转发信息的请求。
在本申请实施例中，工作节点可以响应于对Service目标服务的访问请求，确定该目标服务是否为工作节点自身的已访问服务。工作节点在确定出该目标服务不是该工作节点自身的已访问服务的情况下，可以向服务节点发送请求目标服务的转发信息的获取请求。
这里，服务节点又可以称为服务发现节点，该服务发现节点可以理解为K8s集群中维护K8s集群中全量Service服务的转发信息的节点。例如，该服务发现节点可以为设置有kube-apiserver进程的节点。除此之外，在本申请中，还可以在K8s集群中设置一组ServiceDiscovery组件，每个组件用于维护一组Service服务的转发信息，此时，服务发现节点可以理解为设置有用于维护已创建服务的转发信息的Service Discovery组件所在节点。
S302：基于所述获取请求查找所述目标服务的转发信息。
S303：在查找到所述转发信息的情况下，向所述工作节点发送所述目标服务的转发信息。
服务节点在获取到该获取请求之后，在服务节点的本地存储空间中查找该目标服务的转发信息，并向当前的工作节点返回该目标服务的转发信息。其中，目标服务的转发信息包括目标服务的namespace、service Name和endpoints；通过endpoints可以确定目标服务对应的一个或多个服务容器组。
在本公开技术方案中，针对工作节点中Pod所需要访问使用的目标服务，可以设置在目标服务不是已访问服务的情况下，从服务节点获取所请求目标服务的转发信息。通过上述处理方式，实现设定需要从服务节点获取转发信息的服务，例如，可以设定需要从服务节点获取转发信息的服务不是针对该工作节点的已访问服务。在此基础上，针对每个目标服务，可以不需要向服务节点获取全部目标服务的转发信息，可以对需要获取转发信息的目标服务向服务节点请求转发信息，该处理方式可以降低对K8s集群中kube-apiserver的压力，提高K8s集群的稳定性。
在一个可选的实施方式中，该方法还包括如下步骤：
获取所述工作节点发送的所述已访问服务的服务使用信息；其中，所述服务使用信息用于指示工作负载对所述已访问服务的最近使用时间；
基于所述已访问服务的服务使用信息，确定所述已访问服务的生存状态。
在本申请实施例中，可以在工作节点中配置服务拦截功能，以通过该服务拦截功能发现需要拦截的服务Service；除此之外，还可以通过该服务拦截功能定期将工作节点已经学习的Service的服务使用信息汇报给服务节点，以通过该服务节点对已访问服务的生存状态进行管理。
在本申请实施例中，可以通过服务节点中的状态管理节点Service Group CR（Service Group Cluster Resources），对已访问服务的生存状态进行管理。其中，该生存状态包括：正常生存状态、异常生存状态。其中，正常生存状态用于指示可以维护该服务的转发信息；异常生存状态表示停止维护该服务的转发信息，以及不在检测该转发信息的变更信息。
这里，工作节点可以定期获取已访问服务的服务使用信息，并在获取到已访问服务的服务使用信息之后，可以向状态管理节点Service Group CR同步该服务使用信息，进而通过状态管理节点Service Group CR对该已访问服务的服务使用信息进行管理。
状态管理节点Service Group CR，可以根据该已访问服务的服务使用时间，判断该已访问服务是否已经超过有效时间。如果基于该服务使用时间确定该已访问服务超出有效时间，则设置该已访问服务的监听状态为“异常生存状态”。这里，“异常生存状态”可以理解为不再维护该已访问服务的转发信息，以及不在检测该转发信息的变更信息。
在一个可选的实施方式中，上述步骤基于所述标服务的服务使用信息，确定所述目标服务的生存状态，具体包括如下步骤：
确定当前时刻和所述服务使用信息之间的时间间隔；
在确定所述时间间隔超过所述目标服务的有效时间的情况下，确定所述目标服务的生存状态为异常生存状态。
这里，状态管理节点可以定期检测所管理的每个服务的最近使用时间和当前时间之间的时间间隔，并确定该时间间隔是否超过该服务的有效时间。其中，如果确定该时间间隔超过该服务的有效时间，则确定该服务的生存状态为“异常生存状态”。在此情况下，可以在状态管理节点所维护的服务中删除该失效服务，或者，可以为该服务设置失效标识，以通过该失效标识该服务处于“异常生存状态”。
在一个可选的实施方式中，该方法还包括如下步骤：
接收所述工作节点的检测请求；其中，所述检测请求用于请求检测所述最近使用时间和当前时间之间的时间间隔超过有效时间的失效服务；
基于所述检测请求，查找所述失效服务，并向所述工作节点反馈查找到的所述失效服务的服务标识信息。
工作节点在向服务节点（例如，状态管理节点Service Group CR）发送所述服务使用信息之后，还可以在定期向服务节点发送检测请求，以请求在服务节点所管理的服务中检测失效服务。服务节点在检测到失效服务的情况下，向工作节点返回该失效服务的服务标识信息。之后，工作节点就可以在本地存储空间中删除失效服务的转发信息。
这里，可以将设置有失效标识的服务确定为失效服务；还可以将状态管理节点所管理服务的服务标识信息，与工作节点中已访问服务的服务标识信息进行比较。如果比较出工作节点中的已访问服务并未包含在状态管理节点所管理的服务中，则确定该已访问服务为失效服务。
通过上述处理方式，可以删除访问频率较低的服务的转发信息，从而进一步降低对K8s集群中kube-apiserver的压力，保证集群的稳定性。
参见图4所示，为本申请实施例提供的一种集群的容器组调度方法的流程图，所述方法包括步骤S401至S411，其中：
S401：服务拦截组件向工作节点的内核中下发拦截规则。
这里，服务拦截组件ServiceIntercept运行在每个工作节点上，负责在工作节点上配置拦截规则，通过配置该拦截规则，可以实现对命中拦截规则的针对服务的访问请求进行处理。
在工作节点启动时，工作节点中的kube-proxy并未学习到任何的服务Service。此时，该工作节点的kube-proxy可以从同角色的其他工作节点获取已经学习到的Service列表。其中，同角色的其他工作节点可以理解为与当前的工作节点对应相同类型的工作负载Workload的节点。当工作节点启动时，服务拦截组件ServiceIntercept启动。服务拦截组件ServiceIntercept启动后，向工作节点的内核配置Service Cidr拦截规则。
在一个可选的实施方式中，可以在每个工作节点中设置服务拦截组件；当工作节点启动时，服务拦截组件ServiceIntercept启动。服务拦截组件ServiceIntercept启动后，向工作节点的内核配置Service Cidr拦截规则。
在另一个可选的实施方式中，还可以通过Sidecar设计模式在工作节点中设置服务拦截功能，这里，Sidecar设计模式允许为工作节点添加许多功能，而无需额外第三方组件的配置和代码。
S402：在检测到容器针对目标服务的首次访问请求之后，向内核发送首次访问目标服务的访问请求。
S403：内核在判断出该目标服务命中拦截规则的情况下，向服务拦截组件发送该访问请求。
内核可以获取目标服务列表，其中，目标服务列表包括对所述集群内已访问服务的服务标识信息。内核在确定出目标服务列表中不包含所述目标服务的服务标识信息的情况下，确定目标服务不是已访问服务，也即，可以确定该目标服务命中拦截规则。此时，容器发送的访问请求会被路由到服务拦截组件。
S404：服务拦截组件向服务发现节点发送携带地址信息的获取请求。
服务拦截组件ServiceIntercept在获取到访问请求之后，可以对访问请求进行解析，得到地址信息；例如，可以从访问请求中解析出容器想要访问的目标服务的ClusterIP和Port。之后，根据该地址信息，向Service Discovery发送获取请求。
S405：服务发现节点向服务拦截组件发送该转发信息。
服务发现组件Service Discovery中心化部署在集群中，通过该服务发现节点可以维护集群内所有的服务的转发信息，也即，该服务发现节点拥有全量服务的转发信息；其中，转发信息包括Service Name、space/Name以及Endpoints。
服务发现节点在接收到获取请求之后，可以基于该地址信息查找该目标服务的转发信息，并在查找到该转发信息的情况下，向服务拦截组件发送该转发信息。
S406：服务拦截组件向内核传输该转发信息。
S407：内核基于转发信息向服务容器组发送访问请求。
服务拦截组件可以通过内核将接收到的访问请求转发到目标endpoints地址上，完成Pod内的请求；其中，目标endpoints地址用于指示目标服务对应的服务容器组。
S408：服务拦截组件通知kube-proxy在目标服务列表中添加目标服务的服务标识信息。
S409：kube-proxy获取目标服务的转发信息。
S410：kube-proxy通知工作节点的内核更新该目标服务的转发信息。
这里，在获取到的转发信息之后，还可以将该转发信息交付给kube-proxy，之后kube-proxy就知道需要管理这个新发现的目标服务。然后kube-proxy就会主动获取该目标服务的转发信息。
S411：在检测到容器针对目标服务的非首次访问请求之后，容器向内核发送非首次访问目标服务的访问请求。
S412：内核基于转发信息向服务容器组发送访问请求。
内核在确定出目标服务列表中包含所述目标服务的服务标识信息的情况下，确定目标服务是已访问服务，此时，可以直接在本地存储空间获取该转发信息，并基于获取到的所述目标服务的转发信息确定所述目标服务对应的服务容器组，并向所述服务容器组发送所述访问请求。
上述实施方式中，可以设置在目标服务不是已访问服务的情况下，从服务节点获取所请求目标服务的转发信息，从而实现设定从服务节点获取转发信息的服务，通过该处理方式，可以不必向服务节点获取服务的全量转发信息，从而可以降低对K8s集群中kube-apiserver的压力，提高K8s集群的稳定性。
参见图5所示，为本申请实施例提供的一种集群的容器组调度系统的流程图，所述系统包括：工作节点10和服务节点20。
这里，集群中工作节点10的数量可以为多个，服务节点可以设置在集群的主控节点，除此之外，服务节点还可以设置在该集群中除主控节点之外的其他节点上。
工作节点10，被配置成接收针对目标服务的访问请求；在确定所述目标服务不是已监听服务的情况下，向所述服务节点发送获取请求；以及基于获取到的所述目标服务的转发信息确定所述目标服务对应的服务容器组，并向所述服务容器组发送所述访问请求；其中，所述获取请求用于请求所述目标服务的转发信息的信息。
这里，工作节点的具体功能和所执行的步骤如上述实施例的描述，此处不再详细赘述。
服务节点20，被配置成接收所述获取请求，并基于所述获取请求查找所述目标服务的转发信息；在查找到所述转发信息的情况下，向所述工作节点发送所述目标服务的转发信息。
这里，服务节点的具体功能和所执行的步骤如上述实施例的描述，此处不再详细赘述。
在本公开技术方案中，针对工作节点中Pod所需要访问使用的目标服务，可以设置在目标服务不是已访问服务的情况下，从服务节点获取所请求目标服务的转发信息。通过上述处理方式，实现设定需要从服务节点获取转发信息的服务，例如，可以设定需要从服务节点获取转发信息的服务不是针对该工作节点的已访问服务。在此基础上，针对每个目标服务，可以不需要向服务节点获取全部目标服务的转发信息，可以对需要获取转发信息的目标服务向服务节点请求转发信息，该处理方式可以降低对K8s集群中kube-apiserver的压力，提高K8s集群的稳定性。
参见图6所示，为本申请实施例提供的一种集群的容器组调度系统的流程图，所述系统包括：kube-apiserver（61）、服务发现组件Service Discovery（62）、容器组A（63）、容器组B（64）、其中，容器组A包括容器、内核、kube-proxy和服务拦截组件。
如图6所示，容器可以发送对目标服务的访问请求；内核在接收到该访问请求之后，如果确定首次访问该目标服务，则通过在内核配置的拦截规则拦截访问请求，并通过服务拦截组件向服务发现组件Service Discovery发送获取请求，以从服务发现组件ServiceDiscovery中请求获取目标服务的转发信息。以及通过服务拦截组件获取ServiceDiscovery发送的转发信息，并向内核发送该转发信息，以使内核向目标服务对应的服务容器组（例如，容器组B）转发该访问请求。如果确定未非首次访问该目标服务，则通过内核查找该目标服务的转发信息，并基于该转发信息向目标服务对应的服务容器组（例如，容器组B）转发该访问请求。
这里，服务发现组件可以从kube-apiserver获取全量服务的转发信息，容器组A在本地存储空间中存储的转发信息，可以为容器组A从kube-apiserver获取到的所需要服务的转发信息。
通过上述描述可知，本申请实施例，可以主动发现容器组所使用的服务，此时，就不需要全量加载集群的全量服务的转发信息，降低了客户端的资源占用，同时降低了对kube-apiserver的压力，从而让小规格的eci Pod在大集群中也能很好的运行，以及降低了Kubernetes集群的托管成本。
本领域技术人员可以理解，在具体实施方式的上述方法中，各步骤的撰写顺序并不意味着严格的执行顺序而对实施过程构成任何限定，各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。
基于同一发明构思，本申请实施例中还提供了与集群的容器组调度方法对应的集群的容器组调度装置，由于本申请实施例中的装置解决问题的原理与本申请实施例上述集群的容器组调度方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。
参照图7所示，为本申请实施例提供的一种集群的容器组调度装置的架构示意图，所述装置包括：第一接收单元71、获取单元72和确定单元73；其中，
第一接收单元，用于接收针对目标服务的访问请求；
获取单元，用于在确定所述目标服务不是已访问服务的情况下，基于所述访问请求从服务节点获取所述目标服务的转发信息；其中，所述服务节点中存储有所述集群内已创建服务的转发信息；
确定单元，用于基于获取到的所述目标服务的转发信息确定所述目标服务对应的服务容器组，并向所述服务容器组发送所述访问请求。
上述实施方式中，可以设置在目标服务不是工作节点的已访问服务的情况下，从服务节点获取资源请求节点所请求目标服务的转发信息，从而实现设定从服务节点获取转发信息的服务，通过该处理方式，可以不必向服务节点获取服务的全量转发信息，从而可以降低对K8s集群中kube-apiserver的压力，提高K8s集群的稳定性。
一种可能的实施方式中，该装置还用于：获取目标服务列表；其中，所述目标服务列表包括对所述集群内已访问服务的服务标识信息；在确定所述目标服务列表中不包含所述目标服务的服务标识信息的情况下，确定所述目标服务不是所述已访问服务。
一种可能的实施方式中，该装置还用于：在确定所述目标服务不是已访问服务的情况下，在所述目标服务列表中添加所述目标服务的服务标识信息。
一种可能的实施方式中，该装置还用于：在基于所述访问请求从服务节点获取所述目标服务的转发信息之后，在本地存储空间存储所述目标服务的转发信息；检测所述目标服务的转发信息的变更信息；其中，所述变更信息用于指示所述目标服务所对应的服务容器组的地址变更信息；基于所述检测到的变更信息更新所述本地存储空间中所述目标服务的转发信息。
一种可能的实施方式中，获取单元，还用于：对所述访问请求进行解析，解析得到所述目标服务的地址信息；向所述服务节点发送携带所述地址信息的获取请求；获取所述服务节点基于所述获取请求返回的所述转发信息。
一种可能的实施方式中，该装置还用于：获取所述已访问服务的服务使用信息；其中，所述服务使用信息用于指示所述已访问服务的最近使用时间；向所述服务节点发送所述服务使用信息；其中，所述服务节点用于基于所述服务使用信息对所述已访问服务的生存状态进行管理。
一种可能的实施方式中，该装置还用于：在向所述服务节点发送所述服务使用信息之后，在所述服务节点所管理的服务中检测所述最近使用时间和当前时间之间的时间间隔超过有效时间的失效服务；在本地存储空间中删除所述失效服务的转发信息。
一种可能的实施方式中，该装置还用于：在确定所述目标服务是所述已访问服务的情况下，在本地存储空间中查找所述目标服务的转发信息，并执行基于获取到的所述目标服务的转发信息确定所述目标服务对应的服务容器组，并向所述服务容器组发送所述访问请求的步骤。
参照图8所示，为本申请实施例提供的一种集群的容器组调度装置的架构示意图，所述装置包括：第二接收单元81、查找单元82和发送单元83；其中，
第二接收单元81，用于接收工作节点发送的获取请求；其中，所述获取请求为所述工作节点在确定出所请求访问的目标服务不是已访问服务的情况下发送的获取所述目标服务的转发信息的请求；
查找单元82，用于基于所述获取请求查找所述目标服务的转发信息；
发送单元83，用于在查找到所述转发信息的情况下，向所述工作节点发送所述目标服务的转发信息。
一种可能的实施方式中，该装置还用于：获取所述工作节点发送的所述已访问服务的服务使用信息；其中，所述服务使用信息用于指示工作负载对所述已访问服务的最近使用时间；基于所述已访问服务的服务使用信息，确定所述已访问服务的生存状态。
一种可能的实施方式中，该装置还用于：确定当前时刻和所述服务使用信息之间的时间间隔；在确定所述时间间隔超过所述已访问服务的有效时间的情况下，确定所述已访问服务的生存状态为异常生存状态。
一种可能的实施方式中，该装置还用于：接收所述工作节点的检测请求；其中，所述检测请求用于请求检测所述最近使用时间和当前时间之间的时间间隔超过有效时间的失效服务；基于所述检测请求，查找所述失效服务，并向所述工作节点反馈查找到的所述失效服务的服务标识信息。
关于装置中的各模块的处理流程、以及各模块之间的交互流程的描述可以参照上述方法实施例中的相关说明，这里不再详述。
本申请的另一个实施例提供了一种计算机设备，该计算机设备可以为上位机等工业生产线上用于进行产品分析的设备，该计算机设备包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行该程序，以实现上述任一实施方式的产品分析方法。
如图9所示，计算机设备90可以包括：处理器900，存储器901，总线902和通信接口903，处理器900、通信接口903和存储器901通过总线902连接；存储器901中存储有可在处理器900上运行的计算机程序，处理器900运行该计算机程序时执行本申请前述任一实施方式所提供的方法。
其中，存储器901可能包含高速随机存取存储器（RAM：Random Access Memory），也可能还可以包括非不稳定的存储器（non-volatile memory），例如至少一个磁盘存储器。通过至少一个通信接口903（可以是有线或者无线）实现该系统网元与至少一个其他网元之间的通信连接，可以使用互联网、广域网、本地网、城域网等。
总线902可以是ISA总线、PCI总线或EISA总线等。总线可以分为地址总线、数据总线、控制总线等。其中，存储器901用于存储程序，处理器900在接收到执行指令后，执行该程序，前述本申请实施例任一实施方式揭示的方法可以应用于处理器900中，或者由处理器900实现。
处理器900可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器900中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器900可以是通用处理器，可以包括处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器901，处理器900读取存储器901中的信息，结合其硬件完成上述方法的步骤。
本申请实施例提供的计算机设备与本申请实施例提供的方法出于相同的发明构思，具有与其采用、运行或实现的方法相同的有益效果。
本申请的另一个实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行，以实现上述任一实施方式的控制方法。
参考图10所示，其示出的计算机可读存储介质为光盘100，其上存储有计算机程序（即程序产品），该计算机程序在被处理器运行时，会执行前述任意实施方式所提供的方法。
需要说明的是，计算机可读存储介质的例子还可以包括，但不限于相变内存(Parallel Random Access Machine，PRAM)、静态随机存取存储器(Static Random-AccessMemory，SRAM)、动态随机存取存储器(Dynamic Random Access Memory，DRAM)、其他类型的随机存取存储器(Random Access Memory ，RAM)、只读存储器 (Read-Only Memory ，ROM)、电可擦除可编程只读存储器(Electrically Erasable Programmable read only memoryEEPROM)、快闪记忆体或其他光学、磁性存储介质，在此不再一一赘述。
本申请的另一个实施例提供了一种计算机程序产品，包括计算机程序，该程序被处理器执行，以实现上述任一实施方式的控制方法。
本申请的上述实施例提供的计算机可读存储介质及计算机程序产品均与本申请实施例提供的方法出于相同的发明构思，具有与其存储的应用程序所采用、运行或实现的方法相同的有益效果。
需要说明的是：
术语“模块”并非意图受限于特定物理形式。取决于具体应用，模块可以实现为硬件、固件、软件和/或其组合。此外，不同的模块可以共享公共组件或甚至由相同组件实现。不同模块之间可以存在或不存在清楚的界限。
在此提供的算法和显示不与任何特定计算机、虚拟装置或者其它设备固有相关。各种通用装置也可以与基于在此的示例一起使用。根据上面的描述，构造这类装置所要求的结构是显而易见的。此外，本申请也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本申请的内容，并且上面对特定语言所做的描述是为了披露本申请的实施方式。
应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
以上实施例仅表达了本申请的实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。

Claims (14)

1.一种集群的容器组调度方法，其特征在于，所述集群包括工作节点和服务节点，所述工作节点中包含至少一个容器组，所述服务节点用于存储所述工作节点中容器组所使用服务的转发信息，所述方法应用于工作节点，包括：
接收针对目标服务的访问请求；
在确定所述目标服务不是已访问服务的情况下，基于所述访问请求从服务节点获取所述目标服务的转发信息；其中，所述已访问服务用于指示非首次向所述工作节点请求访问的服务，和/或，历史时刻向所述工作节点请求访问的服务中未超过有效时间的服务；
基于获取到的所述目标服务的转发信息确定所述目标服务对应的服务容器组，并向所述服务容器组发送所述访问请求。
2.根据权利要求1所述的方法，其特征在于，所述确定所述目标服务不是已访问服务，包括：
获取预先设置的服务拦截规则；其中，所述服务拦截规则用于拦截需要从所述服务节点获取转发信息的服务；
在确定所述目标服务与所述服务拦截规则相匹配的情况下，确定所述目标服务不是已访问服务。
3.根据权利要求2所述的方法，其特征在于，所述确定所述目标服务与所述服务拦截规则相匹配，包括：
获取目标服务列表；其中，所述目标服务列表包括对所述集群内已访问服务的服务标识信息；
在确定所述目标服务列表中不包含所述目标服务的服务标识信息的情况下，确定所述目标服务与所述服务拦截规则相匹配。
4.根据权利要求3所述的方法，其特征在于，所述方法还包括：
在确定所述目标服务不是已访问服务的情况下，在所述目标服务列表中添加所述目标服务的服务标识信息。
5.根据权利要求1所述的方法，其特征在于，所述方法还包括：
在基于所述访问请求从服务节点获取所述目标服务的转发信息之后，在本地存储空间存储所述目标服务的转发信息；
检测所述目标服务的转发信息的变更信息；其中，所述变更信息用于指示所述目标服务所对应的服务容器组的地址变更信息；
基于所述检测到的变更信息更新所述本地存储空间中所述目标服务的转发信息。
6.根据权利要求1所述的方法，其特征在于，所述方法还包括：
在确定所述目标服务不是已访问服务的情况下，获取所述目标服务的服务使用信息；其中，所述服务使用信息用于指示所述目标服务的最近使用时间；
向所述服务节点发送所述服务使用信息；其中，所述服务节点用于基于所述服务使用信息对所述目标服务的生存状态进行管理。
7.根据权利要求6所述的方法，其特征在于，所述方法还包括：
在向所述服务节点发送所述服务使用信息之后，获取所述服务节点所管理的服务中检测所述最近使用时间和当前时间之间的时间间隔超过有效时间的失效服务的服务信息；
基于所述服务信息，在本地存储空间中删除所述失效服务的转发信息。
8.根据权利要求1所述的方法，其特征在于，所述方法还包括：
在确定所述目标服务是所述已访问服务的情况下，在本地存储空间中查找所述目标服务的转发信息，并执行基于获取到的所述目标服务的转发信息确定所述目标服务对应的服务容器组，并向所述服务容器组发送所述访问请求的步骤。
9.一种集群的容器组调度方法，其特征在于，所述集群包括工作节点和服务节点，所述工作节点中包含至少一个容器组，所述服务节点用于存储所述工作节点中容器组所使用服务的转发信息，所述方法应用于服务节点，包括：
接收工作节点发送的获取请求；其中，所述获取请求为所述工作节点在确定出所请求访问的目标服务不是已访问服务的情况下发送的获取所述目标服务的转发信息的请求；
基于所述获取请求查找所述目标服务的转发信息；
在查找到所述转发信息的情况下，向所述工作节点发送所述目标服务的转发信息。
10.根据权利要求9所述的方法，其特征在于，所述方法还包括：
获取所述工作节点发送的所述已访问服务的服务使用信息；其中，所述服务使用信息用于指示工作负载对所述已访问服务的最近使用时间；
基于所述已访问服务的服务使用信息，确定所述已访问服务的生存状态。
11.根据权利要求10所述的方法，其特征在于，所述基于所述标服务的服务使用信息，确定所述目标服务的生存状态，包括：
确定当前时刻和所述服务使用信息之间的时间间隔；
在确定所述时间间隔超过所述已访问服务的有效时间的情况下，确定所述已访问服务的生存状态为异常生存状态。
12.根据权利要求10所述的方法，其特征在于，所述方法还包括：
接收所述工作节点的检测请求；其中，所述检测请求用于请求检测所述最近使用时间和当前时间之间的时间间隔超过有效时间的失效服务；
基于所述检测请求，查找所述失效服务，并向所述工作节点反馈查找到的所述失效服务的服务标识信息。
13.一种集群的容器组调度系统，其特征在于，包括：工作节点和服务节点；
所述工作节点，被配置成接收针对目标服务的访问请求；在确定所述目标服务不是已监听服务的情况下，向所述服务节点发送获取请求；以及基于获取到的所述目标服务的转发信息确定所述目标服务对应的服务容器组，并向所述服务容器组发送所述访问请求；其中，所述获取请求用于请求所述目标服务的转发信息的信息；
所述服务节点，被配置成接收所述获取请求，并基于所述获取请求查找所述目标服务的转发信息；在查找到所述转发信息的情况下，向所述工作节点发送所述目标服务的转发信息。
14.一种计算机设备，其特征在于，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当计算机设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行如权利要求1至12任一项所述的集群的容器组调度方法的步骤。
CN202311791135.XA 2023-12-25 2023-12-25 集群的容器组调度方法、系统以及计算机设备 Active CN117453380B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311791135.XA CN117453380B (zh) 2023-12-25 2023-12-25 集群的容器组调度方法、系统以及计算机设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311791135.XA CN117453380B (zh) 2023-12-25 2023-12-25 集群的容器组调度方法、系统以及计算机设备

Publications (2)

Publication Number Publication Date
CN117453380A CN117453380A (zh) 2024-01-26
CN117453380B true CN117453380B (zh) 2024-02-23

Family

ID=89580312

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311791135.XA Active CN117453380B (zh) 2023-12-25 2023-12-25 集群的容器组调度方法、系统以及计算机设备

Country Status (1)

Country Link
CN (1) CN117453380B (zh)

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7746987B1 (en) * 2010-04-11 2010-06-29 Dennis Becker Voice message transmission and retrieval
CN106027647A (zh) * 2016-05-20 2016-10-12 云南云电同方科技有限公司 Lxpfs集群分布式文件存储系统
CN113641505A (zh) * 2021-10-14 2021-11-12 阿里云计算有限公司 一种服务器集群的资源分配控制方法和装置
CN113760452A (zh) * 2021-08-02 2021-12-07 阿里巴巴新加坡控股有限公司 一种容器调度方法、系统、设备及存储介质
CN113783695A (zh) * 2021-08-03 2021-12-10 西北大学 一种微服务架构的客户端信息认证方法及系统
CN114461303A (zh) * 2022-02-10 2022-05-10 京东科技信息技术有限公司 一种访问集群内部服务的方法和装置
US11481243B1 (en) * 2021-08-25 2022-10-25 International Business Machines Corporation Service access across Kubernetes clusters
EP4160409A1 (en) * 2021-10-04 2023-04-05 Juniper Networks, Inc. Cloud native software-defined network architecture for multiple clusters
CN116996578A (zh) * 2023-09-27 2023-11-03 联通在线信息科技有限公司 基于内容分发网络的资源处理方法和装置

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220124162A1 (en) * 2019-04-02 2022-04-21 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for service discovery
US11640315B2 (en) * 2019-11-04 2023-05-02 Vmware, Inc. Multi-site virtual infrastructure orchestration of network service in hybrid cloud environments
US11558426B2 (en) * 2020-07-29 2023-01-17 Vmware, Inc. Connection tracking for container cluster

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7746987B1 (en) * 2010-04-11 2010-06-29 Dennis Becker Voice message transmission and retrieval
CN106027647A (zh) * 2016-05-20 2016-10-12 云南云电同方科技有限公司 Lxpfs集群分布式文件存储系统
CN113760452A (zh) * 2021-08-02 2021-12-07 阿里巴巴新加坡控股有限公司 一种容器调度方法、系统、设备及存储介质
CN113783695A (zh) * 2021-08-03 2021-12-10 西北大学 一种微服务架构的客户端信息认证方法及系统
US11481243B1 (en) * 2021-08-25 2022-10-25 International Business Machines Corporation Service access across Kubernetes clusters
EP4160409A1 (en) * 2021-10-04 2023-04-05 Juniper Networks, Inc. Cloud native software-defined network architecture for multiple clusters
CN113641505A (zh) * 2021-10-14 2021-11-12 阿里云计算有限公司 一种服务器集群的资源分配控制方法和装置
CN114461303A (zh) * 2022-02-10 2022-05-10 京东科技信息技术有限公司 一种访问集群内部服务的方法和装置
CN116996578A (zh) * 2023-09-27 2023-11-03 联通在线信息科技有限公司 基于内容分发网络的资源处理方法和装置

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
Tom Goethals ET AL.Extending Kubernetes Clusters to Low-Resource Edge Devices Using Virtual Kubelets.《IEEE Transaction on Cloud Computing》.2022,第第10卷卷(第第4期期),全文. *
张立强 ; 何凡 ; 叶卫军 ; 应时 ; 李晶 ; .一种基于Kerberos扩展的Web服务安全框架.武汉大学学报(理学版).(02),全文. *
燕彩蓉,彭勤科,沈钧毅,武红江.基于两阶段散列的Web集群服务器内容分配研究.西安交通大学学报.2005,(08),全文. *

Also Published As

Publication number Publication date
CN117453380A (zh) 2024-01-26

Similar Documents

Publication Publication Date Title
EP3391627B1 (en) Shared multi-tenant domain name system (dns) server for virtual networks and corresponding method
CN115291964B (zh) 减少无服务器函数启动延迟的机制
CN113596184B (zh) 混合云系统、网闸、网络访问方法及存储介质
US9917889B2 (en) Enterprise service bus routing system
US9531664B2 (en) Selecting between domain name system servers of a plurality of networks
WO2019165665A1 (zh) 一种域名解析方法、服务器及系统
CN110635933B (zh) 用于管理sdn的网络的装置、控制方法及记录介质
CN109684282B (zh) 一种构建元数据缓存的方法及装置
EP2710477B1 (en) Distributed caching and cache analysis
CN107135242B (zh) Mongodb集群访问方法、装置及系统
CN110413845B (zh) 基于物联网操作系统的资源存储方法及装置
US11822970B2 (en) Identifier (ID) allocation in a virtualized computing environment
CN113452780B (zh) 针对客户端的访问请求处理方法、装置、设备及介质
CN111586201A (zh) 域名解析系统、方法、设备及存储介质
CN111327606A (zh) 资源管理方法、系统及存储介质
JP2016177688A (ja) データ処理装置、データ処理方法およびコンピュータプログラム
CN109413224B (zh) 报文转发方法和装置
US11683316B2 (en) Method and device for communication between microservices
US20150186269A1 (en) Managing memory
CN112583760B (zh) 一种对象存储的访问方法、装置、设备和计算机存储介质
CN117453380B (zh) 集群的容器组调度方法、系统以及计算机设备
CN111708594A (zh) 页面渲染方法、装置、电子设备及存储介质
US6947971B1 (en) Ethernet packet header cache
US10452295B1 (en) Data routing in information processing system utilizing persistent memory
CN116389599A (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
GR01 Patent grant
GR01 Patent grant