CN115016862A - Kubernetes cluster-based software starting method, device, server and storage medium - Google Patents
Kubernetes cluster-based software starting method, device, server and storage medium Download PDFInfo
- Publication number
- CN115016862A CN115016862A CN202210692824.4A CN202210692824A CN115016862A CN 115016862 A CN115016862 A CN 115016862A CN 202210692824 A CN202210692824 A CN 202210692824A CN 115016862 A CN115016862 A CN 115016862A
- Authority
- CN
- China
- Prior art keywords
- software
- configmap
- operation unit
- configuration file
- minimum operation
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 80
- 230000008569 process Effects 0.000 abstract description 16
- 238000010586 diagram Methods 0.000 description 8
- 238000004590 computer program Methods 0.000 description 6
- 238000007726 management method Methods 0.000 description 4
- 238000004891 communication Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000014509 gene expression Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44568—Immediately runnable code
- G06F9/44578—Preparing or optimising for loading
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
The application relates to the technical field of internet, and discloses a software starting method, a device, a server and a storage medium based on a Kubernetes cluster, wherein the method comprises the following steps: after a Kubernetes cluster acquires a project file corresponding to certain software, a minimum operation unit is established, and the project file is deployed in the minimum operation unit; acquiring a ConfigMap configuration file corresponding to the software from a ConfigMap storage space, and loading the ConfigMap configuration file corresponding to the software on a minimum operation unit; and acquiring a ConfigMap configuration file corresponding to the software from the minimum operation unit so as to start the software. By means of the method and the device, the ConfigMap configuration file corresponding to the software is loaded in the minimum operation unit, so that the ConfigMap configuration file is directly read from the minimum operation unit in the starting process of the software.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to a Kubernetes cluster-based software boot method, apparatus, server, and storage medium.
Background
Kubernetes, K8s for short, is an abbreviation for 8 replacing the 8 characters "ubernet" in the middle of the name. Kubernets is an open source application for managing containerization on multiple hosts in a cloud platform, the goal of kubernets is to make deploying containerization applications simple and efficient, and kubernets provides a mechanism for application deployment, planning, updating, and maintenance.
ConfigMap serves as a configuration resource for kubernets. The method comprises the following steps of: the value form is stored in the kubernets system for use by applications, and can be used to represent either the value of a variable or the contents of a complete configuration file.
At present, after software development is completed, engineering files of software are submitted to Kubernets cluster for management, and the Kubernets are responsible for distributing hardware resources to run the engineering files of the software, so that the purpose of running the software is achieved. Normally, the parameters of the software are configured in the ConfigMap configuration file, and the ConfigMap configuration file is loaded when the software is started, so that the software is started.
However, since the ConfigMap configuration file is usually stored in the ConfigMap storage space of Kubernetes, the ConfigMap configuration file needs to be downloaded from the ConfigMap storage space when the software is started, which causes inefficient loading of the configuration file and affects the efficiency of software startup.
Disclosure of Invention
The embodiment of the application provides a Kubernets cluster-based software starting method, a Kubernets cluster-based software starting device, a Kubernets cluster-based software starting server and a storage medium, so that the loading efficiency of a ConfigMap configuration file is improved, and the software starting efficiency is improved.
In a first aspect, an embodiment of the present application provides a software starting method based on a kubernets cluster, where the method includes:
after a Kubernetes cluster acquires a project file corresponding to certain software, a minimum operation unit is established, and the project file is deployed in the minimum operation unit;
acquiring a ConfigMap configuration file corresponding to the software from a ConfigMap storage space, and loading the ConfigMap configuration file corresponding to the software on a minimum operation unit;
and acquiring a ConfigMap configuration file corresponding to the software from the minimum operation unit so as to start the software.
In some embodiments, creating a minimal execution unit includes:
and creating a minimum operation unit corresponding to the software according to the operation parameters of the software, wherein the operation parameters of the software comprise hard disk parameters, the minimum operation unit corresponds to a hard disk space, and the size of the space corresponding to the hard disk space is not less than that of the space corresponding to the hard disk parameters.
In some embodiments, deploying the engineering file to the minimal execution unit includes:
and storing the project file to a hard disk space corresponding to the minimum operation unit.
In some embodiments, the loading the ConfigMap configuration file corresponding to the software to the minimum execution unit includes:
and storing the ConfigMap configuration file into a hard disk space corresponding to the minimum operation unit, wherein the ConfigMap configuration file corresponds to a preset path of the hard disk space, and the preset path is stored in an attribute file in an engineering file corresponding to software.
In some embodiments, acquiring a ConfigMap configuration file corresponding to the software from the minimum running unit to start the software includes:
the method comprises the steps that an engineering file corresponding to software is operated in a minimum operation unit, and a preset path of a hard disk space corresponding to the minimum operation unit is obtained from an attribute file in the engineering file corresponding to the software;
acquiring a ConfigMap configuration file corresponding to software according to a preset path of a hard disk space corresponding to a minimum operation unit;
and reading the configuration parameters in the ConfigMap configuration file, and loading the configuration parameters into the context of the software to start the software.
In some embodiments, the method further comprises:
and when the ConfigMap configuration file is updated, automatically acquiring the updated ConfigMap configuration file, and deploying the updated ConfigMap configuration file in the minimum operation unit.
In some embodiments, the engineering file corresponding to the software is obtained by developing through a Quarkus framework, and the engineering file corresponding to the software includes a Docker image file.
In a second aspect, an embodiment of the present application provides a software starting apparatus based on a kubernets cluster, including:
the engineering file module is used for creating a minimum operation unit after the Kubernets cluster acquires an engineering file corresponding to certain software, and deploying the engineering file in the minimum operation unit;
the configuration file module is used for acquiring a ConfigMap configuration file corresponding to the software from the ConfigMap storage space and deploying the ConfigMap configuration file corresponding to the software in the minimum operation unit;
and the software starting module is used for acquiring the ConfigMap configuration file corresponding to the software from the minimum operation unit so as to start the software.
In a third aspect, an embodiment of the present application provides a server, including:
at least one processor; and
a memory communicatively coupled to the at least one processor; wherein,
the memory stores instructions executable by the at least one processor to enable the at least one processor to perform a kubernets cluster based software start-up method as in the first aspect.
In a fourth aspect, embodiments of the present application provide a non-transitory computer-readable storage medium storing computer-executable instructions for causing a server to perform the kubernets cluster-based software boot method according to the first aspect.
In a fifth aspect, embodiments of the present application provide a computer program product comprising computer program instructions that, when read and executed by one or more processors, perform the kubernets cluster-based software boot method as described above.
In an embodiment of the present application, by providing a software boot method, device, server, and storage medium based on a kubernets cluster, the method includes: after a Kubernetes cluster acquires a project file corresponding to certain software, a minimum operation unit is established, and the project file is deployed in the minimum operation unit; acquiring a ConfigMap configuration file corresponding to the software from a ConfigMap storage space, and loading the ConfigMap configuration file corresponding to the software on a minimum operation unit; and acquiring a ConfigMap configuration file corresponding to the software from the minimum operation unit so as to start the software. By means of the method and the device, the ConfigMap configuration file corresponding to the software is loaded in the minimum operation unit, so that the ConfigMap configuration file is directly read from the minimum operation unit in the starting process of the software.
Drawings
One or more embodiments are illustrated by way of example in the accompanying drawings, which correspond to the figures in which like reference numerals refer to similar elements and which are not to scale unless otherwise specified.
Fig. 1 is a schematic structural diagram of a kubernets cluster provided in an embodiment of the present application;
fig. 2 is a schematic structural diagram of another kubernets cluster provided in the embodiment of the present application;
FIG. 3 is a schematic flowchart of software boot provided by an embodiment of the present application;
fig. 4 is a schematic flowchart of a software starting method based on a Kubernetes cluster according to an embodiment of the present application;
FIG. 5 is a detailed flowchart of step S403 in FIG. 4;
fig. 6 is a schematic overall flow chart of a software starting method based on a Kubernetes cluster according to an embodiment of the present application;
fig. 7 is a schematic diagram of a software startup device based on a kubernets cluster according to an embodiment of the present application;
fig. 8 is a schematic structural diagram of a server according to an embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
It should be noted that, if not conflicted, the various features of the embodiments of the present application may be combined with each other within the scope of protection of the present application. Additionally, while functional block divisions are performed in device schematics, with logical sequences shown in flowcharts, in some cases, steps shown or described may be performed in a different order than the block divisions in devices, or in flowcharts. In addition, the words "first", "second", "third", and the like used herein do not limit the data and execution order, but merely distinguish the same items or similar items having substantially the same functions and actions.
Before the present application is explained in detail, terms and expressions referred to in the embodiments of the present application are explained, and the terms and expressions referred to in the embodiments of the present application are applied to the following explanations.
(1) The Kubernetes Cluster refers to a Cluster (Cluster) composed of a control Node (Master) and a load Node (Node), wherein the control Node (Master) is responsible for management and control of the whole Cluster. The control node (Master) usually occupies a separate server.
(2) A load Node, that is, a Node, refers to a physical host or a virtual machine in a Kubernetes cluster, a Node is a workload Node in the Kubernetes cluster, each Node may be assigned some workloads (Docker containers) by a Master, and when a certain Node is down, the workload on the Node may be automatically transferred to other nodes by the Master. Basic information of Node: name, label, creation time, etc.
(3) The smallest unit of execution, Pod, refers to the most basic deployment schedule element of kubernets, and may contain containers (containers), logically representing an instance of an application. Each Pod has a special Pause container called the "root container". The corresponding mirror image of the Pause container is part of the kubernets platform, and in addition to the Pause container, each Pod also contains one or more closely related user traffic containers.
Referring to fig. 1, fig. 1 is a schematic structural diagram of a kubernets cluster according to an embodiment of the present disclosure;
as shown in fig. 1, the kubernets cluster 100 includes a plurality of load nodes 110 and a plurality of control nodes 120, wherein each load node 110 is connected to at least one of the plurality of control nodes 120.
Specifically, each load node 110 is communicatively connected to the control node 120, and the load node 110 serves as a workload node in the kubernets cluster 100 to run a critical process. In the embodiment of the present application, the minimum operation unit operates in the load node 110.
Wherein, a plurality of control nodes 120 form a group of control nodes for taking charge of management and control of the whole kubernets cluster 100. It is to be understood that the number of the control nodes 120 in the embodiment of the present application may be one or more than two.
For an example, a kubernets cluster includes a control Node (Master) and two load nodes (nodes), please refer to fig. 2 again, and fig. 2 is a schematic structural diagram of another kubernets cluster provided in the embodiment of the present application;
as shown in fig. 2, the kubernets cluster 200 includes a control node 220, a first load node 211, and a second load node 212, wherein the first load node 211 and the second load node 212 are both communicatively connected to the control node 220.
Specifically, the first load node 211 includes two minimum operation units (Pod), which are a minimum operation unit 1 and a minimum operation unit 2, respectively, and each minimum operation unit is assigned a separate IP address, where the minimum operation unit 1 includes two containers (containers), which are a Container 1 and a Container 2; the minimum operating unit 2 comprises two containers (containers), Container 3 and Container 4 respectively.
Specifically, the second load node 212 includes two minimum operation units (Pod), which are a minimum operation unit 3 and a minimum operation unit 4, respectively, where the minimum operation unit 3 includes two containers (containers), which are a Container 1 and a Container 2; the minimum operation unit 4 includes two containers (containers), Container 3 and Container 4.
The ConfigMap serves as a configuration resource of Kubernets, and is expressed by one or more keys: the value form is stored in the kubernets system for use by applications, and can be used to represent either the value of a variable or the contents of a complete configuration file.
At present, after software development is completed, engineering files of software are submitted to Kubernets cluster for management, and the Kubernets are responsible for distributing hardware resources to run the engineering files of the software, so that the purpose of running the software is achieved. Normally, the parameters of the software are configured in the ConfigMap configuration file, and the ConfigMap configuration file is loaded when the software is started, so that the software is started.
Specifically, please refer to fig. 3, fig. 3 is a schematic flowchart of a software boot process according to an embodiment of the present application;
as shown in fig. 3, the software startup process includes:
step S301: starting software;
specifically, a minimum operation unit (Pod) starts a project file corresponding to the software, for example: docker mirror files.
Step S302: downloading a ConfigMap configuration file;
specifically, the minimum operation unit requests the ConfigMap storage space of the Kubernetes cluster to download the ConfigMap configuration file corresponding to the software.
Step S303: returning a ConfigMap configuration file;
specifically, the ConfigMap storage space returns the ConfigMap configuration file corresponding to the software to the minimum running unit.
Step S304: loading ConfigMap file contents;
specifically, the minimum running unit loads the file content of the ConfigMap configuration file corresponding to the software.
Step S305: starting normally;
specifically, the software starts normally.
It can be seen from the above steps that, in the starting process of software, the software needs to request the ConfigMap storage space of the Kubernetes cluster to download the ConfigMap configuration file corresponding to the software, but since the ConfigMap configuration file needs to be downloaded from the ConfigMap storage space when the software is started, the naming and path of the ConfigMap configuration file are limited, the loading efficiency of the configuration file is not high, and the software starting efficiency is affected.
Based on this, the embodiment of the application provides a software starting method based on a Kubernetes cluster, so as to improve the loading efficiency of a ConfigMap configuration file, and thus improve the efficiency of software starting.
Referring to fig. 4, fig. 4 is a schematic flowchart of a software startup method based on a kubernets cluster according to an embodiment of the present application;
the software starting method based on the Kubernetes cluster is applied to servers, and particularly, the execution main body of the software starting method based on the Kubernetes cluster is one or more than two processors of one or more than two servers.
As shown in fig. 4, the software booting method based on the kubernets cluster includes:
step S401: after a Kubernetes cluster acquires a project file corresponding to certain software, a minimum operation unit is established, and the project file is deployed in the minimum operation unit;
specifically, a developer completes software development on the basis of a Quarkus framework, and then packages environment (such as an operating system, JDK, and the like) files required by software operation after software compilation to generate engineering files corresponding to the software, for example: a Docker image file.
And then, submitting the engineering file corresponding to the software to a Kubernets cluster, and allocating hardware resources by the Kubernets cluster to create a minimum operation unit, such as: pod, and deploy the project file to the minimum unit of operation, for example: and deploying the Docker image file in the Pod to run the Docker image file on the Pod. It is understood that the minimum operating unit, for example: the Pod can be understood as a computer, which corresponds to hardware resources such as a memory space, a hard disk space, a CPU, and the like.
Specifically, creating a minimum run unit includes:
and creating a minimum operation unit corresponding to the software according to the operation parameters of the software, wherein the operation parameters of the software comprise hard disk parameters, the minimum operation unit corresponds to a hard disk space, and the size of the space corresponding to the hard disk space is not less than that of the space corresponding to the hard disk parameters.
For example: if the size of a hard disk required by the operation of certain software is 50GB, the hard disk parameters included in the operation parameters of the software are 50GB, at this time, the Kubernet cluster allocates a load node, the space size of the load node is larger than 50GB, the load node includes a server, namely, a server is allocated, and a minimum operation unit with a hard disk space not smaller than 50GB is created, wherein the minimum operation unit corresponds to a hard disk space, and the space size corresponding to the hard disk space is not smaller than the space size corresponding to the hard disk parameters. Preferably, the size of the space corresponding to the hard disk space is equal to the size of the space corresponding to the hard disk parameter, for example: if the hard disk parameters included in the operating parameters of the software are 50GB, the size of the hard disk space corresponding to the minimum operating unit is also 50 GB.
It is understood that the operating parameters of the software further include parameters such as memory space, computing power, and the like, wherein the computing power is characterized by the number of processors, for example: the number of Central Processing Units (CPUs).
By utilizing the operating parameters of the software and creating the minimum operating unit corresponding to the software, the engineering files corresponding to the software can be deployed in the minimum operating unit corresponding to the software, so that necessary operating conditions are provided for the software.
After the minimum operation unit is created, the engineering file is deployed in the minimum operation unit, specifically, the engineering file is deployed in the minimum operation unit, including:
and saving the project file to a hard disk space corresponding to the minimum operation unit.
Specifically, the engineering file includes a Docker image file, the minimum operation unit includes Pod, and the engineering file is stored in a hard disk space corresponding to the minimum operation unit, for example: and saving the Docker image file to a hard disk of the Pod.
The engineering file is deployed in the hard disk space corresponding to the minimum operation unit corresponding to the software, so that the operation parameters of the software can be matched, the operation of the software in the minimum operation unit is facilitated, and the operation efficiency of the software is improved.
Step S402: acquiring a ConfigMap configuration file corresponding to the software from a ConfigMap storage space, and loading the ConfigMap configuration file corresponding to the software on a minimum operation unit;
it will be appreciated that the ConfigMap storage space is a special storage volume in the kubernets cluster that is used to hold unencrypted data. In practical applications, configuration data is usually saved in the form of a ConfigMap configuration file, such as: configuration data required by the software project is assembled in a ConfigMap configuration file, which is then stored in the ConfigMap storage space of the kubernets cluster.
In the starting process of the software, a ConfigMap configuration file corresponding to the software needs to be acquired from a ConfigMap storage space, and the ConfigMap configuration file corresponding to the software needs to be loaded on the minimum operation unit.
Specifically, the loading the ConfigMap configuration file corresponding to the software to the minimum operation unit includes:
the ConfigMap configuration file is stored in a hard disk space corresponding to the minimum operation unit, and specifically, the ConfigMap configuration file is stored in a Container (Container) in the hard disk space corresponding to the minimum operation unit, where the ConfigMap configuration file corresponds to a preset path of the hard disk space, and the preset path is stored in an attribute file in an engineering file corresponding to software.
For example: mounting the ConfigMap configuration file into a Container (Container) of a minimum operation unit (Pod) through the configuration of a yaml file, wherein the preset path is stored in a property file in a project file corresponding to the software, such as: the engineering file is developed and obtained based on a Quarkus framework, the property file includes an application properties file, and the preset path is configured through path configuration parameters of the Quarkus framework, for example: configuring through a parameter of quarkus, beauerycamp, configmap, and after the configuration is completed, saving the preset path in an attribute file in the project file, for example: property file.
The ConfigMap configuration file is saved to the preset path of the hard disk space corresponding to the minimum operation unit, so that the ConfigMap configuration file can be acquired quickly, and the starting speed of software is increased.
Step S403: and acquiring a ConfigMap configuration file corresponding to the software from the minimum operation unit so as to start the software.
Specifically, referring to fig. 5 again, fig. 5 is a flowchart of step S403 in fig. 4;
as shown in fig. 5, the step S403: acquiring a ConfigMap configuration file corresponding to software from a minimum operation unit to start the software, wherein the ConfigMap configuration file comprises the following steps:
step S4031: the method comprises the steps that an engineering file corresponding to software is operated in a minimum operation unit, and a preset path of a hard disk space corresponding to the minimum operation unit is obtained from an attribute file in the engineering file corresponding to the software;
specifically, the process of operating the engineering file corresponding to the software in the minimum operation unit includes: decompressing the engineering file corresponding to the software in the hard disk space of the minimum operation unit, for example: a Docker image file.
The method includes the steps of decompressing an engineering file corresponding to the software to obtain an attribute file corresponding to the engineering file, and obtaining a preset path of a hard disk space corresponding to a minimum operation unit from the attribute file, for example: the property file comprises an application properties file, and the application properties file is used for storing a path of a ConfigMap configuration file corresponding to the software.
Step S4032: acquiring a ConfigMap configuration file corresponding to software according to a preset path of a hard disk space corresponding to a minimum operation unit;
specifically, according to a preset path of a hard disk space corresponding to the minimum operation unit, a ConfigMap configuration file corresponding to the software is obtained from the hard disk space of the minimum operation unit.
It can be understood that, since the minimum running unit runs on the load node, which is equivalent to locally acquiring the ConfigMap configuration file corresponding to the software, compared with a method that the ConfigMap configuration file needs to be downloaded in the ConfigMap storage space, the loading efficiency of the configuration file can be improved, so that the starting efficiency of the software is improved; moreover, the software release can conveniently use the configmap under the Kubernets environment, the requirement on the Kubernets environment is reduced, the relevant configuration of the configmap is more convenient to modify, operations such as recompilation and packaging of the software are not needed, and the Quarkus framework and the configmap can be better integrated.
On the other hand, because the kubernets cluster downloads the ConfigMap configuration file through a HyperText Transfer Protocol (HTTP), anonymous access needs to be opened in the kubernets environment, so that certain requirements are required for the kubernets environment, and a safety problem may exist.
Step S4033: and reading the configuration parameters in the ConfigMap configuration file, and loading the configuration parameters into the context of the software to start the software.
Specifically, after the ConfigMap configuration file is obtained, the configuration parameters in the ConfigMap configuration file are read, and the configuration parameters are loaded to the context of the software, where the software is developed through a Quarkus framework, that is, the engineering file corresponding to the software is developed through a Quarkus framework.
It is understood that the context of software refers to the collection of resources required in the running of the software, such as: when software of the Quarkus framework is started, all resources required by the software running process are stored in a context, wherein the context comprises configuration data, execution files and the relation among the resources.
Specifically, the context includes configuration resource files, such as: the configSource file loads the configuration parameters to the context of the software, and comprises the following steps: configuration resource files that save configuration parameters to context, such as: a configSource file. In the embodiment of the present application, the configuration resource file of the context is further used for including configuration data of the database, for example: database user name, password; a software name; monitored ports, etc.
It will be appreciated that after loading the configuration parameters into the context of the software, the target node launches the software, where the target node is the load node, which is the load node running the smallest unit of execution.
Referring to fig. 6, fig. 6 is a schematic overall flowchart of a software startup method based on a kubernets cluster according to an embodiment of the present application;
as shown in fig. 6, the overall process of the software startup method based on the kubernets cluster includes:
step S601: the Kubernetes cluster acquires a project file corresponding to the software;
specifically, a developer completes software development on the basis of a Quarkus framework, and then packages environment (such as an operating system, JDK, and the like) files required by software operation after software compilation to generate engineering files corresponding to the software, for example: and the Docker mirror image file issues the engineering file corresponding to the software to the Kubernets cluster, so that the Kubernets cluster acquires the engineering file corresponding to the software.
Step S602: the Kubernetes cluster creates a minimum operation unit;
specifically, the Kubernetes cluster creates a minimum operation unit corresponding to the software according to operation parameters of the software, wherein the operation parameters of the software include hard disk parameters, the minimum operation unit corresponds to a hard disk space, and the size of the space corresponding to the hard disk space is not less than the size of the space corresponding to the hard disk parameters.
It can be understood that the minimum operation unit is equivalent to a computer, and it has its own hardware resources such as memory, hard disk, CPU, etc., for example: the software operating parameters require 50GB of hard disk space, 10GB of memory, and 2 CPUs, so the Kubernetes cluster divides these resources into a minimum operating unit on the servers that meet the operating parameters, for example: and Pod. Wherein, the server meeting the operation parameter is a load node in a Kubernetes cluster.
Step S603: the Kubernetes cluster deploys the engineering files in a minimum operation unit;
specifically, the kubernets cluster deploys the engineering file in a minimum operation unit, where the minimum operation unit operates on the load node in the kubernets cluster, that is, the load node in the kubernets cluster determined in the above steps.
Step S604: the Kubernetes cluster requests a ConfigMap configuration file;
specifically, the Kubernetes cluster requests the ConfigMap configuration file corresponding to the software from the ConfigMap storage space.
It is understood that the user saves the content of the configuration file into the ConfigMap storage space, the file name can be used as key, value is the content of the whole file, and a plurality of configuration files can be put into the same ConfigMap storage space.
Step S605: the ConfigMap storage space returns a ConfigMap configuration file;
specifically, the ConfigMap storage space returns a ConfigMap configuration file to the kubernets cluster.
Step S606: the Kubernetes cluster stores a ConfigMap configuration file;
specifically, the Kubernetes cluster loads the ConfigMap configuration file corresponding to the software to the minimum operation unit, and includes:
the ConfigMap configuration file is stored in a hard disk space corresponding to the minimum operation unit, and specifically, the ConfigMap configuration file is stored in a Container (Container) in the hard disk space corresponding to the minimum operation unit, where the ConfigMap configuration file corresponds to a preset path of the hard disk space, and the preset path is stored in an attribute file in an engineering file corresponding to software.
For example: and mounting the ConfigMap configuration file into a Container (Container) of a minimum operation unit (Pod) through the configuration of a yaml file, wherein the preset path is stored in a property file in a project file corresponding to the software, such as: the engineering file is developed and obtained based on a Quarkus framework, the property file includes an application properties file, and the preset path is configured through path configuration parameters of the Quarkus framework, for example: configuring through a parameter of quarkus, beauerycamp-configmap, and saving the preset path in an attribute file in the project file after the configuration is completed, for example: property file.
Step S607: starting the project file by the minimum operation unit;
specifically, the engineering file corresponding to the minimum operation unit startup software includes: and decompressing the engineering file corresponding to the software to a hard disk space of a minimum operation unit, wherein the engineering file corresponding to the software comprises a Docker mirror image file.
Step S608: the minimum operation unit reads a ConfigMap configuration file;
specifically, the minimum operation unit reads the configuration parameters in the ConfigMap configuration file.
Step S609: the minimum operation unit loads the configuration parameters in the ConfigMap configuration file into the context of the software to start the software.
Specifically, the minimum running unit loads configuration parameters in the ConfigMap configuration file to a context of software, where the software is developed through a Quarkus framework, that is, an engineering file corresponding to the software is developed through the Quarkus framework.
In some embodiments, the method further comprises:
and when the ConfigMap configuration file is updated, automatically acquiring the updated ConfigMap configuration file, and deploying the updated ConfigMap configuration file in the minimum operation unit.
Specifically, after the content of the ConfigMap configuration file is modified, the kubernets cluster may automatically reacquire the content of the ConfigMap configuration file, and deploy the updated ConfigMap configuration file to the minimum operation unit, where the minimum operation unit operates on the target node, which is equivalent to updating the corresponding ConfigMap configuration file on the target node, where the target node refers to a load node corresponding to the ConfigMap configuration file.
In modeling a user's software or application or program, in a minimum unit of execution, for example: and the Pod defines the ConfigMap configuration file as a special storage volume for mounting. When the minimum operation unit is dispatched to a specific load Node (Node), the ConfigMap configuration file in the ConfigMap storage space is automatically restored to the local directory of the load Node and then mapped to the configuration directory specified by the minimum operation unit, so that the ConfigMap configuration file is read by software or application or program of a user in an imperceptible manner, and the software starting efficiency is improved.
It should be noted that, in the foregoing embodiments, a certain order does not necessarily exist between the foregoing steps, and it can be understood by those skilled in the art from the description of the embodiments of the present application that, in different embodiments, the foregoing steps may have different execution orders, that is, may be executed in parallel, may also be executed in an exchange manner, and the like.
In an embodiment of the present application, a kubernets cluster-based software starting method is provided, where the method includes: after a Kubernetes cluster acquires a project file corresponding to certain software, a minimum operation unit is established, and the project file is deployed in the minimum operation unit; acquiring a ConfigMap configuration file corresponding to the software from a ConfigMap storage space, and loading the ConfigMap configuration file corresponding to the software on a minimum operation unit; and acquiring a ConfigMap configuration file corresponding to the software from the minimum operation unit so as to start the software. By means of the method and the device, the ConfigMap configuration file corresponding to the software is loaded in the minimum operation unit, so that the ConfigMap configuration file is directly read from the minimum operation unit in the starting process of the software.
As another aspect of the embodiments of the present application, an embodiment of the present application provides a software starting apparatus based on a Kubernetes cluster. The software starting device based on the kubernets cluster can be a software module, the software module comprises a plurality of instructions, the instructions are stored in a memory, a processor can access the memory, and the instructions are called to execute the instructions, so that the software starting method based on the kubernets cluster, which is explained in the embodiments, is completed.
Referring to fig. 7, fig. 7 is a schematic diagram of a software startup device based on a kubernets cluster according to an embodiment of the present application;
the software starting device based on the Kubernetes cluster is applied to the server, and particularly, the software starting method based on the Kubernetes cluster is applied to one or more processors of one or more than two servers.
The software starting device based on the kubernets cluster can be a software module, the software module comprises a plurality of instructions, the instructions are stored in a memory, and a processor can access the memory and call the instructions to execute the instructions, so that the software starting method based on the kubernets cluster in the embodiments is completed.
As shown in fig. 7, the software startup device 70 based on kubernets cluster includes:
the engineering file module 701 is configured to create a minimum operation unit after the kubernets cluster obtains an engineering file corresponding to a certain software, and deploy the engineering file in the minimum operation unit;
a configuration file module 702, configured to obtain a ConfigMap configuration file corresponding to the software from a ConfigMap storage space, and deploy the ConfigMap configuration file corresponding to the software to the minimum running unit;
the software starting module 703 is configured to obtain a ConfigMap configuration file corresponding to the software from the minimum running unit, so as to start the software.
In the embodiment of the present application, the software starting apparatus based on the kubernets cluster may also be built by hardware devices, for example, the software starting apparatus based on the kubernets cluster may be built by one or more than two chips, and each chip may work in coordination with each other to complete the software starting method based on the kubernets cluster described in each embodiment. For another example, the kubernets cluster-based software starting device may also be constructed by various types of logic devices, such as a general processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a single chip, an arm (aconris cmachine) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination of these components.
The software starting device based on the kubernets cluster in the embodiment of the application can be a device, and can also be a component, an integrated circuit or a chip in a terminal. The device can be mobile electronic equipment or non-mobile electronic equipment. By way of example, the mobile electronic device may be a mobile phone, a tablet computer, a notebook computer, a palm top computer, a vehicle-mounted electronic device, a wearable device, an ultra-mobile personal computer (UMPC), a netbook or a Personal Digital Assistant (PDA), and the like, and the non-mobile electronic device may be a server, a Network Attached Storage (NAS), a Personal Computer (PC), a Television (TV), a teller machine or a self-service machine, and the like, and the embodiments of the present application are not particularly limited.
The software boot device based on the kubernets cluster in the embodiment of the present application may be a device with an operating system. The operating system may be an Android (Android) operating system, an ios operating system, or other possible operating systems, and embodiments of the present application are not limited specifically.
The software starting device based on the kubernets cluster provided in the embodiment of the present application can implement each process implemented in the embodiment of the method in fig. 4, and is not described here again to avoid repetition.
It should be noted that the software starting device based on the kubernets cluster can execute the software starting method based on the kubernets cluster provided in the embodiment of the present application, and has corresponding functional modules and beneficial effects of the execution method. For technical details that are not described in detail in the embodiments of the software startup device based on the kubernets cluster, reference may be made to the software startup method based on the kubernets cluster provided in the embodiments of the present application.
In an embodiment of the present application, a kubernets cluster-based software startup device is provided, where the device includes: the engineering file module is used for creating a minimum operation unit after the Kubernets cluster acquires an engineering file corresponding to certain software, and deploying the engineering file in the minimum operation unit; the configuration file module is used for acquiring a ConfigMap configuration file corresponding to the software from the ConfigMap storage space and deploying the ConfigMap configuration file corresponding to the software in the minimum operation unit; and the software starting module is used for acquiring the ConfigMap configuration file corresponding to the software from the minimum operation unit so as to start the software. By means of the method and the device, the ConfigMap configuration file corresponding to the software is loaded in the minimum operation unit, so that the ConfigMap configuration file is directly read from the minimum operation unit in the starting process of the software.
Referring to fig. 8 again, fig. 8 is a schematic structural diagram of a server according to an embodiment of the present disclosure;
as shown in fig. 8, the server 80 includes one or more processors 801 and memory 802. In fig. 8, one processor 801 is taken as an example.
The processor 801 and the memory 802 may be connected by a bus or other means, such as by a bus in fig. 8.
The memory 802 is used as a non-volatile computer-readable storage medium and can be used for storing non-volatile software programs, non-volatile computer-executable programs, and modules, such as program instructions/modules corresponding to the kubernets cluster-based software booting method in the embodiment of the present application. The processor 801 executes various functional applications and data processing by running nonvolatile software programs, instructions and modules stored in the memory 802, that is, the functions of the various modules or units of the kubernets cluster-based software starting method and the apparatus embodiments provided by the above method embodiments are realized.
The memory 802 may include high speed random access memory and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid state storage device. In some embodiments, the memory 802 optionally includes memory located remotely from the processor 801, which may be connected to the processor 801 via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.
Stored in memory 802 are program instructions/modules that, when executed by the one or more processors 801, perform the kubernets cluster-based software boot method of any of the method embodiments described above.
The server 80 of the present embodiment exists in various forms, and performs the above-described steps shown in fig. 4; the above-mentioned server 80 includes but is not limited to: the system comprises a tower server, a rack server, a blade server and a cloud server.
Embodiments of the present application further provide a non-transitory computer storage medium, where the computer storage medium stores computer-executable instructions, which are executed by one or more processors, for example, one processor 801 in fig. 8, so that the one or more processors may perform the software boot method based on the kubernets cluster in any method embodiment described above.
The embodiment of the present application further provides a computer program product, where the computer program product includes a computer program stored on a non-volatile computer-readable storage medium, and the computer program includes program instructions, where when the program instructions are executed by a server, the server executes the software starting method based on the kubernets cluster, and when the program instructions are executed by a processor, the program instructions implement each process of the embodiment of the software starting method based on the kubernets cluster, and can achieve the same technical effect, and in order to avoid repetition, the detailed description is omitted here.
By means of the method and the device, the ConfigMap configuration file corresponding to the software is loaded in the minimum operation unit, so that the ConfigMap configuration file is directly read from the minimum operation unit in the starting process of the software.
The embodiment of the present application further provides a chip, where the chip includes a processor and a communication interface, the communication interface is coupled with the processor, and the processor is configured to execute a program or an instruction, to implement each process of the above embodiment of the software startup method based on the kubernets cluster, and can achieve the same technical effect, and in order to avoid repetition, details are not repeated here. It should be understood that the chips mentioned in the embodiments of the present application may also be referred to as system-on-chip, system-on-chip or system-on-chip, etc.
The above-described embodiments of the apparatus or device are merely illustrative, wherein the unit modules described as separate parts may or may not be physically separate, and the parts displayed as module units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network module units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment.
Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented by software plus a general hardware platform, and certainly can also be implemented by hardware. With this in mind, the above-described technical solutions may be embodied in the form of a software product, which can be stored in a computer-readable storage medium, such as ROM/RAM, magnetic disk, optical disk, etc., and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods of the various embodiments or some parts of the embodiments.
Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit the same; within the context of the present application, features from the above embodiments or from different embodiments may also be combined, steps may be implemented in any order, and there are many other variations of the different aspects of the present application as described above, which are not provided in detail for the sake of brevity; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and these modifications or substitutions do not depart from the scope of the technical solutions of the embodiments of the present application.
Claims (10)
1. A software starting method based on a Kubernetes cluster is characterized by comprising the following steps:
after a Kubernetes cluster acquires a project file corresponding to certain software, a minimum operation unit is established, and the project file is deployed in the minimum operation unit;
acquiring a ConfigMap configuration file corresponding to the software from a ConfigMap storage space, and mounting the ConfigMap configuration file corresponding to the software on the minimum operation unit;
and acquiring a ConfigMap configuration file corresponding to the software from the minimum operation unit so as to start the software.
2. The method of claim 1, wherein creating the minimal execution unit comprises:
and creating a minimum operation unit corresponding to the software according to the operation parameters of the software, wherein the operation parameters of the software comprise hard disk parameters, the minimum operation unit corresponds to a hard disk space, and the space size corresponding to the hard disk space is not less than the space size corresponding to the hard disk parameters.
3. The method of claim 2, wherein said deploying the project file to the minimal execution unit comprises:
and saving the project file to a hard disk space corresponding to the minimum operation unit.
4. The method according to claim 2 or 3, wherein the loading the ConfigMap configuration file corresponding to the software to the minimal operation unit comprises:
and saving the ConfigMap configuration file to a hard disk space corresponding to the minimum operation unit, wherein the ConfigMap configuration file corresponds to a preset path of the hard disk space, and the preset path is stored in an attribute file in an engineering file corresponding to the software.
5. The method according to claim 4, wherein the obtaining a ConfigMap configuration file corresponding to the software from the minimum running unit to start the software comprises:
running the engineering file corresponding to the software in the minimum running unit, and acquiring a preset path of the hard disk space corresponding to the minimum running unit from an attribute file in the engineering file corresponding to the software;
acquiring a ConfigMap configuration file corresponding to the software according to a preset path of a hard disk space corresponding to the minimum operation unit;
and reading configuration parameters in the ConfigMap configuration file, and loading the configuration parameters to the context of the software to start the software.
6. The method according to any one of claims 1-3, further comprising:
and when the ConfigMap configuration file is updated, automatically acquiring the updated ConfigMap configuration file, and deploying the updated ConfigMap configuration file in the minimum operation unit.
7. The method according to any one of claims 1 to 3, wherein the engineering file corresponding to the software is obtained by developing through a Quarkus framework, and the engineering file corresponding to the software comprises a Docker image file.
8. A software starting device based on a Kubernetes cluster is characterized by comprising:
the system comprises an engineering file module, a management module and a management module, wherein the engineering file module is used for creating a minimum operation unit after a Kubernets cluster acquires an engineering file corresponding to certain software, and deploying the engineering file in the minimum operation unit;
the configuration file module is used for acquiring a ConfigMap configuration file corresponding to the software from a ConfigMap storage space and deploying the ConfigMap configuration file corresponding to the software to the minimum operation unit;
and the software starting module is used for acquiring the ConfigMap configuration file corresponding to the software from the minimum operation unit so as to start the software.
9. A server, comprising:
at least one processor; and
a memory communicatively coupled to the at least one processor; wherein,
the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the kubernets cluster-based software boot method of any one of claims 1-7.
10. A non-transitory computer-readable storage medium having stored thereon computer-executable instructions for causing a server to perform the kubernets cluster-based software boot method of any one of claims 1-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210692824.4A CN115016862A (en) | 2022-06-17 | 2022-06-17 | Kubernetes cluster-based software starting method, device, server and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210692824.4A CN115016862A (en) | 2022-06-17 | 2022-06-17 | Kubernetes cluster-based software starting method, device, server and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115016862A true CN115016862A (en) | 2022-09-06 |
Family
ID=83074204
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210692824.4A Pending CN115016862A (en) | 2022-06-17 | 2022-06-17 | Kubernetes cluster-based software starting method, device, server and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115016862A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116909584A (en) * | 2023-05-06 | 2023-10-20 | 广东国地规划科技股份有限公司 | Deployment method, device, equipment and storage medium of space-time big data engine |
-
2022
- 2022-06-17 CN CN202210692824.4A patent/CN115016862A/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116909584A (en) * | 2023-05-06 | 2023-10-20 | 广东国地规划科技股份有限公司 | Deployment method, device, equipment and storage medium of space-time big data engine |
| CN116909584B (en) * | 2023-05-06 | 2024-05-24 | 广东国地规划科技股份有限公司 | Deployment method, device, equipment and storage medium of space-time big data engine |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11405274B2 (en) | Managing virtual network functions | |
| US9189619B2 (en) | Runtime based application security and regulatory compliance in cloud environment | |
| US9195294B2 (en) | Cooperatively managing enforcement of energy related policies between virtual machine and application runtime | |
| CN111527474B (en) | Dynamic delivery of software functions | |
| CN103608773A (en) | Deployment system for multi-node applications | |
| US10338952B2 (en) | Program execution without the use of bytecode modification or injection | |
| US20180054359A1 (en) | Network attached reconfigurable computing device | |
| CN113474751A (en) | Managing software programs | |
| CN104750528A (en) | Management method and device for components in Android program | |
| US20130132945A1 (en) | Virtual machine updates | |
| US12056095B2 (en) | Host-level persistent volume management for container clouds | |
| CN112035121B (en) | Edge application deployment method and system | |
| CN114168255A (en) | Operation method and device of heterogeneous instruction set container in container cloud platform | |
| US20200319868A1 (en) | Shared middleware layer containers | |
| CN115016862A (en) | Kubernetes cluster-based software starting method, device, server and storage medium | |
| CN113821220A (en) | Installation method and device of linux operating system | |
| CN114281444B (en) | Arrangement method for implementing cloud desktop client | |
| US20180341475A1 (en) | Just In Time Deployment with Package Managers | |
| CN110321335B (en) | Modeling data downloading method and device, electronic equipment and computer storage medium | |
| CN112835865A (en) | Application hot deployment system, method and device | |
| CN111488322A (en) | File system service method and device and server equipment | |
| US11561787B2 (en) | Application invocation on specified operating system version | |
| CN113222174B (en) | Model management method and device | |
| US20230409716A1 (en) | Shared library customization | |
| CN114281443B (en) | Cloud desktop system and method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |