Cloud native software licensing system, method and equipment and storage medium

Abstract

The invention provides a cloud native software licensing system, method and device and a storage medium, and relates to the field of software licensing. The problems that under the cloud native scene, the software license cannot be verified off line, the deployment position is difficult to limit, and the operation state is difficult to control accurately are solved. The system comprises containerized application software, license management software and an encrypted License file, the License file comprises customer information, K8s cluster hardware features and application operation limitation information, and the customer information and the K8s cluster hardware features are deployed in the same cluster to realize offline verification. The license management software can form an etcd / Paxos cluster, the hardware features of the cluster are verified during starting, the application needs to apply for authorization during starting, and heartbeat communication is maintained after starting. According to the scheme, by means of the original capacity of K8s, precise limitation of an application deployment cluster and refined management and control of the application concurrency number, the single instance operation duration and the total operation duration are achieved, and the availability and reliability of permission services are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of software licensing, and in particular to a cloud-native software licensing system, method, device and storage medium. BACKGROUND

[0002] Software publishers usually use software licenses to control users to run software products, including: limiting the number of devices installed software, validity period, etc., and preventing unauthorized users from illegally installing and running software. Traditional software licensing technology relies on the fixed identification of the hardware of the computer or server, such as the Mac address of the network card or the ID of the GPU, and performs software authorization management on the fixed identification of the hardware. In the Kubernetes environment, applications can be scheduled to run on any server in the cluster, so the application is no longer bound to a specific hardware. In addition, the existing software licensing process relies too much on online services, and uploads application-related information to a remote server for verification of the validity of the current software license (License). In the private deployment scenario lacking public network, such technical solutions are difficult to apply.

[0003] Some technical improvements have been made in existing patent applications, such as Chinese invention patent CN117851985A, which discloses a distributed cloud-native software authentication system and its application in private cloud. The technical solution uses the Operator mechanism and CRD (Custom Resource Definition) mechanism of Kubernetes to automatically start the licenseProxy service in the Pod of the software application in Sidecar mode, which is responsible for the import and update of the License file. This solution proposes a software authentication system in a microservice scenario, but the solution only involves the transmission process of the License file.

[0004] CN120493235A, a software license generation method and system based on Kubernetes. The technical solution of this patent application uses the Secret mechanism of Kubernetes to use the Kubernetes Secret resource as the unique identification source of the license binding, solving the problem of lack of global uniqueness and persistence of temporary container identification (such as container ID). The unique identification and encrypted license metadata (such as validity period and permissions, etc.) are stored in the Kubernetes Secret resource, which is decoupled from the Pod. By injecting the Secret identification into the container environment variable, the license generation service can read it. When the Pod is deleted, the Secret information is cleaned up through the Finalizers mechanism of Kubernetes, thereby releasing the license resource.

[0005] For example, the Chinese invention patent with publication number CN117370940A discloses a software authorization method and device for cloud-native environment and a medium. In the technical solution of the patent application, the software publisher generates a License file in advance, and deploys a License service on multiple nodes of a server cluster. The License service performs heartbeat detection on the to-be-licensed service, thereby controlling the number of instances and the running time of the to-be-licensed service. However, the patent application does not describe how the License service and the to-be-licensed service discover each other and communicate. In addition, if multiple software services of different software vendors are deployed on the server cluster, the License service of each vendor needs to be installed on multiple nodes at the same time, which will bring about a large management and performance overhead.

[0006] For example, the Chinese invention patent with publication number CN113868602B discloses an application authorization method, a distributed cluster system, an electronic device, and a storage medium. In the technical solution of the patent application, the authorization management service, as an intermediary between the software publisher and the application service, is deployed on the master node of Kubernetes, and uses device fingerprints as basic information for application authentication. The business request of the application triggers an authorization request, and the application obtains authorization information from the authorization management service with the smallest load in a round-robin manner through a load balancing algorithm. In this solution, software authorization is triggered by a business request, which will bring about a large performance overhead when the frequency of business requests is high. In addition, multiple authorization management services lack an information synchronization mechanism and cannot manage the running authorization of each application from a unified perspective.

[0007] The Chinese invention patent with publication number CN119918029A discloses a License verification method and device for private deployment of Kubernetes or docker environment. The technical solution of the patent application generates a License application request using user Token, container identifier (container ID and container name), and physical machine Mac address information, thereby solving the problem of multiple applications running on the same physical machine.

