Kubernetes-based multi-modal software delivery apparatus, method and computer readable storage medium

Abstract

The application discloses a multi-form software delivery device, method and computer readable storage medium based on Kubernetes, to solve the problem that the prior art cannot support the installation of software in different deployment forms. When there are multiple deployment forms in the list of business software to be deployed, a part of the software is deployed through the Kubernetes mode, a part of the software is deployed through the traditional mode, and the like, the multi-form software delivery device can send business software installation instructions to different deployment executors according to the deployment form of the software, so that the business software in different deployment forms can be quickly and simultaneously installed in batches, thereby accelerating the progress of the software installation of the protection personnel and reducing the understanding of the business software. The multi-form software delivery device also realizes the access of the business software through the software domain name, and improves the high reliability when the business software deployed through the Kubernetes mode and the business software deployed through the traditional mode access each other.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a Kubernetes-based multi-form software delivery apparatus, method, and computer-readable storage medium. Background Technology

[0002] Business software can be delivered in various forms, such as traditional deployment (starting directly on physical / VM server nodes via scripts), container deployment, Kubernetes deployment, OpenStack deployment, etc. Among these, Kubernetes deployment is the most widely used and has a relatively high reliability. The general process for deploying business software using Kubernetes is as follows: package the business software into an image, create Deployment resources, and create Service resources; set the number of service instances of the business software through the Deployment resources; if it is 1, it means that the business software runs in singleton mode; if it is more than 1, it means that the business software runs in cluster mode.

[0003] In the field of continuous delivery in cloud computing, business software can be deployed and maintained uniformly by Kubernetes clusters. However, not all business software meets the conditions for successful management by Kubernetes clusters. Current delivery models lack a multi-mode software delivery (hybrid deployment) approach; that is, it's impossible to simultaneously deploy and manage software with multiple delivery modes; and when the IP address of software deployed on a physical server node changes, the caller needs to update its access configuration. If a project's architecture adopts a microservices or distributed architecture, there will inevitably be multiple software entities. In this case, it cannot be guaranteed that all software entities are delivered using the same delivery mode; multiple delivery modes may exist. The existence of multiple delivery modes inevitably slows down delivery progress, leads to inconsistent server resource scheduling, and results in unreliable and unstable communication between software with different delivery modes. Summary of the Invention

[0004] This invention provides a Kubernetes-based multi-form software delivery device, method, and computer-readable storage medium to solve the problem that existing technologies cannot support software installation in different deployment forms.

[0005] This invention proposes a multi-form software delivery device based on Kubernetes, comprising: a deployment module, a software access control module, a load balancing module, and a domain name service module;

[0006] The deployment module is used to acquire the software to be deployed and deploy it to a physical server cluster, VM server cluster, or Kubernetes cluster according to the delivery type of the software: for traditional delivery methods, it selects a target server node and sends software pull instructions, software start script instructions, and software stop script instructions to the deployment agent on the target server node; for Kubernetes delivery methods, it creates a Pod and a corresponding ClusterIP type Service, and deploys it through the Kubernetes cluster; it is also used to send service access permission requests to the software access control module.

[0007] The software access control module is used to create ClusterIP type Services and corresponding Endpoints for software deployed using traditional delivery methods. The Endpoints are set to the physical or VM IP address used by the software when it starts up. The module also constructs a string "serviceName: software's Port", a domain name, and a service name for the software to be deployed, and renders them into the upstream and server modules of the nginx.conf configuration file. It also sets and updates the weights for each Service. Furthermore, the module sends a hot-load command, nginx-sreload, to the load balancing module, enabling the load balancing module to apply the current nginx.conf configuration, and registers the domain name information of the software to be deployed with the domain name service module.

[0008] The load balancing module is implemented using NGINX software and is used to forward traffic to the service instances of the client access software.

[0009] The domain name service module is used to provide domain name resolution for the software to be deployed. The deployed software and the client access the software all use domain names to access services.

[0010] This invention also proposes a multi-form software delivery method based on Kubernetes, including:

[0011] Obtain the software to be deployed, and deploy the software to a physical, VM server cluster, or Kubernetes cluster according to the delivery type of the software to be deployed: For traditional delivery methods, select a target server node and send software pull instructions, software start script instructions, and software stop script instructions to the deployment agent on the target server node; For Kubernetes delivery methods, create Pods and corresponding ClusterIP type Services, and implement deployment through the Kubernetes cluster;

[0012] Create a ClusterIP type Service and corresponding Endpoints for software deployed using traditional delivery methods. The Endpoints are set to the physical or VM IP address used when the software starts.

[0013] After constructing the string "serviceName: software's Port", domain name, and service name for the software to be deployed, it is rendered into the upstream and server modules in the nginx.conf configuration file, and the weight is set and updated for each service.

[0014] Apply the current nginx.conf configuration and register the domain name information of the software to be deployed. All software access and client access to the software will be conducted through the domain name.

[0015] This invention also proposes a computer-readable storage medium storing an implementation program for information transmission, which, when executed by a processor, implements the steps of the Kubernetes-based multi-form software delivery method described above.

