Resource scheduling method and device, equipment, storage medium and product

Abstract

The invention discloses a resource scheduling method, device and equipment, a storage medium and a product, and is applied to a container arrangement platform K8s cluster, the method comprises the following steps: receiving a service request sent by a service requester, the service request being used for requesting to access an upper layer service; determining a node where a service requester is located based on a pre-acquired cluster resource mapping table and the service request; based on the cluster resource mapping table, a first service provider corresponding to the upper layer service is determined, and the first service provider and the service requester run on the same node; and instructing the service requester to access the first service provider. According to the application, a local priority scheduling strategy is realized, when the upper-layer service in the K8s cluster is requested, the service request is sent to the service provider operating at the same node as the service requester based on the cluster resource mapping table, so that network delay and bandwidth consumption are reduced, and the service request directly points to the service provider, so that the service request is more convenient to use. The virtual address of the upper-layer service does not need to be obtained, and headless service is compatible.

Description

Technical Field

[0001] The present application relates to resource scheduling processing technology, and in particular to a resource scheduling method, device, equipment, storage medium and product. Background Art

[0002] The container orchestration platform (Kubernetes, K8s) simplifies the deployment, expansion and management of containerized applications, and supports functions such as automatic load balancing, service discovery, horizontal expansion and rolling updates. It is widely used in cloud-native application development and deployment. K8s Domain Name System (DNS) is a service discovery mechanism. K8sDNS assigns a unique domain name to each upper-level service in the K8s cluster. When a Pod in the cluster communicates with other upper-level services, K8s DNS obtains the corresponding IP address based on the accessed service name, and establishes communication with the upper-level service based on the service name.

[0003] The service types within the K8s cluster include Cluster IP Service and Headless Service. The Cluster IP Service is the default type of service. The Cluster IP Service will assign a virtual IP address. The Pod corresponding to this service is usually not directly accessed by other Pods within the K8s cluster. Instead, the Pod corresponding to this service is accessed by accessing the virtual IP address. Specifically, when the service requests the Pod to access the Cluster IP Service based on the virtual IP address, the Cluster IP Service determines the corresponding Pod to be accessed based on the set load balancing strategy. Headless services do not assign virtual IP addresses, but directly point K8s DNS resolution to the IP address of the corresponding Pod. Headless services are usually used for applications that require direct communication with each corresponding Pod or require complex service discovery. In the related technology, when a cluster address service is requested, based on the load balancing strategy, the service request may be sent to a service instance on a node that is far away from the service request Pod, which obviously increases network latency and bandwidth loss. In addition, the process of allocating traffic to the Pod corresponding to the upper-layer service based on the load balancing strategy involves network layer forwarding and packet processing, which will cause performance loss. When a headless service is requested, the headless service does not support the load balancing strategy and has no corresponding resource scheduling method. Summary of the invention

[0004] In view of this, the embodiments of the present application provide a resource scheduling method, apparatus, device, storage medium and product, which aim to reduce the network traffic generated during service resource scheduling within a K8s cluster and achieve compatibility with headless services.

[0005] The technical solution of the embodiment of the present application is implemented as follows:

[0006] In a first aspect, an embodiment of the present application provides a resource scheduling method, which is applied to a K8s cluster, and the method includes:

[0007] Receiving a service request sent by a service requester, wherein the service request is used to request access to an upper layer service;

[0008] Determine the node where the service requester is located based on the pre-acquired cluster resource mapping table and the service request;

[0009] Determine, based on the cluster resource mapping table, a first service provider corresponding to the upper-layer service, where the first service provider and the service requester run on the same node;

[0010] The service requester is instructed to access the first service provider.

[0011] In the above solution, the method further includes:

[0012] Acquire the cluster resource mapping table, where the cluster resource mapping table includes a first mapping table, a second mapping table, and a third mapping table;

[0013] Among them, the first mapping table indicates the correspondence between Pod information and Pod address, and the Pod information includes the node name; the second mapping table indicates the correspondence between service information and service name of the upper-layer service; the third mapping table indicates the relationship between the service name of the upper-layer service and the Pod address; the Pod is the resource unit of the service requester and service provider.

[0014] In the above solution, determining the node where the service requester is located based on the pre-acquired cluster resource mapping table and the service request includes:

[0015] Based on the Pod address corresponding to the service requester carried in the service request, the first mapping table is queried to determine the node name of the node where the service requester is located.

[0016] In the above solution, determining the first service provider corresponding to the upper layer service based on the cluster resource mapping table includes:

[0017] Based on the service name of the upper-layer service carried in the service request, query the third mapping table to obtain the Pod address of each service provider corresponding to the upper-layer service;

[0018] Based on the Pod addresses of the service providers corresponding to the upper-layer service, query the first mapping table to obtain the Pod addresses of the service providers running on the same node as the service requester, and generate a first sub-list;

[0019] A first Pod address is selected from the first sub-list, and a service provider corresponding to the first Pod address is determined to be the first service provider, and the first Pod address is any Pod address in the first sub-list.

[0020] In the above solution, the step of instructing the service requester to access the first service provider includes:

[0021] Instruct the service requester to access the first service provider based on the first Pod address.

[0022] In the above solution, before determining the node where the service requester is located based on the pre-acquired cluster resource mapping table and the service request, the method further includes:

[0023] Based on the service name of the upper layer service carried in the service request, query the second mapping table;

[0024] Based on the corresponding service information queried, if it is determined that the upper-layer service exists in the K8s cluster, the node where the service requester is located is obtained;

[0025] If it is determined that the upper-layer service does not exist in the K8s cluster, an indication indicating that the service name cannot be resolved is returned to the service requester.

[0026] In the above solution, the method further includes:

[0027] Based on the Pod addresses of the service providers corresponding to the upper-layer service, query the first mapping table to obtain the Pod addresses of the service providers that are not running on the same node as the service requester, and generate a second sub-list;

[0028] If it is determined that there is no available first service provider in the K8s cluster, determining a second service provider corresponding to the upper-layer service based on the second sublist;

[0029] The service requester is instructed to access the second service provider.

[0030] In the above solution, determining the second service provider corresponding to the upper layer service based on the second sublist includes:

[0031] A second Pod address is selected from the second sub-list, and a service provider corresponding to the second Pod address is determined to be the second service provider, and the second Pod address is any Pod address in the second sub-list.

[0032] In the above solution, the method further includes:

[0033] Create one or more headless services in the K8s cluster;

[0034] The headless service is an upper layer service to which a corresponding service address is not allocated; and the service request is specifically used to request access to the headless service.

[0035] In a second aspect, an embodiment of the present application provides a resource scheduling device, which is applied to a K8s cluster, and the device includes:

[0036] A receiving module, used to receive a service request sent by a service requester, wherein the service request is used to request access to an upper layer service;

[0037] A first determination module, configured to determine the node where the service requester is located based on a pre-acquired cluster resource mapping table and the service request;

[0038] A second determination module is used to determine a first service provider corresponding to the upper layer service based on the cluster resource mapping table, where the first service provider and the service requester run on the same node;

[0039] The instruction module is used to instruct the service requester to access the first service provider.

[0040] In a third aspect, an embodiment of the present application provides a resource scheduling device, comprising: a processor and a memory for storing a computer program that can be run on the processor, wherein the processor, when running the computer program, executes the steps of the method described in the first aspect.

[0041] In a fourth aspect, an embodiment of the present application provides a storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of the method described in the first aspect are implemented.

[0042] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the method described in the first aspect.

[0043] The embodiment of the present application provides a resource scheduling method applied to a K8s cluster, the method comprising: receiving a service request sent by a service requester, the service request being used to request access to an upper-layer service; determining the node where the service requester is located based on a pre-acquired cluster resource mapping table and a service request; determining the first service provider corresponding to the upper-layer service based on the cluster resource mapping table, the first service provider and the service requester running on the same node; instructing the service requester to access the first service provider. In this way, the embodiment of the present application implements a local priority scheduling strategy based on service topology awareness technology. When an upper-layer service in a K8s cluster is requested, the service request is sent to a service provider running on the same node as the service requester based on the cluster resource mapping table, thereby reducing network latency and bandwidth consumption. Moreover, the service request of the embodiment of the present application directly points to the service provider, without obtaining the virtual address of the upper-layer service, and is compatible with headless services. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 This is a schematic diagram of the resource objects of the K8s cluster;

[0045] Figure 2 It is a schematic diagram of a K8s resource scheduling method in related technologies;

[0046] Figure 3 A schematic diagram of a resource scheduling method according to an embodiment of the present application;

[0047] Figure 4 A schematic diagram of a resource scheduling method in an application example of the present application;

[0048] Figure 5 A schematic diagram of a resource scheduling method in another application example of the present application;

[0049] Figure 6 A method diagram of a service request processing method applied to a K8s cluster in an application example of this application;

[0050] Figure 7 This is a schematic diagram of the structure of the resource scheduling device according to an embodiment of the present application;

[0051] Figure 8 This is a schematic diagram of the structure of the resource scheduling device according to an embodiment of the present application. DETAILED DESCRIPTION

[0052] The present application is further described in detail below in conjunction with the accompanying drawings and embodiments.

[0053] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein in the specification of this application are only for the purpose of describing specific embodiments and are not intended to limit this application.

[0054] Before describing the resource scheduling method of the embodiment of the present application, a brief description of the K8s cluster is first given. Pod is the smallest resource unit that can be scheduled in the K8s cluster, running on the worker node Worker. A Worker contains multiple Pods, and each Pod encapsulates one or more containers; the upper-level service Service is a resource object of the K8s cluster, which is used to expose the network application running on one or a group of Pods as a network service, and each Pod corresponds to a service instance; K8sDNS is a service discovery mechanism of the K8s cluster. When a Service is created in the K8s cluster, the K8s DNS service will assign a unique domain name to the Service. When accessing within the K8s cluster, other Pods can establish communication with the Service based on the service name. Specifically, K8s DNS will resolve the corresponding IP address based on the service name to instruct other Pods to access the Service.

