Container group scheduling method and system for cluster, and computer device

Abstract

The present disclosure provides a container group scheduling method and system for a cluster, and a computer device. The method comprises: receiving an access request for a target service; when it is determined that the target service is not an accessed service, acquiring forwarding information of the target service from a service node on the basis of the access request, the accessed service being used for indicating a service the access to which has not been requested from a worker node for the first time, and / or, a service which remains within a time to live amongst services the access to which has been requested from the worker node at historical moments; and determining a service container group corresponding to the target service on the basis of the acquired forwarding information of the target service, and sending the access request to the service container group.

Description

Cluster container group scheduling method, system and computer device Technical Field

[0001] The present disclosure relates to the technical field of computers, and in particular to a method and system for scheduling container groups in a cluster, and a computer device. Background Art

[0002] Kubernetes (K8s for short) is an open source containerized application for managing multiple hosts in a cloud platform. The goal of K8s is to make the deployment of containerized applications simple and efficient. K8s provides a mechanism for application deployment, planning, updating, and maintenance.

[0003] In related technologies, the worker nodes in a K8s cluster can automatically discover services in the K8s cluster and add forwarding configurations for services in the cluster on the worker nodes. The worker nodes will locally configure the forwarding configurations for each service that the Pod in the worker node needs to use, as well as the forwarding configurations for services that do not need to be used. Configuring forwarding configurations in the worker nodes will increase the pressure on the K8s Application Programming Interface (API) server (kube-apiserver for short) in the K8s cluster. If there are many worker nodes and services in the cluster, a large amount of forwarding configurations will be stored on the worker nodes, thereby increasing the pressure on the kube-apiserver in the K8s cluster, and thus affecting the stability of the K8s cluster.

[0004] Summary of the Invention

[0005] The embodiments of the present disclosure at least provide a method, system, and computer device for scheduling container groups in a cluster.

[0006] In a first aspect, an embodiment of the present disclosure provides a method for scheduling container groups in a cluster, wherein the cluster includes a working node and a service node, the working node includes at least one container group, and the service node is used to store forwarding information of a service used by the container group in the working node. The method is applied to the working node and includes:

[0007] Receive access requests for target services;

[0008] If it is determined that the target service is not an accessed service, obtaining forwarding information of the target service from the service node based on the access request; wherein the accessed service is used to indicate a service that is not the first time access is requested from the working node, and / or a service that has not exceeded its validity period among services that have been requested from the working node at a historical moment;

[0009] The service container group corresponding to the target service is determined based on the acquired forwarding information of the target service, and the access request is sent to the service container group.

[0010] In an optional implementation manner, determining that the target service is not an accessed service includes:

[0011] Obtaining a preset service interception rule; wherein the service interception rule is used to intercept a service that requires obtaining forwarding information from the service node;

[0012] If it is determined that the target service matches the service interception rule, it is determined that the target service is not an accessed service.

[0013] In an optional implementation manner, determining whether the target service matches the service interception rule includes:

[0014] Obtain a target service list; wherein the target service list includes service identification information of services that have been accessed by the working node;

[0015] When it is determined that the target service list does not include the service identification information of the target service, it is determined that the target service matches the service interception rule.

[0016] In an optional implementation, the method further includes:

[0017] If it is determined that the target service is not an accessed service, the service identification information of the target service is added to the target service list.

[0018] In an optional implementation, the method further includes:

[0019] After acquiring the forwarding information of the target service from the service node based on the access request, storing the forwarding information of the target service in a local storage space;

[0020] Detecting change information of the forwarding information of the target service; wherein the change information is used to indicate address change information of the service container group corresponding to the target service;

[0021] The forwarding information of the target service in the local storage space is updated based on the detected change information.

[0022] In an optional implementation, the method further includes:

[0023] Obtaining service usage information of the accessed service; wherein the service usage information is used to indicate the most recent usage time of the accessed service;

[0024] The service usage information is sent to the service node; wherein the service node is used to manage the survival status of the accessed service based on the service usage information.

[0025] In an optional implementation, the method further includes:

[0026] After sending the service usage information to the service node, sending a detection request to the service node, wherein the detection request is used to request detection of an invalid service whose time interval between the most recent usage time and the current time exceeds the validity time;

[0027] Obtain service information of an invalid service in which the time interval between the most recently used time and the current time exceeds the valid time among the services managed by the service node;

[0028] Based on the service information, the forwarding information of the invalid service is deleted in the local storage space.

[0029] In an optional implementation, the method further includes:

[0030] When it is determined that the target service is the accessed service, forwarding information of the target service is searched in the local storage space; a service container group corresponding to the target service is determined based on the obtained forwarding information of the target service; and the access request is sent to the service container group.

[0031] In a second aspect, an embodiment of the present disclosure provides a method for scheduling container groups in a cluster, wherein the cluster includes a working node and a service node, the working node includes at least one container group, and the service node is used to store forwarding information of a service used by the container group in the working node. The method is applied to the service node and includes:

[0032] Receiving an acquisition request sent by a working node; wherein the acquisition request is a request for acquiring forwarding information of the target service sent by the working node when determining that the target service requested to be accessed is not an accessed service;

[0033] Searching for forwarding information of the target service based on the acquisition request;

[0034] When the forwarding information is found, the forwarding information of the target service is sent to the working node.

[0035] In an optional implementation, the method further includes:

[0036] Obtaining service usage information of the accessed service sent by the working node; wherein the service usage information is used to indicate the most recent usage time of the accessed service by the workload;

[0037] Based on the service usage information of the accessed service, the survival status of the accessed service is managed.

[0038] In an optional implementation manner, determining the survival status of the target service based on the service usage information of the target service includes:

[0039] Determine the time interval between the current moment and the service usage information;

[0040] If it is determined that the time interval exceeds the validity period of the accessed service, determining that the survival state of the accessed service is an abnormal survival state;

[0041] If it is determined that the time interval does not exceed the valid time of the accessed service, the survival state of the accessed service is determined to be a normal survival state.

[0042] In an optional implementation, the method further includes:

[0043] Receive a detection request from the working node; wherein the detection request is used to request detection of an invalid service whose time interval between the most recently used time and the current time exceeds a valid time;

[0044] Based on the detection request, the failed service is searched, and the service identification information of the failed service found is fed back to the working node.

[0045] In a third aspect, an embodiment of the present disclosure provides a cluster container group scheduling system, including: a working node and a service node;

[0046] The working node is configured to receive an access request for a target service; if it is determined that the target service is not a monitored service, send a get request to the service node; and determine a service container group corresponding to the target service based on the obtained forwarding information of the target service, and send the access request to the service container group; wherein the get request is used to request information about the forwarding information of the target service;

[0047] The service node is configured to receive the acquisition request and search for the forwarding information of the target service based on the acquisition request; and send the forwarding information of the target service to the working node when the forwarding information is found.

[0048] In a fourth aspect, an embodiment of the present disclosure further provides a computer device comprising: a processor, a memory and a bus, wherein the memory stores machine-readable instructions executable by the processor. When the computer device is running, the processor and the memory communicate via the bus, and when the machine-readable instructions are executed by the processor, the steps of the above-mentioned first aspect or any possible implementation of the first aspect are performed.

[0049] In a fifth aspect, an embodiment of the present disclosure further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the above-mentioned first aspect or any possible implementation of the first aspect are executed.

