Resource allocation method and related equipment based on container cluster management system

Abstract

The present application provides a resource allocation method and related equipment based on a container cluster management system. The method includes: receiving a data request sent by a terminal device through the request receiving interface of the front-end container cluster management system; using the front-end container cluster management system to add the user's unique identifier to the interface identifier to complete the protocol conversion, obtain the request after the protocol conversion, and send the request after the protocol conversion to the back-end container cluster management system; using the back-end container cluster management system to determine the resource range according to the user's unique identifier in the request after the protocol conversion, determine the data content corresponding to the request after the protocol conversion in the resource range, associate the data content with the request after the protocol conversion to form a request result, and send the request result to the terminal device through the front-end container cluster management system. This resource allocation method is simple and convenient, and can save costs while improving the efficiency of resource allocation.

Description

Technical Field

[0001] The present application relates to the technical field of data resource allocation, and in particular to a resource allocation method and related equipment based on a container cluster management system. Background Art

[0002] In the existing technology, multi-tenancy is a common software architectural design. The core idea is to achieve resource sharing in a multi-user environment and ensure isolation and security between tenants.

[0003] Kubernetes (Container Cluster Management System) is typically used to allocate computing, network, and storage resources. Traditional Kubernetes resource allocation ensures that resources between tenants do not conflict or impact each other, using each independent Kubernetes for multi-tenant resource allocation.

[0004] However, traditional resource allocation solutions require building a Kubernetes for each tenant, which is costly and inefficient. Summary of the Invention

[0005] In view of this, the purpose of this application is to propose a resource allocation method based on a container cluster management system and related devices to solve or partially solve the above technical problems.

[0006] Based on the above purpose, the first aspect of the present application provides a resource allocation method based on a container cluster management system, wherein the container cluster management system includes: a front-end container cluster management system and a back-end container cluster management system;

[0007] The method comprises:

[0008] Receiving a data request from a terminal device through a request receiving interface of the front-end container cluster management system, wherein the data request includes an interface identifier corresponding to the request receiving interface and a unique identifier of a user;

[0009] Using the front-end container cluster management system to add the user's unique identifier to the interface identifier to complete the protocol conversion, obtain the request after protocol conversion, and send the request after protocol conversion to the back-end container cluster management system;

[0010] The backend container cluster management system is used to determine the resource scope according to the unique identifier of the user in the request after the protocol conversion, determine the data content corresponding to the request after the protocol conversion in the resource scope, associate the data content with the request after the protocol conversion to form a request result, and send the request result to the terminal device through the front-end container cluster management system, wherein the backend container cluster management system stores the resource scope corresponding to the unique identifier of each user.

[0011] In some embodiments, the request receiving interface includes at least one of the following:

[0012] Namespace resource interface, used to receive data requests for built-in resources in the namespace;

[0013] Cluster-wide resource interface, used to receive data requests for non-namespaced built-in resources;

[0014] Custom resource interface, used to receive data requests for custom resources.

[0015] In some embodiments, the method of using the front-end container cluster management system to add the user's unique identifier to the interface identifier to complete the protocol conversion, obtain a request after protocol conversion, and send the request after protocol conversion to the back-end container cluster management system includes:

[0016] Determining, by using a front-end container cluster management system, that a request receiving interface corresponding to the data request is the namespace resource interface, and locating a namespace data segment corresponding to the namespace resource interface in the data request;

[0017] The front-end container cluster management system associates the user's unique identifier with the namespace data segment to obtain a request after protocol conversion, and sends the request after protocol conversion to the back-end container cluster management system.

[0018] In some embodiments, the front-end container cluster management system adds the user's unique identifier to the interface identifier of the request receiving interface corresponding to the data request to complete the protocol conversion, obtains the request after protocol conversion, and sends the request after protocol conversion to the back-end container cluster management system, including:

[0019] Determining, by using the front-end container cluster management system, that the request receiving interface corresponding to the data request is the cluster-wide resource interface, and locating the named data segment corresponding to the cluster-wide resource interface in the data request;

[0020] The front-end container cluster management system associates the user's unique identifier with the named data segment to obtain a request after protocol conversion, and sends the request after protocol conversion to the back-end container cluster management system.

[0021] In some embodiments, the front-end container cluster management system adds the user's unique identifier to the interface identifier of the request receiving interface corresponding to the data request to complete the protocol conversion, obtains the request after protocol conversion, and sends the request after protocol conversion to the back-end container cluster management system, including:

[0022] Determining, by using a front-end container cluster management system, that a request receiving interface corresponding to the data request is the custom resource interface, and locating a custom data segment and a grouped data segment corresponding to the custom resource interface in the data request;

[0023] The front-end container cluster management system associates the user's unique identifier with the custom data segment and the packet data segment to obtain a request after protocol conversion, and sends the request after protocol conversion to the back-end container cluster management system.

[0024] In some embodiments, locating the custom data segment and grouping data segment corresponding to the custom resource interface in the data request includes:

[0025] In response to determining that the type of the custom resource interface is a custom namespace resource interface, locating a namespace metadata segment and a grouping data segment corresponding to the custom namespace resource interface in the data request;

[0026] In response to determining that the type of the custom resource interface is a custom cluster-scope resource interface, a named metadata segment and a grouped data segment corresponding to the custom cluster-scope resource interface in the data request are located.

[0027] In some embodiments, sending the request result to the terminal device through the front-end container cluster management system includes:

[0028] The front-end container cluster management system is used to delete the unique identifier of the requesting user after the protocol conversion in the request result, and the request result after the identifier is deleted is sent to the terminal device.

[0029] In some embodiments, the data request includes at least one of the following:

[0030] Create type request, query type request, update type request, and delete type request.

[0031] In some embodiments, using the front-end container cluster management system to add the user's unique identifier to the interface identifier to complete the protocol conversion, obtain a request after protocol conversion, and send the request after protocol conversion to the back-end container cluster management system, including:

[0032] In response to determining, by the front-end container cluster management system, that the data request is a create type request or an update type request, wherein the create type request or the update type request includes: a uniform resource locator and data content, and the data content includes: creation data corresponding to the create type request or update data corresponding to the update type request;

[0033] The front-end container cluster management system adds the user's unique identifier to the interface identifiers of the request receiving interface corresponding to the uniform resource locator and the data content, obtains a uniform resource locator protocol conversion request and a data content protocol conversion request as protocol-converted requests, and sends the protocol-converted requests to the back-end container cluster management system;

[0034] The determining, within the resource range, data content corresponding to the request after the protocol conversion, includes:

[0035] The backend container cluster management system is used to create or update resources within the resource range according to the request converted by the protocol, and the data information after the resource creation or resource update is used as the data content.

[0036] In some embodiments, the front-end container cluster management system adds the user's unique identifier to the interface identifier of the request receiving interface corresponding to the data request to complete the protocol conversion, obtains the request after protocol conversion, and sends the request after protocol conversion to the back-end container cluster management system, including:

[0037] In response to determining, by the front-end container cluster management system, that the data request is a query type request, wherein the query type request includes a uniform resource locator;

[0038] The front-end container cluster management system adds the user's unique identifier to the interface identifier of the request receiving interface corresponding to the uniform resource locator to complete the protocol conversion, obtains the request after protocol conversion, and sends the request after protocol conversion to the back-end container cluster management system;

[0039] The determining of corresponding data content within the resource range includes:

[0040] The backend container cluster management system is used to query at least one resource data information in the resource range according to the request converted by the protocol, and the at least one resource data information obtained is used as the data content.