[0008] The Chinese invention patent with publication number CN119293756A discloses a software license verification method, device, medium, equipment, and program product. In the technical solution of the patent application, a gateway receives a user's access request and verifies whether the software license corresponding to the backend software service stored in the gateway is within the valid period. If it is within the valid period, the gateway forwards the user's access request to the backend software service.

[0009] The Chinese invention patent with publication number CN114186284A discloses a software license verification system based on digital signature. The technical solution of the patent application describes the encryption and decryption process of License information.

[0010] However, the existing patent application still cannot limit the installation and deployment position of application services in a private deployment scenario. For example, a software publisher may need to limit users to only deploy and run application software on a certain specific Kubernetes cluster. In addition, the number of concurrent starts of application software and the running time of each application service cannot be accurately controlled. SUMMARY

[0011] The application aims to provide a cloud-native software licensing system, method, device and storage medium to solve the above problems in the prior art.

[0012] In a first aspect of the application, a cloud-native software licensing system is provided, which includes application software published in the form of a container, license management software published in the form of a container, and a License file. The License file is encrypted by the software publisher according to customer information, customer Kubernetes cluster characteristics, a limited number of concurrent instances of application software, a limited running time of each application software instance, and total running time information. The application software container communicates with the license management software during startup to obtain license authorization, and only after authorization is completed can it start and provide services to the outside world. If authorization is not passed, it will terminate operation by itself. The license management software and the application software are deployed in the same Kubernetes cluster to achieve offline verification of software licensing. The license management software can run multiple instances and form a cluster to synchronize the running information of each application software instance and achieve accurate control of the running of application software instances.

[0013] In a further embodiment of the first aspect, the customer information is a customer name provided by the customer, which is a string. The customer Kubernetes cluster characteristics are the serial numbers of all CPUs in the customer Kubernetes cluster, GPU card identifiers, and Mac addresses of network cards. The limited running time of each application software instance is the maximum running time of each application software instance, and the total running time is the maximum value of the sum of the running times of all application software instances. The License file is encrypted after being organized into a JSON or XML format string.

[0014] In a further embodiment of the first aspect, the license management software cluster is deployed by a Kubernetes StatefulSet controller, which provides stable identification and persistent storage for the license management software Pods; the license management software cluster configures a service of Headless Service type, directly exposes the IP addresses of the license management software Pod instances through DNS for direct communication by the application software Pod instances; and the license management software Pods save the data run by the application software Pod instances through persistent volumes.

[0015] In a further embodiment of the first aspect, the License file is injected into the license management software Pod instance by a Kubernetes Secret, and the license management software Pod instance reads the environment variable value corresponding to the Secret when starting and decrypts to obtain the plaintext content of the License file.

[0016] In a further embodiment of the first aspect, after the license management software Pod is started, the CPU serial number, GPU unique identifier and network card Mac address of the Kubernetes cluster where the license management software Pod is located are obtained and compared with the cluster feature information in the License file, and when the matching proportion of the hardware information exceeds a preset threshold, the license management software Pod is normally started, otherwise the startup is terminated.

[0017] In a second aspect of the application, a cloud-native software licensing method is provided, which comprises the following steps: S1, a software publisher packages application software and license management software into a container form, and encrypts a License file according to customer information, customer Kubernetes cluster features, a limited number of concurrent instances of the application software, a limited running time of each application software instance and total running time information, and delivers the three to the customer; S2, the customer deploys application software Pod instances and license management software Pod instances in its Kubernetes cluster, the license management software Pod instances form a cluster and complete the acquisition and decryption of the License file, and at the same time verify the hardware feature information of the cluster to complete the startup of the license management software Pod instances; S3, when the application software Pod instance is started, it communicates with any license management software Pod instance according to the domain name of the Headless Service of the license management software cluster and sends an authorization request containing the Pod ID of the application software Pod instance; S4, after receiving the authorization request, the license management software Pod instance processes the request according to a preset logic and returns a response, and the application software Pod instance only completes the startup after receiving a normal response, and terminates the startup if no response is received; S5, the application software Pod instance successfully started periodically sends an authorization request to the license management software cluster to maintain heartbeat communication, and if no normal response is received for two consecutive heartbeat periods, the application software Pod instance terminates operation by itself.