[0050] In a sixth aspect, an embodiment of the present disclosure further provides a container group scheduling device for a cluster, wherein the cluster includes a working node and a service node, the working node includes at least one container group, and the service node is used to store forwarding information of the service used by the container group in the working node. The device is applied to the working node and includes:

[0051] A first receiving unit, configured to receive an access request for a target service;

[0052] an acquiring unit, configured to acquire, if it is determined that the target service is not an accessed service, forwarding information of the target service from the service node based on the access request; wherein the accessed service is used to indicate a service that is not the first time access is requested from the working node, and / or a service that has not exceeded its validity period among services that have been requested from the working node at a historical moment;

[0053] The determining unit is configured to determine a service container group corresponding to the target service based on the acquired forwarding information of the target service, and send an access request to the service container group.

[0054] In a seventh aspect, an embodiment of the present disclosure further provides a computer program product, comprising a computer program, which executes the steps in the above-mentioned first aspect or any possible implementation of the first aspect when executed by a processor.

[0055] In order to make the above-mentioned objectives, features and advantages of the present disclosure more obvious and easy to understand, preferred embodiments are given below and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the following briefly introduces the drawings required for use in the embodiments. The drawings herein are incorporated into and constitute a part of the specification. These drawings illustrate embodiments consistent with the present disclosure and, together with the specification, are used to illustrate the technical solutions of the present disclosure. It should be understood that the following drawings only illustrate certain embodiments of the present disclosure and should not be regarded as limiting the scope. For those of ordinary skill in the art, other relevant drawings can be obtained based on these drawings without inventive effort.

[0057] FIG1 shows a flowchart of a method for scheduling a container group in a cluster provided by an embodiment of the present disclosure;

[0058] FIG2 shows a flowchart of a second cluster container group scheduling method provided by an embodiment of the present disclosure;

[0059] FIG3 shows a flowchart of a third cluster container group scheduling method provided by an embodiment of the present disclosure;

[0060] FIG4 shows a flowchart of an interaction between a working node and a service node provided by an embodiment of the present disclosure;

[0061] FIG5 shows a schematic diagram of a cluster container group scheduling system provided by an embodiment of the present disclosure;

[0062] FIG6 shows a schematic diagram of another cluster container group scheduling system provided by an embodiment of the present disclosure;

[0063] FIG7 shows a schematic diagram of a cluster container group scheduling device provided by an embodiment of the present disclosure;

[0064] FIG8 shows a schematic diagram of another cluster container group scheduling device provided by an embodiment of the present disclosure;

[0065] FIG9 shows a schematic diagram of a computer device provided by an embodiment of the present disclosure;

[0066] FIG10 shows a schematic diagram of a computer-readable storage medium provided by an embodiment of the present disclosure. DETAILED DESCRIPTION

[0067] In order to make the purpose, technical solutions and advantages of the embodiments of the present disclosure clearer, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are only part of the embodiments of the present disclosure, not all of the embodiments. The components of the embodiments of the present disclosure generally described and shown in the drawings herein can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present disclosure provided in the drawings is not intended to limit the scope of the disclosure for which protection is sought, but merely represents selected embodiments of the present disclosure. Based on the embodiments of the present disclosure, all other embodiments obtained by those skilled in the art without making creative work are within the scope of protection of the present disclosure.

[0068] Kubernetes (K8s for short) is an open source containerized application for managing multiple hosts in a cloud platform. The goal of K8s is to make the deployment of containerized applications simple and efficient. K8s provides a mechanism for application deployment, planning, updating, and maintenance.

[0069] In Kubernetes, a pod is a basic unit of functionality. A pod typically consists of one or more related containers. A group of pods with the same functionality is abstracted into a service. These services are accessed by application clients built on Kubernetes.

[0070] kube-proxy is a core component of K8s and is deployed on each worker node. It is an important component for implementing the communication and load balancing mechanism of K8s services (Kubernetes services). kube-proxy is responsible for obtaining the forwarding configuration of all services from the Kubernetes apiserver and creating proxy services for the services based on the forwarding configuration. It implements request routing and forwarding from services to pods, thereby building a virtual forwarding network at the K8s level.

[0071] In related technologies, worker nodes in a K8s cluster can automatically discover services in the K8s cluster and add forwarding configurations for the services in the cluster to the worker nodes. Regardless of whether the pods in the worker nodes use the forwarding configurations for the services, the worker nodes will configure the forwarding configurations locally. If there are many worker nodes and services in the cluster, a large amount of forwarding configurations will be stored on the worker nodes, increasing the pressure on the kube-apiserver in the K8s cluster and affecting the stability of the K8s cluster. This effect is even more pronounced in serverless Kubernetes. The serverless Kubernetes kube-proxy is deployed in the pods. With a single virtual node managing tens of thousands of pods, tens of thousands of kube-proxy instances will access the kube-apiserver to obtain the forwarding configurations for the services, posing a significant challenge to cluster stability.

[0072] In related technologies, container group scheduling can be achieved through the following:

[0073] (1) Microservices: Traditional microservices manage service calls through a registration center. Microservices require user awareness, and existing network platforms cannot automatically make these operations transparent to users, increasing the burden of maintaining applications.

[0074] (2) Expand the kube-apiserver or add a cache layer: In the K8s scenario, you can expand the kube-apiserver or add a cache to the kube-apiserver. This solution does not reduce the resource cost of cluster management, but also increases resources. At the same time, if the cluster is large and contains many services, the kube-proxy will occupy a lot of resources when forwarding configuration (endpoints) updates. Expanding the kube-apiserver cannot solve the above problem.

[0075] (3) Centralization: Remove kube-proxy and transfer all Classless Inter-Domain Routing (CIDR) services of the K8s cluster to a central location, and implement the proxy forwarding function through a centralized gateway. This increases the explosion radius of the cluster.

[0076] Based on the above research, the present disclosure provides a cluster container group scheduling method, system, and computer device. In an embodiment of the present disclosure, a working node first receives an access request for a target service and determines whether the target service is an accessed service. If the target service is not an accessed service, the working node obtains forwarding information for the target service from the service node based on the access request, determines the service container group corresponding to the target service based on the forwarding information, and then sends the access request to the service container group.

[0077] From the above description, it can be seen that in the related art, for each service that the Pod in the working node needs to use, the corresponding forwarding configuration needs to be configured locally to obtain the forwarding information of the service.

[0078] Based on this, in order to reduce the processing pressure of the forwarding configuration on the K8s cluster, in the technical solution disclosed in the present invention, for the target service that the Pod in the working node needs to access and use, it can be set to obtain the forwarding information of the requested target service from the service node when the target service is not an accessed service. Through the above processing method, it is possible to set the service that needs to obtain forwarding information from the service node. For example, it can be set that the service that needs to obtain forwarding information from the service node is not an accessed service for the working node. On this basis, for each target service, it is not necessary to obtain the forwarding information of all target services from the service node. For the target service that needs to obtain forwarding information, the service node can be requested for forwarding information. This processing method can reduce the pressure on the kube-apiserver in the K8s cluster and improve the stability of the K8s cluster.

[0079] The defects in the above solutions are the results obtained by the inventors after practice and careful research. Therefore, the process of discovering the above problems and the solutions proposed by this disclosure for the above problems below should be the contributions made by the inventors to this disclosure during the disclosure process.

[0080] It should be noted that similar reference numerals and letters denote similar items in the following drawings, and therefore, once an item is defined in one drawing, it does not need to be further defined or explained in subsequent drawings.