[0041] In some embodiments, the front-end container cluster management system adds the user's unique identifier to the interface identifier of the request receiving interface corresponding to the data request to complete the protocol conversion, obtains the request after protocol conversion, and sends the request after protocol conversion to the back-end container cluster management system, including:

[0042] In response to determining, by the front-end container cluster management system, that the data request is a delete type request, wherein the delete type request includes a uniform resource locator;

[0043] The front-end container cluster management system adds the user's unique identifier to the interface identifier of the request receiving interface corresponding to the uniform resource locator to complete the protocol conversion, obtains the request after protocol conversion, and sends the request after protocol conversion to the back-end container cluster management system;

[0044] The determining of corresponding data content within the resource range includes:

[0045] The backend container cluster management system is used to determine the corresponding deleted resource data in the resource range according to the request after the protocol conversion and delete it, generate deleted data information, and use the deleted data information as the data content.

[0046] Based on the same inventive concept, the second aspect of this application proposes a resource allocation device based on a container cluster management system, wherein the container cluster management system includes: a front-end container cluster management system and a back-end container cluster management system, and the device includes:

[0047] A request receiving module is configured to receive a data request sent by a terminal device through a request receiving interface of the front-end container cluster management system, wherein the data request includes an interface identifier corresponding to the request receiving interface and a unique identifier of a user;

[0048] A protocol conversion module is configured to use the front-end container cluster management system to add the user's unique identifier to the interface identifier to complete the protocol conversion, obtain the request after protocol conversion, and send the request after protocol conversion to the back-end container cluster management system;

[0049] The request processing module is configured to use the backend container cluster management system to determine the resource range according to the unique identifier of the user in the request after the protocol conversion, determine the data content corresponding to the request after the protocol conversion in the resource range, associate the data content with the request after the protocol conversion to form a request result, and send the request result to the terminal device through the frontend container cluster management system, wherein the backend container cluster management system stores the resource range corresponding to the unique identifier of each user.

[0050] Based on the same inventive concept, the third aspect of this application proposes an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method described in the first aspect when executing the program.

[0051] Based on the same inventive concept, the fourth aspect of this application proposes a non-transitory computer-readable storage medium, which stores computer instructions, and the computer instructions are used to enable a computer to execute the method described in the first aspect.

[0052] From the above, it can be seen that the resource allocation method and related equipment based on the container cluster management system provided by this application can add the user's unique identifier to the interface identifier of the corresponding request receiving interface in the data request through the front-end container cluster management system, and then complete the protocol conversion. This protocol conversion method can ensure the security of the tenant resources of each terminal device while being compatible with the native API of the container cluster management system; then the front-end container cluster management system sends the request after protocol conversion to the back-end container cluster management system, and uses the back-end container cluster management system to determine the corresponding resource range based on the user's unique identifier, and then determine the data content corresponding to the request from the resource range, and feed it back to the terminal device. This resource allocation method is simple and convenient, and can save costs while improving the efficiency of resource allocation. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] In order to more clearly illustrate the technical solutions in this application or related technologies, the following briefly introduces the drawings required for use in the embodiments or related technical descriptions. Obviously, the drawings described below are merely embodiments of this application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0054] Figure 1 A schematic diagram of an application scenario of an embodiment of the present application;

[0055] Figure 2A This is a schematic diagram of the structure of the container cluster management system according to an embodiment of the present application;

[0056] Figure 2B This is a flowchart of a resource allocation method based on a container cluster management system according to an embodiment of the present application;

[0057] Figure 2C This is a protocol conversion diagram using the Pod namespace resource interface as an example in an embodiment of the present application;

[0058] Figure 2D This is a protocol conversion diagram using a cluster-wide resource interface such as Kubernetes PV as an example in an embodiment of the present application;

[0059] Figure 2E This is a protocol conversion diagram of an embodiment of the present application, taking the custom resource interface as CRD as an example;

[0060] Figure 3 This is a structural block diagram of a resource allocation device based on a container cluster management system according to an embodiment of the present application;

[0061] Figure 4 This is a schematic structural diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0062] The principles and spirit of the present application will be described below with reference to several exemplary embodiments. It should be understood that these embodiments are provided solely to enable those skilled in the art to better understand and implement the present application, and are not intended to limit the scope of the present application in any way. Rather, these embodiments are provided to make the present application more thorough and complete, and to fully convey the scope of the present application to those skilled in the art.

[0063] It should be understood herein that any number of elements in the drawings is for illustration only and not for limitation, and any naming is only for distinction and does not have any limiting meaning.

[0064] Based on the description of the above background technology, the following situations also exist in the related art:

[0065] Cloud computing (English: cloud computing) is an internet-based computing method in which shared hardware and software resources and information can be provided on demand to various computer terminals and other devices, using the computer infrastructure provided by the service provider for computing and resource utilization. Cloud computing achieves economies of scale through resource sharing and possesses excellent elasticity. More and more companies, large and small, are building their IT infrastructure on this basis. The Kubernetes container cluster management system (abbreviated as K8S) is an open source project for automatically deploying, scaling, and managing "containerized applications." Among the many products and services provided by cloud computing, Kubernetes, as an indispensable core technology, plays the core role of the "Platform as a Service" and is the foundation of many products and services.

[0066] Multi-tenancy is a common software architectural design concept. Its core concept is to enable resource sharing in a multi-user environment while ensuring isolation and security between tenants. Kubernetes multi-tenancy refers to providing Kubernetes services to multiple tenants within one or more Kubernetes clusters. This approach ensures security and isolation while implementing service architecture and resource sharing. It also offers extremely low resource and maintenance costs, efficient tenant lifecycle management, and other advantages. When building multi-tenancy capabilities, adhere to the following principles while ensuring functionality:

[0067] Low cost: Provides lightweight and low-cost tenant management capabilities.

[0068] Compatibility: Maintain API compatibility.

[0069] Non-intrusive: Avoid intrusion into Kubernetes and keep the solution simple.

[0070] Security: Ensure isolation and security between tenants.

[0071] With the development and promotion of cloud computing and Kubernetes, the demand for multiple tenants to share Kubernetes clusters has emerged, and various solutions have emerged, which can be divided into the following three categories.

[0072] Namespace as a Service (NaaS)

[0073] Multiple tenants share a Kubernetes cluster, each confined to a specific Kubernetes namespace. Leveraging native isolation, tenant workloads are isolated while resources are shared. Under these conditions, tenants are generally limited to using resources within their own namespace and typically lack global access, limiting functionality. The advantage is that tenants can share the same Kubernetes and computing resource pool, resulting in low resource and O&M costs and efficient management.

[0074] Cluster as a Service (CaaS)

[0075] Each tenant has its own independent Kubernetes cluster and computing resources, meaning that a Kubernetes cluster is used by only one tenant. This ensures complete isolation between tenants, preventing them from interfering with each other and ensuring absolute security and isolation. However, the downside is the high management and resource costs for each tenant.

[0076] Control planes as a Service (CPaaS)

[0077] Each tenant has its own independent Kubernetes (also known as a virtual cluster), which achieves multi-tenancy through a shared computing resource pool. A typical example is the Virtual Cluster project, which deploys virtual clusters in a containerized manner on a Kubernetes cluster called a supercluster. Each virtual cluster shares the supercluster's computing resources, thus achieving multi-tenancy.

[0078] Summarize:

[0079] After analysis, it was found that the above multi-tenant solutions each have their own focus, which is a trade-off between functionality, cost, efficiency, and security, as shown in Table 1.

[0080] Table 1