[0018] In further embodiments of the second aspect, the preset logic in step S4 is specifically: If the application software Pod instance sends the authorization request for the first time, it is determined whether the number of currently authorized application software Pods is less than the maximum number of concurrent instances in the License file, and whether the running time of all application software instances is less than the total running time, if both conditions are met, a normal response is returned and the shared information of the license management software cluster is updated, otherwise an error response is returned. If the application software Pod instance sends the authorization request for the first time, it is determined whether the number of currently authorized application software Pods is less than the maximum number of concurrent instances in the License file, and whether the running time of all application software instances is less than the total running time, if both conditions are met, a normal response is returned and the shared information of the license management software cluster is updated, otherwise an error response is returned.

[0019] In further embodiments of the second aspect, the shared information of the license management software cluster includes an ID list of the application software Pods that have obtained authorization, the number of Pods, the running time of a single application software Pod instance, and the total running time of all application software Pod instances.

[0020] In further embodiments of the second aspect, the specific way in which the license management software Pod instance checks the cluster hardware feature information in step S2 is: the obtained cluster CPU serial number, GPU unique identifier, and network card Mac address are compared with the corresponding information in the License file, and when the matching proportion of each hardware information exceeds a preset threshold, the cluster is determined to be an authorized cluster and is normally started.

[0021] In further embodiments of the second aspect, the period of the heartbeat communication in step S5 is a preset fixed time length, and the application software Pod instance includes its own Pod ID in each heartbeat authorization request it sends, and the license management software Pod instance updates the corresponding running time information synchronously when responding to the heartbeat request.

[0022] In a third aspect of the application, an electronic device is provided, which includes a processor and a memory storing computer program instructions; the processor implements the cloud-native software license method disclosed in the second aspect and further embodiments thereof when executing the computer program instructions.

[0023] A fourth aspect of the present invention provides a computer-readable storage medium, characterized in that the storage medium stores at least one executable instruction, which, when executed on an electronic device, causes the electronic device to perform the cloud-native software licensing method disclosed in the second aspect and its further embodiments.

[0024] Compared with the prior art, the present invention has at least the following beneficial effects: (1) Make full use of Kubernetes’ native APIs and ensure that the technical solution is compatible with Kubernetes scenarios.

[0025] (2) It does not rely on a public network connection for deployment environment, and can realize offline verification of software license.

[0026] (3) It can restrict users from deploying application software on other Kubernetes clusters without authorization.

[0027] (4) The license management software can run multiple instances to form an etcd or paxos cluster, share the running information of application software instances, and improve the availability and reliability of the license management service.

[0028] (5) The license management software can update the runtime of each application software instance and the total runtime of each instance, thereby enabling more precise authorization control over the application software. Attached Figure Description

[0029] Figure 1 This is a processing logic diagram of the license management software handling the authorization request of the application software in the embodiment. Detailed Implementation

[0030] In the following description, numerous specific details are set forth in order to provide a more thorough understanding of the invention. However, it will be apparent to those skilled in the art that the invention can be practiced without one or more of these details. In other instances, certain technical features well-known in the art have not been described in order to avoid obscuring the invention.

[0031] Before describing the embodiments, some specific terms that may appear in the following text will be explained.

[0032] Kubernetes: An open-source container orchestration engine. It is used to automate the deployment, scaling, and management of containerized applications. Kubernetes enables efficient scheduling and resource management of containers, ensuring their reliable operation within a cluster.

[0033] Pod: In Kubernetes, a Pod is one or a group of containers in a cluster. It is the most basic unit of deployment and an instance of an application. Containers within a Pod are always deployed together on the same host, sharing storage and network resources.

[0034] This invention proposes a cloud-native software licensing system and method. First, the software publisher releases application software in container form, and simultaneously releases license management software in container form, which is responsible for managing the application software's licenses. The application software and license management software can be deployed and run in the same Kubernetes cluster, enabling offline verification of software licenses. The software publisher generates a license file based on customer information, customer Kubernetes cluster characteristics, the limited number of concurrent startups for the application software, the limited runtime of each application software instance, and the total runtime, and releases it along with the application software and license management software. Second, the customer deploys and runs a specific number of application software instances and license management software instances in their Kubernetes cluster as needed. The license management software can run multiple instances simultaneously, forming an etcd or Paxos cluster, synchronizing the runtime information of each application software instance, thereby achieving precise control over the operation of multiple application software instances while ensuring the availability and reliability of the license management service. Finally, during the startup process, the application software first obtains authorization information from the license management software; only after successful verification can it start normally. After normal startup, the application software maintains heartbeat communication with the license management service. If the application receives an error response from the license management software or fails to receive a normal response from the license management software for two consecutive heartbeat cycles, the application will automatically terminate its operation.