[0081] To facilitate understanding of this embodiment, we first provide a detailed introduction to a cluster container group scheduling method disclosed in this embodiment. The cluster container group scheduling method provided in this embodiment is generally executed by a computer device with certain computing capabilities. In some possible implementations, this cluster container group scheduling method can be implemented by a processor invoking computer-readable instructions stored in a memory.

[0082] The following describes a method for scheduling container groups in a cluster provided by an embodiment of the present disclosure.

[0083] 1 , which is a flowchart of a method for scheduling a container group in a cluster provided by an embodiment of the present disclosure, includes steps S101 to S103, wherein:

[0084] S101: Receive an access request for a target service.

[0085] As can be seen from the preceding description, each worker node can have multiple Pods, each of which can contain multiple or a single container. Kube-proxy is deployed on each worker node and primarily implements service functionality. Specifically, kube-proxy enables Pods within the Kubernetes cluster to access services, and hosts outside the cluster to access services through methods such as node ports. A service is a service abstraction for a group of Pods.

[0086] Here, it is possible to determine whether the target service is an accessed service of the working node itself in response to an access request from a container in the Pod to the target service, or in response to an access request from a host outside the K8s cluster to the target service.

[0087] Here, the accessed service can be understood as a service that has been successfully intercepted by the worker node. The worker node can detect the forwarding information of the service through the detection process, for example, the forwarding information includes information such as namespace, service name, and endpoints.

[0088] Here, a Service service that is not requested to be accessed by the working node for the first time can be determined as an accessed service; and / or a Service service that has not exceeded the validity period and has been requested to be accessed by the working node at a historical moment can be determined as an accessed service.

[0089] S102: When it is determined that the target service is not an accessed service, obtain forwarding information of the target service from the service node based on the access request; wherein the accessed service is used to indicate a service that is not the first time to be accessed to the working node, and / or a service that has not exceeded the validity period among the services that have been requested to be accessed to the working node at a historical moment.

[0090] The service node stores forwarding information of services created in the cluster.

[0091] When the working node determines that the target service is not an accessed service of the working node itself, the working node may obtain the forwarding information of the target service from the service node.

[0092] Here, the service node can also be called a service discovery node, which can be understood as a node in the K8s cluster that maintains the forwarding information of all Service services in the K8s cluster. For example, the service discovery node can be a node with a kube-apiserver process. In addition, in the present disclosure, a group of service discovery components can be set in the K8s cluster, each component is used to maintain the forwarding information of a group of Service services. In this case, the service discovery node can be understood as a node where a Service Discovery component for maintaining the forwarding information of the created service is located.

[0093] Based on the access request, the worker node can send a request to the service node for forwarding information. After receiving the request, the service node searches the local storage space of the service node for the forwarding information of the target service and returns the forwarding information to the current worker node. The forwarding information of the target service includes the target service's namespace, service name, and endpoints. The endpoints can be used to determine one or more service container groups corresponding to the target service.

[0094] The forwarded information involved in this disclosure is information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0095] S103: Determine a service container group corresponding to the target service based on the acquired forwarding information of the target service, and send the access request to the service container group.

[0096] After obtaining the forwarding information of the target service, one or more service container groups corresponding to the target service can be determined based on the forwarding information, and a service container group can be determined from the one or more service container groups. For example, any one of the one or more service container groups can be used as the service container group.

[0097] In the technical solution disclosed in the present invention, for the target service that the Pod in the working node needs to access and use, it can be set to obtain the forwarding information of the requested target service from the service node when the target service is not an accessed service. Through the above processing method, it is possible to set the service that needs to obtain forwarding information from the service node. For example, it can be set that the service that needs to obtain forwarding information from the service node is not an accessed service for the working node. On this basis, for each target service, it is not necessary to obtain the forwarding information of all target services from the service node. For the target service that needs to obtain forwarding information, the service node can be requested to obtain forwarding information. This processing method can reduce the pressure on the kube-apiserver in the K8s cluster and improve the stability of the K8s cluster.

[0098] The above steps will be described in detail below in conjunction with specific implementation methods.

[0099] From the above description, it can be seen that in the embodiment of the present disclosure, after receiving an access request to the target service, if it is determined that the target service is not an accessed service of the working node itself, the forwarding information of the target service can be obtained from the service node based on the access request.

[0100] As shown in FIG2 , the method further includes the following steps:

[0101] Step S104: When it is determined that the target service is an accessed service, the forwarding information of the target service is searched in the local storage space.

[0102] In the disclosed embodiment, when a worker node starts up, the kube-proxy has not yet learned any services. At this point, the kube-proxy of the worker node can obtain a list of learned services from other worker nodes with the same role. Other worker nodes with the same role can be understood as nodes that correspond to the same type of workload as the current worker node.

[0103] After obtaining the Service list, the Service list can be used as the target service list of the accessed services (i.e., the Watch list). The working node can then obtain the forwarding information of the accessed services in the Watch list and store the forwarding information in the local storage space. Here, the current working node can also detect changes in the forwarding information of the accessed services in the Watch list through the detection process and update the forwarding information of the accessed services in the local storage space based on the change information.

[0104] When it is determined that the target service is an accessed service of the working node, the forwarding information of the target service can be searched in the local storage space of the working node. When the forwarding information is found, the service container group corresponding to the target service is determined based on the forwarding information of the target service obtained, and the access request is sent to the service container group.

[0105] Through the above processing method, for access requests to accessed services, forwarding information can be searched in the local storage space; for access requests to unaccessed services, forwarding information of the service can be requested from the service node. Through this processing method, there is no need to obtain the full forwarding information of the service from the service node, thereby reducing the pressure on the kube-apiserver in the K8s cluster and improving the stability of the K8s cluster.

[0106] In an optional implementation, the above step S101 of determining whether the target service is an accessed service of the working node itself specifically includes the following steps:

[0107] Step S11: obtaining a preset service interception rule; wherein the service interception rule is used to intercept a service that requires obtaining forwarding information from the service node;

[0108] Step S12: When it is determined that the target service matches the service interception rule, it is determined that the target service is not an accessed service.

[0109] In an embodiment of the present disclosure, an interception function is pre-added to the kernel of each working node. By adding this interception function, the kernel of the working node can determine whether the target service is an accessed service of the working node after obtaining an access request to the target service.

[0110] In an optional implementation, a service interception component can be set up in each worker node. When the worker node starts, the service interception component (ServiceIntercept) starts. After ServiceIntercept starts, it configures the Service Cidr interception rules in the worker node's kernel. Service Cidr can be understood as the virtual IP address of the service in the K8s cluster.

[0111] In another optional implementation, the service interception function can also be set up in the worker node through the Sidecar design pattern. Here, the Sidecar design pattern allows many functions to be added to the worker node without the configuration and code of additional third-party components.

[0112] Here, for the added interception function, a pre-set service interception rule can be obtained, wherein, if it is determined that the target service hits the service interception rule, it can be determined that the target service is not an accessed service; otherwise, it can be determined that the target service is an accessed service.

[0113] In an optional implementation, determining that the target service matches the service interception rule includes:

[0114] Obtain a target service list; wherein the target service list includes service identification information of services that have been accessed by the working node;

[0115] When it is determined that the target service list does not include the service identification information of the target service, it is determined that the target service matches the service interception rule.

[0116] From the above description, we can know that when the worker node starts, kube-proxy can obtain the learned Service list from other worker nodes with the same role, and use the obtained Service list as the target service list of its own accessed services.

[0117] The target service list includes service identification information of each accessed service. For example, the service identification information may be information such as the namespace and service name of the accessed service.