[0055] Specifically, Figure 1 As shown, in one example, the K8s cluster includes a first worker node Worker1 and a second worker node Worker2, and the Pods corresponding to the Service in the K8s cluster include Pod1, Pod2, and Pod3, wherein Pod1 runs on Worker1, and Pod2 and Pod3 run on Worker2, and Pod1, Pod2, and Pod3 serve as service instances of the Service. When the Service is requested to be accessed, at least one of Pod1, Pod2, and Pod3 responds to the service request.

[0056] Here, in the K8s cluster, Pod is a temporary resource that changes dynamically when running an application. The Service cannot grasp the corresponding Pod quantity, Pod address, and Pod availability in real time. Therefore, a resource object with the same name as the Service is created in the K8s cluster: Endpoint, to record the changes in the Pod corresponding to the Service. The endpoint Endpoint is the interface for accessing the Pod corresponding to the Service. The Endpoint information includes information such as the Endpoint address and the node name NodeName. Among them, the Endpoint corresponds to the Pod one-to-one, and the Endpoint address is the Pod address of the Pod corresponding to the service with the same name. When the Pod corresponding to the Service changes, the Endpoint Endpoint corresponding to the Service updates the Endpoint information based on the Pod change. When the Service is requested, the access request can be sent to the Pod corresponding to the Service based on the Endpoint information to provide the corresponding service. It should be noted that the K8s cluster supports multiple types of services, and different types of services can be selected according to different usage scenarios. For example, the Cluster IP Service is used for internal access to the K8s cluster, where the Cluster IP Service provides a unified virtual IP address for the corresponding Pods. When the service request Pod requests to access the Cluster IP Service, the service request Pod can access the Pod corresponding to the Cluster IP Service based on the virtual IP address returned by the K8s DNS service. Specifically, after the Cluster IP Service receives the service request, it determines the corresponding one or more Pods to respond to the request based on the set scheduling strategy (such as load balancing strategy). In the internal access scenario of the K8s cluster, it also supports requesting a Headless Service. The Headless Service will not allocate a virtual IP address (that is, the IP address is None). When the Headless Service is requested, the IP address of the Pod corresponding to the Headless Service is directly returned after K8s DNS resolution. The Headless Service is usually used for applications that require direct communication with each corresponding Pod or require complex service discovery.

[0057] It should be noted that in the related technology, the service request Pod accesses the Service based on the IP address returned after K8s DNS resolution. If the requested Service is a cluster address service, the returned IP address is the virtual IP address of the cluster address service; if the requested service is a headless service, the returned IP address is the IP address of the Pod corresponding to the headless service. When the cluster address service is requested, based on the load balancing strategy, the resource usage status of each corresponding service instance is given priority when scheduling resources. The service request of the service request Pod may be sent to an idle service instance far away from the service request Pod, which increases the network delay and bandwidth loss of the service. In addition, the process of allocating traffic to the Pod based on the load balancing strategy by the cluster address service involves forwarding and data processing at the network layer, resulting in performance consumption; and when the headless service is requested, the headless service does not support the load balancing strategy and has no responsive resource scheduling method.

[0058] Specifically, Figure 2 As shown, in one example, the Service is a cluster address service. When Pod4 running on Worker1 requests to access the Service, the K8s DNS service resolves the service name of the Service carried in the access request and returns the virtual IP address corresponding to the Service. Pod4 accesses the Service based on the returned virtual IP address. The Service determines that Pod2 running on Worker2 is currently idle based on the Endpoint information according to the load balancing strategy, and sends the access request to Pod2 based on the Endpoint2 information, and Pod2 provides services for Pod4.

[0059] Based on this, the present application provides a resource scheduling method for applying a K8s cluster, aiming to improve the response speed and performance of the service and reduce the generation of network traffic in the internal access scenario of the K8s cluster, and this method is compatible with headless services.

[0060] The present application embodiment provides a resource scheduling method, which is applied to a K8s cluster. Figure 3 As shown, the method includes:

[0061] Step 301: Receive a service request sent by a service requester, where the service requester is used to request access to an upper-layer service. Here, Pod is the resource unit of the service requester, and the service requester is specifically the service requester Pod. The service request carries the Pod address of the service requester Pod and the service name of the service requested to be accessed. The service name of the service is used to obtain the corresponding IP address after K8s DNS resolution.

[0062] Step 302: Determine the node where the service requester is located based on the pre-acquired cluster resource mapping table and the service request.

[0063] Here, the service request Pod runs on a working node, which can be a virtual machine node, a physical machine node, or a cloud server node. Exemplarily, the method also includes: obtaining a cluster resource mapping table, the cluster resource mapping table includes a first mapping table, a second mapping table, and a third mapping table. Among them, the first mapping table indicates the correspondence between Pod information and Pod address, and the Pod information includes the node name; the second mapping table indicates the correspondence between the service information and the service name of the upper-level service; the third mapping table indicates the relationship between the service name of the upper-level service and the Pod address.