[0035] 1. Software publishers distribute application software and license management software, along with license files, in the form of containers.

[0036] Software publishers package application software into containers and distribute them. During the startup process, the application software container attempts to communicate with the license management software service to obtain a license. Only after obtaining a license can the application software complete the startup process and provide services normally; otherwise, it will automatically terminate its operation.

[0037] The software publisher packages the license management software into a container and distributes it. This software is responsible for managing the application software's licenses. The application software and the license management software can be deployed and run in the same Kubernetes cluster, so that the application software can complete the licensing process even without a public network connection, thus enabling offline verification of software licenses.

[0038] The software distributor encrypts and generates a License file based on customer information, customer Kubernetes cluster characteristics, the maximum number of concurrent instances of the application software, the maximum runtime for each application service, and the total runtime. This License file is released simultaneously with the application software and the license management software. Customer information consists of the customer name provided by the customer (string type). Customer Kubernetes cluster characteristics are the serial numbers of all CPUs, GPU card identifiers, and MAC addresses of the network cards within the cluster, provided by the customer. These characteristics physically identify the cluster. The license management software periodically checks for significant changes between the application software's deployment environment and the cluster characteristics information in the License file to determine if the application software has been deployed to other clusters without authorization. The maximum runtime for each application software instance is the agreed-upon maximum runtime for each instance, measured in seconds; the total runtime is the maximum sum of the agreed-upon runtimes for all application software instances, also measured in seconds. The software distributor organizes this information into a JSON or XML string, encrypts it, and generates the License file.

[0039] The JSON format can be referenced as follows: { "customerName": "ChinaTelecom", "clusterCharacteristics": { "cpuSerialNumbers": [ "GenuineIntel-123456-ABCDEF-789", "GenuineIntel-123456-ABCDEF-790", "GenuineIntel-987654-ZYXWVU-321", "GenuineIntel-987654-ZYXWVU-322", "GenuineIntel-987654-ZYXWVU-637" "GenuineIntel-987654-ZYXWVU-638", "GenuineIntel-987654-ABCDEF-825", "GenuineIntel-987654-ABCDEF-826" ], "gpuIdentifiers": [ "GPU-8a8b7c6d-1234-5678-9abc-def012345678", "GPU-7dd44050-9df4-43aa-b3b4-3b47eff8fc31", "GPU-cca71187-f666-46ff-81c6-eb3b72ff6972", "GPU-6ff086ad-493d-4b3a-8ed1-970239d7125b", "GPU-f9813daa-6a8e-4543-8708-d42cefdda20a", "GPU-a7e9e43b-d2b1-4415-b73d-ff72b713e45f", "GPU-0d1d13fe-777d-44d8-b1b2-302ca1e48aa1", "GPU-f85d0772-22d2-43d0-8d71-4e6714c2bb20", "GPU-f46eb868-0a99-4291-98f2-19d95f1e9fbb", "GPU-eaa4a63e-2646-427a-a892-f8027c2791ed", "GPU-d75f6720-b249-4395-bcc7-9ffe2b67cabb" ], "networkInterfaceMACAddresses": [ "aa:bb:cc:11:22:33", "aa:bb:cc:44:55:66", "52:54:00:1A:B2:C9", "00:16:3E:8D:4F:10", "52:54:00:E3:75:8A", "00:16:3E:22:AC:5B", "52:54:00:6C:91:D4", "00:16:3E:F0:9D:36", "52:54:00:4D:08:E7", "00:16:3E:B7:64:A2" ] }, "applicationLimits": { "maxInstanceNum": 6, "maxRuntimePerInstance": 86400, "maxTotalRuntime": 2592000 } } } Among them, cpuSerialNumbers is a list of all CPU serial numbers in the cluster, gpuIdentifiers is a list of unique identifiers for all GPUs in the cluster, networkInterfaceMACAddresses is a list of MAC addresses for all network cards in the cluster, maxInstanceNum is the maximum number of concurrent application instances, maxRuntimePerInstance is the maximum runtime of each application instance in seconds, and maxTotalRuntime is the maximum sum of runtimes of all application instances in seconds.