[0118] In an embodiment of the present disclosure, after receiving the access request, the service identification information of the target service can be parsed from the access request, for example, the namespace and service name of the target service. The service identification information of the target service is then searched in the Watch list. If the service identification information of the target service is found in the Watch list, the target service is determined to be an already-accessed service of the worker node. If the service identification information of the target service is not found in the Watch list, the target service is determined not to be an already-accessed service of the worker node.

[0119] By configuring interception rules in the kernel, the kernel of the worker node can determine whether the target service is an accessed service of the worker node after receiving an access request to the target service, and then obtain the forwarding information of the service actually required, thereby reducing the request pressure on kube-proxy and kube-apiserver and ensuring the stability of cluster operation.

[0120] In an optional implementation, the technical solution provided by the embodiment of the present disclosure further includes the following steps:

[0121] If it is determined that the target service is not an accessed service, the service identification information of the target service is added to the target service list.

[0122] In an embodiment of the present disclosure, if it is determined that the target service is not an accessed service of the working node itself, then it can be determined that the Watch list does not contain the service identification information of the target service. At this time, the service identification information of the target service can be added to the Watch list. For example, information such as the namespace and service Name of the target service can be added to the Watch list.

[0123] If an access request for the target service is received again, the service identification information of the target service can be found in the Watch list, indicating that the target service is an accessed service of the working node. At this time, the forwarding information of the target service can be found in the local storage space of the working node, and the service container group corresponding to the target service can be determined based on the forwarding information of the target service found, and the access request can be sent to the service container group.

[0124] By adding the service identification information of the target service to the Watch list, you can intercept the service you actually need, thereby obtaining the forwarding information of the accessed service, reducing the request pressure on kube-proxy to kube-apiserver, and ensuring the stability of the cluster operation.

[0125] In an optional implementation, the technical solution provided by the embodiment of the present disclosure further includes the following steps:

[0126] Step S21: After obtaining the forwarding information of the target service from the service node based on the access request, storing the forwarding information of the target service in a local storage space;

[0127] Step S22: Detecting change information of the forwarding information of the target service; wherein the change information is used to indicate address change information of the service container group corresponding to the target service;

[0128] Step S23: updating the forwarding information of the target service in the local storage space based on the detected change information.

[0129] In the disclosed embodiment, if it is determined that the target service is not a service that the worker node has already accessed, then it can be determined that the service identification information of the target service is not included in the Watch list, and it can be determined that the forwarding information of the target service is not stored in the local storage space of the worker node. In this case, in order to quickly obtain the forwarding information of the target service when an access request to the target service is obtained again, the forwarding information of the target service can also be stored in the local storage space of the worker node.

[0130] Here, the detection process may also be used to detect change information of the target service's forwarding information, where the change information may be address change information of the service container group corresponding to the target service, such as migration, addition, deletion, and other change information of the service container group.

[0131] After the change information of the forwarding information of the target service is detected through the detection process, the forwarding information may be updated in the local storage space.

[0132] Through the above processing method, the forwarding information of the actually required Service can be recorded, ensuring the accuracy and real-time nature of the forwarding information of the Service, thereby improving the processing efficiency of the access request.

[0133] In an optional embodiment, the step S103 of obtaining the forwarding information of the target service from the service node based on the access request specifically includes the following steps:

[0134] Step S31: Parse the access request to obtain the address information of the target service;

[0135] Step S32: Sending an acquisition request carrying the address information to the service node;

[0136] Step S33: Acquire the forwarding information returned by the service node based on the acquisition request.

[0137] In the embodiment of the present disclosure, after obtaining the access request, the working node may parse the access request to obtain the address information of the target service. For example, the address information may be information such as ClusterIP and Port.

[0138] Cluster IP is the IP address of the Service, which is a virtual IP address. When nodes within the Kubernetes cluster access the service, they can obtain the virtual IP address through Cluster IP. Port is the port used to access the Service within the Kubernetes cluster (the port exposed by the Service on Cluster IP). In other words, a Service can be accessed through clusterIP:port.

[0139] After the address information is obtained through parsing, a request carrying the address information may be sent to the service node to request forwarding information of the target service.

[0140] After obtaining the address information, the service node can search for the address information in the pre-created association list, search for the forwarding information associated with the address information in the association list, and return the forwarding information to the working node, where the association list is used to record the address information of each Service and the forwarding information of the Service corresponding to the address information.

[0141] It can be seen from the above description that in the embodiment of the present disclosure, a service interception component is pre-set in each working node; when the working node is started, the service interception component is started. After the kernel of the working node obtains the access request, if it determines that the target service is not an accessed service of the working node itself, then the kernel can send the access request to the service interception component. After obtaining the access request, the service interception component parses the address information such as ClusterIP and Port of the target service in the access request, and sends the address information such as ClusterIP and Port to the service node. For example, the above address information can be sent to the Service Discovery component. The Service Discovery component can search for the forwarding information of the target service based on the address information, and return the forwarding information to the service interception component. The service interception component can send the received forwarding information to the kernel, so that the kernel determines the service container group corresponding to the target service based on the forwarding information of the target service obtained, and sends the access request to the service container group.

[0142] In an optional implementation, the technical solution provided by the embodiment of the present disclosure further includes the following steps:

[0143] Step S41: Acquire service usage information of the accessed service; wherein the service usage information is used to indicate the most recent usage time of the accessed service;

[0144] Step S42: Sending the service usage information to the service node; wherein the service node is used to manage the survival status of the accessed service based on the service usage information.

[0145] From the above description, it can be seen that in the embodiment of the present disclosure, a service interception function can be configured in the working node to discover the Service that needs to be intercepted through the service interception function; in addition, the service interception function can also be used to regularly report the service usage information of the Service (for example, the target service) that the working node has learned to the service node, so that the survival status of the target service can be managed through the service node.

[0146] Here, after detecting that the Service has been created, the forwarding information of the service can be managed through the service node. For example, the forwarding information of the service can be managed through the kube-apiserver; for another example, the forwarding information of the service can be managed through the Service Discovery component.

[0147] In addition, the state management node in the service node can also be used to manage the target service's survival status. This survival status includes normal and abnormal states. Normal states indicate that the service's forwarding information can be maintained; abnormal states indicate that the service's forwarding information is no longer maintained and that changes to the forwarding information are no longer being detected.

[0148] In an embodiment of the present disclosure, the working node can periodically obtain the service usage information of the target service, and after obtaining the service usage information of the target service, it can synchronize the service usage information to the state management node, and then manage the service usage information of the target service through the state management node.

[0149] Here, the service usage information may be the time of the most recent request to access the target service, that is, the most recent usage time of the target service by the workload.

[0150] Here, a validity period (TTL, Time To Live) may be set for the target service; the same validity period may be set for different target services, or different validity periods may be set for different target services. Here, there is no specific limitation on the setting of the validity period.

[0151] The state management node can determine whether the target service has exceeded its validity period based on the target service's service usage time. If the target service is determined to have exceeded its validity period based on the service usage time, the monitoring state of the target service is set to "abnormal survival state." Here, "abnormal survival state" can be understood as no longer maintaining the target service's forwarding information and no longer detecting changes to the forwarding information.

[0152] In an optional implementation, the working node may send the service usage information to the service discovery node, and the service discovery node may send the service usage information to the state management node.

[0153] Here, the service discovery node and the state management node can be the same node in the cluster or different nodes in the cluster.