[0081]

[0082] Based on the above description, the principles and spirit of the present application are explained in detail below with reference to several representative implementations of the present application.

[0083] This application provides a resource allocation method and related equipment based on a container cluster management system. The front-end container cluster management system adds the user's unique identifier to the interface identifier of the corresponding request receiving interface in the data request, thereby completing the protocol conversion. This protocol conversion method ensures the security of the tenant resources of each terminal device while being compatible with the native API of the container cluster management system. The front-end container cluster management system then sends the request after protocol conversion to the back-end container cluster management system, which uses the back-end container cluster management system to determine the corresponding resource range based on the user's unique identifier, and then determines the data content corresponding to the request from this resource range, and feeds it back to the terminal device. This resource allocation method is simple and convenient, and can save costs while improving the efficiency of resource allocation.

[0084] refer to Figure 1 , which is a schematic diagram of an application scenario of a resource allocation method based on a container cluster management system provided in an embodiment of the present application. The application scenario includes a terminal device 101, a server 102, and a data storage system 103. Among them, the terminal device 101, the server 102 and the data storage system 103 can be connected through a wired or wireless communication network. The terminal device 101 includes but is not limited to a desktop computer, a mobile phone, a mobile computer, a tablet computer, a media player, a smart wearable device, a personal digital assistant (PDA) or other electronic devices capable of realizing the above functions. The server 102 and the data storage system 103 can both be independent physical servers, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0085] The user of terminal device 101 is a tenant. If there are multiple tenants, there will be multiple corresponding terminal devices 101. A container cluster management system is deployed on server 102. The tenant sends a data request through terminal device 101, which is received by the container cluster management system. The user's unique identifier is added to the interface identifier of the request receiving interface in the data request, and then the protocol conversion is completed. The corresponding resource range is determined based on the user's unique identifier, and the data content corresponding to the request is determined from the resource range and fed back to the terminal device 101. The data storage system 103 provides data storage support for the operation of server 102, for example, for storing program code that can implement the above-mentioned resource allocation process.

[0086] The following combination Figure 1The resource allocation method based on the container cluster management system according to the exemplary embodiment of the present application is described in the application scenario. It should be noted that the above application scenario is only shown to facilitate understanding of the spirit and principles of the present application, and the implementation of the present application is not limited in this respect. On the contrary, the implementation of the present application can be applied to any applicable scenario.

[0087] An embodiment of the present application provides a resource allocation method based on a container cluster management system, wherein the container cluster management system used in the method includes: a front-end container cluster management system and a back-end container cluster management system.

[0088] Among them, such as Figure 2A As shown, the front-end container cluster management system includes a stateless service and a key-value database, which has excellent horizontal scalability. The stateless service provides tenant management capabilities and a unified access point, forwarding requests from tenants' terminal devices to the back-end container cluster management system after protocol conversion. It can provide security features such as tenant isolation and rate limiting. The stateless service can be deployed in multiple copies and is highly reliable and horizontally scalable. The key-value database is used to store tenant information, including basic information, resource quotas, security configurations, etc. It is globally unique in deployment and has high reliability and scalability.

[0089] The backend container cluster management system can interact with the computing / storage / network resource pool according to the request, complete the processing of resource data, and then feed back the processing results to the tenant's terminal device through the front-end container cluster management system.

[0090] like Figure 2B As shown, the method includes:

[0091] Step 200: Perform security processing on the container cluster management system. The security processing includes: security authentication, traffic management, and quota management.

[0092] Safety certification:

[0093] Supports multiple security authentication methods, including Kubernetes certificates (X509) and Service Account (SA) certificates. Both types of credentials utilize PKI (Public Key Infrastructure) authentication. Simply sharing the same CA (digital certificate) with the Kubernetes Master (the control module of the container cluster management system) allows authentication and tenant information extraction.

[0094] For X509 certificates issued by administrators via terminal devices, the tenant name is hidden and added to the certificate whenever a tenant is created. This allows the system to verify the validity of the certificate included in the request, parse the tenant name field in the certificate, and determine the tenant's authenticity. Once verification is successful, the system then performs subsequent protocol conversion.

[0095] For the Service Account (SA) certificate issued by the tenant through the terminal device, since the certificate contains the namespace field, the SA issued by the tenant also contains the tenant information. First, the validity of the certificate carried in the authentication data request is verified, and then the tenant name field in the certificate is parsed to determine the authenticity of the tenant. After the authentication is passed, the subsequent protocol conversion processing is performed.

[0096] Traffic Management:

[0097] Traffic management methods can be used to implement flow control management for tenants (i.e., the client accounts corresponding to the terminal devices used by tenants). Traffic management methods include: tenant traffic isolation, which prevents tenants from interfering with each other, and malicious tenants (sending a large number of API requests in a short period of time) will not affect other tenants; tenant traffic weighting, which allows administrators to set different weights for different tenants through corresponding terminal devices, allowing high-priority tenants to send more concurrent requests.

[0098] When creating a tenant using a corresponding terminal device, the administrator sets the maximum number of concurrent requests from that tenant in the max-requests-inflight field. The corresponding module will count the current concurrent number of requests for the current tenant. Whenever a request is received from a tenant via a terminal device, the module will check the current concurrent number for that tenant. If the concurrent number exceeds the upper limit, the request will be rejected; otherwise, it will be allowed.

[0099] Quota Management:

[0100] Real-time statistics of tenant quotas, including common resources such as CPU, internal fields, and Pod number; and real-time control of tenant resources within preset limits through built-in admission logic.

[0101] The above-mentioned security authentication and traffic management need to be completed before implementing the subsequent steps of the following embodiments. Quota management will always exist in all subsequent steps of the following embodiments, thereby ensuring that resources are always within a controllable range during resource allocation, thereby ensuring the safe operation of the overall resources.

[0102] Step 201: Receive a data request from a terminal device through a request receiving interface of the front-end container cluster management system, wherein the data request includes an interface identifier corresponding to the request receiving interface and a unique identifier of a user.

[0103] In practice, multiple tenants can send data requests to the front-end container cluster management system through their respective terminal devices. This can result in the front-end container cluster management system receiving multiple data requests, but the required computing, storage, and network resources for these requests may be mixed, requiring subsequent steps to isolate and allocate them.

[0104] In some embodiments, the data request includes at least one of the following: a create type request, a query type request, an update type request, and a delete type request.

[0105] Create a tenant based on the creation type request: The administrator creates the tenant and sets the tenant's name, security configuration, and other configurations. After the administrator completes the tenant creation, this solution generates a certificate for the tenant.

[0106] Request to update tenants based on the update type: Administrators update tenants, modify security configurations, other configurations, etc.

[0107] Deleting a tenant based on a deletion type request: The administrator deletes a tenant, including the tenant's basic information and the resources owned by the tenant in the backend Kubernetes cluster.

[0108] Query tenants based on query type: Administrators query basic tenant information, including the tenant's name, security configuration, tenant certificate, and other configurations. Administrators issue tenant certificates to tenants, who use them to add, delete, modify, and query resources in Kubernetes.

[0109] In some embodiments, the query type request includes at least one of the following:

[0110] Query / monitor a selected resource, list / monitor all resources of a selected namespace resource interface, and list / monitor all resources of a selected tenant.

[0111] In some embodiments, the delete-type request includes deleting one selected resource or deleting multiple selected resources.

[0112] After receiving the data request, before performing the protocol conversion, the validity of the tenant credentials corresponding to the terminal device will be authenticated first, and then the tenant identity information will be parsed from the certificate corresponding to the tenant credentials. If the conditions preset in the previous step 200 are met, the subsequent protocol conversion process will begin.

[0113] Step 202: Use the front-end container cluster management system to add the user's unique identifier to the interface identifier to complete protocol conversion, obtain a request after protocol conversion, and send the request after protocol conversion to the back-end container cluster management system.

[0114] In specific implementations, data requests can directly carry the unique identifier of the user (tenant) of the terminal device (e.g., the tenant name). The data request also includes the interface identifier of the corresponding resource, which is the corresponding character segment of the corresponding resource. A resource type may have one or more character segments. Adding the user's unique identifier to this interface identifier prevents confusion and conflicts between data requests from different tenants, thereby enabling faster and more accurate allocation of resources for processing data requests.

[0115] In some embodiments, the request receiving interface includes at least one of the following:

[0116] Namespace resource interface, used to receive data requests for built-in resources in the namespace;

[0117] Cluster-wide resource interface, used to receive data requests for non-namespaced built-in resources;

[0118] Custom resource interface, used to receive data requests for custom resources.

[0119] There are other resource interfaces for receiving data requests from resources other than the three mentioned above.

[0120] In practice, the request receiving interfaces mentioned above refer to the native Kubernetes API interfaces, which can be divided into the following categories. Each type of interface receives and processes data requests sent by different tenants through terminal devices.

[0121] In some embodiments, for a namespace resource interface, step 202 includes:

[0122] Step 202A1: Use the front-end container cluster management system to determine that the request receiving interface corresponding to the data request is the namespace resource interface, and locate the namespace data segment corresponding to the namespace resource interface in the data request.

[0123] In step 202A2, the front-end container cluster management system associates the user's unique identifier with the namespace data segment to obtain a request after protocol conversion.

[0124] In practice, data requests for namespace resources are received through the namespace resource interface. Namespace scope resources represent built-in resources within a namespace. Namespace scope resources provide a scope for resource names. Duplicate names are not allowed within the same namespace resource, but are permitted within different namespace resources. Each resource within a namespace resource includes the name of its namespace. For such resources, the name and namespace are reflected in the following key aspects of the data request HTTP URL (Uniform Resource Locator) and HTTP Body (data content), respectively:

[0125] HTTP URL: The URL format is / prefix / namespace / {namespace} / resource / {name}, where the two "{}" represent the key values ​​corresponding to namespace and name respectively.

[0126] HTTP Body: Contains two key values: namespace and name.

[0127] The namespace data segment corresponding to the namespace resource interface is namespace.

[0128] There are more than 40 namespace resource interfaces in Kubernetes, such as Figure 2C The diagram below illustrates protocol conversion for a namespace resource interface like Pod. The protocol conversion process for other namespace resource interfaces is similar to that for Pod. As shown in the diagram, tenants foofoo and barbar perform protocol conversion on their corresponding Pod-type requests (which include name: a and namespace: a). The tenant names "foofoo" and "barbar" are added as prefixes to the corresponding namespace fields to complete the protocol conversion. The resulting requests for the two tenants are Pod{name: a; namespace: foofoo-a} and Pod{name: a; namespace: barbar-a}.

[0129] Since data requests are divided into the above four types of requests, the protocol conversion process of the namespace resource interface corresponding to each request is as follows:

[0130] Create Request (POST): After receiving a data request including an HTTP URL (Uniform Resource Locator) and HTTP Body (data content), the client adds the user's unique identifier (for example, the tenant name) to the namespace field of the HTTP URL and HTTP Body. The protocol-converted request is then forwarded to the Kubernetes backend, which completes resource creation. The HTTP Body includes the creation data corresponding to the create request.

[0131] Query type request (GET)

[0132] Query / monitor a resource: After receiving a data request, add the user's unique identifier to the namespace field of the HTTP URL, and then forward the request after protocol conversion to the backend Kubernetes, and complete the resource query through the backend Kubernetes.

[0133] List / listen all resources under a certain namespace resource: After receiving a data request, add the user's unique identifier to the namespace field of the HTTP URL, and then forward the request after protocol conversion to the backend Kubernetes, and complete the resource query through the backend Kubernetes.

[0134] List / listen all tenant resources: After receiving a data request, add the user's unique identifier to the namespace field of the HTTP URL, and then forward the request after protocol conversion to the backend Kubernetes. Kubernetes queries all Kubernetes resources of this type of namespace resources and matches all such resources of this tenant based on the user's unique identifier of the namespace in the HTTP URL to complete the resource query.

[0135] Update Request (PUT): After receiving a data request, the user's unique identifier is added to the namespace field of the HTTP URL and HTTP Body. The request, after protocol conversion, is then forwarded to the backend Kubernetes, which completes the resource update. The HTTP Body includes the updated data corresponding to the update request.

[0136] Delete type request (DELETE)

[0137] Delete a resource: After receiving a data request, add the user's unique identifier to the namespace field of the HTTP URL, and then forward the request after protocol conversion to Kubernetes to complete resource deletion.

[0138] Delete certain resources: After receiving a data request, add the user's unique identifier to the namespace field of the HTTP URL, then forward the request after protocol conversion to Kubernetes. Query the backend Kubernetes cluster for matching resources based on the deletion matching conditions. For resources belonging to this tenant, send deletion requests to the backend Kubernetes one by one.

[0139] In some embodiments, step 202 corresponding to the cluster-wide resource interface includes:

[0140] Step 202B1: using the front-end container cluster management system to determine that the request receiving interface corresponding to the data request is the cluster-wide resource interface, and locating the named data segment corresponding to the cluster-wide resource interface in the data request.

[0141] Step 202B2: The front-end container cluster management system associates the user's unique identifier with the named data segment to obtain a request after protocol conversion, and sends the request after protocol conversion to the back-end container cluster management system.

[0142] In specific implementations, data requests corresponding to cluster-scoped resources are received through the cluster-scoped resource interface. Cluster-scoped resources are built-in Kubernetes resources for non-namespaced resources. Cluster-scoped resource names must be globally unique. The corresponding data request includes an HTTP URL and HTTP body:

[0143] HTTP URL: The URL format is / prefix / resource / {name}, where "{}" represents the value corresponding to name.

[0144] HTTP Body: Contains the name key value and the corresponding request data.

[0145] The named data segment corresponding to the cluster-wide resource interface is name.

[0146] Kubernetes has more than 20 cluster-scoped resource interfaces. In data requests, the name field prefix corresponding to the cluster-scoped resource interface is associated with the user's unique identifier (for example, the tenant name) to implement multi-tenancy capabilities for such resources.

[0147] like Figure 2DThe following diagram illustrates an overview of protocol conversion using the Kubernetes cluster-scoped resource interface, PV. Tenants foofoo and barbar perform protocol conversion on requests for PVs (name:a) by prefixing the tenant names "foofoo" and "barbar" with the corresponding name fields. The resulting requests are PV{name:foofoo-a} and PV{name:barbar-a}.

[0148] Since data requests are divided into the above four types of requests, the protocol conversion process of the cluster-wide resource interface corresponding to each request is as follows:

[0149] Create Request (POST): After receiving a data request (including the HTTP URL and HTTP body), the user's unique identifier (for example, the tenant name) is added to the name field of the HTTP URL and HTTP body. The request, after protocol conversion, is then forwarded to the Kubernetes backend, which completes resource creation. The HTTP body includes the creation data corresponding to the create request.

[0150] Query type request (GET)