[0064] It should be noted that K8s supports a list connection mechanism (List-Watch). List-Watch is a mechanism provided by the K8s API Server for monitoring changes in resource objects. The specific mechanism is as follows: the client sends a list request to the K8s API server, requesting a list of objects of a specific resource type; the K8s API server returns a list of resource objects and maintains a connection with the client; when the resource object requested by the list changes (such as creation, update, or deletion), the K8s API server sends a change notification to the client; after receiving the change notification, the client can process it as needed, such as updating the local cache or triggering an operation.

[0065] It can be understood that the embodiment of the present application is based on the List-Watch mechanism, which can obtain the full object list of a specific resource type from the K8s application interface server in real time and obtain the cluster resource mapping table without frequently sending requests to poll the K8s application interface server.

[0066] Here, the cluster resource mapping table obtained by the embodiment of the present application includes a first mapping table, a second mapping table and a third mapping table, wherein the first mapping table is a Pods mapping table, indicating the correspondence between Pod information and Pod address, and the Pod information includes the Pod name and the node name (Node Name) of the node where the Pod is located, and other information. Based on the first mapping table, the Pod information of each Pod in the K8s cluster can be quickly queried.

[0067] Exemplarily, based on the pre-acquired cluster resource mapping table and the service request, determining the node where the service requester is located includes: querying the first mapping table based on the Pod address corresponding to the service requester carried in the service request, and determining the node name of the node where the service requester is located.

[0068] It can be understood that when the K8s DNS service in the K8s cluster resolves the service name carried in the service request, it can obtain the node name of the node where the service request Pod is located based on the first mapping table and the Pod address of the service request Pod also carried in the service request.

[0069] Here, the second mapping table in the cluster resource mapping table is the Services mapping table, which indicates the correspondence between the service information of the Service and the service name, wherein the service information may include at least one of the following: service type, service address and port information. Based on the second mapping table, the service information of the Service in the K8s cluster can be quickly queried.

[0070] In an application example of the present application, the service name is named in the form of "service identifier.namespace name" to isolate service resources under different namespaces.

[0071] Here, the third mapping table in the cluster resource mapping table is the Endpoints mapping table, which indicates the relationship between the service name of the Service and the Pod address. Based on the third mapping table, the Endpoint information corresponding to the Service in K8s can be quickly queried.

[0072] It can be understood that the K8s DNS service in the embodiment of the present application obtains the full object list of Pod, Service and Endpoint based on the List-Watch mechanism, and then obtains the cluster resource mapping table.

[0073] Exemplarily, before determining the node where the service requester is located based on the pre-acquired cluster resource mapping table and service request, the method also includes: querying the second mapping table based on the service name of the upper-layer service carried in the service request; based on the corresponding service information queried, if it is determined that the upper-layer service exists in the K8s cluster, obtaining the node where the service requester is located; if it is determined that the upper-layer service does not exist in the K8s cluster, returning an indication to the service requester indicating that the service name cannot be resolved.

[0074] It should be noted that before performing resource scheduling, the embodiment of the present application first determines whether an available Service has been created in the K8s cluster by querying the second mapping table based on the service name of the Service requested by the service request Pod. If the corresponding service information is queried, the subsequent resource scheduling method is executed; if the corresponding service information is not queried, the K8sDNS service returns an indication that the service name cannot be resolved to the service request Pod, and the subsequent resource scheduling method is no longer executed.

[0075] Step 303: Determine a first service provider corresponding to the upper layer service based on the cluster resource mapping table, where the first service provider and the service requester run on the same node.

[0076] Here, the service provider is the service instance of the requested Service, and the Pod is the resource unit of the service provider. The service provider is specifically the Pod corresponding to the Service, and the Pod corresponding to the Service runs on the working node.

[0077] Exemplarily, based on the cluster resource mapping table, determining the first service provider corresponding to the upper-layer service includes: based on the service name of the upper-layer service carried in the service request, querying the third mapping table to obtain the Pod addresses of each service provider corresponding to the upper-layer service; based on the Pod addresses of each service provider corresponding to the upper-layer service, querying the first mapping table to obtain the Pod addresses of each service provider running on the same node as the service requester, and generating a first sub-list; selecting the first Pod address from the first sub-list, and determining that the service provider corresponding to the first Pod address is the first service provider, and the first Pod address is any Pod address in the first sub-list.

[0078] It should be noted that the embodiment of the present application performs resource scheduling based on the local priority strategy (Local First), that is, after receiving the service request sent by the service request Pod, the service instance on the node where the service request Pod is located is preferentially selected to respond to the request, which can reduce cross-node network communication and improve the response speed and reliability of the service.

[0079] It is understandable that the service request Pod accesses the service instance through any Pod address in the first sublist, which is an internal access to the local node, and no cross-node network communication is performed.