[0154] In an optional implementation, the technical solution provided by the embodiment of the present disclosure further includes the following steps:

[0155] Step S51: After sending the service usage information to the service node, sending a detection request to the service node, wherein the detection request is used to request detection of invalid services whose time interval between the most recent usage time and the current time exceeds the validity period;

[0156] Step S52: obtaining service information of an invalid service in which the time interval between the most recently used time and the current time exceeds the valid time from among the services managed by the service node;

[0157] Step S53: Based on the service information, the forwarding information of the invalid service is deleted from the local storage space.

[0158] In an embodiment of the present disclosure, the state management node may periodically detect the time interval between the most recent usage time and the current time of each managed service and determine whether the time interval exceeds the service's validity period. If the time interval is determined to exceed the service's validity period, the service's survival state is determined to be "abnormal survival state." In this case, the failed service may be deleted from the services maintained by the state management node, or an invalidation flag may be set for the service, thereby indicating that the service is in an "abnormal survival state" through the invalidation flag.

[0159] After sending the service usage information to the service node (e.g., the state management node), the working node may send a detection request to the service node, requesting detection of failed services whose time interval between the most recent usage time and the current time exceeds the validity period. After sending the service usage information to the service node (e.g., the state management node), the working node may also periodically detect failed services among the services managed by the service node, and upon detecting a failed service, delete the forwarding information of the failed service from the local storage space.

[0160] Here, a service with an invalidation flag set can be determined as an invalid service. Alternatively, the service identification information of the service managed by the state management node can be compared with the service identification information of the accessed service in the working node. If the comparison shows that the accessed service in the working node is not included in the services managed by the state management node, the accessed service is determined to be an invalid service.

[0161] The above processing method can delete the forwarding information of services with low access frequency, thereby further reducing the pressure on the kube-apiserver in the K8s cluster and ensuring the stability of the cluster.

[0162] FIG3 is a flowchart of a method for scheduling a container group in a cluster according to an embodiment of the present disclosure. The method includes steps S301 to S303, wherein:

[0163] S301: Receive an acquisition request sent by a working node; wherein the acquisition request is a request for acquiring forwarding information of a target service sent by the working node when it determines that the target service requested to be accessed is not an accessed service.

[0164] In an embodiment of the present disclosure, a worker node may, in response to an access request to a target service of a Service, determine whether the target service is a service that the worker node has already accessed. If the worker node determines that the target service is not a service that the worker node has already accessed, the worker node may send a request to the service node to obtain forwarding information of the target service.

[0165] Here, a service node can also be referred to as a service discovery node. This service discovery node can be understood as a node in a K8s cluster that maintains forwarding information for all services in the K8s cluster. For example, the service discovery node can be a node that is configured with a kube-apiserver process. In addition, in the present disclosure, a set of Service Discovery components can also be configured in the K8s cluster, each component being used to maintain forwarding information for a set of Service services. In this case, a service discovery node can be understood as a node where a Service Discovery component is configured to maintain forwarding information for created services.

[0166] S302: Search for forwarding information of the target service based on the acquisition request.

[0167] S303: When the forwarding information is found, the forwarding information of the target service is sent to the working node.

[0168] After receiving the request, the service node searches its local storage for the target service's forwarding information and returns it to the current working node. The target service's forwarding information includes its namespace, service name, and endpoints. The endpoints identify one or more service container groups corresponding to the target service.

[0169] In the technical solution disclosed in the present invention, for the target service that the Pod in the working node needs to access and use, it can be set to obtain the forwarding information of the requested target service from the service node when the target service is not an accessed service. Through the above processing method, it is possible to set the service that needs to obtain forwarding information from the service node. For example, it can be set that the service that needs to obtain forwarding information from the service node is not an accessed service for the working node. On this basis, for each target service, it is not necessary to obtain the forwarding information of all target services from the service node. For the target service that needs to obtain forwarding information, the service node can be requested to obtain forwarding information. This processing method can reduce the pressure on the kube-apiserver in the K8s cluster and improve the stability of the K8s cluster.

[0170] In an optional embodiment, the method further comprises the following steps:

[0171] Obtaining service usage information of the accessed service sent by the working node; wherein the service usage information is used to indicate the most recent usage time of the accessed service by the workload;

[0172] Based on the service usage information of the accessed service, the survival status of the accessed service is managed.

[0173] In an embodiment of the present disclosure, a service interception function can be configured in the working node to discover the service that needs to be intercepted through the service interception function; in addition, the service usage information of the service that the working node has learned can be regularly reported to the service node through the service interception function, so that the survival status of the accessed service can be managed through the service node.

[0174] In the disclosed embodiments, the state management node in the service node can manage the life state of the accessed service. This life state includes a normal life state and an abnormal life state. The normal life state indicates that the forwarding information of the service can be maintained; the abnormal life state indicates that the forwarding information of the service is no longer maintained and that changes to the forwarding information are no longer being detected.

[0175] Here, the working node may periodically obtain the service usage information of the accessed service, and after obtaining the service usage information of the accessed service, may synchronize the service usage information to the state management node, and then manage the service usage information of the accessed service through the state management node.

[0176] The state management node can determine whether the accessed service has exceeded its validity period based on the service usage time of the accessed service. If the accessed service is determined to have exceeded its validity period based on the service usage time, the monitoring state of the accessed service is set to "abnormal survival state." Here, "abnormal survival state" can be understood as no longer maintaining the forwarding information of the accessed service and no longer detecting changes to the forwarding information.

[0177] In an optional implementation, the above steps of determining the survival status of the target service based on the service usage information of the target service specifically include the following steps:

[0178] Determine the time interval between the current moment and the service usage information;

[0179] In a case where it is determined that the time interval exceeds the validity period of the target service, the survival state of the target service is determined to be an abnormal survival state.

[0180] Here, the state management node can periodically detect the time interval between the most recent usage time and the current time of each managed service and determine whether the time interval exceeds the service's validity period. If the time interval is determined to exceed the service's validity period, the service's survival state is determined to be "abnormal." In this case, the failed service can be deleted from the services maintained by the state management node, or an invalidation flag can be set for the service, indicating that the service is in an "abnormal survival state" through the invalidation flag.

[0181] In an optional embodiment, the method further comprises the following steps:

[0182] Receive a detection request from the working node; wherein the detection request is used to request detection of an invalid service whose time interval between the most recently used time and the current time exceeds a valid time;

[0183] Based on the detection request, the failed service is searched, and the service identification information of the failed service found is fed back to the working node.

[0184] After sending the service usage information to a service node (e.g., a state management node), the worker node may also periodically send detection requests to the service node to request detection of failed services among the services managed by the service node. Upon detecting a failed service, the service node returns the service identification information of the failed service to the worker node. The worker node may then delete the forwarding information of the failed service from its local storage space.

[0185] Here, a service with an invalidation flag set can be determined as an invalid service. Alternatively, the service identification information of the service managed by the state management node can be compared with the service identification information of the accessed service in the working node. If the comparison shows that the accessed service in the working node is not included in the services managed by the state management node, the accessed service is determined to be an invalid service.

[0186] The above processing method can delete the forwarding information of services with low access frequency, thereby further reducing the pressure on the kube-apiserver in the K8s cluster and ensuring the stability of the cluster.

[0187] 4 is a flowchart of a method for scheduling a container group in a cluster provided by an embodiment of the present disclosure. The method includes steps S401 to S411, wherein:

[0188] S401: The service interception component sends interception rules to the kernel of the working node.