[0040] The application software container, license management software container, and license file are delivered together to the customer for deployment and operation within their Kubernetes cluster.

[0041] II. Deployment and operation of application software and license management software.

[0042] Customers deploy and run a specific number of application software Pod instances and license management software Pod instances in their Kubernetes clusters as needed. For example, if a customer has a high workload, they can deploy and run multiple application software Pod instances within their Kubernetes cluster. These application software Pod instances can run on different servers within the Kubernetes cluster, thereby providing higher business response performance. The license management software can also run multiple Pod instances simultaneously, such as an odd number of instances like 3, 5, or 7. These instances form a license management software cluster, synchronizing the running information of each application software instance within the license management software cluster. This enables precise control over the operation of multiple application software instances while ensuring the availability and reliability of the license management service.

[0043] Taking the deployment of an etcd cluster as an example, the Kubernetes StatefulSet controller provides stable identities (fixed names and network identifiers) and persistent storage for license management software Pods. This ensures that deployed license management software Pods are created, updated, and deleted in sequence, and retain their original identities after restarts or rebuilds. Stable network identifiers (such as etcd-0, etcd-1, etcd-2) and orderly deployment are provided for each etcd member. Using the Headless Service type, the IP addresses of license management software Pod instances are directly exposed via DNS. Subsequent application software instances can communicate directly with the license management software Pod instances, rather than through service IP forwarding, facilitating application software Pod instances to discover the license management software Pod instances within the cluster via DNS. Each etcd node uses a persistent volume to store the data running on the application software Pod instances, ensuring that this data is not lost even after the license management software Pod instances restart.

[0044] Next, the contents of the License file need to be passed to the license management software Pod instance. First, create a Kubernetes Secret. Below is an example of creating a Kubernetes Secret using a YAML file, where the data in the License file needs to be Base64 encoded.

[0045] # secret.yaml apiVersion: v1 kind: Secret metadata: name: my-license-secrets#Secret's name namespace: etcd-cluster # Ensure it's in the same namespace as etcd's StatefulSet. type: Opaque # Default type, used to store arbitrary key-value pairs data: license-data: eHh4eHh4eHg=# The Base64 encoded contents of the license file are placed here. Subsequently, in the StatefulSet Pod template of the license management software cluster, the created Kubernetes Secret is injected as an environment variable through the env.valueFrom.secretKeyRef field. Each license management software Pod instance needs to read the value of this environment variable at startup, decrypt it, and obtain the plaintext content of the License file.

[0046] Each license management software Pod, upon startup, retrieves the CPU serial numbers, GPU unique identifiers, and network card MAC addresses from all nodes in the entire Kubernetes cluster and compares them with the corresponding information in the license file. Since cluster hardware may be adjusted due to upgrades or failures—for example, adding multiple CPUs or GPUs or replacing faulty network cards—the hardware information of the cluster will change as the cluster's runtime increases. A threshold, such as 70%, is set. If the proportion of the cluster's hardware information collected by the license management software Pod that includes the cluster characteristic information in the license file exceeds this threshold, the cluster running on the license management software Pod is considered to be the same cluster for which the customer obtained the license file. For example, if all CPU serial numbers in the license file are included in the list of all CPU serial numbers collected by the license management software Pod, or if 70% of the CPU serial numbers in the license file are included in the list of CPU serial numbers collected by the license management software Pod, then the CPU configuration change is considered normal. Similarly, the same principle applies to determining whether changes in the cluster's GPU and network card configurations are normal. If the configuration changes of CPU, GPU, and network card are all judged to be normal, the license management software Pod will consider the running cluster to be the same cluster for which the customer obtained the license file, and it can start normally; otherwise, it will terminate the startup.

[0047] III. Processing of application software authorization request messages by the license management software.

[0048] In the YAML file deploying the application Pod, the domain name of the Headless Service of the license management software cluster needs to be specified. During the startup process of the application Pod instance, the application Pod instance will communicate with any license management software Pod instance based on the domain name of the license management software cluster to obtain authorization information. Only after successful authorization verification can the application Pod instance start normally.