[0080] It can be understood that the embodiment of the present application is based on creating a first mapping table indicating the correspondence between Pod information and Pod address and a third mapping table indicating the correspondence between Endpoint information and service name, so that after the service name of the Service carried by the service request is resolved, the Pod information of the service instance running on the local node can be directly obtained, and one of the service instances can be randomly selected to respond to the request, effectively avoiding the problem that the Service may dispatch a service instance that is far away from the service request Pod to respond to the request.

[0081] Step 304: instruct the service requester to access the first service provider.

[0082] Exemplarily, instructing the service requester to access the first service provider includes: instructing the service requester to access the first service provider based on the first Pod address.

[0083] Exemplarily, the method also includes: creating one or more headless services in the K8s cluster; wherein the headless service is an upper-layer service that does not allocate a corresponding service address; and the service request is specifically used to request access to the headless service.

[0084] Here, in the embodiment of the present application, in addition to being used to request access to the cluster address service, the service request can also be used to request access to the headless service. It is understandable that in the embodiment of the present application, regardless of whether the service request Pod requests access to the cluster address service or the headless service, the K8s DNS service will return the first Pod address of the first service provider for access, thereby achieving compatibility with the headless service; and the service request Pod directly accesses the service instance based on the first Pod address, eliminating the step of determining the service instance that responds to the request based on the load balancing strategy after the Service is requested, thereby avoiding the problem of performance loss caused by the above steps. In an application example of the present application, such as Figure 4 As shown, when Pod4 requests to access the Service, the K8s DNS service obtains the service name of the Service and the Pod address of Pod4 carried in the access request, and determines that there is an available Service in the K8s cluster based on the query of the second mapping table. Then, based on the first mapping table, it is determined that Pod4 is running on Worker1, and based on the third mapping table, it is obtained that among the Pods corresponding to the Service, there is Pod1 running on Worker1, and the Pod address corresponding to Pod1 is returned to Pod4. Pod4 directly accesses Pod1 based on the returned Pod address, thereby realizing local node priority scheduling.

[0085] Here, the open source DNS server CoreDNS runs on the K8s DNS service. CoreDNS has a modular architecture and can extend functions through plug-ins as needed. Based on the List-Watch mechanism, the K8s DNS service requests a connection to the API server of the K8s cluster, obtains a full list of cluster resource objects from the API server based on the connection interface, generates an initialized cluster resource mapping table based on the obtained full list, and subscribes to change notifications of cluster resource objects from the API server based on the connection interface to update the cluster resource mapping table. It can be understood that the adaptive adjustment of CoreDNS in the embodiment of the present application can enable the K8s DNS service to obtain a cluster resource mapping table including service information, Pod information, and endpoint information.

[0086] Exemplarily, the method also includes: based on the Pod addresses of each service provider corresponding to the upper-layer service, querying the first mapping table, obtaining the Pod addresses of each service provider that does not run on the same node as the service requester, and generating a second sub-list; if it is determined that there is no available first service provider in the K8s cluster, then based on the second sub-list, obtaining the second service provider corresponding to the upper-layer service; instructing the service requester to access the second service provider.

[0087] It is understandable that after querying the first mapping table to determine that the requested Service has no corresponding available service instance running on the local node, the service request is sent to the service instance running on other nodes because the service instance of the local node cannot be scheduled.

[0088] Exemplarily, based on the second sub-list, obtaining the second service provider corresponding to the upper-layer service includes: selecting a second Pod address from the second sub-list, and determining that the service provider corresponding to the second Pod address is the second service provider, and the second Pod address is any Pod address in the second sub-list.

[0089] Here, if the requested Service is a cluster address service, a second service provider for responding to the request may also be determined based on a load balancing strategy.

[0090] In an application example of the present application, Figure 5 As shown in the figure, if Pod1 corresponding to the Service has been deleted or is unavailable, when Pod4 requests to access the Service, the K8s DNS service determines that Pod4 is running on Worker1 based on the first mapping table, and based on the third mapping table, it is found that there is no available Pod running on Worker1 among the Pods corresponding to the Service. Then the K8s DNS service randomly returns the Pod address of Pod2, and Pod4 directly accesses Pod2 based on the returned Pod address, and Pod2 responds to the service.

[0091] In an application example of the present application, the K8s DNS service can also obtain the topological distance between each node in the K8s cluster based on the List-Watch mechanism. If it is determined that there is no available Pod running on the local node among the Pods corresponding to the Service requested by the service request Pod to access, then based on the topological distance between the nodes, the Pod address of one or more Pods corresponding to the Service on the node closest to the node where the service request Pod is located is returned to the service request Pod.

[0092] In an application example of the present application, a service request processing method applied to a K8s cluster is provided, such as Figure 6 As shown, the method includes:

[0093] Step 601, the K8s DNS service receives a service request from a service request Pod.

[0094] Here, the service request carries the Pod address of the service request Pod and the service name of the requested Service.