[0189] Here, the service interception component runs on each working node and is responsible for configuring interception rules on the working node. By configuring the interception rules, access requests to the service that hit the interception rules can be processed.

[0190] When a worker node starts, its kube-proxy has not yet learned any services. At this point, the worker node's kube-proxy can obtain a list of learned services from other worker nodes with the same role. Other worker nodes with the same role can be understood as nodes that support the same type of workload as the current worker node. When a worker node starts, the service interception component is activated. After the service interception component is activated, it configures the service CIDR interception rules in the worker node's kernel.

[0191] In an optional implementation, a service interception component may be set in each working node; when the working node is started, the service interception component is started, and after the service interception component is started, the Service Cidr interception rule is configured in the kernel of the working node.

[0192] In another optional implementation, the service interception function can also be set up in the worker node through the Sidecar design pattern. Here, the Sidecar design pattern allows many functions to be added to the worker node without the configuration and code of additional third-party components.

[0193] S402: After detecting the first access request of the container to the target service, the container of the working node sends the first access request to the target service to the kernel.

[0194] S403: When the kernel determines that the target service hits the interception rule, it sends the access request to the service interception component.

[0195] The kernel can obtain a target service list, which includes service identification information for services already accessed by the worker node. If the kernel determines that the target service's service identification information is not included in the target service list, it determines that the target service is not an already accessed service, that is, it can determine that the target service hits the interception rule. At this point, the access request sent by the container is routed to the service interception component.

[0196] S404: The service interception component sends an acquisition request carrying address information to the service discovery node.

[0197] After receiving the access request, the service interception component can parse the access request to obtain the address information. For example, it can parse the access request to obtain the ClusterIP and Port of the target service that the container wants to access. Then, based on this address information, it sends a request to Service Discovery.

[0198] S405: The service discovery node sends the forwarding information to the service interception component.

[0199] The service discovery component is centrally deployed in the cluster. The service discovery node can maintain the forwarding information of all services in the cluster. That is, the service discovery node has the forwarding information of all services; the forwarding information includes the Service Name, space / Name, and Endpoints.

[0200] After receiving the acquisition request, the service discovery node may search for the forwarding information of the target service based on the address information, and send the forwarding information to the service interception component if the forwarding information is found.

[0201] S406: The service interception component transmits the forwarding information to the kernel.

[0202] S407: The kernel sends an access request to the service container group based on the forwarding information.

[0203] The service interception component can forward the received access request to the target endpoints address through the kernel to complete the request within the Pod; among them, the target endpoints address is used to indicate the service container group corresponding to the target service.

[0204] S408: The service interception component notifies kube-proxy to add the service identification information of the target service to the target service list.

[0205] S409: kube-proxy obtains the forwarding information of the target service.

[0206] S410: kube-proxy notifies the kernel of the working node to update the forwarding information of the target service.

[0207] Here, after obtaining the forwarding information, it can also be delivered to kube-proxy, which then knows that it needs to manage this newly discovered target service. Then, kube-proxy will actively obtain the forwarding information of the target service.

[0208] S411: After detecting that the container is not making the first access request to the target service, the container sends the non-first access request to the target service to the kernel.

[0209] S412: The kernel sends an access request to the service container group based on the forwarding information.

[0210] It should be noted that the execution order between S402 and S410 is not restricted, and the execution order between S411 and S412 is not restricted.

[0211] When the kernel determines that the target service list contains the service identification information of the target service, it determines that the target service is an accessed service. At this time, the kernel can directly obtain the forwarding information in the local storage space, and determine the service container group corresponding to the target service based on the obtained forwarding information of the target service, and send the access request to the service container group.

[0212] In the above implementation mode, it can be set to obtain the forwarding information of the requested target service from the service node when the target service is not an accessed service, thereby realizing the service of setting the forwarding information to be obtained from the service node. Through this processing method, it is not necessary to obtain the full forwarding information of the service from the service node, thereby reducing the pressure on the kube-apiserver in the K8s cluster and improving the stability of the K8s cluster.

[0213] It should be noted that in Figure 4, kube-proxy is marked as the first component of K8s. This is only an example and is not a limitation.

[0214] 5 , which is a flowchart of a cluster container group scheduling system provided by an embodiment of the present disclosure, the system includes: a working node 10 and a service node 20 .

[0215] Here, there may be multiple working nodes 10 in the cluster, and the service node may be set on the master node of the cluster. In addition, the service node may also be set on other nodes in the cluster except the master node.

[0216] The working node 10 is configured to receive an access request for a target service; if it is determined that the target service is not a monitored service, send a get request to the service node; and determine the service container group corresponding to the target service based on the obtained forwarding information of the target service, and send the access request to the service container group; wherein the get request is used to request information about the forwarding information of the target service.

[0217] Here, the specific functions and steps performed by the working node are as described in the above embodiment and will not be repeated here in detail.

[0218] The service node 20 is configured to receive the acquisition request and search for the forwarding information of the target service based on the acquisition request; and send the forwarding information of the target service to the working node if the forwarding information is found.

[0219] Here, the specific functions and steps performed by the service node are as described in the above embodiment and will not be repeated here in detail.

[0220] In the technical solution disclosed in the present invention, for the target service that the Pod in the working node needs to access and use, it can be set to obtain the forwarding information of the requested target service from the service node when the target service is not an accessed service. Through the above processing method, it is possible to set the service that needs to obtain forwarding information from the service node. For example, it can be set that the service that needs to obtain forwarding information from the service node is not an accessed service for the working node. On this basis, for each target service, it is not necessary to obtain the forwarding information of all target services from the service node. For the target service that needs to obtain forwarding information, the service node can be requested to obtain forwarding information. This processing method can reduce the pressure on the kube-apiserver in the K8s cluster and improve the stability of the K8s cluster.

[0221] FIG6 shows a flow chart of a cluster container group scheduling system provided by an embodiment of the present disclosure. The system includes: kube-apiserver (61), a service discovery component (62), container group A (63), and container group B (64). Container group A includes a container, a kernel, a kube-proxy, and a service interception component. It should be noted that in FIG6 , kube-proxy is marked as the first component of K8s, and kube-apiserver is marked as the second component of K8s. This is for illustrative purposes only and is not intended to be limiting.

[0222] As shown in Figure 6, the container can send an access request to the target service; after receiving the access request, if the kernel determines that the target service is accessed for the first time, the kernel intercepts the access request through the interception rules configured in the kernel, and sends a request to the service discovery component through the service interception component to request the forwarding information of the target service from the service discovery component. The forwarding information sent by Service Discovery is obtained through the service interception component, and the forwarding information is sent to the kernel so that the kernel forwards the access request to the service container group corresponding to the target service (for example, container group B). If it is determined that this is not the first time to access the target service, the kernel searches for the forwarding information of the target service and forwards the access request to the service container group corresponding to the target service (for example, container group B) based on the forwarding information.

[0223] Here, the service discovery component can obtain the forwarding information of all services from the kube-apiserver. The forwarding information stored in the local storage space of container group A can be the forwarding information of the required services obtained by container group A from the kube-apiserver.

[0224] From the above description, it can be seen that the embodiments of the present disclosure can actively discover the services used by the container group. In this case, there is no need to fully load the forwarding information of all services in the cluster, which reduces the resource usage of the client and the pressure on the kube-apiserver. This allows small-scale eci pods to run well in large clusters and reduces the hosting cost of the K8s cluster.