[0049] The authorization request message sent by the application software Pod to the license management software Pod contains the application software Pod's ID.

[0050] After receiving an authorization request message from an application pod, the license management software pod parses the application pod's ID from the message and determines whether this is the first time the application pod instance has sent an authorization request message to the license management software pod. If it is the first time, the license management software pod instance checks the shared information of the license management software cluster to see if the number of currently authorized application pods is less than the value of `maxInstanceNum` in the license file. If it is less, it then checks if the total runtime of all application instances is less than the value of `maxTotalRuntime` in the license file. If it is less, the license management software pod responds normally to the application pod's authorization request and updates the list of currently authorized application pod IDs, the number of pods, and the runtime of all application pod instances in the shared information of the license management software cluster. Otherwise, the license management software pod sends an error response to the application pod's authorization request. If this is not the first time an authorization request message has been sent (meaning the application software Pod's ID is already stored in the shared information of the license management software cluster), the license management software Pod instance checks whether the application software Pod instance's runtime is less than the `maxRuntimePerInstance` value in the license file, and whether the runtime of all instances of the application software is less than the `maxTotalRuntime` value in the license file. If yes, the license management software Pod replies with a correct response to the application software Pod's authorization request and updates the current application software Pod's runtime and the runtime of all application software Pod instances in the shared information of the license management software cluster, i.e., adding one heartbeat cycle to each. If no, the license management software Pod replies with an error response to the application software Pod's authorization request.

[0051] If the application Pod receives a normal authorization request response, it can continue the subsequent startup process. If the application Pod receives an incorrect authorization request response, it will terminate the startup process itself.

[0052] After an application Pod instance starts normally, it will periodically (e.g., every minute) resend an authorization request message to any license management software Pod instance in the license management software cluster. The message contains the application Pod ID, thus establishing a heartbeat mechanism between the application Pod instance and the license management software Pod. If the application Pod instance does not receive a response to the license management software's authorization request within two consecutive heartbeat cycles, the application will automatically terminate its operation.

[0053] The processing logic for application software license requests by the license management software is as follows: Figure 1.

[0054] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet or intranets.

[0055] In summary, the cloud-native software licensing system, method, device, and storage medium disclosed in this invention cover the following key technical points: 1. The software publisher releases the application software, along with the accompanying license management software and license file in the form of a container.

[0056] 2. Application software and supporting license management software can be deployed on the same cluster to achieve offline verification of software licenses.

[0057] 3. The license file contains Kubernetes cluster characteristics, including the cluster's CPU serial number, GPU identifier, and network card MAC address information. These cluster characteristics restrict users from deploying application software on other Kubernetes clusters.

[0058] 4. The license management software can be deployed in multiple instances to form an etcd or paxos cluster, sharing the running information of application software instances, while improving the availability and reliability of the license management service.

[0059] 5. The process by which the license management software processes authorization requests sent by application software.

[0060] 6. A heartbeat mechanism between application software and license management software allows the license management software to update the runtime of each application software instance and the total runtime of all instances, enabling more precise authorization control over application software.

[0061] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments have been described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification. Although the present invention has been shown and described with reference to specific preferred embodiments, it should not be construed as limiting the invention itself. Various changes in form and detail may be made without departing from the spirit and scope of the invention as defined in the appended claims.

Claims

1. A cloud-native software licensing system, characterized in that, include: Application software distributed in containers, license management software distributed in containers, and license files; The license file is generated by the software distributor using encrypted information based on customer information, customer Kubernetes cluster characteristics, the limited number of concurrent instances of the application software, the limited runtime of each application software instance, and the total runtime. During the startup process, the application software container communicates with the license management software to obtain license authorization. It only completes startup and provides services after authorization is granted; otherwise, it terminates its operation automatically. The license management software and the application software are deployed on the same Kubernetes cluster to enable offline verification of software licenses; The license management software can run multiple instances and form a cluster to synchronize the running information of each application software instance, thereby achieving precise control over the operation of the application software instances.

2. The cloud-native software licensing system according to claim 1, characterized in that, The customer information is the customer name provided to the customer, and the type is string; the customer Kubernetes cluster characteristics are the serial numbers of all CPUs, GPU card identifiers, and MAC addresses of the network cards in the customer Kubernetes cluster; the limited running time of each application software instance is the maximum running time of each application software instance, and the total running time is the maximum value of the sum of the running times of all application software instances; the license file is formed by encrypting the above information into a JSON or XML format string.