[0016] By employing the embodiments of this invention, when the list of business software to be deployed contains multiple deployment types (some software is deployed via Kubernetes, some via traditional methods, etc.), business software installation instructions can be sent to different deployment executors according to the software's deployment type. This allows for the rapid, simultaneous, and batch installation of business software with different deployment types, thereby accelerating the software installation process for support personnel and reducing the need for them to have a thorough understanding of the business software. Furthermore, accessing business software via software domain names improves the reliability of communication between business software deployed via Kubernetes and business software deployed via traditional methods; for example, changes in the service instance IP of a business software will not affect client access.

[0017] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0018] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of the embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. In the drawings:

[0019] Figure 1 This is the core flowchart of the multi-form software delivery device in this embodiment of the invention;

[0020] Figure 2 This is an overall architecture diagram of the multi-form software delivery device in this embodiment of the invention;

[0021] Figure 3 This is a deployment architecture diagram of the business software in an embodiment of the present invention;

[0022] Figure 4 This is a diagram of the device architecture upon which the conventional deployment method in this embodiment of the invention relies;

[0023] Figure 5 This is a flowchart illustrating the deployment process of the traditional deployment method in this embodiment of the invention;

[0024] Figure 6 This is the architecture diagram upon which the Kubernetes deployment in this embodiment of the invention depends;

[0025] Figure 7 This is a flowchart of the Kubernetes deployment method in this embodiment of the invention;

[0026] Figure 8 This is an execution flowchart of the software access control module in an embodiment of the present invention;

[0027] Figure 9 This is a flowchart illustrating an example of a client accessing a software backend service in an embodiment of the present invention;

[0028] Figure 10 This is the main flowchart of software mutual access in the embodiments of the present invention. Detailed Implementation

[0029] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the invention and to fully convey the scope of the invention to those skilled in the art. Furthermore, in some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0030] This invention provides a multi-form software delivery device based on Kubernetes, which mainly solves the following technical problems: 1. How to install business software with different delivery forms at the same time; for example, some software is deployed via Kubernetes and some software is deployed via traditional methods. How to install these two types of software quickly and simultaneously is an urgent problem to be solved; 2. How to ensure that communication between business software managed by Kubernetes cluster and business software deployed via traditional methods is not affected by changes in software IP.

[0031] The “Kubernetes-based multi-form software delivery device” mentioned herein can be understood as the multi-form software delivery device in this embodiment of the invention being implemented based on Kubernetes.

[0032] The Kubernetes-based multi-form software delivery device of this invention includes: a deployment module, a software access control module, a load balancing module, and a domain name service module;

[0033] The deployment module is used to acquire the software to be deployed and deploy the software to a physical, VM server cluster, or Kubernetes cluster according to the delivery type of the software to be deployed: for traditional delivery methods, a target server node is selected, and software pull instructions, software start script instructions, and software stop script instructions are sent to the deployment agent on the target server node; for Kubernetes delivery methods, a Pod and a corresponding ClusterIP type Service are created, and deployment is achieved through the Kubernetes cluster.

[0034] It is understandable that when the deployment module obtains a list of software to be deployed, which contains at least one piece of software, if it finds that the list has multiple deployment methods (some software is deployed via Kubernetes, some software is deployed via traditional methods, etc.), it can send business software installation instructions to different types of deployment executors according to the software's deployment method (i.e. delivery type).

[0035] The deployment module is also used to send service access permission requests to the software access control module;

[0036] The software access control module is used to create a ClusterIP type Service and corresponding Endpoints for software deployed using traditional delivery methods. The Endpoints are configured to use the physical or VM IP address when the software starts.

[0037] When business software is deployed in a non-Kubernetes manner (i.e., traditional deployment), N ClusterIP type Service resources and N Endpoint resources need to be created in the Kubernetes cluster; that is, the access of the business software is routed to the physical (VM) server node through the Service resources in the Kubernetes cluster.

[0038] The software access control module is used to construct the string "serviceName: software's Port", domain name, and service name for the software to be deployed, and then render them into the upstream and server modules in the nginx.conf configuration file, and set and update the weight for each service; it is also used to send the hot reload command nginx-sreload to the load balancing module, so that the load balancing module takes effect with the current nginx.conf configuration, and register the domain name information of the software to be deployed to the domain name service module;

[0039] In a Pod service instance containing an NGINX process, the upstream module of the nginx.conf configuration file stores a string in the form of "serviceName:port of the software"; each server has the same initial access weight; and the domain name of the software is registered in the nginx.conf configuration file.

[0040] Instead of using Istio, Ingress-nginx, etc., to provide external access to business software, NGINX is encapsulated in Pod resources, and a NodePort type Service resource is created for it. Access to business software is provided externally through the NodePort method. That is, all business software, whether deployed through Kubernetes or in a traditional way, provides external access in the form of "business software domain name: nginx Service NodePort".

[0041] The load balancing module is implemented using NGINX software and is used to forward traffic to the service instances of the client access software.

[0042] The domain name service module is used to provide domain name resolution for the software to be deployed. The deployed software and the client access the software all use domain names to access services.

[0043] Business software deployed via Kubernetes and business software deployed via traditional methods both need to register their domain names with the same domain name server. This domain name server needs to be configured on the local area network where the client (e.g., browser) resides, the physical (VM) server cluster, and the Kubernetes cluster.

[0044] Whether the software is deployed using Kubernetes or a traditional deployment method, the following scenarios may occur when the software interacts with each other:

[0045] 1) Inter-application communication between business software within a Kubernetes cluster;

[0046] 2) Inter-access between business software in physical and VM clusters;

[0047] 3) Mutual access between business software in the Kubernetes cluster and business software in physical and VM clusters;

[0048] Regardless of the access method, the overall access process is the same;

[0049] First, the IP address corresponding to the software domain name is obtained through the DNS (Domain Name Service) server.

[0050] Secondly, the underlying system will re-render the latest request address when the client requests it; that is, the IP address: NGINX NodePort, and automatically initiate the latest request.

[0051] Secondly, after the NodePort of the NGINX Service resource receives a client request, it will automatically forward the client request traffic to the Pod resource containing the NGINX process according to the iptables rules. The NGINX process in the Pod will look up the relevant upstream load balancer list in the nginx.conf configuration file according to the software name and domain name, and select an appropriate server address for forwarding based on the weight.

[0052] Finally, NGINX forwards the client request to a server in the upstream module, that is, to the Service resource of the target software. The Service resource of the target software will automatically forward the client request traffic to the Pod containing the target software for response according to iptables rules, or will automatically forward the client request traffic to a node in the physical or VM service cluster where the software is installed for response according to iptables rules.

[0053] By employing the embodiments of this invention, when the list of business software to be deployed contains multiple deployment types (some software is deployed via Kubernetes, some via traditional methods, etc.), business software installation instructions can be sent to different deployment executors according to the software's deployment type. This allows for the rapid, simultaneous, and batch installation of business software with different deployment types, thereby accelerating the software installation process for support personnel and reducing the need for them to have a thorough understanding of the business software. Furthermore, accessing business software via software domain names improves the reliability of communication between business software deployed via Kubernetes and business software deployed via traditional methods; for example, changes in the service instance IP of a business software will not affect client access.

[0054] Based on the above embodiments, further variant embodiments are proposed. It should be noted that, in order to keep the description brief, only the differences from the above embodiments are described in each variant embodiment.

[0055] According to some embodiments of the present invention, the multi-form software delivery apparatus further includes:

[0056] Business software packaging tools are used to package software entities, software configurations, software startup scripts, uninstallation scripts, and software deployment description files into software to be deployed.

[0057] Business software packaging tools package business software (also referred to as software) in a unified format. The file name format of the packaged file is as follows: software name-version number-CPU architecture.zip; there are two main packaging modes.

[0058] Furthermore, for software deployed using traditional methods, the software deployment description file includes CPU, memory, ports, and service instances;

[0059] For software deployed using Kubernetes, the software deployment description file includes CPU, memory, port, service instance, log path, and data path.

[0060] According to some embodiments of the present invention, the deployment module includes a deployment scheduler, a deployment executor, and a resource monitoring controller;

[0061] The deployment scheduler is used to obtain all software to be deployed, create a dependency topology structure for all software to be deployed, determine software suitable for direct deployment based on the dependency topology structure, and sequentially call the traditional deployment executor and / or the Kubernetes deployment executor to deploy the software according to the delivery type of these software.

[0062] The dependency topology reflects the dependencies between the software to be deployed and the startup status of the software to be deployed;

[0063] The software suitable for direct deployment is software that does not currently depend on other software and is suitable for direct installation;

[0064] The conventional deployment executor is used to send software pull instructions, software start script instructions, and software stop script instructions to the deployment agent on the target server node.

[0065] The Kubernetes deployment executor is used to create Pods and corresponding ClusterIP-type Services, and automatically calculates the target server nodes and pulls the software to be deployed through the Kubernetes cluster.

[0066] The resource monitoring controller is used to collect the resource status of server nodes, including the number of available CPU cores, the amount of memory remaining, and the CPU architecture type.

[0067] The deployment scheduler is also used to determine the target server node based on the currently acquired resource status of the server node.

[0068] In some embodiments of the present invention, the storage structure for storing the dependencies of the business software to be deployed is in the form of key-value pairs; wherein, the key represents the business software to be deployed, and the key type is string; the value represents the list of software that the business software to be deployed directly depends on when it starts up, and the type is set (array, slice, etc.); and the content of this storage structure changes dynamically according to the installation progress of the dependent software.

[0069] According to some embodiments of the present invention, deployment commands are sent to different deployment executors based on the deployment mode of the software to be deployed, thereby enabling software installation that supports multiple deployment modes simultaneously. The deployment executor can be a traditional deployment method (started directly on a physical / VM server node via a script), a Kubernetes deployment method, an OpenStack deployment method, etc.

[0070] According to some embodiments of the present invention, the deployment module further includes:

[0071] A deployment status listener is used to monitor the deployment process status of the software and the installation status of the Pods, and to provide timely feedback to the deployment scheduler.

[0072] According to some embodiments of the present invention, the domain name service module is implemented using the CoreDN open-source software.

[0073] According to some embodiments of the present invention, the software access control module and the load balancing module are uniformly encapsulated within a Pod, and access requests are provided externally through a Service resource of type NodePort.

[0074] According to some embodiments of the present invention, the deployment strategy of the software to be deployed includes singleton deployment, cluster deployment, and canary deployment.