[0225] Those skilled in the art will understand that in the above-mentioned method of the specific implementation method, the writing order of each step does not mean a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0226] Based on the same inventive concept, the embodiments of the present disclosure also provide a cluster container group scheduling device corresponding to the cluster container group scheduling method. Since the principle of solving the problem by the device in the embodiments of the present disclosure is similar to that of the cluster container group scheduling method in the embodiments of the present disclosure, the implementation of the device can refer to the implementation of the method, and the repeated parts are not repeated here.

[0227] 7 , which is a schematic diagram of the architecture of a cluster container group scheduling device provided by an embodiment of the present disclosure, the device includes: a first receiving unit 71 , an acquiring unit 72 , and a determining unit 73 ; wherein,

[0228] A first receiving unit is configured to receive an access request for a target service;

[0229] an acquiring unit configured to acquire, when determining that the target service is not an accessed service, forwarding information of the target service from a service node based on the access request; wherein the service node stores forwarding information of services created in the cluster;

[0230] The determining unit is configured to determine a service container group corresponding to the target service based on the acquired forwarding information of the target service, and send the access request to the service container group.

[0231] In the above implementation mode, it can be set that when the target service is not an accessed service of the working node, the forwarding information of the target service requested by the resource requesting node is obtained from the service node, thereby realizing the service of setting the forwarding information to be obtained from the service node. Through this processing method, it is not necessary to obtain the full forwarding information of the service from the service node, thereby reducing the pressure on the kube-apiserver in the K8s cluster and improving the stability of the K8s cluster.

[0232] In one possible implementation, the device further includes: a first comparison unit, configured to: obtain a pre-set service interception rule; wherein the service interception rule is used to intercept a service that requires obtaining forwarding information from the service node; and when it is determined that the target service matches the service interception rule, determine that the target service is not an accessed service.

[0233] In one possible implementation, the device further includes: a second comparison unit, configured to: obtain a target service list; wherein the target service list includes service identification information of services that have been accessed by the working node; and when it is determined that the target service list does not contain the service identification information of the target service, determine that the target service is not the accessed service.

[0234] In a possible implementation manner, the apparatus further includes: an adding unit configured to: add service identification information of the target service to the target service list when it is determined that the target service is not an accessed service.

[0235] In one possible implementation, the device further includes: a storage unit configured to: store the forwarding information of the target service in a local storage space after obtaining the forwarding information of the target service from the service node based on the access request; detect change information of the forwarding information of the target service; wherein the change information is used to indicate address change information of the service container group corresponding to the target service; and update the forwarding information of the target service in the local storage space based on the detected change information.

[0236] In one possible implementation, the acquisition unit is further configured to: parse the access request to obtain the address information of the target service; send an acquisition request carrying the address information to the service node; and obtain the forwarding information returned by the service node based on the acquisition request.

[0237] In one possible implementation, the device further includes: a sending unit configured to: obtain service usage information of the accessed service; wherein the service usage information is used to indicate the most recent usage time of the accessed service; and send the service usage information to the service node; wherein the service node is used to manage the survival status of the accessed service based on the service usage information.

[0238] In one possible implementation, the device further includes: a deletion unit configured to: after sending the service usage information to the service node, detect, among the services managed by the service node, an invalid service whose time interval between the most recent usage time and the current time exceeds a valid time; and delete the forwarding information of the invalid service in the local storage space.

[0239] In one possible implementation, the device further includes: a search unit configured to: upon determining that the target service is the accessed service, search for forwarding information of the target service in a local storage space; determine a service container group corresponding to the target service based on the obtained forwarding information of the target service; and send the access request to the service container group.

[0240] 8 , which is a schematic diagram of the architecture of a cluster container group scheduling device provided by an embodiment of the present disclosure, the device includes: a second receiving unit 81 , a search unit 82 , and a sending unit 83 ; wherein,

[0241] The second receiving unit 81 is configured to receive an acquisition request sent by a working node; wherein the acquisition request is a request for obtaining forwarding information of the target service sent by the working node when it is determined that the target service requested to be accessed is not an accessed service;

[0242] A search unit 82 is configured to search for forwarding information of the target service based on the acquisition request;

[0243] The sending unit 83 is configured to send the forwarding information of the target service to the working node when the forwarding information is found.

[0244] In one possible implementation, the device is further configured to: obtain service usage information of the accessed service sent by the working node; wherein the service usage information is used to indicate the workload's most recent usage time of the accessed service; and manage the survival status of the accessed service based on the service usage information of the accessed service.

[0245] In one possible implementation, the device is further configured to: determine the time interval between the current moment and the service usage information; if it is determined that the time interval exceeds the valid time of the accessed service, determine that the survival state of the accessed service is an abnormal survival state; if it is determined that the time interval does not exceed the valid time of the accessed service, determine that the survival state of the accessed service is a normal survival state.

[0246] In one possible implementation, the device is further configured to: receive a detection request from the working node; wherein the detection request is used to request detection of an invalid service whose time interval between the most recently used time and the current time exceeds a valid time; based on the detection request, search for the invalid service, and feed back the service identification information of the invalid service found to the working node.

[0247] For descriptions of the processing flow of each module in the device and the interaction flow between each module, reference can be made to the relevant descriptions in the above method embodiment, which will not be described in detail here.

[0248] Another embodiment of the present disclosure provides a computer device, which can be a device used for cluster container group scheduling on an industrial production line such as a host computer. The computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor executes the program to implement the cluster container group scheduling method of any of the above-mentioned embodiments.

[0249] As shown in Figure 9, the computer device 90 may include: a processor 900, a memory 901, a bus 902 and a communication interface 903. The processor 900, the communication interface 903 and the memory 901 are connected via the bus 902; the memory 901 stores a computer program that can be run on the processor 900, and when the processor 900 runs the computer program, it executes the method provided in any of the aforementioned embodiments of the present disclosure.

[0250] The memory 901 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage. The system network element communicates with at least one other network element via at least one communication interface 903 (which may be wired or wireless), and may utilize the Internet, a wide area network, a local area network, a metropolitan area network, or the like.

[0251] Bus 902 may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. Buses may be classified as address buses, data buses, control buses, and the like. Memory 901 is configured to store programs, and processor 900 executes the programs upon receiving execution instructions. The methods disclosed in any of the aforementioned embodiments of the present disclosure may be applied to or implemented by processor 900.

[0252] The processor 900 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method may be completed by hardware integrated logic circuits or software instructions in the processor 900. The processor 900 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The methods, steps, and logic block diagrams disclosed in the embodiments of the present disclosure may be implemented or executed. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in conjunction with the embodiments of the present disclosure may be directly implemented and executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module may be located in a storage medium mature in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. The storage medium is located in the memory 901 , and the processor 900 reads the information in the memory 901 and completes the steps of the above method in combination with its hardware.

[0253] The computer device provided by the embodiment of the present disclosure and the method provided by the embodiment of the present disclosure are based on the same inventive concept and have the same beneficial effects as the method adopted, operated or implemented by them.

[0254] Another embodiment of the present disclosure provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the method for scheduling a container group in a cluster according to any of the above embodiments.

[0255] Referring to FIG. 10 , the computer-readable storage medium shown therein is a CD 100 on which a computer program (ie, a program product) is stored. When the computer program is executed by a processor, the method provided in any of the aforementioned embodiments is executed.

[0256] It should be noted that examples of computer-readable storage media may also include, but are not limited to, Parallel Random Access Machine (PRAM), Static Random-Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read-Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other optical or magnetic storage media, which are not listed here one by one.