[0095] Here, the K8s DNS service pre-acquires a cluster resource mapping table based on the List-Watch mechanism. The cluster resource mapping table includes a first mapping table indicating Pod information, a second mapping table indicating Service information, and a third mapping table indicating Endpoint information.

[0096] Step 602, the K8s DNS service resolves the service request and obtains the namespace name and service identifier of the requested Service.

[0097] Step 603, based on the second mapping table, determine whether there is a corresponding Service in the K8s cluster. If so, execute step 604; if not, execute step 612.

[0098] Here, the second mapping table records the correspondence between the service name and the service information. Based on the parsed namespace name and service identifier, it is queried whether the corresponding service information is recorded in the second mapping table to determine whether the corresponding Service exists in the K8s cluster.

[0099] Step 604, the K8s DNS service resolves the service request and obtains the Pod address of the service request Pod.

[0100] Step 605, the K8s DNS service queries the Pod information of the service request Pod based on the first mapping table and the Pod address of the service request Pod, including the node name of the node where the service request Pod is located.

[0101] Step 606, the K8s DNS service queries the Pod address of each Pod corresponding to the Service and the node name of the node where the Pod is located based on the first mapping table, the third mapping table, the node name of the node where the service request Pod is located, the namespace name of the Service, and the service identifier.

[0102] Here, the third mapping table records the Endpoint information corresponding to the Service. Based on the service name including the namespace name and the service identifier, the Pod address of each Pod corresponding to the Service can be queried; based on the queried Pod addresses and the first mapping table, the node name corresponding to the Pod address is obtained.

[0103] Step 607: The K8s DNS service traverses the third mapping table and divides the obtained Pod addresses into a first sub-list and a second sub-list based on the corresponding node names.

[0104] Here, the first sublist includes the Pod addresses corresponding to the node names of the nodes where the service request Pod is located, and the second sublist includes the Pod addresses corresponding to the node names of the nodes where the non-service request Pod is located.

[0105] Here, the service instance corresponding to the Pod address in the first sublist is a service instance with local priority scheduling.

[0106] Step 608 , determining whether the first sublist is an empty list, if so, executing step 610 ; if not, executing step 609 .

[0107] Step 609: The K8s DNS service randomly selects a Pod address from the first sublist and returns the selected Pod address to the service requesting Pod.

[0108] Step 610, determining whether the second sublist is an empty list, if so, executing step 612; if not, executing step 611.

[0109] Step 611, the K8s DNS service randomly selects a Pod address from the second sublist and returns the selected Pod address to the service request Pod.

[0110] Here, if the first sublist is an empty list, it means that there is currently no available service instance of the Service on the K8s DNS service, and the local priority policy cannot be executed; if the second sublist is not an empty list, a Pod address is randomly returned to respond to the request.

[0111] In step 612, the K8s DNS service returns an error message indicating that the resolution cannot be performed to the service requesting Pod.

[0112] Here, if the service information corresponding to the namespace name and service identifier carried in the service request is not found based on the first mapping table, it means that the corresponding Service is not created in the K8s cluster, and an error prompt is returned.

[0113] Here, if both the first sublist and the second sublist are empty lists, it means that the service instances of the Service in the K8s cluster are currently unavailable, and an error prompt is returned.

[0114] It can be understood that the service request processing method of this application example, combined with the method for obtaining the cluster resource mapping table, can implement the resource scheduling method applied to the K8s cluster of the embodiment of the present application.

[0115] In order to implement the method of the embodiment of the present application, the embodiment of the present application also provides a resource scheduling device for a K8s cluster. The resource scheduling device corresponds to the above-mentioned resource scheduling method, and each step in the above-mentioned resource scheduling method embodiment is also fully applicable to the embodiment of the present device.

[0116] like Figure 7 As shown, an embodiment of the present application provides a resource scheduling device, which is applied to a K8s cluster, and the device includes: a receiving module 701, a first determination module 702, a second determination module 703 and an indication module 704. The receiving module 701 is used to receive a service request sent by a service requester, and the service request is used to request access to an upper-layer service. The first determination module 702 is used to determine the node where the service requester is located based on a pre-acquired cluster resource mapping table and a service request. The second determination module 703 is used to determine the first service provider corresponding to the upper-layer service based on the cluster resource mapping table, and the first service provider and the service requester run on the same node. The indication module 704 is used to instruct the service requester to access the first service provider.

[0117] In some embodiments, the resource scheduling device further includes an acquisition module 705. The acquisition module 705 is used to acquire a cluster resource mapping table, which includes a first mapping table, a second mapping table, and a third mapping table. The first mapping table indicates the correspondence between Pod information and Pod addresses, and the Pod information includes a node name; the second mapping table indicates the correspondence between service information and service names of upper-layer services; the third mapping table indicates the relationship between service names and Pod addresses of upper-layer services; and Pod is a resource unit of a service requester and a service provider.

[0118] In some embodiments, the first determination module 702 is also used to: query the second mapping table based on the service name of the upper-layer service carried in the service request; based on the corresponding service information queried, if it is determined that the upper-layer service exists in the K8s cluster, obtain the node where the service requester is located; if it is determined that the upper-layer service does not exist in the K8s cluster, return an indication information indicating that the service name cannot be resolved to the service requester.