[0075] According to some embodiments of the present invention, the Pod corresponds one-to-one with the Service of the ClusterIP type. When the business software is deployed via Kubernetes, the Service / Pod relationship in the deployment model is no longer 1:N but 1:1; that is, one Service can only be associated with one Pod; if the business software needs to create N service instances when deployed in a cluster, that is, N Services of the ClusterIP type and N Pods are created.

[0076] The Kubernetes-based multi-form software delivery apparatus according to the present invention will now be described in detail with reference to the accompanying drawings and a specific embodiment. It is to be understood that the following description is merely exemplary and should not be construed as a specific limitation of the invention.

[0077] like Figure 2 As shown, the Kubernetes-based multi-form software delivery device architecture mainly consists of three parts:

[0078] The business software packaging tool is primarily responsible for packaging business software according to a unified format. The packaged file name format is as follows: software name-version number-CPU architecture.zip. It mainly uses two packaging modes:

[0079] Traditional deployment methods mainly encapsulate the following: software entities, software configuration, software startup scripts, uninstallation scripts, and software deployment description files (CPU, memory, ports, service instances, etc.).

[0080] Kubernetes deployment software encapsulation mainly involves encapsulating the following: software entities, software configuration, software startup scripts, uninstallation scripts, and software deployment description files (CPU, memory, ports, service instances, log paths, data paths, etc.).

[0081] The business software deployment and delivery component is primarily responsible for supporting various software delivery methods and ultimately deploying the software to a physical (VM) cluster or a Kubernetes cluster.

[0082] The deployment methods are divided into traditional deployment and Kubernetes deployment. The deployment scheduler sends deployment instructions to either the traditional deployment executor or the Kubernetes deployment executor based on the delivery type of the software to be deployed, thus deploying the software on the target server cluster. Both traditional and Kubernetes deployments require creating Service resources for the software to be deployed. If the software is deployed using Kubernetes, N ClusterIP-type Services and N Pod resources need to be created, with each Service associated with a Pod. If the software is deployed using the traditional method, N ClusterIP-type Service resources and N Endpoints (setting the IP address and port of the service instance) need to be created.

[0083] The software access control module primarily provides web services, such as enabling access permissions for deployed software API interfaces and updating the access weights of business software service instances.

[0084] The domain name module primarily provides domain name resolution and registration capabilities for business software deployed in physical, VM server clusters, and Kubernetes clusters.

[0085] The load balancing module can use NGINX as the load balancer, which can be deployed in a Kubernetes cluster. A NodePort type Service resource and a Pod resource are created for it; the main use is NGINX's load balancing and forwarding capabilities.

[0086] Infrastructure clusters are mainly divided into two categories: physical (VM) server clusters and Kubernetes clusters. Infrastructure clusters provide the environment and operating resources for the business software to be deployed, including resources such as CPU, memory, ports, disks, and bandwidth.

[0087] like Figure 1 As shown, the main core processes of the multi-form software delivery device include:

[0088] The deployment scheduler's scheduling algorithm creates a dependency topology structure for the business software to be deployed based on the scheduling policy; this dependency topology structure can be cached in memory or a relational database.

[0089] The deployment scheduler obtains the list of software that can be deployed directly from the dependency topology (i.e., a certain software can be installed directly without depending on other software) and transmits it to the deployment task distributor.

[0090] The deployment task distributor selects software sequentially from the list of software that can be deployed directly, and sends software installation commands to different deployers according to the deployment mode of the software.

[0091] Based on the software deployment method:

[0092] If the software to be installed was deployed using the traditional deployment method, then:

[0093] The target server node list for the software to be installed is obtained through a deployment node algorithm; the target server node can be selected based on resource indicators such as CPU, memory, disk space, and CPU architecture.

[0094] Send software pull commands and software startup script commands to the deployment agent on the target server node;

[0095] The software startup results are fed back to the deployment scheduler in real time;

[0096] If the software to be installed is deployed via Kubernetes, then:

[0097] Create N ClusterIP type Services and N Pods; the relationship between Services and Pods is 1:1, a one-to-one association;

[0098] Kubernetes clusters automatically calculate target server nodes and automatically pull the software to be installed;

[0099] Monitor the status of the Pod and provide real-time feedback to the deployment scheduler;

[0100] The deployment scheduler sends a service access permission request to the service instance access controller;

[0101] The service instance access controller (i.e., the software access control module) will determine whether the service access permissions to be set are deployed through the traditional deployment method; if they are deployed through the traditional deployment method, then N ClusterIP type Service resources and N Endpoint resources need to be created (the Endpoint needs to be set to the physical or VM IP occupied when the software starts).

[0102] Construct N pairs of strings such as "serviceName: software's Port", domain name, and service name, render them into the upstream and server modules in the nginx.conf configuration file, and set a default weight of 1 for each server.

[0103] Send the hot reload command `nginx -s reload` to the load balancer NGINX to make its latest nginx.conf configuration take effect immediately.

[0104] Register the software's domain name information with a domain name server;

[0105] The above process allows support personnel to install both traditionally deployed software and Kubernetes-deployed software simultaneously; client access to software services and communication between software programs are all done via domain names, improving the reliability of software access.

[0106] The following reference Figure 3 A detailed introduction to the business software deployment and delivery components is provided.