[0151] Query / monitor a resource: After receiving a data request, add the user's unique identifier to the name field of the HTTP URL, and then forward the request after protocol conversion to the backend Kubernetes to complete the resource query.

[0152] List / listen all tenant resources: After receiving a data request, add the user's unique identifier to the name field of the HTTP URL, and then forward the request after protocol conversion to the backend Kubernetes. Kubernetes queries all Kubernetes resources of this type of namespace resources and matches all such resources of this tenant based on the user's unique identifier in the name field of the HTTP URL to complete the resource query.

[0153] Update Request (PUT): After receiving a data request, the user's unique identifier is added to the HTTP URL and the name field of the HTTP body. The request, after protocol conversion, is then forwarded to the Kubernetes backend, which completes the resource update. The HTTP body includes the updated data corresponding to the update request.

[0154] Delete type request (DELETE)

[0155] Delete a resource: After receiving a data request, add the user's unique identifier to the name field of the HTTP URL, and then forward the request after protocol conversion to Kubernetes to complete resource deletion.

[0156] Delete certain resources: After receiving a data request, add the user's unique identifier to the name field of the HTTP URL, and then forward the request after protocol conversion to Kubernetes. Query the backend Kubernetes cluster for matching resources based on the deletion matching conditions. For resources belonging to this tenant, send deletion requests to the backend Kubernetes one by one.

[0157] In some embodiments, for a custom resource interface, step 202 includes:

[0158] Step 202C1: using the front-end container cluster management system to determine that the request receiving interface corresponding to the data request is the custom resource interface, and locating the custom data segment and the grouped data segment corresponding to the custom resource interface in the data request.

[0159] The data request corresponding to the custom resource is received through the custom resource interface. The type of the custom resource interface can be a type specified by the user from a custom namespace resource and a custom cluster-scope resource.

[0160] In some embodiments, in response to determining that the type of the custom resource interface is a custom namespace resource interface, the namespace metadata segment and grouping data segment corresponding to the custom namespace resource interface in the data request are located; in response to determining that the type of the custom resource interface is a custom cluster-scope resource interface, the naming metadata segment and grouping data segment corresponding to the custom cluster-scope resource interface in the data request are located.

[0161] In step 202C2, the front-end container cluster management system associates the user's unique identifier with the custom data segment and the packet data segment to obtain a request after protocol conversion, and sends the request after protocol conversion to the back-end container cluster management system.

[0162] In practice, the custom resource interface (Custom Resource) is a non-built-in resource, defined by the user, that extends Kubernetes functionality to support specific business scenarios. Custom resources can be scoped to either namespaces or clusters.

[0163] Set custom data segments and group data segments (group) in the corresponding data request HTTP URL and HTTP Body. If the custom data segment is a namespace resource, it is called namespace (i.e., the namespace metadata segment); if it is a cluster-scoped resource, it is called name (i.e., the naming metadata segment).

[0164] The name or namespace of a custom resource interface consists of group+plural. If you choose to associate the user's unique identifier with the group prefix, both the custom data segment (name or namespace) and the group data segment (group) are prefixed with the user's unique identifier.

[0165] like Figure 2E The following diagram illustrates protocol conversion using a custom resource definition (CRD) interface as an example. Tenants foofoo and barbar perform protocol conversion on their corresponding CRD-type requests (name: a.demo.com; group: demo.com; plural: a). The tenant names "foofoo" and "barbar" are added as prefixes to "demo.com" to complete the protocol conversion. The converted requests for the two tenants become the CRD {name: a.foofoo-demo.com; group: foofoo-demo.com; plural: a} and CRD {name: a.barbar-demo.com; group: barbar-demo.com; plural: a}.

[0166] The protocol conversion process for custom resource interfaces is divided into two cases:

[0167] The first type: If the custom resource interface type is a custom namespace resource interface, the corresponding protocol conversion process for the four data requests mentioned above is as follows:

[0168] Create Request (POST): After receiving a data request (including the HTTP URL and HTTP body), the user's unique identifier (for example, the tenant name) is added to the namespace and group fields of the HTTP URL and HTTP body. The protocol-converted request is then forwarded to the Kubernetes backend, which completes resource creation. The HTTP body includes the creation data corresponding to the create request.

[0169] Query type request (GET)

[0170] Query / monitor a resource: After receiving a data request, add the user's unique identifier to the namespace and group fields of the HTTP URL, and then forward the request after protocol conversion to the backend Kubernetes to complete the resource query.

[0171] List / listen all tenant resources: After receiving a data request, add the user's unique identifier to the namespace and group fields of the HTTP URL, and then forward the request after protocol conversion to the backend Kubernetes. Kubernetes queries all Kubernetes resources of this type of namespace resources and matches all such resources of this tenant based on the user's unique identifier in the namespace and group fields in the HTTP URL to complete the resource query.

[0172] Update Request (PUT): After receiving a data request, the user's unique identifier is added to the namespace and group fields of the HTTP URL and HTTP Body. The request, after protocol conversion, is then forwarded to the Kubernetes backend, which completes the resource update. The HTTP Body includes the updated data corresponding to the update request.

[0173] Delete type request (DELETE)

[0174] Delete a resource: After receiving a data request, add the user's unique identifier to the namespace and group fields of the HTTP URL, and then forward the request after protocol conversion to Kubernetes to complete resource deletion.

[0175] Delete certain resources: After receiving a data request, add the user's unique identifier to the namespace and group fields of the HTTP URL, then forward the request after protocol conversion to Kubernetes. Query the backend Kubernetes cluster for matching resources based on the deletion matching conditions. For resources belonging to this tenant, send deletion requests to the backend Kubernetes one by one.

[0176] Second: If the custom resource interface type is a custom cluster-scoped resource interface, the corresponding protocol conversion process for the four data requests above is as follows:

[0177] Create Request (POST): After receiving a data request (including the HTTP URL and HTTP body), the client adds the user's unique identifier (for example, the tenant name) to the name and group fields of the HTTP URL and HTTP body. The protocol-converted request is then forwarded to the Kubernetes backend, which completes resource creation. The HTTP body includes the creation data corresponding to the create request.

[0178] Query type request (GET)

[0179] Query / monitor a resource: After receiving a data request, add the user's unique identifier to the name and group fields of the HTTP URL, and then forward the request after protocol conversion to the backend Kubernetes to complete the resource query.

[0180] List / listen all tenant resources: After receiving a data request, add the user's unique identifier to the name and group fields of the HTTP URL, and then forward the request after protocol conversion to the backend Kubernetes. Kubernetes queries all Kubernetes resources of this type of namespace resources and matches all such resources of this tenant based on the user's unique identifier in the name and group fields of the HTTP URL to complete the resource query.

[0181] Update Request (PUT): After receiving a data request, the user's unique identifier is added to the name and group fields of the HTTP URL and HTTP Body. The request, after protocol conversion, is then forwarded to the Kubernetes backend, which completes the resource update. The HTTP Body includes the updated data corresponding to the update request.

[0182] Delete type request (DELETE)

[0183] Delete a resource: After receiving a data request, add the user's unique identifier to the name and group fields of the HTTP URL, and then forward the request after protocol conversion to Kubernetes to complete resource deletion.

[0184] Delete certain resources: After receiving a data request, add the user's unique identifier to the name and group fields of the HTTP URL, then forward the request after protocol conversion to Kubernetes. Query the backend Kubernetes cluster for matching resources based on the deletion matching conditions. For resources belonging to this tenant, send deletion requests to the backend Kubernetes one by one.

[0185] For other resources

