Container unit scheduling method, server, program product and storage medium

Abstract

The embodiments of the present disclosure provide a container unit scheduling method, a server, a program product and a storage medium. The container unit scheduling method comprises: in response to a scheduling request for a first container unit, acquiring service dependency information of the first container unit; on the basis of the service dependency information, determining from among a plurality of candidate computing nodes a target candidate computing node for deploying the first container unit; and after the target computing node is determined, creating the first container unit on the target candidate computing node, wherein the service dependency information is acquired on the basis of traffic monitoring data of a first workload in the first container unit over historical periods, thereby enabling feedback on the actual dependency of the first workload on other services. Thus, using service dependency information as the basis for scheduling container units to select candidate nodes can facilitate scheduling of container units having a dependency relationship to the same computing node, so that it is not necessary for different container units having a dependency relationship to perform communication interaction across nodes.

Description

[0001] Container Unit Scheduling Method, Server, Program Product, and Storage Medium TECHNICAL FIELD The present disclosure relates to the field of computer technology, and more particularly to a container unit scheduling method, server, program product, and storage medium. Background: Service mesh is often used to describe the microservice network that constitutes an application and the interactions between applications. As the infrastructure layer that handles inter-service communication, the service mesh is responsible for constructing the complex service topology of modern cloud-native applications to reliably deliver requests. In a service mesh, services can be deployed in pods (the smallest container deployment unit), and the scheduler in the container cluster management system can schedule the pods. The scheduler selects a candidate compute node from the server cluster and binds the pod to the candidate compute node. The candidate compute node agent component in the candidate compute node creates and starts the containers in the pod. Some existing pod scheduling solutions typically schedule pods based on metrics such as available resources on the candidate compute node, network throughput, and communication latency. This approach is not conducive to improving the access efficiency of service calls between different pods. Therefore, a new solution is needed. SUMMARY OF THE INVENTION Various aspects of the present disclosure provide a container unit scheduling method, server, program product, and storage medium for improving the rationality of container unit scheduling, thereby increasing the access efficiency of service calls between different container units. An embodiment of the present disclosure provides a container unit scheduling method, comprising: in response to a scheduling request for a first container unit, obtaining service dependency information for the first container unit; obtaining the service dependency information based on traffic monitoring data of a first workload in the first container unit over a historical period; determining a target candidate computing node for deploying the first container unit from multiple candidate computing nodes based on the service dependency information; and creating the first container unit on the target candidate computing node to schedule the first container unit to the target candidate computing node. Optionally, determining, based on the service dependency information, a target candidate computing node for deploying the first container unit from multiple candidate computing nodes includes: filtering candidate computing nodes in a node cluster based on resources required by the first container unit and / or preset constraints to obtain the multiple candidate computing nodes; scoring the multiple candidate computing nodes based on the service dependency information of the first container unit to obtain scores for each of the multiple candidate computing nodes; and determining the target candidate computing node from the multiple candidate computing nodes based on the scores for each of the multiple candidate computing nodes.Optionally, scoring the multiple candidate compute nodes based on the service dependency information of the first container unit to obtain scores for each of the multiple candidate compute nodes includes: when scoring any candidate compute node among the multiple candidate compute nodes, querying the definition information of the first container unit for the first workload corresponding to the first container unit; obtaining at least one workload on which the first workload depends from a configuration file of the first workload; traversing the at least one workload and scoring the candidate compute node based on a dependency weight between the traversed workload and the first workload. Optionally, traversing the at least one workload and scoring the candidate compute node based on a dependency weight between the traversed workload and the first workload includes: when traversing any workload among the at least one workload, determining whether the workload is running on the candidate compute node; and if the workload is running on the candidate compute node, scoring the candidate compute node based on the dependency weight corresponding to the workload. Optionally, the method further includes: if the workload is not running on the candidate computing node, setting the score of the candidate computing node to a score below a set threshold. Optionally, querying the definition information of the first container unit for the first workload corresponding to the first container unit includes: determining, based on the definition information of the first container unit, whether the first container unit belongs to any target application group; if the first container unit belongs to the target application group, determining whether the target application group includes a parent workload of the first container unit; if the target application group includes the parent workload, using the parent workload as the first workload corresponding to the first container unit. Optionally, before obtaining service dependency information for the first container unit, the method further includes: obtaining, through a first grid agent component of the first workload, traffic monitoring data of the first workload; determining, based on the traffic monitoring data of the first workload, at least one workload that has a dependency relationship with the first workload; calculating, based on the traffic monitoring data of the first workload, a dependency weight of the first workload on the at least one workload; and storing the at least one workload and its corresponding dependency weight as the dependency relationship of the first workload in a configuration file of the first workload.Optionally, obtaining the traffic monitoring data of the first workload includes at least one of the following: using a preset traffic statistical indicator to count the inlet traffic and / or outlet traffic of the first workload to obtain the value of the traffic statistical indicator; obtaining an access log from the inlet traffic and / or outlet traffic of the first workload; the access log includes: identification information of the upstream workload, identification information of the downstream workload, and at least one of the protocol type; tracing the path of the access request processed by the first workload to obtain a request processing path of the access request; the request processing path includes: an ordered link formed by the workload for processing the access request. Optionally, a second container unit is running on the target candidate compute node, and the container unit is configured to run a second workload corresponding to the target service. After creating the first container unit on the target candidate compute node, the method further includes: obtaining an access request from the first workload via a first grid proxy component corresponding to the first workload; if the access request is for accessing the target service, intercepting the access request and, based on a preset local redirection policy, forwarding the access request to a second grid proxy component corresponding to the second workload; and forwarding the access request to the second workload via the second grid proxy component, so that the second workload performs a data processing operation corresponding to the target service on the access request. Optionally, forwarding the access request to the second grid proxy component corresponding to the second workload based on the preset local redirection policy includes: obtaining a traffic type corresponding to the access request and / or a container unit selection condition corresponding to the first workload; and if the traffic type meets a preset type requirement and / or the second container unit meets the container unit selection condition, forwarding the access request to the second grid proxy component corresponding to the second workload. Optionally, forwarding the access request to the second grid proxy component corresponding to the second workload includes: obtaining quad-tuple information of the access request through a first socket in the first grid proxy component; querying a preset socket mapping relationship based on the quad-tuple information to obtain an operation handle for a second socket in the second grid proxy component; and sending the access request to the second socket based on the operation handle for the second socket. Embodiments of the present disclosure also provide a server comprising: a memory and a processor; the memory being configured to store one or more computer instructions; and the processor being configured to execute the one or more computer instructions to perform the steps of the method provided in embodiments of the present disclosure.The present disclosure also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program can implement the steps of the method provided in the present disclosure. The present disclosure also provides a computer program product, including a computer program / instructions. When executed by a processor, the computer program / instructions can implement the steps of the method provided in the present disclosure. In this embodiment, in response to a scheduling request for a first container unit, service dependency information of the first container unit can be obtained. Based on the service dependency information, a target candidate computing node for deploying the first container unit can be determined from multiple candidate computing nodes. After determining the target computing node, the first container unit can be created on the target candidate computing node. The service dependency information is obtained based on traffic monitoring data of the first workload in the first container unit over a historical period, thereby providing feedback on the actual dependency of the first workload on other services. Furthermore, using the service dependency information as a basis for scheduling container units to select candidate nodes can facilitate scheduling dependent container units onto the same computing node, eliminating the need for cross-node communication between dependent container units. When dependencies exist between different container units, the network resources required for communication between them can be effectively reduced. Furthermore, efficient communication mechanisms within computing nodes can be leveraged to improve communication efficiency and service access efficiency between them, significantly improving workload service processing performance, service processing efficiency, and service response efficiency. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings described herein are provided to provide a further understanding of the present disclosure and constitute a part thereof. The exemplary embodiments of the present disclosure and their descriptions are intended to explain the present disclosure and do not constitute undue limitations thereon. In the accompanying drawings: FIG1 is a schematic diagram of a service grid provided by an exemplary embodiment of the present disclosure; FIG2 is a flow diagram of a container unit scheduling method provided by an exemplary embodiment of the present disclosure; FIG3 is a schematic diagram of a service grid component for executing the container unit scheduling method provided by an exemplary embodiment of the present disclosure; FIG4 is a schematic diagram of socket data stream processing in a local computing node provided by an exemplary embodiment of the present disclosure; and FIG5 is a schematic diagram of the server structure provided by an exemplary embodiment of the present disclosure. DETAILED DESCRIPTION To further clarify the objectives, technical solutions, and advantages of the present disclosure, the technical solutions of the present disclosure will be described clearly and completely below in conjunction with the specific embodiments of the present disclosure and the corresponding drawings. Obviously, the described embodiments are only some of the embodiments of this disclosure, and not all of them. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of this disclosure without inventive effort are within the scope of protection of this disclosure.The terms used in the embodiments of this disclosure are for the purpose of describing specific embodiments only and are not intended to limit this disclosure. As used in the embodiments of this disclosure and the appended claims, the singular forms "a," "an," "the," and "the" are intended to include the plural forms, unless the context clearly indicates otherwise. "A plurality" generally includes at least two, but does not exclude the inclusion of at least one. It should be understood that the term "and / or" as used herein is merely a description of an associative relationship between associated elements, indicating that three possible relationships exist. For example, "A and / or B" can mean: A alone, A and B simultaneously, or B alone. Furthermore, the character " / " as used herein generally indicates that the associated elements are in an "or" relationship. It should also be noted that the terms "comprise," "include," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a product or system comprising a list of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such product or system. Without further restriction, elements defined by the phrase "comprising a..." do not preclude the presence of other identical elements in the product or system that includes the element. To more clearly describe the technical solutions provided by various embodiments of the present disclosure, the following introduces the service mesh architecture and some related concepts involved in the embodiments of the present disclosure. A service mesh is a dedicated infrastructure layer used to implement reliable, fast, and secure inter-service calls in a microservices architecture. A service mesh primarily facilitates secure and reliable communication between multiple microservices. Microservices refer to applications that are broken down into multiple smaller services or instances and distributed across different clusters / machines. An application service instance can also be referred to as a workload. Each application service instance is bound to a mesh proxy to facilitate communication and management between services. As shown in Figure 1, microservices include application service instance A and application service instance B, which form the functional application layer of service mesh 100. In one embodiment, application service instances A and B run as containers / processes on a machine / workload container group. In one implementation, application service instance A may be a product query service, and application service instance B may be a product ordering service.As shown in Figure 1, application service instance A and grid proxy (sidecar) 103 coexist in machine / workload container group 109, while application service instance B and grid proxy 105 coexist in machine / workload container group 110. Grid proxy 103 and grid proxy 105 form the data plane of service grid 100. Grid proxy 103 and grid proxy 105 run as container / process 104 and container / process 106, respectively. Application service instance A and application service instance B run as container / process 107 and container / process 108, respectively. Bidirectional communication is possible between grid proxy 103 and application service instance A, and between grid proxy 105 and application service instance B. Furthermore, bidirectional communication is possible between grid proxy 103 and grid proxy 105. In one embodiment, all traffic for application service instance A is routed to the appropriate destination through grid proxy 103, and all network traffic for application service instance B is routed to the appropriate destination through grid proxy 105. In one embodiment, the functionality of the data plane layer can be extended by writing custom filters for the proxy (Envoy) in service mesh 100. Mesh proxy configuration can be designed to enable the service mesh to correctly proxy service traffic, enabling service interoperability and service governance. Mesh proxy 103 and mesh proxy 105 can be configured to perform at least one of the following functions: service discovery, health checking, routing, load balancing, authentication and authorization, and observability. As shown in Figure 1, service mesh 100 also includes a control plane layer. The control plane layer can be composed of a set of services running in a dedicated namespace, hosted by a managed control plane component 101 on a machine / workload container group (machine / pod) 102. As shown in Figure 1, managed control plane component 101 communicates bidirectionally with mesh proxy 103 and mesh proxy 105. Managed control plane component 101 is configured to perform certain control and management functions. For example, the managed control plane component 101 receives telemetry data transmitted by the grid agent 103 and the grid agent 105 and may further aggregate the telemetry data.These services, including the managed control plane component 101, can also provide user-oriented application programming interfaces (APIs) to easily manipulate network behavior and provide configuration data to the grid agents 103 and 105. In a container cluster management system, pods can be scheduled through the scheduler. Unless constraints are defined in affinity and anti-affinity rules, the scheduler always assumes that pods are independent and evenly distributes them across candidate compute nodes in the cluster. Therefore, pods that communicate frequently with each other may be scheduled to different candidate compute nodes, resulting in significant network latency. Typically, the network interface card (NIC) of a physical server has a fixed bandwidth, such as 1 Gbps or 10 Gbps. This bandwidth limits the speed of data transmission in and out of the server's network interface. If pods that need to frequently exchange large amounts of data run on different physical machines, communication between them must occur over the network and is limited by the NIC bandwidth. To address the above technical issues, the present disclosure provides a solution, which will be illustrated below with reference to the accompanying figures. Figure 2 is a flow chart of a container unit scheduling method provided in an exemplary embodiment of the present disclosure. As shown in Figure 2, the method includes the following steps: Step 201: Responding to a scheduling request for a first container unit, obtaining service dependency information for the first container unit; the service dependency information is obtained based on traffic monitoring data of a first workload in the first container unit over a historical period. Step 202: Determining a target candidate compute node for deploying the first container unit from multiple candidate compute nodes based on the service dependency information. Step 203: Creating the first container unit on the target candidate compute node to schedule the first container unit to the target candidate compute node. In this embodiment, a container unit refers to a Pod, also known as a "container pod" or "container set," which is the basic scheduling unit for containers. A first container unit refers to any container unit to be created in a service grid. A first workload and its grid agent component are running in the first container unit. The first workload can be any application service instance. The scheduling request for the first container unit can be triggered by a user or a scheduling event for the first container unit. For example, in some scenarios, when the resource utilization rate of the candidate computing node where the first container unit is located is high, a scheduling event for the first container unit may be triggered. In other scenarios, when the candidate computing node where the first container unit is located fails, a scheduling event for the first container unit may be triggered.In response to a scheduling request for a first container unit, service dependency information for the first container unit can be obtained. Service dependency information refers to information describing the dependency and degree of dependency of a container unit on other services when providing a service. This dependency can manifest as: a workload in the container unit requiring data from another workload to perform a specified operation, or a workload in the container unit needing to call another workload to complete a data processing operation. The degree of dependency of a container unit on other services when providing a service can be described using dependency weights. In this embodiment, service dependency information can be obtained based on traffic monitoring data of the first workload in the first container unit over a historical period. In some optional embodiments, this traffic monitoring data can be obtained by monitoring the actual ingress and egress traffic of the first workload, and this data is used to provide feedback on the actual dependency between the first workload and other workloads. In other optional embodiments, the traffic monitoring data of the first workload over a historical period can include data obtained by monitoring the actual ingress and egress traffic of other workloads of the same type as the first workload. Other workloads of the same type as the first workload may be one or more workloads belonging to the same application service as the first workload. For example, a certain application service S is instantiated into multiple application service instances, namely, application service instance S1, application service instance S2, and application service instance S3. These three application service instances may each run as workloads in different container units. Traffic monitoring data for any application service instance during a historical period may include data obtained by monitoring the actual ingress and egress traffic of other application service instances. For example, traffic monitoring data for application service instance S1 during a historical period may include data obtained by monitoring the actual ingress and egress traffic of application service instances S2 and S3. In some scenarios, when application service S is instantiated into a new application service instance S4, application service instance S4 is not yet running and has not yet collected its own traffic monitoring data for the historical period. In this case, traffic monitoring data for application service instance S during a historical period can be obtained based on traffic monitoring data for application service instance S1, application service instance S2, and application service instance S3 during a historical period. In some optional embodiments, traffic monitoring data can be obtained by monitoring the traffic of any workload in the service grid, and other workloads on which the workload depends can be determined based on the monitoring data of the workload.The following will continue to illustrate the first workload as an example. The first workload can be any workload in the service grid. Optionally, traffic monitoring data for the first workload can be obtained through the first grid proxy component of the first workload. Based on the traffic monitoring data of the first workload, at least one workload with a dependency relationship with the first workload can be determined. The at least one workload refers to any one or more workloads. Based on the traffic monitoring data of the first workload, a dependency weight of the first workload on the at least one workload can be calculated. The at least one workload and its corresponding dependency weight can then be stored as the dependency relationship of the first workload in the configuration file of the first workload. The following will continue to illustrate an optional implementation method for obtaining traffic monitoring data for the first workload, using the first workload as an example, in conjunction with Figure 3. As shown in Figure 3 , a first workload 301 runs in a first container unit 300. A metadata collector 302 connected to the first container unit 300 is configured to collect metadata information for the first workload 301. This metadata information may include at least one of the instance name, environment, pod identifier, version, and namespace of the first workload 301. A first grid proxy component 303 is connected to the metadata collector 302 and may be configured to proxy traffic for the first workload 301. The first grid proxy component 303 may include an observable data collector and analyzer 304, configured to collect traffic monitoring data for the first workload 301 and analyze service dependency information for the first workload 301 based on the collected traffic monitoring data. Optionally, the observable data collector and analyzer 304 may include at least one of the monitoring data collector 305, log data collector 306, and trace data collector 307 shown in Figure 3 , and may collect traffic monitoring data based on these collectors. In some optional embodiments A1, the first grid proxy component 303 includes the monitoring data collector 305 shown in FIG3 . The monitoring data collector 305 may use a preset traffic statistics indicator to collect statistics on the ingress and / or egress traffic of the first workload 301 to obtain a value for the traffic statistics indicator. Optionally, the traffic statistics indicator may include at least one of the number of requests, request data length, number of responses, and response data length.In this embodiment, first grid proxy component 303 can intercept the traffic of first workload 301 and, after interception, use monitoring data collector 305 to perform multi-dimensional statistics on the traffic of first workload 301 to obtain traffic statistics indicator values, namely, monitoring indicator 308 shown in FIG3 . It is worth noting that when workloads use different protocols, different types of monitoring indicator data, log data, or trace data can be obtained from the workload's ingress traffic / ingress traffic. For example, when the workload uses HTTP (Hypertext Transfer Protocol), the data transmitted between services is in uncompressed JSON (JSON Object Notation) format. The request data length is the text length. Therefore, the request data length corresponding to the workload can be monitored to determine the dependency strength between services based on the data request length. When the workload uses the gRPC (Google Remote Procedure Calls) protocol, an open-source remote call protocol, data transmitted between services is often compressed, and the request data length is less correlated with dependencies. Therefore, the number of requests corresponding to the workload can be monitored, which will not be further described. In some optional embodiments A2, the first grid proxy component 303 includes a log data collector 306 as shown in FIG3 . The log data collector 306 can obtain access logs, namely, access log 309 shown in FIG3 , from the ingress and / or egress traffic of the first workload 301. The access logs can include at least one of the identification information of the upstream workload, the identification information of the downstream workload, and the protocol type. In this embodiment, the protocol types obtained by the log data collector from the ingress and / or egress traffic may include HTTP, gRPC, TCP (Transmission Control Protocol), and the like. In this embodiment, first grid proxy component 303 can intercept traffic from first workload 301. After interception, log data collector 306 can generate access logs based on each intercepted traffic flow. The access logs primarily record at least one of the following information: the name, port, and protocol of the requested service contained in the traffic flow. In some optional embodiments A3, first grid proxy component 303 includes tracing data collector 307, as shown in FIG3 . Tracing data collector 307 can trace the path of access requests processed by first workload 301 to obtain the request processing path of the access requests, i.e., tracing data 130, as shown in FIG3 .The request processing path includes an ordered chain of workloads used to process the access request. When tracing the access request path, the tracing data collector 307 can extract tracing information (e.g., request ID) contained in the access request and, based on the transfer links between multiple workloads for the request ID, generate a request processing path corresponding to the access request. For example, the transfer links between candidate compute nodes for an access request carrying a certain request ID include, in order, workload w1, workload w2, workload w3, and workload w4. These multiple transfer links constitute the request processing path for the access request. After obtaining traffic monitoring data based on the above-described embodiments, the observable data collection and analysis unit 304 can analyze one or more of the traffic monitoring data to determine the dependency relationships between the first workload 301 and other workloads. The following will further illustrate the different types of traffic monitoring data obtained in the above-described embodiments. Optionally, observable data collector and analyzer 304 may include at least one of the metric analyzer 311, log analyzer 312, and trace analyzer 313 shown in FIG3 , and analyze traffic monitoring data based on the aforementioned analyzers. In some optional embodiments B1, first grid proxy component 303 includes metric analyzer 311 as shown in FIG3 . Metric analyzer 311 may be connected to monitoring data collector 305 and configured to analyze monitoring metrics 308 collected by monitoring data collector 305 . Optionally, metric analyzer 311 may obtain and analyze traffic statistical metrics of one or more workloads to determine inter-service dependencies. Continuing with the example of first workload 301 and any workload, metric analyzer 311 may optionally obtain, based on a specified time window, metric value distribution information for traffic statistical metrics of first workload 301 and any workload. If the time series similarity between the indicator value distribution information of the first workload 301 and the any workload exceeds a set similarity threshold, it can be determined that the first workload 301 has a dependency on the any workload. In some optional embodiments B2, the first grid proxy component 303 includes the log analyzer 312 shown in FIG3 . The log analyzer 312 can be connected to the log data collector 306 and configured to analyze the access logs 309 collected by the log data collector 306 . Optionally, the log analyzer 312 can obtain at least one of the following information: the service name, port, and protocol carried in the request from the log generated by the log data collector 306 , and determine the service dependency of each service based on the at least one information.Continuing with the example of first workload 301 and any workload, if the access log shows that the name of the service initiating the request is the service name corresponding to first workload 301, and the name of the requested service is the service name corresponding to any workload, then first workload 301 can be considered to frequently access or call any workload, and first workload 301 can be marked as the source service, while any requested workload can be marked as the destination service. If the number of times or percentages of times in the access log that first workload 301 and any dependent workload serve as the source service and destination service, respectively, satisfy certain conditions, then first workload 301 can be determined to have a dependency on any workload. In some optional embodiments B3, first grid proxy component 303 includes trace analyzer 313 shown in FIG3 . Trace analyzer 313 can be connected to trace data collector 307 and configured to analyze trace data 130 (i.e., request processing path) collected by trace data collector 307. The request processing path of each service request in the service grid contains accurate dependency information between services. Trace analyzer 313 can accurately obtain the dependencies between all services in the service grid by integrating and analyzing a large number of request processing paths. Continuing with the example of first workload 301 and any workload, the following description is provided. Optionally, if the number of times first workload 301 and any workload appear in the same request processing path exceeds a certain threshold, first workload 301 can be considered to have a dependency on the any workload. In the above embodiment, the first grid proxy component collects and analyzes traffic monitoring data of the first workload. This allows for the collection of traffic monitoring data without intruding on the first workload, thereby reducing interference with the workload. After determining at least one workload on which the first workload depends based on the above embodiment, the dependency weight of the first workload on the at least one workload can be calculated based on the traffic monitoring data of the first workload. Each of these is described below with examples. In some optional embodiments C1, the traffic monitoring data is the value of the traffic statistical indicator collected in embodiment A1. The dependency weight of the first workload 301 on any of its dependent workloads can be calculated based on the traffic statistical indicator values ​​of the first workload 301 and any of its dependent workloads. Optionally, the indicator analyzer 311 can calculate the dependency weight between the first workload 301 and any of its dependent workloads based on the time series similarity of the indicator value distribution information between the first workload 301 and any of its dependent workloads. The time series similarity of the indicator value distribution information and the dependency weight are positively correlated.The higher the time series similarity of the indicator value distribution information of any two workloads, the greater the dependency weight of the two workloads. Optionally, a target sorting algorithm can be used to calculate the values ​​of the traffic statistics indicator to obtain the dependency weight of the first workload 301 on any workload. In this embodiment, a topology graph can be constructed based on the first workload 301 and at least one of its dependent workloads. In the topology graph, workloads are vertices, and the weights of the edges between workloads are the values ​​of the traffic statistics indicator. Using the target sorting algorithm to calculate the topology graph, a ranking result of the at least one workload on which the workload depends can be obtained. Based on the ranking result, weights can be assigned to the at least one workload in turn. Optionally, the target sorting algorithm can be at least one of the KahnSort algorithm (an algorithm for topologically sorting undirected graphs), the Taijan algorithm (a sorting algorithm based on depth-first search), the ReverseKahn algorithm (a topological sorting algorithm), and the ReverseTaijan algorithm (a sorting algorithm for reverse graphs). In some optional embodiments C2, the traffic monitoring data is the access log collected in embodiment A2. The dependency weight of the first workload 301 on any of its dependent workloads can be calculated based on the number and / or proportion of times the first workload 301 and any of its dependent workloads appear as source services and destination services in the access logs. Optionally, the more times any two workloads appear as source services and destination services, the stronger their dependency strength. Based on this, the number of times the first workload 301 and each of its dependent workloads appear as source services and destination services in the access logs can be counted, and the dependency weight of the first workload 301 on any of its dependent workloads can be calculated based on the counted number of accesses. Optionally, the proportion of the counted number of accesses to the total number of accesses to the first workload 301 within a certain time period can be calculated. Based on this proportion, the dependency weight of the first workload 301 on at least one of its dependent workloads can be determined. The higher the proportion, the higher the dependency weight.For example, if the number of accesses to the first workload 301 and workload w1 as the source service and destination service, respectively, in the access log accounts for 30% of the total access volume of the first workload 301 during a certain period, and the number of accesses to the first workload 301 and workload w2 as the source service and destination service, respectively, in the access log accounts for 50% of the total access volume of the first workload 301 during a certain period, then the dependency weight of the first workload 301 on workload w2 can be set to 50, and the dependency weight of the first workload 301 on workload w1 can be set to 30. In some optional embodiments C3, the traffic monitoring data is the request processing path collected in embodiment A3. The dependency weight of the first workload 301 on any dependent workload can be calculated based on the number of times the first workload 301 and any dependent workload appear in the same request processing path and / or the distance between them in the same request processing path. Optionally, the more times any two workloads appear in the same request processing path, the higher the strength of their dependency. Based on this, the number of times the first workload 301 and each of its dependent workloads appear in the same request processing path can be counted, and based on the counted number of times, the dependency weight of the first workload 301 on each of the workloads can be calculated. The distance between any two workloads in the request processing path refers to the number of workloads between them. The fewer workloads that separate any two workloads in the request processing path, the closer the distance between the two workloads, and the stronger the dependency relationship between the two workloads. Based on this, optionally, the distance between the first workload 301 and each of its dependent workloads in the request processing path can be counted, and based on the inverse relationship between the distance and the dependency weight, the dependency weight of the first workload 301 on each of its dependent workloads can be determined. After calculating the other workloads that each workload depends on and their dependency weights based on the above embodiment, the other workloads that the workload depends on and their corresponding dependency weights can be stored as the service dependency information of the workload in the configuration file of the workload. In this embodiment, service dependency information is also referred to as the application service chain directed graph 314 shown in FIG3 . In the application service directed graph 114, nodes are workloads, and nodes are connected by directed edges. Each directed edge consists of a pair of ordered vertices. In each ordered vertex pair, the workload corresponding to the starting point depends on the workload corresponding to the end point. The edge between the nodes is marked with the dependency weight between the workloads. The application service chain directed graph 314 can be stored in the workload configuration file.In some container cluster management systems, the workload configuration file can be a user-defined resource file (Custom Resource Definition, CRD). O The configuration file may describe the resources corresponding to a workload group. A workload group may include multiple workloads, with dependencies between workloads. In some optional embodiments, when defining any workload in a workload group's configuration file, the workload's dependencies, traffic monitoring data, and the ranking algorithm used to calculate dependency weights based on the traffic monitoring data may be described. An optional configuration file definition may be as shown in the following table: As shown in the table above, within a workload group, a target algorithm F() can be used to calculate traffic monitoring data to obtain dependencies and dependency weights between workloads. The target algorithm F() can be at least one of the sorting algorithms described in the previous examples. For a workload named wl, its dependent workloads are: workload w2 and workload w3. The traffic statistics between workload wl and workload w2 are: number of requests = 100, request data size = 200k, response data size = 150k. The traffic statistics between workload wl and workload w3 are: number of requests = 20, request data size = 1k, response data size = 1k. Based on the target algorithm, the above traffic statistics can be calculated to obtain the dependency weights of workload wl on workload w2 and workload w3. For example, the weight of workload wl on workload w2 = F(number of requests = 100, request data size = 200k, response data size = 150k) = 100. The weight of workload wl on workload w3 = F(number of requests = 20, request data size = 1k, response data size = 1k) = 20. Optionally, when defining any workload in a workload group configuration file, the dependency weights of that workload on other workloads can be described. For example, as shown in the table above, the workload named wl depends on workloads named w2 and w3. The dependency weight of workload w2 is 100, and the dependency weight of workload w3 is 80. A larger dependency weight indicates a stronger dependency, and workloads should be deployed on the same candidate compute node whenever possible during scheduling. After obtaining the service dependency information of the first container unit based on the above embodiment, a target candidate compute node for deploying the first container unit can be determined from multiple candidate compute nodes based on the service dependency information. Typically, a distributed system includes a scheduler, which primarily selects the most appropriate resources (such as servers or candidate compute nodes) to run one or more tasks based on predetermined rules and policies. When the distributed system is a container cluster management system, the service instance corresponding to each task runs as a workload in a container, and the scheduler can allocate the container units to appropriate candidate compute nodes for execution. Continuing with the example of first container unit 300, as shown in Figure 3 , first container unit 300 can be scheduled based on scheduler 315.Optionally, the scheduling process of the scheduler 315 for the container unit may include multiple steps, including filtering, scoring, candidate computing node selection, and binding. Each step will be described below in exemplary terms. In the filtering step, the scheduler 315 may filter candidate computing nodes in the node cluster based on the resources required by the first container unit 300 and / or preset constraints to obtain multiple candidate computing nodes. Optionally, the scheduler 315 may determine whether each candidate computing node has the resources required to run the first container unit 300. These resources may include at least one of memory resources, processor resources, and network resources. Optionally, the scheduler 315 may determine whether each candidate computing node meets preset constraints. These constraints may include at least one of affinity / anti-affinity rules, taints and tolerance attributes, and the health status of the candidate computing node. Taints and tolerance attributes are parameters set on a candidate computing node that influence the scheduling of other objects onto the candidate computing node. A single candidate compute node can have multiple taints added to indicate that it will not schedule pods that cannot tolerate taints. In a node cluster, candidate compute nodes that pass this filtering operation are described as candidate compute nodes. After obtaining multiple candidate compute nodes based on the above steps, scheduler 315 can score each candidate compute node to assess its suitability for running the first container unit 300. Optionally, scheduler 315 includes a same-node priority scheduler 316. Same-node priority scheduler 316 is configured to prioritize scheduling pods with strong dependencies onto the same compute node. In this embodiment, scheduler 315 uses same-node priority scheduler 316 to score the multiple candidate compute nodes based on the service dependency information of the first container unit 300, thereby obtaining a score for each candidate compute node. The following description uses the scoring operation of any candidate compute node as an example. When scoring any candidate computing node, the same-node priority scheduler 316 may query the definition information of the first container unit 300 for the first workload 301 corresponding to the first container unit 300. Optionally, the same-node priority scheduler 316 may determine whether the first container unit 300 belongs to any target application group based on the definition information of the first container unit 300. Typically, an application group tag may be added to the container unit to identify whether the first workload belongs to a specific application group. Based on this, when determining whether the first container unit belongs to any target application group, it may be determined whether the first workload has an application group tag. If the first workload has an application group tag, the target application group to which the target workload belongs may be obtained based on the application group tag.If the first container unit 300 belongs to the target application group, it can be determined whether the target application group contains any workloads. If the target application group contains any workloads, it can be determined whether the first workload 301 corresponding to the first container unit 300 exists in the workloads of the target application group. In an application group, workloads and container units have an inheritance relationship, with workloads being the parent class of container units. Based on this, it can be determined whether the target application group contains a parent workload corresponding to the first container unit 300. If the target application group contains the parent workload, the parent workload is used as the first workload 301 corresponding to the first container unit 300. After determining the first workload 301, at least one workload on which the first workload 301 depends can be obtained from the configuration file of the first workload 301. The at least one workload can then be traversed and the candidate compute nodes scored based on the dependency weights of the traversed workloads and the first workload 301. For any candidate compute node among the multiple candidate compute nodes, when traversing any workload with which the first workload 301 has a dependency, it can be determined whether the workload is running on the candidate compute node. If the workload is running on the candidate compute node, the candidate compute node can be scored based on the dependency weight corresponding to the workload. The higher the dependency weight, the higher the score for the candidate compute node. Optionally, if the workload is not running on the candidate compute node, the score for the candidate compute node can be set to a score below a set threshold. It should be understood that the above description using any workload as an example is merely intended to illustrate the process of scoring any candidate compute node based on the dependency weight of each workload on which the first workload 301 depends. When scoring each candidate compute node, the same-node priority scheduler 316 can perform the above-described scoring operation based on the dependency weight of each workload on which the first workload 301 depends, and the scores assigned based on the dependency weights of multiple workloads can be added together. Furthermore, for the same candidate compute node, if the first workload 301 depends on more workloads deployed on the candidate compute node, the candidate compute node will receive a higher score. It is worth noting that in some cases, if there are no other workloads in the target application group that have a dependency on the first workload 301, the scores of all candidate compute nodes' partitions can be set to be below a set threshold. In other cases, if the first workload 301 does not belong to any application group, the scores of all candidate compute nodes can also be set to be below a set threshold.In other cases, if the first workload 301 belongs to the target application group, but the target application group contains no workloads, the scores of all candidate compute nodes can be set to scores below a set threshold. Specifically, if the target container component belongs to a target application group, the target application group contains workloads, and the workloads in the target application group include the first workload 301 corresponding to the target container component, the dependency weights of the other workloads on which the first workload 301 depends are obtained, and the candidate compute nodes where the other workloads are located are scored based on the dependency weights of these other workloads. This implementation uses the actual dependencies between workloads as a basis for scoring, facilitating optimization of workload deployment locations. It is also worth noting that in a container cluster management system, a custom plugin for the same-node priority scheduler 316 can be implemented through extension points within the same-node priority scheduler 316 framework. First, a structure can be defined to implement the interface defined in the framework for use in the scoring phase. Subsequently, a function is provided to create an instance of the plugin and register it during the plugin initialization phase. After filtering the candidate computing nodes in the node cluster, the plug-in can be used to score each of the filtered candidate computing nodes. When the same-node priority scheduler 316 uses the plug-in to perform the scoring operation on each candidate computing node, the scoring processing logic is as follows:

[0002] 1) When a pod is created, the same-node priority scheduler 316 determines whether the pod has an App Group label. If the pod does not have an App Group label, it indicates that it does not belong to any application group. The candidate compute node is assigned the lowest score and the default scoring logic is reverted to early. The default scoring logic can be the least requested logic or the balanced resource allocation strategy.

[0003] 2) If the Pod belongs to an application group, the custom resource corresponding to the application group is queried. If no custom resource corresponding to the application group is found or the custom resource does not contain a workload, the candidate compute node is assigned the lowest score and returned.

[0004] 3) If the application group's custom resource has a workload, determine whether the custom resource has a parent workload of the query Pod.

[0005] 4) If the parent workload of the Pod is found, the dependencies under the parent workload are traversed.

[0006] 5) If no dependencies are found for the parent workload, the candidate compute node is assigned the lowest score. 6) If dependencies are found for the parent workload, the found dependencies are traversed to obtain the names of the candidate compute nodes where other workloads that the parent workload depends on are located. Each dependent workload is then checked to see if it is running on the current candidate compute node.

[0007] 7) If other dependent workloads are running on the current candidate compute node, the current candidate compute node is assigned a score based on the dependency weight of the other workloads.

[0008] 8) If, after traversing all dependencies, no workload running on the current candidate compute node is found, the current candidate compute node is assigned the lowest score. In addition to scoring candidate compute nodes based on the service dependency information of the first container unit, candidate compute nodes may also be scored based on other information. Scores derived from multiple types of information can be combined to calculate the total score for each candidate compute node. This is illustrated below. Typically, a physical server's network interface card (NIC) has a fixed bandwidth, such as 1 Gbps or 10 Gbps. This bandwidth limits the speed of data transmission in and out of the server's network interface. If pods that frequently exchange large amounts of data run on different physical machines, communication between them must occur over the network and is limited by the NIC bandwidth. Therefore, in some optional embodiments, the scheduler 315 may score candidate compute nodes based on the NIC bandwidth and the data flow per second between dependent workloads. Alternatively, taking the first workload 301 as application A, and assuming that application B exists in the service grid and has a dependency on application A, when scoring the candidate compute nodes where application B resides, scheduler 315 may count the traffic from application A to application B and the traffic from application B to application A during the time period t1 to t2. Scheduler 315 may divide the counted traffic by the length of the time period t2-t1 to obtain the average per-second data traffic between application A and application B. The average per-second data traffic can be used to assess the intensity and communication pattern of inter-application communication. The ratio of the average per-second data traffic to the bandwidth of the physical machine's network interface card can then be calculated to obtain a ratio threshold. Based on the ratio threshold, a score can be assigned to the candidate compute nodes where application B resides. The higher the ratio threshold, the greater the pressure on network communication caused by the interaction between application A and application B, and the greater the need to deploy application A and application B on the same candidate compute node to avoid network communication. Based on this, when scoring, the higher the threshold for the average per-second data traffic between Application A and Application B relative to the network card bandwidth, the higher the score of the candidate compute node where Application B resides. Therefore, by somewhat raising the score of the candidate compute node where Application B resides during scoring, the probability of Application A and Application B being deployed on the same candidate compute node can be increased. When Application A and Application B are deployed on the same candidate compute node, the interaction between them no longer relies on the network, thereby reducing the pressure on network bandwidth caused by the interaction between Application A and Application B. In other optional embodiments, scoring of candidate compute nodes can be based on the status of the container units on the candidate compute nodes.Optionally, the scheduler 315 may score the candidate compute nodes based on the number of terminating container units they contain. Since terminating container units are eventually physically removed from the candidate compute node, a greater number of terminating container units in a candidate compute node indicates greater available resources for the candidate compute node, resulting in a higher score for the candidate compute node. Alternatively, the scheduler 315 may score the candidate compute nodes based on the number of nominating container units they contain. Since nominating container units will accommodate preemptive Pods in future scheduling cycles, a greater number of nominating container units in a candidate compute node indicates greater resource constraints for the candidate compute node in future scheduling cycles, resulting in a lower score for the candidate compute node. Of course, in addition to the above scoring methods, scheduler 315 may also score candidate compute nodes based on other criteria, such as resource utilization, affinity between pods, network topology, or custom priority rules. These criteria will not be discussed further. After obtaining the scores of multiple candidate compute nodes based on the above embodiments, a target candidate compute node may be determined from the multiple candidate compute nodes based on their scores. Optionally, scheduler 315 may select the candidate compute node with the highest score as the target candidate compute node for deploying the first container unit. If multiple candidate compute nodes have the same score, scheduler 315 may randomly select one candidate compute node as the target candidate compute node. After selecting a target candidate compute node, scheduler 315 may notify the container cluster management system server to create a Pod on the target candidate compute node. In this embodiment, a plugin in scheduler 315 may prioritize scheduling Pods with high dependency levels to the same candidate compute node as the Pods they depend on, based on the definition of the application service chain directed graph 314. This helps ensure performance optimization and latency reduction between application calls. In some embodiments, scheduler 315 also includes a rescheduler 317. This rescheduler 317 may be configured to run periodically within the cluster to analyze whether the placement of Pods in the cluster remains reasonable. It should be understood that over time, the state of a node cluster may change, and the original Pod distribution may no longer be optimal. For example, the addition or removal of new candidate compute nodes, changes in workload, or other factors may cause the cluster state to change.In this case, the rescheduler 317 can periodically analyze the Pod distribution of the current workload to determine if it is reasonable. After identifying target Pods that may not be in ideal locations based on predefined policies, the rescheduler 317 can evict inappropriate target Pods, allowing the scheduler 315 to reschedule these Pods to more suitable candidate compute nodes. Based on the above implementation, Pods with high dependency levels can be placed on the same candidate compute node, effectively reducing application response time. When multiple Pods need to frequently exchange data and are deployed on the same physical machine, communication between the Pods can occur within the same machine, rather than through a network interface controller. This effectively reduces the network resources required for communication between different container units. Furthermore, the efficient communication mechanisms within the compute node can be leveraged to improve communication efficiency and service access efficiency between different container units, significantly improving workload service processing performance, service processing efficiency, and service response efficiency. The following further illustrates the communication process on the same candidate compute node, with reference to the accompanying figures. Continuing with the example of first workload 301, assume that a second workload corresponding to a target service is running on the target candidate compute node where first workload 301 resides. The target service refers to the service that first workload 301 needs to access. The second workload is an application service instance corresponding to the target service. A grid proxy component corresponding to the second workload, hereinafter referred to as the second grid proxy component, runs on the target candidate compute node. Optionally, after creating first container unit 300 on the target candidate compute node, the first grid proxy component corresponding to first workload 301 obtains an access request from the first workload 301. If the access request is for accessing the target service, the access request may be intercepted and, based on a preset local redirection policy, forwarded to the second grid proxy component corresponding to the second workload. The second grid proxy component then forwards the access request to the second workload, enabling the second workload to perform data processing operations corresponding to the target service on the access request. In this embodiment, scheduler 315 may include a rescheduler 317 as shown in FIG3 . Rescheduler 317 is configured to forward the access request to the second grid proxy component corresponding to the second workload based on a preset local redirection policy. The preset local redirection policy describes the traffic type to be redirected and / or the Pod selection criteria corresponding to the first workload. Traffic types may include directed traffic or undirected traffic.Directed traffic corresponds to a designated workload, while non-directed traffic does not specify a workload. Traffic types may also include text traffic or audio and video traffic. Audio and video traffic typically has large data volumes and consumes a large amount of transmission bandwidth. Therefore, if the traffic type of an access request is audio and video traffic, the access request can be redirected to a local second workload to reduce network transmission pressure. Pod selection criteria may include at least one of the Pod version number, Pod status (running, stopped, etc.), Pod creation time, and Pod annotations. Optionally, when forwarding the access request to the second grid proxy component corresponding to the second workload based on a preset local redirection policy, the rescheduler 317 may obtain the traffic type corresponding to the access request and / or the container unit selection criteria corresponding to the first workload 301. If the traffic type meets the specified type requirements and / or the second container unit meets the container unit selection criteria, the access request is forwarded to the second grid proxy component corresponding to the second workload. Specifically, when the egress traffic of the first workload 301 meets the traffic type and / or Pod selection criteria defined in the local redirection policy, the first grid proxy component may redirect the egress traffic to one or more target Pods on the same candidate compute node, rather than forwarding it according to the grid proxy's firewall rules table (iptables) or IPVS (IP Virtual Server) rules. Alternatively, if no backend Pods are available locally, the scheduler 315 may configure a fallback policy using the Link Reversal Routing Protocol (LRP) to forward the traffic to Pods on other candidate compute nodes, ensuring service availability. In some optional embodiments, the communication flow between different workloads on a compute node may be optimized based on the same-node communication accelerator 318 shown in FIG3 . As shown in FIG3 , the same-node communication accelerator 318 includes a socket data flow processor 319 and an eBPF (Extended Berkeley Packet Filter) accelerator 320. The socket data stream processor 319 is configured to execute a local redirection policy based on the network protocol stack shown in FIG4 . This will be further illustrated below with reference to FIG4 . FIG4 illustrates the local communication process between application APP1 in Pod1 and application APP2 in Pod2 , where Pod1 and Pod2 are located on the same compute node.Grid proxy component SP1 is configured to proxy traffic for application APP1, while grid proxy component SP2 is configured to proxy traffic for application APP2. The socket data flow processor 319 includes the socket in Pod1, the socket in Pod2, the kernel's multi-layer network protocol stack, and the virtual network card (Veth), as shown in Figure 4. As shown in Figure 4, the kernel's multi-layer network protocol stack includes the TCP / IP protocol stack, the Network protocol stack, and the Loopback protocol stack. As shown in Figure 4, in grid proxy mode, pod traffic can be categorized into three directions: egress, from grid proxy component SP1 to another grid proxy component SP2, and ingress. The egress direction refers to the direction in which workloads (i.e., applications) in a pod send messages to remote services. As shown in Figure 4, the socket can listen on the loopback interface created by grid proxy component SP1 for egress traffic from application APP1, which has a static IP address and port. When application APP1 sends a request message to a remote service, APP1 acts as the client, and APP2, the corresponding application of the remote service, acts as the server. This message is written to a socket buffer in kernel space through a socket created by APP1. The message in the socket buffer is then sent out via the TCP / IP protocol. While traversing the network stack, the message is intercepted by iptables rules in the kernel. After being intercepted, the message completes the remaining path through the network stack using the new destination. The direction from grid proxy component SP1 to another grid proxy component SP2 refers to the direction in which grid proxy component SP1 receives a message from its proxy workload (i.e., application APP1) and then sends the message to the corresponding workload (i.e., application APP2) through another grid proxy component SP2. On the same host, grid proxy component SP1 performs security checks and routing rule checks on the request message before sending a message to Pod2, where the server application resides. The socket buffer intercepts the message using iptables rules configured in the server's network namespace and redirects it to the default port where the grid proxy component SP2 is listening to handle ingress traffic. Ingress refers to the direction in which the server-side application APP2 receives the request message.After receiving the request message and performing security checks and routing rule checks on the request message, the grid proxy component SP2 can access the server-side application APP2o using the loopback interface. The message in the socket buffer passes through the network protocol stack twice before ultimately reaching the server-side application APP2o. The eBPF accelerator 320 is configured to inject an eBPF program into the packet transmission and reception path to process and forward traffic at a lower level of the network stack. This allows packets to bypass the network stack processing shown in FIG. 4 , reducing the number of hops in the network stack, thereby reducing latency and improving processing efficiency. The eBPF accelerator 320 may include one or more eBPF programs. The process of injecting the eBPF program into the packet transmission and reception path by the eBPF accelerator 320 can be described in the following embodiment: The socket optimization component (Sockops) allows, when establishing a TCP-based socket connection, to identify the socket using a key (typically a four-tuple) and store it in a socket map (SockMap) data structure. When transmitting TCP data, socket redirection uses this key to retrieve the corresponding socket from the SockMap and forward the data directly to that socket. If the socket is not found in the SockMap, the data packet is sent through the kernel network protocol stack according to the normal process. The basic steps for communication acceleration based on SockMap are as follows:

[0009] 1) Intercepting Socket Connection Events: Attach the first eBPF program to the kernel, responsible for handling socket connection event functions (e.g., the connect function or the accept system call). When a socket attempts to establish a connection (either actively initiating a connection or passively accepting a connection), the first eBPF program is triggered. This first stores the local and remote address information for each actively established TCP connection in a defined eBPF hash table, with the local address (IP and port) serving as the key and the remote address (IP and port) as the value. For example, if an application in a pod at address xxx.17.0.2 sends an egress request to port 80 on xxx.17.0.3, the following hash table can be created during the active connection establishment: The first eBPF program can extract the socket's quad-tuple information. The quad-tuple information includes the source IP address, source port number, destination IP address, and destination port number. This information is then stored in an eBPF-type hash table along with the corresponding socket file descriptor or a socket structure pointer in the kernel.

[0010] 2) Mapping of 4-tuples to socket operation handles: Assume that there is a connection from port A (PortA) to port B (PortB). This connection will generate two records in the hash table:

[0011] AIP address: PortA+BIP address: PortB->A-side Socket handle

[0012] BIP address: PortB + AIP address: PortA -> B-side socket handle. Based on this, whether A or B's socket initiates communication, the corresponding peer socket handle can be quickly located using the four-tuple. When the mesh proxy intercepts and forwards, the metadata of the sockets at both ends of the connection is asymmetric. For example, when an application in a pod at IP address xxx.17.0.2 sends an egress request to port 80 on xxx.17.0.3, after being redirected to port 1357 on the mesh proxy via iptables rules, the socket four-tuple on both the application and the mesh proxy is as shown in the following table: That is, the actual target address is inconsistent with the original target address, so another eBPF hash table can be established to store the mapping relationship between them, for example: The hash table used to express the hash information of the socket in the egress scenario is as follows: The hash table of the four-tuple socket meta information is as follows: Accordingly, between one grid proxy component and another, the hash table used to express the hash information of the socket is as follows: The hash table of the four-tuple socket meta information is as follows: The corresponding hash table in the ingress direction is as follows:

[0013] 3) Pre-message Interception: This interception operation can be implemented using a second eBPF program, which intercepts events before a socket sends a message. For example, this second eBPF program can be attached to the sendto function or the write system call. The sendto system call is primarily used to write outgoing data to a socket. The write system call is used to send data from the connected socket's buffer. Before sending a message, the second eBPF program can assemble the current socket's quad-tuple information and use it as a key to search a map for the corresponding socket reference. If a corresponding record is found in the map, i.e., a matching quad-tuple is found, the second eBPF program obtains the target socket's operation handle.

[0014] 4) Direct message forwarding: If the handle of the target socket is obtained, the second eBPF program can directly forward the packet to the target socket without going through the entire network protocol stack.

[0015] 5) Resource Management and Cleanup: When a socket is closed or a connection is terminated, the socket-related record can be deleted from the map to prevent resource leakage. This resource management and cleanup logic can be implemented by the second eBPF program. In a service mesh, containers within a pod and the local mesh proxy component can communicate via SockMap to reduce communication overhead. Continuing with the example of an access request sent from the first workload 301 to the second workload, after the first mesh proxy component 303 intercepts the access request, the eBPF accelerator 320 can obtain the access request's quad-tuple information from the first socket in the first mesh proxy component 303. Based on this quad-tuple information, it queries the preset socket mapping relationship 321 to obtain an operation handle for the second socket in the second mesh proxy component. The operation handle for the second socket can be obtained by the second eBPF program based on the above-described embodiment and will not be further described. Based on this second socket's operation handle, the access request can be sent to the second socket. Furthermore, the second mesh proxy component can obtain the access request via the second socket. Based on this forwarding mechanism, access requests sent from the first workload to the second workload do not need to be forwarded through multiple layers of the protocol stack, significantly improving communication efficiency between different workloads on the same candidate compute node. It should be noted that the execution entity of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution entity of steps 201 to 204 can be device A; another example, the execution entity of steps 201 and 202 can be device A, and the execution entity of step 203 can be device B; and so on. Furthermore, some processes described in the above embodiments and accompanying figures include multiple operations that appear in a specific order. However, it should be understood that these operations may be executed in a different order than the order in which they appear herein or in parallel. Operation sequence numbers, such as 201 and 202, are merely used to distinguish between different operations and do not represent any specific execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first" and "second" in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequence, nor do they limit "first" and "second" to different types.It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, storage, and display, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. The collection, use, and processing of relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or deny. Figure 5 illustrates a schematic diagram of the server provided in an exemplary embodiment of the present disclosure. As shown in Figure 5, the server includes: memory 501, processor 502, and communication component 503. Memory 501 is used to store computer programs and can be configured to store various other data to support operations on the server. Examples of such data include instructions for any application or method operating on the server. The processor 502 is coupled to the memory 501 and configured to execute a computer program in the memory 501 to: obtain service dependency information of the first container unit in response to a scheduling request for the first container unit; obtain the service dependency information based on traffic monitoring data of a first workload in the first container unit during a historical period; determine a target candidate computing node for deploying the first container unit from multiple candidate computing nodes based on the service dependency information; and create the first container unit on the target candidate computing node to schedule the first container unit to the target candidate computing node. Optionally, when determining the target candidate computing node for deploying the first container unit from multiple candidate computing nodes based on the service dependency information, the processor 502 is configured to: filter candidate computing nodes in a node cluster based on resources required by the first container unit and / or preset constraints to obtain the multiple candidate computing nodes; score the multiple candidate computing nodes based on the service dependency information of the first container unit to obtain a score for each of the multiple candidate computing nodes; and determine the target candidate computing node from the multiple candidate computing nodes based on the scores for each of the multiple candidate computing nodes.Optionally, when scoring the multiple candidate computing nodes based on the service dependency information of the first container unit and obtaining scores for each of the multiple candidate computing nodes, the processor 502 is specifically configured to: when scoring any candidate computing node among the multiple candidate computing nodes, query the definition information of the first container unit for the first workload corresponding to the first container unit; obtain at least one workload on which the first workload depends from a configuration file of the first workload; traverse the at least one workload and score the candidate computing node based on a dependency weight between the traversed workload and the first workload. Optionally, when traversing the at least one workload and scoring the candidate computing nodes based on a dependency weight between the traversed workload and the first workload, the processor 502 is specifically configured to: when traversing any workload among the at least one workload, determine whether the workload is running on the candidate computing node; and if the workload is running on the candidate computing node, score the candidate computing node based on the dependency weight corresponding to the workload. Optionally, the processor 502 further includes: if the workload is not running on the candidate computing node, setting the score of the candidate computing node to a score below a set threshold. Optionally, when querying the definition information of the first container unit for the first workload corresponding to the first container unit, the processor 502 is specifically configured to: determine, based on the definition information of the first container unit, whether the first container unit belongs to any target application group; if the first container unit belongs to the target application group, determine whether the target application group includes a parent workload of the first container unit; and if the target application group includes the parent workload, use the parent workload as the first workload corresponding to the first container unit. Optionally, before obtaining the service dependency information of the first container unit, the processor 502 is further configured to: obtain traffic monitoring data of the first workload through the first grid proxy component of the first workload; determine, based on the traffic monitoring data of the first workload, at least one workload that has a dependency relationship with the first workload; calculate, based on the traffic monitoring data of the first workload, a dependency weight of the first workload on the at least one workload; and store the at least one workload and its corresponding dependency weight as a dependency relationship of the first workload in a configuration file of the first workload.Optionally, when obtaining the traffic monitoring data of the first workload, the processor 502 is specifically used to perform at least one of the following operations: using a preset traffic statistical indicator to count the inlet traffic and / or outlet traffic of the first workload to obtain the value of the traffic statistical indicator; obtaining an access log from the inlet traffic and / or outlet traffic of the first workload; the access log includes: identification information of the upstream workload, identification information of the downstream workload, and at least one of the protocol type; tracing the path of the access request processed by the first workload to obtain a request processing path of the access request; the request processing path includes: an ordered link formed by the workload for processing the access request. Optionally, a second container unit is running on the target candidate computing node, the container unit being configured to run a second workload corresponding to the target service. After creating the first container unit on the target candidate computing node, the processor 502 is further configured to: obtain, via a first grid proxy component corresponding to the first workload, an access request from the first workload; if the access request is for accessing the target service, intercept the access request and, based on a preset local redirection policy, forward the access request to a second grid proxy component corresponding to the second workload; and forward the access request to the second workload via the second grid proxy component, so that the second workload performs a data processing operation corresponding to the target service on the access request. Optionally, when forwarding the access request to the second grid proxy component corresponding to the second workload based on the preset local redirection policy, the processor 502 is further configured to: obtain a traffic type corresponding to the access request and / or a container unit selection condition corresponding to the first workload; and if the traffic type meets a set type requirement and / or the second container unit meets the container unit selection condition, forward the access request to the second grid proxy component corresponding to the second workload. Optionally, when forwarding the access request to the second grid proxy component corresponding to the second workload, the processor 502 is specifically configured to: obtain quad-tuple information of the access request through the first socket in the first grid proxy component; query a preset socket mapping relationship based on the quad-tuple information to obtain an operation handle for the second socket in the second grid proxy component; and send the access request to the second socket based on the operation handle of the second socket. Furthermore, as shown in FIG5 , the server also includes other components, such as a power supply component 504. FIG5 schematically illustrates only some components and does not imply that the server includes only the components shown in FIG5 .The memory 501 may be implemented by any type of volatile or non-volatile memory device, or a combination thereof, such as static random-access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The communication component 503 is configured to facilitate wired or wireless communication between the device in which the communication component is located and other devices. The device where the communication component is located can access a wireless network based on a communication standard, such as Wi-Fi (wireless network communication technology), 2G (such as Global System for Mobile Communications (GSM)), 3G (such as Wideband Code Division Multiple Access (WCDMA), 4G (such as Long Term Evolution (LTE)), 4G+ (such as upgraded Long Term Evolution (LTE-Advanced, LTE-A)), or 5G (fifth-generation mobile communication technology (5G). thGeneration Mobile Communication Technology), or a combination thereof. In an exemplary embodiment, the communication component receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component can be implemented based on Near Field Communication (NFC) technology, Radio Frequency Identification (RFID) technology, Infrared Data Association (IrDA) technology, Ultra Wide Band (UWB) technology, Bluetooth (BT) technology, and other technologies. Among them, the power supply component 504 is used to provide power to various components of the device where the power supply component is located. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the device where the power supply component is located. In this embodiment, in response to a scheduling request for the first container unit, service dependency information of the first container unit may be obtained, and based on the service dependency information, a target candidate computing node for deploying the first container unit may be determined from multiple candidate computing nodes. After the target computing node is determined, the first container unit may be created on the target candidate computing node. Service dependency information is obtained based on traffic monitoring data of the first workload in the first container unit over a historical period, thereby providing feedback on the first workload's actual dependency on other services. Furthermore, using this service dependency information as a basis for scheduling container units to select candidate nodes can facilitate scheduling dependent container units onto the same compute node, eliminating the need for cross-node communication between dependent container units. When different container units have dependencies, this effectively reduces the network resources required for communication between them. Furthermore, efficient communication mechanisms within compute nodes can be leveraged to improve communication efficiency and service access efficiency between them, thereby significantly improving the workload's service processing performance, service processing efficiency, and service response efficiency. Accordingly, embodiments of the present disclosure also provide a computer-readable storage medium storing a computer program. When executed, the computer program can implement the steps of the method provided in embodiments of the present disclosure. Embodiments of the present disclosure also provide a computer program product comprising a computer program / instructions. When executed by a processor, the computer program / instructions can implement the steps of the method provided in embodiments of the present disclosure.Accordingly, embodiments of the present disclosure also provide a computer program product, including a computer program / instructions. When executed by a processor, the computer program / instructions can implement the steps of the methods provided in the embodiments of the present disclosure. Those skilled in the art will appreciate that the embodiments of the present disclosure can be provided as methods, systems, or computer program products. Therefore, the present disclosure can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present disclosure can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM (Compact Disc Read-Only Memory), optical storage, etc.) containing computer-usable program code. The present disclosure is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present disclosure. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing device produce means for implementing the functions specified in one or more flow charts and / or one or more blocks in a block diagram. These computer program instructions can also be stored in a computer-readable memory that can direct the computer or other programmable data processing device to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means that implement the functions specified in one or more flow charts and / or one or more blocks in a block diagram. These computer program instructions can also be loaded onto a computer or other programmable data processing device, such that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, such that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more flow charts and / or one or more blocks in a block diagram. In a typical configuration, a computing device includes one or more processors (Central Processing Units, CPUs), input / output interfaces, network interfaces, and memory. Memory may include non-permanent storage in a computer-readable medium in the form of random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.Computer-readable media include both permanent and non-permanent, removable and non-removable media that can implement information storage using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media 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 memory technologies, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media, such as modulated data signals and carrier waves. It should also be noted that the terms "comprise," "include," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, product, or apparatus comprising a list of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, product, or apparatus. Without further limitation, the phrase "comprising a..." does not preclude the presence of additional identical elements in the process, method, product, or apparatus comprising the recited elements. The foregoing description is merely an example of the present disclosure and is not intended to limit the present disclosure. Those skilled in the art will readily appreciate that various modifications and variations of the present disclosure are possible. Any modifications, equivalent substitutions, improvements, and the like made within the spirit and principles of the present disclosure are intended to be encompassed by the claims of the present disclosure.