3. A cloud-native software licensing system according to claim 1, characterized in that, The license management software cluster is deployed through a Kubernetes StatefulSet controller, which provides stable identification and persistent storage for the license management software Pods. The license management software cluster is configured with a Headless Service type service, which directly exposes the IP address of the license management software Pod instance through DNS, enabling direct communication with the application software Pod instance. The license management software Pod stores the data running on the application software Pod instance through persistent volumes.

4. A cloud-native software licensing system according to claim 3, characterized in that, The license file is injected into the license management software Pod instance via a Kubernetes Secret. When the license management software Pod instance starts, it reads the environment variable value corresponding to the Secret and decrypts it to obtain the plaintext content of the license file.

5. A cloud-native software licensing system according to claim 3 or 4, characterized in that, After the license management software Pod starts, it obtains the CPU serial number, GPU unique identifier, and network card MAC address of the Kubernetes cluster it is in, and compares them with the cluster characteristic information in the license file. When the hardware information matching ratio exceeds a preset threshold, the license management software Pod starts normally; otherwise, it terminates the startup process.

6. A cloud-native software licensing method, characterized in that, Includes the following steps: S1. The software publisher packages the application software and license management software into a container and generates a license file by encrypting it based on customer information, customer Kubernetes cluster characteristics, the limited number of concurrent instances of the application software, the limited runtime of each application software instance and the total runtime information. All three are then delivered to the customer. S2. The customer deploys application software Pod instances and license management software Pod instances in their Kubernetes cluster. The license management software Pod instances form a cluster and complete the acquisition and decryption of the license file. At the same time, they verify the hardware feature information of the cluster and complete their own startup. S3. When the application software Pod instance starts, it communicates with any license management software Pod instance based on the Headless Service domain name of the license management software cluster and sends an authorization request containing its own Pod ID. S4. After receiving the authorization request, the license management software Pod instance processes the request according to the preset logic and returns a response. The application software Pod instance will only start after receiving a normal response, and will terminate the startup if no response is received. S5. Successfully started application software Pod instances periodically send authorization requests to the license management software cluster to maintain heartbeat communication. If no normal response is received for two consecutive heartbeat cycles, the instance will automatically terminate its operation.

7. A cloud-native software licensing method according to claim 6, characterized in that, The preset logic mentioned in step S4 is as follows: If this is the first authorization request sent by an application software Pod instance, it checks whether the number of currently authorized application software Pods is less than the maximum number of concurrent instances in the License file, and whether the running time of all application software instances is less than the total running time. If both conditions are met, it responds normally and updates the shared information of the license management software cluster; otherwise, it returns an error response. If this is not the first authorization request, it checks whether the running time of the application software Pod instance is less than the maximum running time of a single instance, and whether the running time of all instances is less than the total running time. If both conditions are met, it responds normally and updates the corresponding running time information; otherwise, it returns an error response.

8. A cloud-native software licensing method according to claim 7, characterized in that, The shared information of the license management software cluster includes a list of authorized application software Pod IDs, the number of Pods, the running time of a single application software Pod instance, and the total running time of all application software Pod instances.

9. A cloud-native software licensing method according to claim 6, characterized in that, The specific method for verifying the hardware feature information of the cluster where the license management software Pod instance is located in step S2 is as follows: the obtained cluster CPU serial number, GPU unique identifier, and network card MAC address are compared with the corresponding information in the License file. When the matching ratio of each hardware information exceeds the preset threshold, the cluster is determined to be an authorized cluster and starts normally.

10. A cloud-native software licensing method according to claim 6, characterized in that, The heartbeat communication period in step S5 is a preset fixed duration. Each heartbeat authorization request sent by the application software Pod instance includes its own Pod ID. When responding to the heartbeat request, the license management software Pod instance synchronously updates the corresponding runtime information.

11. An electronic device, characterized in that, include: Processor and memory storing computer program instructions; When the processor executes the computer program instructions, it implements the cloud-native software licensing method as described in any one of claims 6 to 10.

12. A computer-readable storage medium, characterized in that, The storage medium stores at least one executable instruction that, when executed on an electronic device, causes the electronic device to perform the cloud-native software licensing method as described in any one of claims 6 to 10.

Images