[0257] Another embodiment of the present disclosure provides a computer program product, including a computer program, which is executed by a processor to implement the cluster container group scheduling method of any of the above embodiments.

[0258] The computer-readable storage medium and computer program product provided by the above-mentioned embodiments of the present disclosure are based on the same inventive concept as the method provided by the embodiments of the present disclosure, and have the same beneficial effects as the method adopted, run or implemented by the application program stored therein.

[0259] It should be noted that:

[0260] The term "module" is not intended to be limited to a specific physical form. Depending on the specific application, a module can be implemented as hardware, firmware, software, and / or a combination thereof. In addition, different modules can share common components or even be implemented by the same components. There may or may not be clear boundaries between different modules.

[0261] The algorithms and displays provided herein are not inherently related to any particular computer, virtual device, or other device. Various general-purpose devices may also be used together with the examples based thereon. Based on the above description, it is apparent that the structure required for constructing such devices is suitable. In addition, the present disclosure is not directed to any specific programming language. It should be understood that various programming languages ​​may be utilized to implement the present disclosure described herein, and the above description of specific languages ​​is intended to disclose embodiments of the present disclosure.

[0262] It should be understood that although the steps in the flowcharts of the accompanying drawings are shown in sequence as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some of the steps in the flowcharts of the accompanying drawings may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be executed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

[0263] The above embodiments merely represent implementation methods of the present disclosure, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the present invention. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the scope of the present disclosure, and these modifications and improvements fall within the scope of protection of the present disclosure. Therefore, the scope of protection of the present disclosure shall be based on the appended claims.

Claims

1. A scheduling method for a container group in a cluster, the cluster including worker nodes and service nodes, at least one container group being included in the worker nodes, and the service nodes being used to store forwarding information of services used by the container groups in the worker nodes. The method is applied to a worker node and includes: Receiving an access request for a target service; When it is determined that the target service is not an accessed service, obtaining the forwarding information of the target service from the service node based on the access request; wherein, the accessed service is used to indicate a service that is not requested to access the worker node for the first time, and / or a service that has not exceeded the valid time among the services requested to access the worker node at a historical moment; Determining the service container group corresponding to the target service based on the obtained forwarding information of the target service, and sending the access request to the service container group.

2. The method according to claim 1, wherein The determining that the target service is not an accessed service includes: Obtaining a pre-set service interception rule; wherein, the service interception rule is used to intercept services that need to obtain forwarding information from the service node; When it is determined that the target service matches the service interception rule, determining that the target service is not an accessed service.

3. The method according to claim 2, wherein The determining that the target service matches the service interception rule includes: Obtaining a target service list; wherein, the target service list includes service identification information of services accessed by the worker node; When it is determined that the service identification information of the target service is not included in the target service list, determining that the target service matches the service interception rule.

4. The method according to claim 3, wherein The method further includes: When it is determined that the target service is not an accessed service, adding the service identification information of the target service to the target service list.

5. The method according to claim 1, wherein, The method further includes: After obtaining the forwarding information of the target service from the service node based on the access request, storing The forwarding information of the target service in the local storage space; Detecting change information of the forwarding information of the target service; wherein, the change information is used to indicate address change information of the service container group corresponding to the target service; Updating the forwarding information of the target service in the local storage space based on the detected change information.

6. The method according to claim 1, wherein The method further includes: Obtaining service usage information of the accessed service; wherein, the service usage information is used to indicate the most recent usage time of the accessed service; Sending the service usage information to the service node; wherein, the service node is used to manage the survival status of the accessed service based on the service usage information.

7. The method according to claim 6, wherein, The method further includes: After sending the service usage information to the service node, sending a detection request to the service node, wherein the detection request is used to request detecting invalid services whose time interval between the most recent usage time and the current time exceeds the valid time; Obtaining service information of invalid services whose time interval between the most recent usage time and the current time exceeds the valid time among the services managed by the service node; Based on the service information, deleting the forwarding information of the invalid services in the local storage space.

8. The method according to any one of claims 1-7, wherein The method further includes: When it is determined that the target service is the accessed service, searching for the forwarding information of the target service in the local storage space; Determining the service container group corresponding to the target service based on the obtained forwarding information of the target service; Sending the access request to the service container group.

9. A method for scheduling a container group of a cluster, the cluster including worker nodes and service nodes, at least one container group being included in the worker nodes, and the service nodes being used to store the forwarding information of the services used by the container groups in the worker nodes, the method being applied to the service nodes and including: Receiving an acquisition request sent by a worker node; wherein, the acquisition request is a request for acquiring the forwarding information of the target service sent by the worker node when it is determined that the target service requested to be accessed is not an accessed service; Searching for the forwarding information of the target service based on the acquisition request; When the forwarding information is found, sending the forwarding information of the target service to the worker node.

10. The method according to claim 9, wherein The method further includes: Obtaining the service usage information of the accessed service sent by the worker node; wherein, the service usage information is used to indicate the most recent usage time of the workload for the accessed service; Managing the survival state of the accessed service based on the service usage information of the accessed service.

11. The method according to claim 10, wherein, The determining the survival state of the target service based on the service usage information of the target service includes: Determining the time interval between the current moment and the service usage information; When it is determined that the time interval exceeds the effective time of the accessed service, determining the survival state of the accessed service as an abnormal survival state; When it is determined that the time interval does not exceed the effective time of the accessed service, determining the survival state of the accessed service as a normal survival state.

12. The method according to claim 10, wherein, The method further includes: Receiving a detection request from the worker node; wherein, the detection request is used to request detecting the invalid services whose time interval between the most recent usage time and the current time exceeds the effective time; Searching for the invalid services based on the detection request, and feeding back the service identification information of the found invalid services to the worker node.

13. A container group scheduling system for a cluster, comprising: Worker nodes and service nodes; The worker node is configured to receive an access request for a target service; When it is determined that the target service is not a listened service, sending an acquisition request to the service node; and determining the service container group corresponding to the target service based on the obtained forwarding information of the target service, and sending the access request to the service container group; wherein, the acquisition request is used to request the information of the forwarding information of the target service; The service node is configured to receive the acquisition request, and search for the forwarding information of the target service based on the acquisition request; when the forwarding information is found, sending the forwarding information of the target service to the worker node.

14. A computer device, comprising: A processor, a memory, and a bus, where the memory stores machine-readable instructions executable by the processor. When the computer device runs, the processor communicates with the memory through the bus. When the machine-readable instructions are executed by the processor, the steps of the container group scheduling method of the cluster according to any one of claims 1 to 12 are executed.

15. A container group scheduling device for a cluster, where the cluster includes worker nodes and service nodes. At least one container group is included in the worker nodes, and the service nodes are used to store forwarding information of services used by the container groups in the worker nodes. The device is applied to the worker nodes and includes: A first receiving unit, configured to receive an access request for a target service; An obtaining unit, configured to, when determining that the target service is not an accessed service, obtain the forwarding information of the target service from the service node based on the access request; where the accessed service is used to indicate a service that is not the first time to request access to the worker node and / or a service that has not exceeded the effective time among the services that requested access to the worker node at a historical moment; A determining unit, configured to determine a service container group corresponding to the target service based on the obtained forwarding information of the target service, and send the access request to the service container group.

16. A computer program product, characterized in that, It includes a computer program, and when the computer program is executed by a processor, it implements the container group scheduling method of the cluster according to any one of claims 1 to 12.

Images