Claims

Claims 1. A container unit scheduling method, comprising: In response to a scheduling request for a first container unit, obtaining service dependency information of the first container unit; The service dependency information is obtained based on traffic monitoring data of a first workload in the first container unit during a historical period; and a target candidate computing node for deploying the first container unit is determined from a plurality of candidate computing nodes based on the service dependency information. The first container unit is created on the target candidate computing node to schedule the first container unit to the target candidate computing node.

2. The method according to claim 1, wherein: Determining, based on the service dependency information, a target candidate computing node for deploying the first container unit from a plurality of candidate computing nodes, includes: filtering candidate computing nodes in a node cluster based on resources required by the first container unit and / or preset constraints to obtain the plurality of candidate computing nodes; scoring the plurality of candidate computing nodes based on the service dependency information of the first container unit to obtain scores for each of the plurality of candidate computing nodes; and determining the target candidate computing node from the plurality of candidate computing nodes based on the scores for each of the plurality of candidate computing nodes.

3. The method according to claim 2, wherein: Scoring the multiple candidate computing nodes according to the service dependency information of the first container unit to obtain scores for each of the multiple candidate computing nodes includes: when scoring any candidate computing node among the multiple candidate computing nodes, querying the first workload corresponding to the first container unit in the definition information of the first container unit; obtaining at least one workload on which the first workload depends from a configuration file of the first workload; traversing the at least one workload, and scoring the candidate computing node according to the dependency weight of the traversed workload and the first workload.