[0107] The deployment scheduler primarily generates a dependency topology structure for the software to be deployed based on a scheduling algorithm, and then deploys the business software to be installed sequentially according to this dependency topology structure. This module is mainly divided into:

[0108] Deployment strategies are mainly divided into singleton deployment, cluster deployment, and canary deployment;

[0109] The scheduling algorithm calculates the dependency topology of the software to be deployed. The main process of the scheduling algorithm is as follows: (Assume the name of the software to be deployed is ZHGL)

[0110] The software dependency topology can be stored using a combination of dictionary and list types: (key represents the software name; value represents the name of the software that this software depends on for startup, but which is not currently running); See the example below:

[0111] <ZHGL,[SCTB,RZ]>

[0112] <SCTB,[MYSQL]>

[0113] <MYSQL,[]>

[0114] <RZ,[]>

[0115] Get a list of software that can be launched directly (concurrent launch is possible);

[0116] Traverse the structure above and check which keys have empty values. Empty values ​​indicate that the software does not depend on other software and can be launched directly. The results are as follows:

[0117] [MySQL, RZ]

[0118] The software startup results show that MySQL and RZ have started successfully.

[0119] Update the dependency topology;

[0120] The current dependency storage result is: (Delete the successfully deployed software and retrieve the dependencies again)

[0121] <ZHGL,[SCTB]>

[0122] <SCTB,[]>

[0123] Reacquire the list of software that can be launched directly (concurrent launch is possible);

[0124] [SCTB]

[0125] Start the list of currently available software; repeat this process until all software is deployed.

[0126] The deployment task dispatcher obtains the specific software to be deployed, and constructs a deployment command based on the software delivery form, which is then delivered to the designated deployer for deployment.

[0127] The business software dependency topology stores the dependencies of the business software to be deployed; this topology changes dynamically as deployment progresses. It can be cached and stored in a relational database like MySQL.

[0128] Deployers (or deployment executors) are mainly divided into traditional deployment and Kubernetes deployment; they are used to deploy business software to the target server cluster.

[0129] The domain name service module provides domain name resolution for business software. Business software communicates with each other and clients access business software through domain names. Domain name access between business software improves its portability and reliability; this can be implemented using the open-source software CoreDN.

[0130] The service access control module is mainly divided into two parts: the service instance access controller and the load balancer. The service instance access controller mainly provides web services, such as providing access API interfaces for service instances of business software, updating access weights for service instances of business software, and rendering the latest NGINX configuration file nginx.conf. The load balancer mainly performs traffic forwarding for client access to service instances of business software, which can be implemented using NGINX software.

[0131] The service instance access controller and load balancer NGINX can be managed and maintained by the Kubernetes cluster; for example, the service instance access controller and load balancer NGINX can be encapsulated in a Pod and a NodePort type Service resource can be created to provide access requests to the outside world.

[0132] Figure 4The diagram shows the device architecture relied upon for traditional deployment methods. This architecture mainly consists of the following parts:

[0133] The deployment scheduler is primarily responsible for scheduling the execution of deployment node algorithms, deployment executors, and deployment status; it schedules different services based on the installation progress of the business software. The deployment scheduler obtains the target installation node list from the deployment node algorithm, downloads deployment instructions to the deployment executor, and issues listening instructions to the deployment status listener.

[0134] Traditional deployment executors are mainly responsible for issuing software retrieval instructions to the agents on server nodes, calling the startup scripts and stop scripts of business software, etc.

[0135] The deployment status listener is mainly responsible for monitoring the deployment status of the business software and providing timely feedback to the deployment scheduler.

[0136] Deployment node algorithm; obtain the current server cluster resource status from the resource listener; according to the resource scheduling algorithm, obtain a specified number of nodes from the server nodes that meet the requirements; feed back to the deployment scheduler; indicators that the resource scheduling algorithm can refer to; such as the number of available CPU cores of the current node, the amount of memory remaining of the current node, the CPU architecture type, etc.

[0137] Business software repository; primarily stores business software; a distributed file system, such as HDFS, can be used as the repository for business software.

[0138] Resource monitoring controller; provides API interface to deployment node algorithm; receives resource status reported by resource listener, processes the resource status and reports it to deployment node algorithm.

[0139] Resource Listener: Monitors resources on server nodes and reports them periodically; it needs to be installed on each node; the resources monitored mainly include: number of available CPU cores, currently available memory, current CPU architecture, etc.

[0140] Execution agent; receives instructions to deploy the executor; needs to be installed on each server node; mainly includes:

[0141] Pull command: Pull the specified business software from the business software repository to the local machine;

[0142] Startup command; invokes the startup script of the business software;

[0143] Stop command; invokes the stop script of the business software.

[0144] like Figure 5 As shown, the main processes for deployment in the traditional method include:

[0145] The deployment scheduler sends a request to the deployment node algorithm service to obtain a list of destination nodes to be installed;

[0146] The deployment node algorithm obtains the current resource status of the server cluster from the resource monitoring controller, calculates the list of destination nodes for the software to be installed in real time according to the resource scheduling algorithm strategy, and feeds it back to the deployment scheduler.

[0147] The deployment scheduler sends deployment request commands to the deployment executor and installation process monitoring instructions to the deployment status listener;

[0148] Traditional deployment executors send business software retrieval instructions to the execution agent on the target node server in sequence according to the target node list;