[0119] In some embodiments, the first determination module 702 is specifically used to: query the first mapping table based on the Pod address corresponding to the service requester carried in the service request, and determine the node name of the node where the service requester is located.

[0120] In some embodiments, the second determination module 703 is specifically used to: query the third mapping table based on the service name of the upper-layer service carried by the service request, and obtain the Pod addresses of each service provider corresponding to the upper-layer service; query the first mapping table based on the Pod addresses of each service provider corresponding to the upper-layer service, obtain the Pod addresses of each service provider running on the same node as the service requester, and generate a first sub-list; select the first Pod address from the first sub-list, and determine that the service provider corresponding to the first Pod address is the first service provider, and the first Pod address is any Pod address in the first sub-list.

[0121] In some embodiments, the instructing module 704 is specifically used to instruct the service requester to access the first service provider based on the first Pod address.

[0122] In some embodiments, the second determination module 703 is also used to: query the first mapping table based on the Pod addresses of each service provider corresponding to the upper-layer service, obtain the Pod addresses of each service provider that does not run on the same node as the service requester, and generate a second sub-list; if it is determined that there is no available first service provider in the K8s cluster, determine the second service provider corresponding to the upper-layer service based on the second sub-list.

[0123] In some embodiments, the instructing module 704 is further configured to instruct the service requester to access the second service provider.

[0124] In some embodiments, the second determination module 703 is specifically used to: select a second Pod address from the second sub-list, and determine that the service provider corresponding to the second Pod address is the second service provider, and the second Pod address is any Pod address in the second sub-list.

[0125] In some embodiments, the resource scheduling device further includes a creation module 706. The creation module 706 is used to create one or more headless services in the K8s cluster. Wherein, the headless service is an upper layer service that does not allocate a corresponding service address; the service request is specifically used to request access to the headless service.

[0126] It should be noted that the resource scheduling device provided in the above embodiment only uses the division of the above program modules as an example when performing resource scheduling. In actual applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the device is divided into different program modules to complete all or part of the processing described above. In addition, the resource scheduling device provided in the above embodiment and the resource scheduling method embodiment belong to the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0127] Based on the hardware implementation of the above program modules, and in order to implement the method of the embodiment of the present application, the embodiment of the present application also provides a resource scheduling device. Figure 8 Only an exemplary structure of the resource scheduling device is shown, not the entire structure, and can be implemented as needed. Figure 8 Partial or complete structure shown.

[0128] like Figure 8 As shown, the resource scheduling device 800 provided in the embodiment of the present application includes: at least one processor 801, a memory 802, a user interface 803 and at least one network interface 804. The various components in the resource scheduling device 800 are coupled together through a bus system 805. It can be understood that the bus system 805 is used to realize the connection and communication between these components. In addition to the data bus, the bus system 805 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, in Figure 8 Various buses are labeled as bus system 805 .

[0129] The user interface 803 may include a display, a keyboard, a mouse, a trackball, a click wheel, keys, buttons, a touch pad or a touch screen.

[0130] The memory 802 in the embodiment of the present application is used to store various types of data to support the operation of the resource scheduling device 800. Examples of such data include: any computer program used to operate on the resource scheduling device 800.

[0131] The resource scheduling method disclosed in the embodiment of the present application can be applied to the processor 801, or implemented by the processor 801. The processor 801 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the resource scheduling method can be completed by the hardware integrated logic circuit or software instructions in the processor 801. The above-mentioned processor 801 can be a general-purpose processor, a digital signal processor (DSP, Digital Signal Processor), or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. The processor 801 can implement or execute the various methods, steps and logic block diagrams disclosed in the embodiment of the present application. The general-purpose processor can be a microprocessor or any conventional processor, etc. In combination with the steps of the method disclosed in the embodiment of the present application, it can be directly embodied as a hardware decoding processor to execute, or it can be executed by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium, which is located in the memory 802. The processor 801 reads the information in the memory 802 and completes the steps of the resource scheduling method provided in the embodiment of the present application in combination with its hardware.

[0132] In an exemplary embodiment, the resource scheduling device 800 can be implemented by one or more application specific integrated circuits (ASIC), DSP, programmable logic device (PLD), complex programmable logic device (CPLD), FPGA, general processor, controller, microcontroller (MCU), microprocessor, or other electronic components to execute the aforementioned resource scheduling method.

[0133] It can be understood that the memory 802 can be a volatile memory or a non-volatile memory, and can also include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an EEPROM, a magnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disk, or a compact disc read-only memory (CD-ROM); the magnetic surface memory can be a disk memory or a tape memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available, such as static random access memory (SRAM), synchronous static random access memory (SSRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), direct memory bus random access memory (DRRAM). The memory described in the embodiments of the present application is intended to include but is not limited to these and any other suitable types of memory.