4. The method according to claim 3, wherein: Traversing the at least one workload and scoring the candidate computing node according to the dependency weight between the traversed workload and the first workload, including: when traversing any workload in the at least one workload, determining whether the workload is running on the candidate computing node; if the workload is running on the candidate computing node, scoring the candidate computing node according to the dependency weight corresponding to the workload.

5. The method according to claim 4, wherein: Also includes: If the workload is not running on the candidate computing node, the score of the candidate computing node is set to a score lower than a predetermined threshold.

6. The method according to claim 3, wherein: Querying the first workload corresponding to the first container unit in the definition information of the first container unit includes: determining, according to the definition information of the first container unit, whether the first container unit belongs to any target application group; 25 If the first container unit belongs to the target application group, determine whether the target application group includes the parent workload of the first container unit; if the target application group includes the parent workload, use the parent workload as the first workload corresponding to the first container unit.

7. The method according to any one of claims 1 to 6, wherein: Before obtaining the service dependency information of the first container unit, the method further includes: obtaining traffic monitoring data of the first workload through the first grid agent component of the first workload; determining at least one workload that has a dependency relationship with the first workload based on the traffic monitoring data of the first workload; calculating the dependency weight of the first workload on the at least one workload based on the traffic monitoring data of the first workload; and storing the at least one workload and its corresponding dependency weight as the dependency relationship of the first workload in the configuration file of the first workload.