[0149] After receiving the business software pull instruction, the execution agent on the target node pulls the specified software from the business software repository and feeds back the pull result to the traditional deployment executor.

[0150] After receiving the feedback result from the execution agent, the traditional deployment executor sends a startup script command to the execution agent of the target node;

[0151] The deployment status listener provides real-time feedback on the execution progress of the target node to the deployment scheduler. The deployment scheduler then schedules different services to respond based on the installation progress of the business software.

[0152] Figure 6 This is a diagram illustrating the architecture required for a Kubernetes deployment. The Kubernetes deployment architecture includes:

[0153] The deployment scheduler is primarily responsible for scheduling and executing deployment executors and deployment status; it also schedules different services based on the installation progress of the business software.

[0154] The Kubernetes deployment executor is primarily responsible for creating the deployment model; that is, it creates N ClusterIP-type Services and N Pods based on the received deployment instructions; the relationship between Service and Pod is no longer 1:N, but 1:1.

[0155] The deployment process listener is primarily responsible for monitoring the installation status of Pods and providing real-time feedback on the installation status to the deployment scheduler.

[0156] A Kubernetes cluster is primarily responsible for providing the runtime environment for the software to be installed, including CPU, memory, disk, and the selection of the target node to be installed, etc.

[0157] like Figure 7 As shown, the main deployment process using Kubernetes includes:

[0158] The deployment scheduler sends deployment instructions for the software to be installed to the deployment executor; the main parameters include: the name of the software to be installed, the version number, the number of software instances to be installed, and the running resources (CPU, memory, disk, etc.).

[0159] The Kubernetes deployment executor creates N ClusterIP-type Service resources and N Pod resources according to the creation instructions, and then feeds back the execution results to the deployment scheduler.

[0160] The deployment scheduler sends deployment status monitoring commands to the deployment process listener; the main parameters include: service namespace, list of Pod names, etc.

[0161] The deployment process listener monitors the status of each Pod based on the list of Pod names and feeds back the Pod status to the deployment scheduler.

[0162] The deployment scheduler registers the software's domain name with a domain name server so that clients can access and query it.

[0163] like Figure 8 As shown, the main workflow of the software access control module includes:

[0164] After receiving a service access request, the main parameters of the access request include N serviceName:Port, software domain name and corresponding N weights, deployment type (traditional deployment or Kubernetes deployment), etc.

[0165] Determine whether the software to be installed was deployed in a traditional manner;

[0166] If deployed in the traditional way, it is necessary to create N additional ClusterIP type Service resources and N Endpoint resources so that when accessing through the Service, traffic can be forwarded to the software service instance in the physical (VM) server cluster.

[0167] Service instance access control renders service access request parameters, such as N serviceName:Port values, into the nginx.conf configuration template based on the template. Alternatively, it renders them into the upstretch module to achieve load balancing across N Pod service instances. The nginx.conf configuration template is shown below:

[0168]

[0169]

[0170] The actual rendering can be performed using the template package in the Go language.

[0171] ClusterName represents the software name; Path represents the request path; DomainName represents the software domain name; Url represents the request address, in the format: serviceName:port of the software to be installed; WeightValue represents the weight of this service instance being accessed, with a default value of 1; Servers represents an object containing resources such as url and WeightValue, and its type is a list (array); the upstream module mainly stores N serviceName:port of the software to be installed; that is, the access address of the software's service instance, except that it is not a real IP address, but the name of the Service resource:port of the software to be installed;

[0172] Service instance access control sends the latest nginx.conf configuration file to the load balancer nginx software;

[0173] The service instance access controller sends a hot reload command to the load balancer; for example, nginx -s reload, to make its latest configuration file take effect.

[0174] The following reference Figure 9 This section describes the process of accessing the software's backend service via a client such as a browser. The load balancer in the diagram is maintained within a Kubernetes cluster; it creates a NodePort type Service resource. The NGINX software can be run as a standalone Pod or managed by a Deployment resource. Therefore, access to the NGINX process can be achieved through the external IP address of the Master node in the Kubernetes cluster, in the form of NodePort. The main process is as follows:

[0175] Local clients need to configure the domain name server address in advance; for example, in CentOS 7.5, the DNS address can be set in the / etc / resolv.conf file, and the external address of the Kubernetes cluster's master node can be registered in it.

[0176] Clients such as browsers send service requests to the software in the form of "software domain name:NGINX service NodePort port";

[0177] After the client initiates a service request via a domain name, it will automatically send a domain name resolution request to the DNS service.

[0178] The client request obtains the actual request IP address (e.g., the external IP address of the Master node in a Kubernetes cluster) through the domain name resolver;

[0179] The client request will send a request to NGINX; after receiving the client request in the Kubernetes cluster, the NGINX Service resource will forward the client's request traffic to the NGINX Pod service instance according to the Linux iptables rules;

[0180] When a Pod service instance of the NGINX software in a Kubernetes cluster receives a request, it will select an appropriate server address for forwarding based on the service instance list in the upstream module of the nginx.conf configuration file, and according to the access policy, such as access weight. At this point, it has obtained the Service resource of the backend service instance.

[0181] When NGINX forwards based on the list of service instances in the upstream:

[0182] If the selected target Service resource is software deployed via Kubernetes, then client request traffic will be forwarded from the Service resource to the target Pod service instance of the software; that is, the client's request will ultimately be forwarded to the target service instance.

[0183] If the selected target Service resource is software deployed using traditional deployment methods, then client request traffic will be automatically associated with and queried to the corresponding Endpoint resource by the Service resource; the specific IP address of the software installation (the IP address in the physical VM cluster) will be obtained from the Endpoint resource; thus, the client request can be forwarded to it.

[0184] Figure 10 This is a flowchart illustrating the main flow of communication between software deployed using traditional methods and software deployed using Kubernetes. Regardless of whether the software is deployed using Kubernetes or traditional methods, communication between the software may involve the following scenarios:

[0185] Inter-application communication between application software within a Kubernetes cluster;

[0186] Inter-access between business software in physical and VM clusters;

[0187] Inter-domain communication between application software in a Kubernetes cluster and application software in physical and VM clusters;

[0188] Regardless of the access method, the overall access process is the same;

[0189] First, obtain the IP address corresponding to the software domain name through the DNS server;

[0190] Secondly, the underlying system will re-render the latest request address when the client requests it; that is, IP address: NGINX NodePort; and automatically initiate the latest request.

[0191] Secondly, after the NodePort of the NGINX Service resource receives a client request, it will automatically forward the client request traffic to the Pod resource containing the NGINX process according to the iptables rules. The NGINX process in the Pod will look up the relevant upstream load balancer list in the nginx.conf configuration file according to the software name and domain name, and select an appropriate server address for forwarding based on the weight.

[0192] Finally, NGINX forwards the client request to a server in the upstream module, that is, to the Service resource of the target software. The Service resource of the target software will automatically forward the client request traffic to the Pod containing the target software for response according to iptables rules, or will automatically forward the client request traffic to a node in the physical or VM service cluster where the software is installed for response according to iptables rules.

[0193] The main objectives and advantages of this invention are as follows: 1. When the list of business software to be deployed has multiple deployment methods (some software is deployed via Kubernetes, some via traditional methods, etc.), installation instructions can be sent to different deployment executors according to the deployment method of the software. This allows for the rapid, simultaneous, and batch installation of business software with different deployment methods, thus accelerating the software installation process for support personnel and reducing the need for them to understand the business software. 2. Accessing business software via software domain names improves the reliability of communication between business software deployed via Kubernetes and business software deployed via traditional methods. For example, changes in the service instance IP of a business software will not affect client access.

[0194] It should be noted that the above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

[0195] It should be noted that any content not described in detail in this specification is common knowledge to those skilled in the art.

[0196] This invention also proposes a multi-form software delivery method based on Kubernetes, including:

[0197] Obtain the software to be deployed, and deploy the software to a physical, VM server cluster, or Kubernetes cluster according to the delivery type of the software to be deployed: For traditional delivery methods, select a target server node and send software pull instructions, software start script instructions, and software stop script instructions to the deployment agent on the target server node; For Kubernetes delivery methods, create Pods and corresponding ClusterIP type Services, and implement deployment through the Kubernetes cluster;

[0198] Create a ClusterIP type Service and corresponding Endpoints for software deployed using traditional delivery methods. The Endpoints are set to the physical or VM IP address used when the software starts.

[0199] After constructing the string "serviceName: software's Port", domain name, and service name for the software to be deployed, it is rendered into the upstream and server modules in the nginx.conf configuration file, and the weight is set and updated for each service.

[0200] Apply the current nginx.conf configuration and register the domain name information of the software to be deployed. All software access and client access to the software will be conducted through the domain name.

[0201] This invention also proposes a computer-readable storage medium storing an implementation program for information transmission, which, when executed by a processor, implements the steps of the Kubernetes-based multi-form software delivery method as described above.

[0202] It should be noted that the computer-readable storage medium described in this embodiment includes, but is not limited to, ROM, RAM, disk, or optical disk. The processor can be a mobile phone, computer, server, air conditioner, or network device, etc.

[0203] In this invention, the use of suffixes such as "module" and "device" to denote elements is solely for illustrative purposes and has no specific meaning in itself. Therefore, "module" and "device" can be used interchangeably. For example, "load balancing module" and "load balancer" have the same meaning, and "domain name service module" and "domain name server" have the same meaning.

[0204] The terms “comprising,” “including,” or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase “comprising one…” does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0205] Any reference sign enclosed in parentheses should not be construed as limiting the claims. The word "a" or "an" preceding an element does not exclude the existence of multiple such elements. "And / or" describes the relationship between related objects, indicating that three relationships can exist; for example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

Claims