[0186] In addition to the aforementioned core resources, Kubernetes also has some other resource APIs, mainly including cluster status, logs, documents, etc. These resources have the same characteristics and do not require tenant attributes. Therefore, protocol conversion only performs transparent proxy processing for such resources. That is, data requests from the API interfaces corresponding to other resources are directly transmitted without protocol conversion.

[0187] Step 203: Utilize the backend container cluster management system to determine the resource scope according to the unique identifier of the user in the request after the protocol conversion, determine the data content corresponding to the request after the protocol conversion in the resource scope, associate the data content with the request after the protocol conversion to form a request result, and send the request result to the terminal device through the frontend container cluster management system, wherein the backend container cluster management system stores the resource scope corresponding to the unique identifier of each user.

[0188] The backend container cluster management system stores a resource range corresponding to each user's unique identifier, which provides corresponding data processing resources, traffic resources, storage resources, etc. for the corresponding user.

[0189] In some embodiments, sending the request result to the terminal device through the front-end container cluster management system in step 203 includes:

[0190] The front-end container cluster management system is used to delete the unique identifier of the requesting user after the protocol conversion in the request result, and the request result after the identifier is deleted is sent to the terminal device.

[0191] In specific implementation, after performing protocol conversion on the above four types of data requests, there are also four corresponding requests after protocol conversion.

[0192] (1) For a request after protocol conversion corresponding to a create type request, the backend container cluster management system can determine the resource scope based on the user's unique identifier in the request, and create resources within the resource scope based on the data in the request (such as the name to be created, the number of corresponding matching resources, and some configuration information, etc.). The created data is added to the request after protocol conversion (for example, HTTP Body) to form a request result, and the frontend container cluster management system deletes the corresponding user's unique identifier and returns it to the corresponding terminal device.

[0193] (2) For the request after protocol conversion corresponding to the query type request, the backend container cluster management system can determine the resource scope based on the unique identifier of the user in the request, search for the corresponding resource data in the resource scope according to the task that needs to be queried in the request, add the found resource data to the request after protocol conversion to form a request result, and delete the unique identifier of the corresponding user through the frontend container cluster management system and return it to the corresponding terminal device.

[0194] (3) For the protocol-converted request corresponding to the update type request, the backend container cluster management system can determine the resource scope based on the unique identifier of the user in the request, and perform resource updates within the resource scope based on the data corresponding to the updated resource in the request (for example, updating A to B), and add the updated result data to the protocol-converted request to form a request result. The frontend container cluster management system deletes the unique identifier of the corresponding user and returns it to the corresponding terminal device.

[0195] (4) For the protocol-converted request corresponding to the deletion type request, the backend container cluster management system can determine the resource scope based on the unique identifier of the user in the request, delete the resources that need to be deleted in the resource scope according to the data corresponding to the resource deletion in the request (for example, delete A), and add the result data after deletion to the protocol-converted request to form the request result. If the request is to delete multiple selected resources, there will be multiple deletion requests. Each deletion request carries the corresponding deletion result. After all deletions are completed, all deletion requests carrying deletion results will be aggregated and used as the request result. The unique identifier of the corresponding user will be deleted by the front-end container cluster management system and returned to the corresponding terminal device.

[0196] Based on the solutions of the embodiments described above, the analysis of various performance aspects corresponding to NaaS, CaaS, and CPaaS in related technologies is shown in Table 2 below:

[0197] Table 2

[0198]

[0199]

[0200] From Table 2 above, we can see that the effects that this solution can achieve are as follows:

[0201] 1. Versatility

[0202] The solution of the above embodiment is non-invasive to Kubernetes and can be widely used in various Kubernetes scenarios such as public cloud, private cloud and hybrid cloud in cloud computing.

[0203] 2. Low cost

[0204] It makes resource allocation for multiple tenants faster and achieves lightweight capabilities. It also has the ability to manage massive tenants and manage tenant lifecycles in seconds, thereby achieving extremely low operation and maintenance and resource costs.

[0205] 3. Security

[0206] Based on the control plane and data multi-tenancy, authentication, traffic management, and quota management capabilities are enhanced to ensure the security of the resource allocation environment.

[0207] It should be noted that the method of the embodiment of the present application can be performed by a single device, such as a computer or server. The method of this embodiment can also be applied in a distributed scenario and performed by multiple devices working together. In such a distributed scenario, one of the multiple devices may only perform one or more steps of the method of the embodiment of the present application, and the multiple devices will interact with each other to complete the method.

[0208] It should be noted that the above description is limited to some embodiments of the present application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in an order different from that described in the above embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order or sequential order shown to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0209] Based on the same inventive concept, corresponding to the resource allocation method based on the container cluster management system of any of the above embodiments, the present application also provides a resource allocation device based on the container cluster management system. The container cluster management system set on the resource allocation device includes: a front-end container cluster management system and a back-end container cluster management system.

[0210] refer to Figure 3 , the device comprises:

[0211] The request receiving module 31 is configured to receive a data request from a terminal device through the request receiving interface of the front-end container cluster management system, wherein the data request includes an interface identifier corresponding to the request receiving interface and a unique identifier of the user;

[0212] The protocol conversion module 32 is configured to use the front-end container cluster management system to add the user's unique identifier to the interface identifier to complete the protocol conversion, obtain the request after the protocol conversion, and send the request after the protocol conversion to the back-end container cluster management system;

[0213] The request processing module 33 is configured to use the backend container cluster management system to determine the resource range according to the unique identifier of the user in the request after the protocol conversion, determine the data content corresponding to the request after the protocol conversion in the resource range, associate the data content with the request after the protocol conversion to form a request result, and send the request result to the terminal device through the front-end container cluster management system, wherein the backend container cluster management system stores the resource range corresponding to the unique identifier of each user.

[0214] In some embodiments, the request receiving interface includes at least one of the following:

[0215] Namespace resource interface, used to receive data requests for built-in resources in the namespace;

[0216] Cluster-wide resource interface, used to receive data requests for non-namespaced built-in resources;

[0217] Custom resource interface, used to receive data requests for custom resources.

[0218] In some embodiments, the protocol conversion module 32 includes: a namespace resource interface protocol conversion unit configured to:

[0219] The front-end container cluster management system is used to determine that the request receiving interface corresponding to the data request is the namespace resource interface, and the namespace data segment corresponding to the namespace resource interface in the data request is located; the front-end container cluster management system associates the user's unique identifier with the namespace data segment to obtain the request after protocol conversion, and sends the request after protocol conversion to the back-end container cluster management system.

[0220] In some embodiments, the protocol conversion module 32 includes a cluster-wide resource interface protocol conversion unit configured to:

[0221] The front-end container cluster management system is used to determine that the request receiving interface corresponding to the data request is the cluster-wide resource interface, and the named data segment corresponding to the cluster-wide resource interface in the data request is located; the front-end container cluster management system associates the user's unique identifier with the named data segment to obtain the request after protocol conversion, and sends the request after protocol conversion to the back-end container cluster management system.

[0222] In some embodiments, the protocol conversion module 32 includes: a custom resource interface protocol conversion unit configured to:

[0223] The front-end container cluster management system is used to determine that the request receiving interface corresponding to the data request is the custom resource interface, and the custom data segment and the grouped data segment corresponding to the custom resource interface in the data request are located; the front-end container cluster management system associates the user's unique identifier with the custom data segment and the grouped data segment to obtain the request after protocol conversion, and sends the request after protocol conversion to the back-end container cluster management system.

[0224] In some embodiments, the custom resource interface protocol conversion unit is further configured to:

[0225] In response to determining that the type of the custom resource interface is a custom namespace resource interface, the namespace metadata segment and grouping data segment corresponding to the custom namespace resource interface in the data request are located; in response to determining that the type of the custom resource interface is a custom cluster-scope resource interface, the naming metadata segment and grouping data segment corresponding to the custom cluster-scope resource interface in the data request are located.

[0226] In some embodiments, the request processing module 33 includes a user unique identifier deletion unit configured to:

[0227] The front-end container cluster management system is used to delete the unique identifier of the requesting user after the protocol conversion in the request result, and the request result after the identifier is deleted is sent to the terminal device.

[0228] In some embodiments, the data request includes at least one of the following:

[0229] Create type request, query type request, update type request, and delete type request.

[0230] In some embodiments, the protocol conversion module 32 includes: a create type request or update type request protocol conversion unit, configured to:

[0231] In response to determining, by the front-end container cluster management system, that the data request is a create type request or an update type request, wherein the create type request or the update type request includes: a uniform resource locator and data content, and the data content includes: creation data corresponding to the create type request, or update data corresponding to the update type request; adding the user's unique identifier to the interface identifiers of the request receiving interfaces corresponding to the uniform resource locator and the data content by the front-end container cluster management system, obtaining a uniform resource locator protocol conversion request and a data content protocol conversion request as protocol-converted requests, and sending the protocol-converted requests to the back-end container cluster management system;

[0232] The request processing module 33 includes a data content determination unit configured to:

[0233] The backend container cluster management system is used to create or update resources within the resource range according to the request converted by the protocol, and the data information after the resource creation or resource update is used as the data content.

[0234] In some embodiments, the protocol conversion module 32 includes a query type request protocol conversion unit configured to:

[0235] In response to determining, by the front-end container cluster management system, that the data request is a query type request, wherein the query type request includes a uniform resource locator; completing protocol conversion by the front-end container cluster management system by adding the user's unique identifier to the interface identifier of the request receiving interface corresponding to the uniform resource locator, obtaining a request after protocol conversion, and sending the request after protocol conversion to the back-end container cluster management system;

[0236] The data content determination unit is further configured to:

[0237] The backend container cluster management system is used to query at least one resource data information in the resource range according to the request converted by the protocol, and the at least one resource data information obtained is used as the data content.

[0238] In some embodiments, the query type request includes at least one of the following:

[0239] Query / monitor a selected resource, list / monitor all resources of a selected namespace resource interface, and list / monitor all resources of a selected tenant.

[0240] In some embodiments, the protocol conversion module 32 includes a delete type request protocol conversion unit configured to:

[0241] In response to determining, by the front-end container cluster management system, that the data request is a delete-type request, wherein the delete-type request includes a uniform resource locator; completing protocol conversion by the front-end container cluster management system by adding the user's unique identifier to the interface identifier of the request receiving interface corresponding to the uniform resource locator, obtaining a request after protocol conversion, and sending the request after protocol conversion to the back-end container cluster management system;

[0242] The data content determination unit is further configured to:

[0243] The backend container cluster management system is used to determine the corresponding deleted resource data in the resource range according to the request after the protocol conversion and delete it, generate deleted data information, and use the deleted data information as the data content.

[0244] In some embodiments, the delete-type request includes deleting one selected resource or deleting multiple selected resources.

[0245] Based on the same inventive concept, corresponding to the method of any of the above embodiments, the present application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and runnable on the processor, wherein the processor implements the method described in any of the above embodiments when executing the program.

[0246] Figure 4 A more specific hardware structure diagram of an electronic device provided in this embodiment is shown. The device may include: a processor 410, a memory 420, an input / output interface 430, a communication interface 440, and a bus 450. The processor 410, the memory 420, the input / output interface 430, and the communication interface 440 are communicatively connected to each other within the device via the bus 450.

[0247] The processor 410 can be implemented using a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0248] The memory 420 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage devices, dynamic storage devices, etc. The memory 420 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 420 and is called and executed by the processor 410.

[0249] The input / output interface 430 is used to connect input / output modules to implement information input and output. The input / output modules can be configured as components within the device (not shown in the figure) or can be externally connected to the device to provide corresponding functions. Input devices may include a keyboard, mouse, touch screen, microphone, various sensors, etc., and output devices may include a display, speaker, vibrator, indicator light, etc.

[0250] The communication interface 440 is used to connect to a communication module (not shown) to enable communication between the device and other devices. The communication module can communicate via a wired method (such as USB, network cable, etc.) or a wireless method (such as mobile network, WiFi, Bluetooth, etc.).

[0251] The bus 450 comprises a pathway for transmitting information between the various components of the device, such as the processor 410 , the memory 420 , the input / output interface 430 , and the communication interface 440 .

[0252] It should be noted that although the above device only shows the processor 410, the memory 420, the input / output interface 430, the communication interface 440, and the bus 450, in a specific implementation, the device may also include other components necessary for normal operation. In addition, it will be understood by those skilled in the art that the above device may only include the components necessary to implement the embodiments of this specification, and does not necessarily include all the components shown in the figure.

[0253] The electronic device of the above embodiment is used to implement the corresponding resource allocation method based on the container cluster management system or the chapter error correction method in any of the above embodiments, and has the beneficial effects of the corresponding resource allocation method based on the container cluster management system or the chapter error correction method embodiment, which will not be repeated here.

[0254] Based on the same inventive concept, corresponding to any of the above-mentioned embodiments and methods, the present application also provides a non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores computer instructions, and the computer instructions are used to enable the computer to execute the method described in any of the above embodiments.

[0255] The computer-readable media of this embodiment include permanent and non-permanent, removable and non-removable media that can be used to store information by any method or technology. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (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 technology, read-only compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape 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.

[0256] The computer instructions stored in the storage medium of the above embodiment are used to enable the computer to execute the method described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0257] Those skilled in the art should understand that the discussion of any of the above embodiments is merely illustrative and is not intended to imply that the scope of the present application (including the claims) is limited to these examples. Within the scope of the present application, the technical features in the above embodiments or different embodiments may be combined, the steps may be implemented in any order, and there are many other variations of the different aspects of the embodiments of the present application as described above, which are not provided in detail for the sake of simplicity.

[0258] In addition, for simplicity of description and discussion, and in order not to make the embodiment of the application difficult to understand, the known power supply / ground connection with integrated circuit (IC) chip and other components may or may not be shown in the accompanying drawings provided. In addition, the device can be shown in the form of a block diagram to avoid making the embodiment of the application difficult to understand, and this also takes into account the following fact, that is, the details of the embodiment of these block diagram devices are highly dependent on the platform to be implemented in the embodiment of the application (that is, these details should be fully within the scope of understanding of those skilled in the art). When specific details (for example, circuit) are set forth to describe exemplary embodiments of the application, it will be apparent to those skilled in the art that the embodiment of the application can be implemented without these specific details or when these specific details are changed. Therefore, these descriptions should be considered to be illustrative rather than restrictive.

[0259] Although the present invention has been described in conjunction with specific embodiments thereof, many alternatives, modifications, and variations of these embodiments will be apparent to those skilled in the art based on the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may utilize the embodiments discussed.

[0260] The embodiments of the present application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the embodiments of the present application should be included in the scope of protection of this application.

Claims