[0134] In an exemplary embodiment, the present application also provides a storage medium, namely a computer storage medium, which can be a computer-readable storage medium, for example, a memory 802 storing a computer program, and the computer program can be executed by a processor 801 of a resource scheduling device 800 to complete the steps described in the resource scheduling method of the present application embodiment. The computer-readable storage medium can be a memory such as a ROM, a PROM, an EPROM, an EEPROM, a Flash Memory, a magnetic surface memory, an optical disk, or a CD-ROM.

[0135] In an exemplary embodiment, the embodiment of the present application further provides a computer program product, including a computer program, which can be executed by the processor 801 of the resource scheduling device 800 to complete the steps described in the method of the embodiment of the present application.

[0136] It should be noted that: "first", "second", etc. are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0137] In addition, the technical solutions described in the embodiments of the present application can be combined arbitrarily without conflict.

[0138] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A resource scheduling method, characterized in that: Applied to the K8s cluster of the container orchestration platform, the method includes: Receiving a service request sent by a service requester, wherein the service request is used to request access to an upper layer service; Determine the node where the service requester is located based on the pre-acquired cluster resource mapping table and the service request; Determine, based on the cluster resource mapping table, a first service provider corresponding to the upper-layer service, where the first service provider and the service requester run on the same node; The service requester is instructed to access the first service provider.

2. The method according to claim 1, characterized in that The method further comprises: Acquire the cluster resource mapping table, where the cluster resource mapping table includes a first mapping table, a second mapping table, and a third mapping table; Among them, the first mapping table indicates the correspondence between Pod information and Pod address, and the Pod information includes the node name; the second mapping table indicates the correspondence between service information and service name of the upper-layer service; the third mapping table indicates the relationship between the service name of the upper-layer service and the Pod address; the Pod is the resource unit of the service requester and service provider.

3. The method according to claim 2, characterized in that The determining, based on the pre-acquired cluster resource mapping table and the service request, the node where the service requester is located, comprises: Based on the Pod address corresponding to the service requester carried in the service request, the first mapping table is queried to determine the node name of the node where the service requester is located.

4. The method according to claim 2, characterized in that: The determining, based on the cluster resource mapping table, a first service provider corresponding to the upper layer service includes: Based on the service name of the upper-layer service carried in the service request, query the third mapping table to obtain the Pod address of each service provider corresponding to the upper-layer service; Based on the Pod addresses of the service providers corresponding to the upper-layer service, query the first mapping table to obtain the Pod addresses of the service providers running on the same node as the service requester, and generate a first sub-list; A first Pod address is selected from the first sub-list, and a service provider corresponding to the first Pod address is determined to be the first service provider, and the first Pod address is any Pod address in the first sub-list.

5. The method according to claim 4, characterized in that The instructing the service requester to access the first service provider includes: Instruct the service requester to access the first service provider based on the first Pod address.

6. The method according to claim 4, characterized in that Before determining the node where the service requester is located based on the pre-acquired cluster resource mapping table and the service request, the method further includes: Based on the service name of the upper layer service carried in the service request, query the second mapping table; Based on the corresponding service information queried, if it is determined that the upper-layer service exists in the K8s cluster, the node where the service requester is located is obtained; If it is determined that the upper-layer service does not exist in the K8s cluster, an indication indicating that the service name cannot be resolved is returned to the service requester.

7. The method according to claim 4, characterized in that The method further comprises: Based on the Pod addresses of the service providers corresponding to the upper-layer service, query the first mapping table to obtain the Pod addresses of the service providers that are not running on the same node as the service requester, and generate a second sub-list; If it is determined that there is no available first service provider in the K8s cluster, determining a second service provider corresponding to the upper-layer service based on the second sublist; The service requester is instructed to access the second service provider.

8. The method according to claim 7, characterized in that The determining, based on the second sub-list, a second service provider corresponding to the upper layer service includes: A second Pod address is selected from the second sub-list, and a service provider corresponding to the second Pod address is determined to be the second service provider, and the second Pod address is any Pod address in the second sub-list.

9. The method according to claim 1, characterized in that: The method further comprises: Create one or more headless services in the K8s cluster; The headless service is an upper layer service to which a corresponding service address is not allocated; and the service request is specifically used to request access to the headless service.

10. A resource scheduling device, characterized in that: Applied to K8s cluster, the device includes: A receiving module, used to receive a service request sent by a service requester, wherein the service request is used to request access to an upper layer service; A first determination module, configured to determine the node where the service requester is located based on a pre-acquired cluster resource mapping table and the service request; A second determination module is used to determine a first service provider corresponding to the upper layer service based on the cluster resource mapping table, where the first service provider and the service requester run on the same node; The instruction module is used to instruct the service requester to access the first service provider.

11. A resource scheduling device, characterized in that: include: A processor and a memory for storing a computer program that can be run on the processor, wherein the processor, when running the computer program, executes the steps of the method according to any one of claims 1 to 9.

12. A storage medium, characterized in that: The storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 9 are implemented.

13. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 9 are implemented.

Images