1. A multi-form software delivery device based on Kubernetes, characterized in that, include: Deployment module, software access control module, load balancing module, domain name service module; The deployment module is used to acquire the software to be deployed and deploy it to a physical server cluster, VM server cluster, or Kubernetes cluster according to the delivery type of the software: for traditional delivery methods, it selects a target server node and sends software pull instructions, software start script instructions, and software stop script instructions to the deployment agent on the target server node; for Kubernetes delivery methods, it creates a Pod and a corresponding ClusterIP type Service, and deploys it through the Kubernetes cluster; it is also used to send service access permission requests to the software access control module. The software access control module is used to create ClusterIP type Services and corresponding Endpoints for software deployed using traditional delivery methods. The Endpoints are set to the physical or VM IP address used by the software at startup. The module also constructs a string in the form of serviceName: software Port, domain name, and service name for the software to be deployed, and renders it into the upstream and server modules of the nginx.conf configuration file. It also sets and updates the weight for each Service. Furthermore, the module sends a hot-load command `nginx -sreload` to the load balancing module, enabling the load balancing module to apply the current nginx.conf configuration, and registers the domain name information of the software to be deployed with the domain name service module. The load balancing module is implemented using NGINX software and is used to forward traffic to the service instances of the client access software. The domain name service module is used to provide domain name resolution for the software to be deployed. The deployed software and the client access the software all use domain names to access the service. The deployment module includes a deployment scheduler, a traditional deployment executor, a Kubernetes deployment executor, and a resource monitoring controller; The deployment scheduler is used to obtain all software to be deployed, create a dependency topology structure for all software to be deployed, determine software suitable for direct deployment based on the dependency topology structure, and sequentially call the traditional deployment executor and / or the Kubernetes deployment executor to deploy the software according to the delivery type of these software. The dependency topology reflects the dependencies between the software to be deployed and the startup status of the software to be deployed; The software suitable for direct deployment is software that does not currently depend on other software and is suitable for direct installation; The conventional deployment executor is used to send software pull instructions, software start script instructions, and software stop script instructions to the deployment agent on the target server node. The Kubernetes deployment executor is used to create Pods and corresponding ClusterIP-type Services, and automatically calculates the target server nodes and pulls the software to be deployed through the Kubernetes cluster. The resource monitoring controller is used to collect the resource status of server nodes, including the number of available CPU cores, the amount of memory remaining, and the CPU architecture type. The deployment scheduler is also used to determine the target server node based on the currently acquired resource status of the server node.

2. The Kubernetes-based multi-form software delivery device as described in claim 1, characterized in that, The multi-form software delivery device also includes: Business software packaging tools are used to package software entities, software configurations, software startup scripts, uninstallation scripts, and software deployment description files into software to be deployed. For software deployed using traditional methods, the software deployment description file includes CPU, memory, ports, and service instances; For software deployed using Kubernetes, the software deployment description file includes CPU, memory, port, service instance, log path, and data path.

3. The Kubernetes-based multi-form software delivery device as described in claim 1, characterized in that, The deployment module also includes: A deployment status listener is used to monitor the deployment process status of the software and the installation status of the Pods, and to provide timely feedback to the deployment scheduler.

4. The Kubernetes-based multi-form software delivery device as described in claim 1, characterized in that, The domain name service module is implemented using the Coredns open-source software.

5. The Kubernetes-based multi-form software delivery device as described in claim 1, characterized in that, The software access control module and the load balancing module are encapsulated within a single Pod, and access requests are provided externally through a Service resource of type NodePort.

6. The Kubernetes-based multi-form software delivery device as described in claim 1, characterized in that, The deployment strategies for the software to be deployed include singleton deployment, cluster deployment, and canary deployment.

7. The Kubernetes-based multi-form software delivery device as described in claim 1, characterized in that, Each Pod corresponds one-to-one with a Service of the ClusterIP type.

8. A multi-form software delivery method based on Kubernetes, characterized in that, include: Obtain the software to be deployed, and deploy the software to a physical, VM server cluster, or Kubernetes cluster according to the delivery type of the software to be deployed: For traditional delivery methods, select a target server node and send software pull instructions, software start script instructions, and software stop script instructions to the deployment agent on the target server node; For Kubernetes delivery methods, create Pods and corresponding ClusterIP type Services, and implement deployment through the Kubernetes cluster; Create a ClusterIP type Service and corresponding Endpoints for software deployed using traditional delivery methods. The Endpoints are set to the physical or VM IP address used when the software starts. After constructing a string in the form of serviceName:the software's Port, domain name, and service name for the software to be deployed, the results are rendered into the upstream and server modules in the nginx.conf configuration file, and weights are set and updated for each service. Apply the current nginx.conf configuration and register the domain name information of the software to be deployed. All software access and client access to the software will be conducted through the domain name. Forward traffic for the service instance of the client access software; It provides domain name resolution for the software to be deployed, and the deployed software and the client access the software all use domain names to access services; Obtain all software to be deployed and create a dependency topology for all software to be deployed. Based on the dependency topology, determine the software suitable for direct deployment and deploy the software by calling the traditional deployment executor and / or the Kubernetes deployment executor in sequence according to the delivery type of these software. The dependency topology reflects the dependencies between the software to be deployed and the startup status of the software to be deployed; The software suitable for direct deployment is software that does not currently depend on other software and is suitable for direct installation; Send software pull commands, software start script commands, and software stop script commands to the deployment agent on the target server node; Create Pods and corresponding ClusterIP-type Services, and automatically calculate the target server nodes and pull the software to be deployed through the Kubernetes cluster; Collect the resource status of server nodes, including the number of available CPU cores, the amount of memory remaining, and the CPU architecture type; The target server node is determined based on the currently acquired resource status of the server node.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores an implementation program for information transmission, which, when executed by a processor, implements the steps of the Kubernetes-based multi-form software delivery method as described in claim 8.

Images