1. A resource allocation method based on a container cluster management system, characterized in that: The container cluster management system includes: a front-end container cluster management system and a back-end container cluster management system; The method comprises: A data request sent by a terminal device is received through a request receiving interface of the front-end container cluster management system, wherein the data request includes an interface identifier corresponding to the request receiving interface and a unique identifier of a user, and the request receiving interface includes: a namespace resource interface, the namespace resource interface is used to receive a data request for a built-in resource of a namespace, and the namespace resource interface corresponds to the namespace data segment located in the data request; Using the front-end container cluster management system to add the user's unique identifier to the interface identifier to complete the protocol conversion, obtain the request after protocol conversion, and send the request after protocol conversion to the back-end container cluster management system; The backend container cluster management system is used to determine the resource scope according to the unique identifier of the user in the request after the protocol conversion, determine the data content corresponding to the request after the protocol conversion in the resource scope, associate the data content with the request after the protocol conversion to form a request result, and send the request result to the terminal device through the front-end container cluster management system, wherein the backend container cluster management system stores the resource scope corresponding to the unique identifier of each user.

2. The method according to claim 1, characterized in that The request receiving interface includes at least one of the following: Cluster-wide resource interface, used to receive data requests for non-namespaced built-in resources; Custom resource interface, used to receive data requests for custom resources.

3. The method according to claim 2, characterized in that The method of using the front-end container cluster management system to add the user's unique identifier to the interface identifier to complete the protocol conversion, obtain a request after protocol conversion, and send the request after protocol conversion to the back-end container cluster management system includes: The front-end container cluster management system associates the user's unique identifier with the namespace data segment to obtain a request after protocol conversion, and sends the request after protocol conversion to the back-end container cluster management system.

4. The method according to claim 2, characterized in that The method of using the front-end container cluster management system to add the unique identifier of the user to the interface identifier of the request receiving interface corresponding to the data request to complete the protocol conversion, obtain the request after the protocol conversion, and send the request after the protocol conversion to the back-end container cluster management system includes: Determining, by using the front-end container cluster management system, that the request receiving interface corresponding to the data request is the cluster-wide resource interface, and locating a named data segment corresponding to the cluster-wide resource interface in the data request; The front-end container cluster management system associates the user's unique identifier with the named data segment to obtain a request after protocol conversion, and sends the request after protocol conversion to the back-end container cluster management system.

5. The method according to claim 2, characterized in that The method of using the front-end container cluster management system to add the unique identifier of the user to the interface identifier of the request receiving interface corresponding to the data request to complete the protocol conversion, obtain the request after the protocol conversion, and send the request after the protocol conversion to the back-end container cluster management system includes: Determining, by using the front-end container cluster management system, that the request receiving interface corresponding to the data request is the custom resource interface, and locating the custom data segment and the grouped data segment corresponding to the custom resource interface in the data request; The front-end container cluster management system associates the user's unique identifier with the custom data segment and the packet data segment to obtain the protocol-converted request, and sends the protocol-converted request to the back-end container cluster management system.

6. The method according to claim 5, characterized in that The locating of the custom data segment and the grouping data segment corresponding to the custom resource interface in the data request includes: In response to determining that the type of the custom resource interface is a custom namespace resource interface, locating a namespace metadata segment and a grouping data segment corresponding to the custom namespace resource interface in the data request; In response to determining that the type of the custom resource interface is a custom cluster-scope resource interface, a named metadata segment and a grouped data segment corresponding to the custom cluster-scope resource interface in the data request are located.

7. The method according to any one of claims 1 to 6, characterized in that The sending the request result to the terminal device through the front-end container cluster management system includes: The front-end container cluster management system is used to delete the unique identifier of the requesting user after the protocol conversion in the request result, and the request result after the identifier is deleted is sent to the terminal device.

8. The method according to claim 7, characterized in that The method of using the front-end container cluster management system to add the unique identifier of the user to the interface identifier to complete the protocol conversion, obtain a request after protocol conversion, and send the request after protocol conversion to the back-end container cluster management system includes: In response to determining, by the front-end container cluster management system, that the data request is a create type request or an update type request, wherein the create type request or the update type request includes: a uniform resource locator and data content, and the data content includes: creation data corresponding to the create type request or update data corresponding to the update type request; The front-end container cluster management system adds the user's unique identifier to the uniform resource locator and the interface identifier of the request receiving interface corresponding to the data content, obtains the request after protocol conversion, and sends the request after protocol conversion to the back-end container cluster management system; The determining, within the resource range, data content corresponding to the request after the protocol conversion, includes: The backend container cluster management system is used to create or update resources within the resource range according to the request converted by the protocol, and the data information after the resource creation or resource update is used as the data content.

9. The method according to claim 7, characterized in that The method of using the front-end container cluster management system to add the unique identifier of the user to the interface identifier of the request receiving interface corresponding to the data request to complete the protocol conversion, obtain the request after the protocol conversion, and send the request after the protocol conversion to the back-end container cluster management system includes: In response to determining, by the front-end container cluster management system, that the data request is a query type request, wherein the query type request includes a uniform resource locator; The front-end container cluster management system adds the user's unique identifier to the interface identifier of the request receiving interface corresponding to the uniform resource locator, obtains the request after protocol conversion, and sends the request after protocol conversion to the back-end container cluster management system; The determining, within the resource range, data content corresponding to the request after the protocol conversion, includes: The backend container cluster management system is used to query at least one resource data information in the resource range according to the request converted by the protocol, and the at least one resource data information obtained is used as the data content.

10. The method according to claim 7, characterized in that The method of using the front-end container cluster management system to add the unique identifier of the user to the interface identifier of the request receiving interface corresponding to the data request to complete the protocol conversion, obtain the request after the protocol conversion, and send the request after the protocol conversion to the back-end container cluster management system includes: In response to determining, by the front-end container cluster management system, that the data request is a delete type request, wherein the delete type request includes a uniform resource locator; The front-end container cluster management system adds the user's unique identifier to the interface identifier of the request receiving interface corresponding to the uniform resource locator to complete the protocol conversion, obtains the request after protocol conversion, and sends the request after protocol conversion to the back-end container cluster management system; The determining, within the resource range, data content corresponding to the request after the protocol conversion, includes: The backend container cluster management system is used to determine the corresponding deleted resource data in the resource range according to the request after the protocol conversion and delete it, generate deleted data information, and use the deleted data information as the data content.

11. A resource allocation device based on a container cluster management system, characterized in that: The container cluster management system includes: a front-end container cluster management system and a back-end container cluster management system, and the device includes: A request receiving module is configured to receive a data request sent by a terminal device through a request receiving interface of the front-end container cluster management system, wherein the data request includes an interface identifier corresponding to the request receiving interface and a unique identifier of a user, and the request receiving interface includes: a namespace resource interface, the namespace resource interface is used to receive a data request for a built-in resource of a namespace, and the namespace resource interface corresponds to a namespace data segment located in the data request; A protocol conversion module is configured to use the front-end container cluster management system to add the user's unique identifier to the interface identifier to complete the protocol conversion, obtain the request after protocol conversion, and send the request after protocol conversion to the back-end container cluster management system; The request processing module is configured to use the backend container cluster management system to determine the resource range according to the unique identifier of the user in the request after the protocol conversion, determine the data content corresponding to the request after the protocol conversion in the resource range, associate the data content with the request after the protocol conversion to form a request result, and send the request result to the terminal device through the frontend container cluster management system, wherein the backend container cluster management system stores the resource range corresponding to the unique identifier of each user.

12. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the method according to any one of claims 1 to 10 is implemented.

13. A non-transitory computer-readable storage medium storing computer instructions, characterized in that: The computer instructions are used to enable a computer to execute the method according to any one of claims 1 to 10.

Images