8. The method according to claim 7, wherein: Obtaining traffic monitoring data of the first workload includes at least one of the following: using a preset traffic statistical indicator to collect statistics on the inlet traffic and / or the outlet traffic of the first workload to obtain a value of the traffic statistical indicator; Obtaining an access log from the ingress traffic and / or egress traffic of the first workload; the access log including: identification information of the upstream workload, identification information of the downstream workload, and at least one of the protocol type; tracing the path of the access request processed by the first workload to obtain a request processing path for the access request; the request processing path including: an ordered link formed by the workload for processing the access request.

9. The method according to any one of claims 1 to 6, wherein: A second container unit is running on the target candidate computing node, and the container unit is used to run a second workload corresponding to the target service; After creating the first container unit on the target candidate computing node, the method further includes: obtaining an access request of the first workload through a first grid proxy component corresponding to the first workload; If the access request is for accessing the target service, the access request is intercepted and, based on a preset redirection policy, forwarded to a second grid proxy component corresponding to the second workload. The second grid proxy component then forwards the access request to the second workload, so that the second workload performs a data processing operation corresponding to the target service on the access request.

10. The method according to claim 9, wherein: Forwarding the access request to the second grid proxy component corresponding to the second workload based on a preset local redirection policy includes: obtaining a traffic type corresponding to the access request and / or a container unit selection condition corresponding to the first workload; and forwarding the access request to the second grid proxy component corresponding to the second workload if the traffic type meets the set type requirements and / or the second container unit meets the container unit selection condition.

11. The method according to claim 9, wherein: Forwarding the access request to a second grid proxy component corresponding to the second workload includes: obtaining, through a first socket in the first grid proxy component, quad-tuple information of the access request; querying a preset socket mapping relationship based on the quad-tuple information to obtain an operation handle of a second socket in the second grid proxy component; and sending the access request to the second socket based on the operation handle of the second socket.

12. A server comprising: memory and processor; The memory is configured to store one or more computer instructions; the processor is configured to execute the one or more computer instructions to perform the steps of the method according to any one of claims 1 to 11.

13. A computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, the computer program can implement the steps of the method described in any one of claims 1 to 11.

14. A computer program product, comprising a computer program / instructions, wherein when the computer program / instructions are executed by a processor, the steps of the method according to any one of claims 1 to 11 can be implemented.

Images