WO2019184164A1

WO2019184164A1 - Method for automatically deploying kubernetes worker node, device, terminal apparatus, and readable storage medium

Info

Publication number: WO2019184164A1
Application number: PCT/CN2018/097564
Authority: WO
Inventors: 刘俊杰
Original assignee: 平安科技（深圳）有限公司
Priority date: 2018-03-30
Filing date: 2018-07-27
Publication date: 2019-10-03
Also published as: CN108549580B; CN108549580A

Abstract

The present solution is applicable to the technical field of data processing and provides a method for automatically deploying a Kubernetes worker node, a terminal apparatus, and a computer readable storage medium. The method comprises: acquiring request information of a user, the request information comprising a master node identifier and a node parameter, and the node parameter indicating a physical node or a virtual machine node; searching for a Kubernetes cluster corresponding to the master node identifier, and acquiring, from a database, an identifier of a node to be deployed corresponding to the node parameter; and calling a control server, so as to search for the node to be deployed corresponding to the identifier of the node to be deployed, and deploying the node as a Kubernetes worker node of the Kubernetes cluster. The present solution realizes automatic deployment of Kubernetes worker nodes, reduces the possibility of error during a deployment process, and significantly improves deployment efficiency.

Description

Method, device, terminal device and readable storage medium for automatically deploying Kubernetes slave nodes

This application claims priority to Chinese Patent Application No. 201810277483.8, entitled "Automatic Deployment of Kubernetes Slave Node Method and Terminal Equipment", filed on March 31, 2018, the entire contents of which are incorporated by reference. In this application.

Technical field

The present application belongs to the field of data processing technologies, and in particular, to a method, an apparatus, a terminal device, and a computer readable storage medium for automatically deploying a Kubernetes slave node.

Background technique

Traditional virtualization technologies have shortcomings in terms of performance and resource utilization. Docker provides container technology that has become a research hotspot by dividing the resources managed by a single operating system into isolated groups and improving resource utilization. This container technology allows several containers to run on the same host or virtual machine, each of which is a separate virtual environment or application. Kubernetes, as an open source container operation platform, can realize the functions of combining several containers into one service and dynamically allocating the host running the container, which provides great convenience for users to use the container.

In the Kubernetes cluster, there are two types of nodes: the master node and the slave node. The master node is responsible for the management and scheduling of resources in the Kubernetes cluster, while the slave node is responsible for hosting the container and is the host of the container. In the prior art, if a new slave node is to be deployed in a Kubernetes cluster, a large number of components need to be manually installed on the corresponding host or virtual machine, and a large number of configurations are required. Therefore, the existing method of deploying the Kubernetes slave node mainly relies on manual operations, and the deployment process is cumbersome, and configuration errors are likely to occur during the deployment process, and the error rate is high.

technical problem

In view of this, the embodiment of the present application provides a method, an apparatus, a terminal device, and a computer readable storage medium for automatically deploying a Kubernetes slave node, so as to solve the problem that the Kubernetes slave node deployment is cumbersome and has a high error rate in the prior art. .

Technical solution

A first aspect of the embodiments of the present application provides a method for automatically deploying a Kubernetes slave node, including:

Obtaining request information of the user, where the request information includes a primary node identifier and a node parameter, where the node parameter is used to indicate a physical node or a virtual machine node;

Finding a Kubernetes cluster corresponding to the primary node identifier, and obtaining, from the database, a node identifier to be deployed corresponding to the node parameter;

The control server is invoked to find a node to be deployed corresponding to the node identifier to be deployed, and the node to be deployed is deployed as a Kubernetes slave node of the Kubernetes cluster.

A second aspect of an embodiment of the present application provides an apparatus for automatically deploying a Kubernetes slave node, which may include means for implementing the steps of the method of automatically deploying a Kubernetes slave node as described above.

A third aspect of the embodiments of the present application provides a terminal device, including a memory and a processor, where the computer stores computer readable instructions executable on the processor, the processor executing the computer The steps of the above method of automatically deploying the Kubernetes slave node are implemented when the instruction is read.

A fourth aspect of embodiments of the present application provides a computer readable storage medium storing computer readable instructions that, when executed by a processor, implement the above-described auto-deployment Kubernetes slave node The steps of the method.

Beneficial effect

The embodiment of the present application obtains the request information of the user, and the request information includes a primary node identifier and a node parameter, where the node parameter is used to indicate a physical node or a virtual machine node, and the primary node of the Kubernetes is found by the primary node identifier, thereby determining the primary node of the Kubernetes. The Kubernetes cluster, and finds the node identifier to be deployed corresponding to the node parameter in the database, and finally calls the control server, and the control server searches for the node to be deployed corresponding to the node identifier to be deployed, and deploys the node to be deployed as a Kubernetes cluster. The Kubernetes slave node, after obtaining the request information of the user, implements the automatic deployment of the Kubernetes slave node, reduces the possibility of error in the deployment process, saves manpower, and improves the deployment efficiency.

DRAWINGS

1 is a flowchart of an implementation of a method for automatically deploying a Kubernetes slave node in the first embodiment of the present application;

2 is a flowchart of an implementation of a method for automatically deploying a Kubernetes slave node in Embodiment 2 of the present application;

3 is a flowchart of an implementation of a method for automatically deploying a Kubernetes slave node in Embodiment 3 of the present application;

4 is a flowchart of an implementation of a method for automatically deploying a Kubernetes slave node in Embodiment 4 of the present application;

5 is a flowchart of an implementation of a method for automatically deploying a Kubernetes slave node in Embodiment 5 of the present application;

6 is an implementation structural diagram of a method for automatically deploying a Kubernetes slave node in Embodiment 6 of the present application;

7 is a flowchart of an implementation of a method for automatically deploying a Kubernetes slave node in Embodiment 7 of the present application;

8 is a structural block diagram of an apparatus for automatically searching for logistics information in Embodiment 8 of the present application;

FIG. 9 is a schematic diagram of a terminal device in Embodiment 9 of the present application.

Embodiments of the invention

In order to more clearly understand the technical features, objects and effects of the present application, the specific embodiments of the present application will be described in detail with reference to the accompanying drawings.

Please refer to FIG. 1. FIG. 1 is a flowchart of an implementation of a method for automatically deploying a Kubernetes slave node according to an embodiment of the present application. As shown in Figure 1, the method includes the following steps:

S101: Acquire user request information, where the request information includes a primary node identifier and a node parameter, where the node parameter is used to indicate a physical node or a virtual machine node.

In the embodiment of the present application, the automatic deployment of the new Kubernetes slave node is implemented on the basis of the existing Kubernetes cluster. For the sake of explanation, first introduce the relevant content of Kubernetes and Kubernetes cluster. Kubernetes is an open source platform for automated container operations. It can implement the functions of container deployment, scheduling, and inter-cluster expansion. The physical machine nodes or virtual machines configured with Kubernetes environment are called Kubernetes nodes. In general, Kubernetes Cluster (Kubernetes Cluster) is composed of multiple Kubernetes nodes, which can realize the deployment and management of containers. Within a Kubernetes cluster, there is one and only one control unit, the Kubernetes Master, which is responsible for scheduling and managing Kubernetes services, such as allocating a container of a service to a slave node of the Kubernetes cluster. The Kubernetes master node contains four subcomponents, namely the database (Etcd) component and the interface service (Kube). The ApiServer) component, the Kube Scheduler component and the Kube Controller Manager component, in the embodiment of the present application, mainly relate to an interface service component of the Kubernetes master node, and the interface service component is configured to receive and process the request for the Kubernetes cluster. . In addition to the Kubernetes master node, the Kubernetes cluster also includes a Kubernetes Node (Kubernetes Node) for actually running the container allocated by the Kubernetes master node.

In the embodiment of the present application, on the basis that the Kubernetes master node and the Kubernetes cluster have been established, the nodes to be joined to the Kubernetes cluster are determined from the plurality of nodes of the slave node resource pool, wherein the slave node resource pool refers to a runnable physical node or virtual Machine collection. For ease of explanation, only the case where multiple cloud host virtual machines are stored in the node resource pool is described. The cloud host virtual machine is a virtual host similar to the independent host on the cluster host, but it should be known that the slave node The resource pool can also be used to store other physical nodes, such as physical servers, for use in the embodiments of the present application. In order to determine the node to be added to the Kubernetes cluster, the user's request information is first obtained, wherein the request information includes the primary node identifier and the node parameter. Generally, the master node identifier is an Internet Protocol Address (IP) provided by the interface service component of the Kubernetes master node, and the corresponding Kubernetes master node can be automatically found through the master node identifier, thereby finding the corresponding Kubernetes cluster. The node parameter is related to the physical node or the virtual machine node, and is used to find a specific physical node or virtual machine node to be added to the Kubernetes cluster. Specifically, the physical node or the virtual machine node has the node identifier, and the node parameter and the node identifier. There is a unique correspondence, so the node parameters can be used to indicate the node identification, thereby indicating the physical node or the virtual machine node.

Optionally, the front end page based on the Kubernetes cluster and the slave node resource pool is provided to the user, and the request information sent by the user through the front end page is received. Since the Kubernetes cluster is established, you can obtain the cluster information of the Kubernetes cluster, such as the name of the Kubernetes cluster and the existing Kubernetes slave node name, and obtain the feature information of multiple cloud host virtual machines in the node resource pool, such as multiple clouds. The name of the host virtual machine, etc., through the user interface provided by the Kubernetes cluster, the cluster information and feature information are integrated into the front-end page for display. You can view the front-end page by using the domain name login method on the user device, and select the cloud host virtual machine that needs to be added to the Kubernetes cluster. After the selection is complete, the request information corresponding to the user's selection result is automatically generated, and the request information is sent. The Kubernetes cluster replaces the user query node and manually sends the request information, which improves the convenience of request information generation. It is worth mentioning that in order to improve the security of the request information, the request information is based on the Secure Sockets Layer-based hypertext transfer protocol (Hyper Text Transfer Protocol over Secure Socket Layer (HTTPS) format is sent.

Further, the cluster information of the Kubernetes cluster and the feature information of the plurality of cloud host virtual machines related to the user equipment are provided to the user. On the basis of providing the front-end page to the user, the front-end page including the cluster information and the feature information related to the user equipment is provided to the user according to the authority of the user equipment. For example, there may be multiple Kubernetes clusters. After determining the Kubernetes cluster to which the user equipment belongs, only the cluster information and feature information related to the Kubernetes cluster are provided to the user, which improves the security of the Kubernetes slave node process.

S102: Search for a Kubernetes cluster corresponding to the primary node identifier, and obtain a node identifier to be deployed corresponding to the node parameter from a database.

After receiving the request information of the user, the request information is parsed to obtain the primary node identifier and the node parameter therein. The corresponding Kubernetes primary node is found according to the primary node identifier, thereby determining the Kubernetes cluster corresponding to the Kubernetes primary node, and searching for the to-be-deployed node identifier corresponding to the node parameter from the database. In the embodiment of the present application, in order to improve the accuracy of deploying the Kubernetes slave node, a Kubernetes Manager may be set to manage the Kubernetes cluster, and the operations of step S101 and step S102 are performed. Specifically, after acquiring the request information of the user, the management program parses the request information, and acquires the primary node identifier and the node parameter in the request information. Since the hypervisor may manage multiple Kubernetes clusters at the same time, after obtaining the primary node identifier, the Kubernetes cluster corresponding to the primary node identifier is determined, and the data interface provided by the database is called, and the node parameters are searched from multiple node identifiers in the database. Corresponding node ID to be deployed. It is worth mentioning that if there are multiple Kubernetes clusters, the database is shared by multiple Kubernetes clusters.

S103: Call a control server to find a node to be deployed corresponding to the node identifier to be deployed, and deploy the node to be deployed as a Kubernetes slave node of the Kubernetes cluster.

After obtaining the node identifier to be deployed, the hypervisor calls the control server, specifically calling the control server to add the node's add interface. It is worth mentioning that the control server is a standalone server and is not controlled by the Kubernetes cluster, and is mainly set in the control slave node. A cloud host virtual machine in a resource pool. A plurality of cloud host virtual machines in the node resource pool have corresponding node identifiers. Therefore, after obtaining the node identifiers to be deployed, the control server searches for the cloud host virtual machines corresponding to the node identifiers to be deployed in the slave node resource pool. The node to be deployed and the nodes to be deployed are controlled and deployed as Kubernetes slaves of the Kubernetes cluster.

FIG. 6 shows an implementation architecture diagram of a method for automatically deploying a Kubernetes slave node. As shown in FIG. 6, the architecture diagram has a hypervisor configured to manage a Kubernetes cluster and a slave node resource pool to store multiple cloud host virtual machines. The premise reflects the entire process of automatically deploying Kubernetes from a node. First, the management program receives the request information of the user, and parses the primary node identifier and the node parameter in the request information, finds the corresponding Kubernetes cluster according to the primary node identifier, and finds the corresponding node identifier to be deployed from the database according to the node parameter. And then the hypervisor invokes the control server, and the control server determines the cloud host virtual machine identified from the node to be deployed from the plurality of cloud host virtual machines of the node resource pool, and deploys the cloud host virtual machine as a Kubernetes Nodes are added to the Kubernetes cluster.

The embodiment shown in FIG. 1 shows that, in the embodiment of the present application, by acquiring the request information of the user, the request information includes the primary node identifier and the node parameter, and firstly, the object added by the Kubernetes slave node, that is, the identifier corresponding to the master node identifier is determined. The Kubernetes cluster obtains the node identifier to be deployed corresponding to the node parameter from the database, and finally finds the node to be deployed corresponding to the node identifier to be deployed through the control server, and deploys the node to be deployed as the Kubernetes slave node of the Kubernetes cluster. Reduced manual operations and improved deployment efficiency of Kubernetes slave nodes by building automated deployments.

Referring to FIG. 2, FIG. 2 is a flowchart of an implementation method of automatically deploying a Kubernetes slave node according to Embodiment 2 of the present application. With respect to the embodiment corresponding to FIG. 1, the embodiment refines the process after S102 to obtain S201~S203, which are as follows:

S201: Acquire multiple available node identifiers of multiple available nodes in the node resource pool, and compare the to-be-deployed node identifier with the multiple available node identifiers.

In the embodiment of the present application, for convenience of explanation, only the case where the node stored in the node resource pool is a cloud host virtual machine is described, but it should be known that the slave node resource pool may also store other nodes such as physical nodes. It is used in the embodiment of the present application. Since the node parameter is included in the request information, and the request information is automatically generated according to the user selecting a cloud host virtual machine, the user can specify a cloud host virtual machine to select by writing a code, but in the present application In an embodiment, the user selects a cloud host virtual machine displayed on the front-end page by clicking on the front-end page of the Kubernetes cluster and the slave node resource pool, thereby completing the selection, and the background is completed. The corresponding request information is automatically generated. When the user selects the cloud host virtual machine, there is a possibility that the state of the cloud host virtual machine cannot be known. For example, the front-end page is not updated in real time according to the status of the Kubernetes cluster and the slave node resource pool, and the request information is generated when the request information is generated. The cloud host VM to which the node ID of the node to be deployed corresponds to the node parameter may have joined the Kubernetes cluster or other Kubernetes cluster corresponding to the master node identifier. After obtaining the node identifier to be deployed corresponding to the node parameter from the database, the plurality of available node identifiers of the plurality of available nodes in the node resource pool are obtained, and the node identifier to be deployed is compared with the plurality of available node identifiers. Wherein, the plurality of available nodes refers to a plurality of cloud host virtual machines in the slave resource pool that are not joined to the Kubernetes cluster and are in a running state.

Optionally, the plurality of available node identities of the slave node resource pool are updated, and the plurality of available node identities are stored in the database. In the embodiment of the present application, the status of the node in the slave node resource pool is updated, and then multiple available nodes and corresponding multiple available node identifiers are updated. According to actual requirements, the update may be real-time update, and the time interval may be updated. . After the update, multiple available node identifiers are stored in the database, and the deposit mode may be to newly create a state data table dedicated to storing the available node identifiers in the database. After obtaining the node identifier to be deployed from the database, multiple available node identifiers are obtained from the database, which reduces the operation complexity and improves the accuracy of the node selection to be deployed.

S202: If the comparison between the node identifier to be deployed and the one of the multiple available node identifiers is successful, the node corresponding to the successfully available node identifier is used as the node to be deployed.

After the acquisition of the plurality of available node identifiers is completed, the node identifier to be deployed is compared with the plurality of available node identifiers. If the node identifier to be deployed is successfully matched with the one of the plurality of available node identifiers, the node identifier corresponding to the node to be deployed is proved to be corresponding. If the cloud host virtual machine is available, the node corresponding to the successfully available node identifier (the cloud host virtual machine) is used as the node to be deployed.

S203: If the node identifier to be deployed and the plurality of available node identifiers fail to match, output an error prompt to the user.

If the node identifier to be deployed and the multiple available node identifiers fail to match, it is proved that the cloud host virtual machine corresponding to the node identifier to be deployed is unavailable, and an error prompt is output to the user, and the call control server is stopped to find and locate The node to be deployed corresponding to the deployed node identifier and its subsequent operations are described. The error prompt may include a cloud host virtual machine corresponding to the node identifier to be deployed, so that the user can view the cloud host virtual machine.

According to the embodiment shown in FIG. 2, in the embodiment of the present application, multiple available node identifiers of multiple available nodes in the node resource pool are obtained, and the node identifier to be deployed is compared with multiple available node identifiers. And determining the validity of the node identifier to be deployed. If the node identifier to be deployed is successfully matched with the one of the plurality of available node identifiers, the node identifier to be deployed is valid, and the node corresponding to the successfully available node identifier is compared as the node to be deployed. If the node ID of the node to be deployed fails to be compared with the number of available node identifiers, the node ID of the node to be deployed is invalid, and an error message is sent to the user. The validity of the node ID to be deployed is verified before the node to be deployed is determined. Waste, after the validity verification is passed, the node corresponding to the node ID to be deployed is guaranteed to be available.

Referring to FIG. 3, FIG. 3 is a flowchart of an implementation of a method for automatically deploying a Kubernetes slave node according to Embodiment 3 of the present application. With respect to the embodiment corresponding to FIG. 1, in this embodiment, on the basis that the node to be deployed is installed with the proxy client, the S103 is refined to obtain S301~S302, which are as follows:

S301: Automatically send a deployment instruction corresponding to the request information to the control server.

On the node to be deployed (the cloud host VM) corresponding to the node ID to be deployed, the agent client (Agent) is pre-installed to operate the node to be deployed. Since the node to be deployed needs to be deployed as a Kubernetes slave node of the Kubernetes cluster, the management program of the Kubernetes cluster parses the content of the request information after receiving the request information from the user, and calls the control interface of the control server to the control. The server sends a deployment instruction corresponding to the request information, and preferably, the deployment instruction is sent in an HTTPS format.

S302: Establish a socket connection between the control server and the proxy client, so that after receiving the deployment instruction, the control server causes the proxy client to deploy the proxy according to the deployment instruction. The node is deployed as the Kubernetes slave node of the Kubernetes cluster.

In the embodiment of the present application, the control server establishes a socket connection with the proxy client, and the socket substantially provides the endpoint of the communication, so before the communication is implemented, the two parties first create an endpoint, that is, the control server. Socket and proxy client sockets. The establishment process of a socket connection is mainly divided into three steps, namely, controlling server monitoring, proxy client request, and connection confirmation. During the control server listening process, the control server socket is in a waiting state, monitoring the connection request in the network in real time, and not looking for a specific proxy client socket; in the proxy client request process, the node to be deployed is installed. The proxy client socket first obtains information about the control server socket, including controlling the address and port number of the server socket, and then sending a connection request to the control server socket; during the connection confirmation process, the control server set The connection successfully listens to the connection request of the proxy client socket, and in response to the connection request, sends information about the control server socket to the proxy client socket, and finally the proxy client socket control server After the socket information is related, the establishment of the socket connection is completed.

After the control server establishes a socket connection with the proxy client, the proxy client is controlled based on the received deployment instruction, so that the proxy client performs the deployment operation on the node to be deployed according to the deployment instruction, and the node to be deployed is added. The Kubernetes slave node of the Kubernetes cluster, in particular, the proxy client executes shell commands for deployment operations.

As shown in the embodiment shown in FIG. 3, in the embodiment of the present application, the deployment instruction corresponding to the request information is automatically sent to the control server, and the control server establishes a socket connection with the proxy client, so that the control server receives the connection. After the deployment instruction, the control agent client deploys the node to be deployed as the Kubernetes slave node of the Kubernetes cluster according to the deployment instruction, and performs the deployment operation through the pre-installed proxy client, thereby further improving the automation degree of deploying the Kubernetes slave node, and controlling through A socket connection established between the server and the proxy client improves the stability of the deployment operation.

Referring to FIG. 4, FIG. 4 is a flowchart of an implementation of a method for automatically searching for logistics information according to Embodiment 4 of the present application. With respect to the embodiment corresponding to FIG. 3, in this embodiment, on the basis that the deployment instruction includes the authentication signature value, the process before S302 is refined to obtain S401~S403, which are as follows:

S401: Extract parameters other than the authentication signature value from the deployment instruction, and calculate a calculated signature value of the parameter by using a parameter signature algorithm.

In order to verify whether the control server has the right to execute the deployment instruction, in the embodiment of the present application, the control server performs an authentication operation. First, before sending the deployment instruction, the hypervisor extracts the parameters in the deployment instruction and sorts them, and calculates the authentication signature value through the parameter signature algorithm based on the sorted parameters and the customized string token. Preferably, the parameter signature algorithm is combined with a hash message authentication code (Hash-based) The message authentication code (HMAC) and the Secure Hash Algorithm (SHA) algorithm are the HAMC-SHA1 signature authentication algorithm. The calculated authentication signature value is the signature summary based on the sorted parameters and the token. After the authentication signature value is generated, the authentication signature value is added to the deployment instruction, and the added deployment instruction is sent to the control server. After receiving the added deployment command, the control server extracts parameters other than the authentication signature value, sorts the parameters, and calculates the calculation based on the sorted parameters and the same string token through the HAMC-SHA1 signature authentication algorithm. Signature value.

S402: If the authentication signature value is equal to the calculated signature value, perform the operation of establishing a socket connection between the control server and the proxy client.

After the calculation is completed, the control server compares the calculated signature value with the authentication signature value. If the calculated signature value is equal to the authentication signature value, the control server authenticates and continues to perform the socket connection between the control server and the proxy client. operating.

S403: If the authentication signature value is not equal to the calculated signature value, stopping performing the subsequent operation.

If the calculated signature value and the authentication signature value are not equal, the authentication fails, and the control server does not have the authority to execute the deployment instruction, and then the subsequent operations are stopped.

It can be seen from the embodiment shown in FIG. 4 that the embodiment of the present application performs authentication before establishing a socket connection, thereby improving the security of the connection.

Referring to FIG. 5, FIG. 5 is a flowchart of an implementation method for automatically deploying a Kubernetes slave node according to Embodiment 5 of the present application. With respect to any of the embodiments corresponding to FIG. 1 to FIG. 4, in this embodiment, S103 is refined to obtain S501~S503, which are as follows:

S501: Obtain a binary file related to the Kubernetes cluster from a file server.

After determining the node to be deployed, first check the status of the deployed node to determine whether it has deployment conditions. After checking that the node to be deployed is ready, in order to set up the deployment environment of the node to be deployed, first obtain the binary file related to the Kubernetes cluster from the file server, wherein the file server is a high-speed download server independent of the Kubernetes cluster, and is used for storing the binary. Documents and various scripts.

S502: Acquire a slave service file in the binary file, and obtain a node address of the node to be deployed.

Generally, the binary file obtained from the file server includes a master node service file related to the Kubernetes master node and a slave node service file related to the Kubernetes slave node, wherein the master node service file includes an interface service component file and a scheduling component file, and the like. The slave service files include Kubectl files, Kubelet files, and Kube-Proxy files. Therefore, in the embodiment of the present application, the slave node server file is obtained from the binary file, and the node address of the node to be deployed is obtained for deployment.

Optionally, when the binary file is stored in the file server, the master node identifier and the slave node identifier are respectively set for the master node service file and the slave node service file. After the slave node identifier is set to the slave node server and stored in the file server, when the node to be deployed is deployed later, the slave node service file is directly obtained from the file server according to the slave node identifier, and the master node is not acquired. The service file and the binary file of the slave service file save the extraction of the binary file and improve the deployment efficiency.

S503: Automatically configure the slave node service based on the slave node service file and the node address.

After the node service file and the node address are obtained, the node to be deployed is cleaned. The original configuration of the node to be deployed is cleared. After the cleaning is completed, a certificate related to the Kubernetes cluster is generated, which mainly includes a certification authority (CA) certificate, a kubernetes certificate, an admin certificate, and a proxy certificate. When the above certificate is generated, a key file corresponding to the above certificate is also generated. Subsequent distribution of the key file, the specific distribution process will be described later. After the node is cleaned up and the certificate is generated, the flannel service is configured and started based on the slave service file. The flannel is the network planning service for Kubernetes, so that the docker containers created by the different Kubernetes slave nodes in the Kubernetes cluster have the full Kubernetes cluster. The only virtual IP address, on the other hand, the flannel is essentially the overlay network, that is, the transmission control protocol (Transmission) Control Protocol, TCP) Packets are encapsulated in another network packet for routing and communication. After the configuration of the flannel service is completed according to the node address, and the flannel service is started, the configuration of the container is performed, the startup parameters of the container are modified, and the container is started.

In the Kubernetes cluster, in order to facilitate the control of the container, the Kubectl service, Kubelet service and Kube-Proxy service are further automatically configured. Among them, Kubectl is a console tool for Kubernetes cluster management, which can provide users with a large number of commands for users to view Kubernetes cluster. Kubelet is a container management tool on the Kubernetes slave node, which is used to process the task that the Kubernetes master node delivers to the Kubernetes slave node. Kubelet registers the Kubernetes slave node information on the interface service component of the Kubernetes master node, and periodically reports to the Kubernetes master. The node sends the resource usage of the Kubernetes slave node, while monitoring the container and node resources inside the Kubernetes slave node. Kube-Proxy is the entry component of the Kubernetes service and is used to manage access to the Kubernetes service. Based on the node service file and the node address of the node to be deployed, the Kubectl service, the Kubelet service, and the Kube-Proxy service are sequentially deployed and started. It is worth mentioning that the CA certificate and the admin certificate corresponding key file are distributed to the Kubectl service. The CA certificate corresponding key file is distributed to the Kubelet service, and the CA certificate and the proxy certificate corresponding key file are distributed to the Kube-Proxy service. Finally, when the Kube-Proxy service is successfully deployed and started, the node to be deployed is successfully deployed as Kubernetes. From the node.

Optionally, in the deployment process of steps S501 to S503, a retry and recording mechanism is set. FIG. 7 is a flowchart showing an implementation of deploying a node to be deployed after setting a retry and recording mechanism. Each of x, y, and z is an integer greater than zero. As shown in FIG. 7, the state of the node to be deployed is checked, and the binary is obtained. Files, clean up the nodes to be deployed, generate certificate related files, configure and start the flannel service, install and start the container, configure and start the Kubectl service, configure and start the Kubelet service, and configure and start the Kube-Proxy service. Mechanism, and set the threshold of the number of times, when a link is successful, the next step. However, when there is an error in a certain link, it is judged whether it is the xth attempt. If the xth attempt has not been reached, the link is re-opened; if it is the xth attempt, the current link is recorded and the record is to be deployed. The node fails to deploy at this point and can also record the cause of the error. In the process of checking the status of the node to be deployed, the node to be deployed may be in the initialization process. Therefore, to improve the effectiveness of the deployment process, the threshold of the number of inspections is y, y is greater than x, and the number of times the node to be deployed is not ready does not reach the check. When the threshold value y is set, the waiting time is set. In the embodiment of the present application, after waiting for z minutes, the link to check the status of the node to be deployed is re-entered. After all the links are passed, the deployment of the node to be deployed is completed. The above method improves the fault tolerance of the node to be deployed through the retry and record mechanism, and facilitates the developer to locate the problem by recording the failed link. It is worth mentioning that the flowchart shown in FIG. 7 is only an example. In the actual application scenario, the threshold of the number of times and the waiting time of each link can be freely set according to actual conditions.

Corresponding to a method for automatically deploying a Kubernetes slave node according to the above embodiment, FIG. 8 is a structural block diagram of an apparatus for automatically deploying a Kubernetes slave node according to an embodiment of the present application. Referring to FIG. 8, the device is provided. include:

The obtaining unit 81 is configured to acquire request information of the user, where the request information includes a primary node identifier and a node parameter, where the node parameter is used to indicate a physical node or a virtual machine node;

The searching unit 82 is configured to search for a Kubernetes cluster corresponding to the primary node identifier, and obtain, from the database, a node identifier to be deployed corresponding to the node parameter;

The deployment unit 83 is configured to invoke a control server to find a node to be deployed corresponding to the node identifier to be deployed, and deploy the node to be deployed as a Kubernetes slave node of the Kubernetes cluster.

Optionally, the searching unit 82 further includes:

An identifier obtaining unit, configured to acquire a plurality of available node identifiers of the plurality of available nodes in the node resource pool, and compare the node identifier to be deployed with the plurality of available node identifiers;

a node determining unit, configured to use, as the node to be deployed, a node corresponding to the successfully available node identifier, if the comparison between the node identifier to be deployed and the identifier of the multiple available node identifiers is successful;

And an output unit, configured to output an error prompt to the user if the comparison between the node identifier to be deployed and the multiple available node identifiers fails.

Optionally, if the node to be deployed is installed with a proxy client, the deployment unit 83 includes:

An instruction sending unit, configured to automatically send a deployment instruction corresponding to the request information to the control server;

a connection establishing unit, configured to establish a socket connection between the control server and the proxy client, so that after receiving the deployment instruction, the control server causes the proxy client to perform the The node to be deployed is deployed as the Kubernetes slave node of the Kubernetes cluster.

Optionally, if the deployment instruction includes the authentication signature value, the connection establishing unit further includes:

a calculating unit, configured to extract a parameter other than the authentication signature value from the deployment instruction, and calculate a calculated signature value of the parameter by using a parameter signature algorithm;

An execution unit, configured to perform an operation of establishing a socket connection between the control server and the proxy client if the authentication signature value is equal to the calculated signature value;

Stopping the execution unit, if the verification signature value is not equal to the calculated signature value, stopping performing the subsequent operation.

Optionally, the deployment unit 83 includes:

a file obtaining unit, configured to acquire a binary file related to the Kubernetes cluster from a file server;

An address obtaining unit, configured to acquire a slave node service file in the binary file, and obtain a node address of the node to be deployed;

a service configuration unit, configured to automatically configure a slave node service based on the slave node service file and the node address.

FIG. 9 is a schematic diagram of a terminal device according to an embodiment of the present application. As shown in FIG. 9, the terminal device 9 of this embodiment includes a processor 90 and a memory 91 in which computer readable instructions 92 executable on the processor 90 are stored, for example, a Kubernetes slave node is deployed. program of. The steps in the method embodiment of implementing the above-described various automatic deployment Kubernetes slave nodes when the processor 90 executes the computer readable instructions 92, such as steps S101 to S103 shown in FIG. Alternatively, the processor 90, when executing the computer readable instructions 92, implements the functions of the various units of the apparatus embodiments described above, such as the functions of units 81 through 83 of FIG.

Illustratively, the computer readable instructions 92 may be partitioned into one or more modules/units that are stored in the memory 91 and executed by the processor 90, To complete this application. The one or more modules/units may be a series of computer readable instruction segments capable of performing a particular function, the instruction segments being used to describe the execution of the computer readable instructions 92 in the terminal device 9. For example, the computer readable instructions 92 can be partitioned into an acquisition unit, a lookup unit, and a deployment unit, each unit having a specific function as described above.

The terminal device may include, but is not limited to, a processor 90 and a memory 91. It will be understood by those skilled in the art that FIG. 9 is only an example of the terminal device 9, does not constitute a limitation of the terminal device 9, may include more or less components than those illustrated, or combine some components, or different components. For example, the terminal device may further include an input/output device, a network access device, a bus, and the like.

The so-called processor 90 can be a central processing unit (Central Processing Unit, CPU), can also be other general purpose processors, digital signal processors (Digital Signal Processor, DSP), Application Specific Integrated Circuit (ASIC), off-the-shelf programmable gate array (Field-Programmable Gate Array, FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, etc. The general purpose processor may be a microprocessor or the processor or any conventional processor or the like.

The memory 91 may be an internal storage unit of the terminal device 9, such as a hard disk or a memory of the terminal device 9. The memory 91 may also be an external storage device of the terminal device 9, for example, a plug-in hard disk equipped on the terminal device 9, a smart memory card (SMC), and a secure digital (SD). Card, flash card, etc. Further, the memory 91 may also include both an internal storage unit of the terminal device 9 and an external storage device. The memory 91 is configured to store the computer readable instructions and other programs and data required by the terminal device. The memory 91 can also be used to temporarily store data that has been output or is about to be output.

In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above integrated unit can be implemented in the form of hardware or in the form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a standalone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application, in essence or the contribution to the prior art, or all or part of the technical solution may be embodied in the form of a software product stored in a storage medium. A number of instructions are included to cause a computer device (which may be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in various embodiments of the present application. The foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and the like, which can store program codes. .

The above embodiments are only used to explain the technical solutions of the present application, and are not limited thereto; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still The technical solutions described in the embodiments are modified, or the equivalents of the technical features are replaced by the equivalents. The modifications and substitutions of the embodiments do not depart from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

A method for automatically deploying a Kubernetes slave node, comprising:

Obtaining request information of the user, where the request information includes a primary node identifier and a node parameter, where the node parameter is used to indicate a physical node or a virtual machine node;

Finding a Kubernetes cluster corresponding to the primary node identifier, and obtaining, from the database, a node identifier to be deployed corresponding to the node parameter;

The control server is invoked to find a node to be deployed corresponding to the node identifier to be deployed, and the node to be deployed is deployed as a Kubernetes slave node of the Kubernetes cluster.
The method of claim 1, wherein the obtaining the node identifier to be deployed corresponding to the node parameter from the database further comprises:

Obtaining a plurality of available node identifiers of the plurality of available nodes in the node resource pool, and comparing the to-be-deployed node identifiers with the plurality of available node identifiers;

If the node identifier to be deployed is successfully matched with the one of the plurality of available node identifiers, the node corresponding to the successfully available node identifier is used as the node to be deployed;

If the node identifier to be deployed and the plurality of available node identifiers fail to match, an error prompt is output to the user.
The method according to claim 1, wherein if the node to be deployed is installed with a proxy client, the call control server searches for a node to be deployed corresponding to the node identifier to be deployed, and the The node to be deployed is deployed as a Kubernetes slave of the Kubernetes cluster, including:

Automatically transmitting a deployment instruction corresponding to the request information to the control server;

Establishing a socket connection with the proxy client, so that the control server, after receiving the deployment instruction, causes the proxy client to deploy the node to be deployed according to the deployment instruction. The Kubernetes slave node of the Kubernetes cluster.
The method of claim 3, wherein, before the deploying the command includes the authentication signature value, the method further comprises: before the controlling server establishes a socket connection with the proxy client,

Extracting parameters other than the authentication signature value from the deployment instruction, and calculating a calculated signature value of the parameter by using a parameter signature algorithm;

And if the authentication signature value is equal to the calculated signature value, performing an operation of establishing a socket connection between the control server and the proxy client;

If the authentication signature value is not equal to the calculated signature value, the subsequent operations are stopped.
The method according to any one of claims 1 to 4, wherein the deploying the node to be deployed as a Kubernetes slave node of the Kubernetes cluster comprises:

Obtaining binary files related to the Kubernetes cluster from a file server;

Obtaining a slave node service file in the binary file, and acquiring a node address of the node to be deployed;

The slave node service is automatically configured based on the slave node service file and the node address.
A device for automatically deploying a Kubernetes slave node, comprising:

An obtaining unit, configured to acquire request information of a user, where the request information includes a primary node identifier and a node parameter, where the node parameter is used to indicate a physical node or a virtual machine node;

a search unit, configured to search for a Kubernetes cluster corresponding to the primary node identifier, and obtain, from the database, a node identifier to be deployed corresponding to the node parameter;

a deployment unit, configured to invoke a control server to find a node to be deployed corresponding to the node identifier to be deployed, and deploy the node to be deployed as a Kubernetes slave node of the Kubernetes cluster.
The device according to claim 6, wherein the searching unit further comprises:

An identifier obtaining unit, configured to acquire a plurality of available node identifiers of the plurality of available nodes in the node resource pool, and compare the node identifier to be deployed with the plurality of available node identifiers;

a node determining unit, configured to use, as the node to be deployed, a node corresponding to the successfully available node identifier, if the comparison between the node identifier to be deployed and the identifier of the multiple available node identifiers is successful;

And an output unit, configured to output an error prompt to the user if the comparison between the node identifier to be deployed and the multiple available node identifiers fails.
The device according to claim 6, wherein if the node to be deployed is installed with a proxy client, the deployment unit includes:

An instruction sending unit, configured to automatically send a deployment instruction corresponding to the request information to the control server;

a connection establishing unit, configured to establish a socket connection between the control server and the proxy client, so that after receiving the deployment instruction, the control server causes the proxy client to perform the The node to be deployed is deployed as the Kubernetes slave node of the Kubernetes cluster.
The device according to claim 7, wherein the connection establishing unit further comprises: if the deployment instruction includes an authentication signature value,

a calculating unit, configured to extract a parameter other than the authentication signature value from the deployment instruction, and calculate a calculated signature value of the parameter by using a parameter signature algorithm;

An execution unit, configured to perform an operation of establishing a socket connection between the control server and the proxy client if the authentication signature value is equal to the calculated signature value;

Stopping the execution unit, if the verification signature value is not equal to the calculated signature value, stopping performing the subsequent operation.
The device according to any one of claims 6 to 9, wherein the deployment unit comprises:

a file obtaining unit, configured to acquire a binary file related to the Kubernetes cluster from a file server;

An address obtaining unit, configured to acquire a slave node service file in the binary file, and obtain a node address of the node to be deployed;

a service configuration unit, configured to automatically configure a slave node service based on the slave node service file and the node address.
A terminal device, comprising: a memory and a processor, wherein the memory stores computer readable instructions executable on the processor, and the processor implements the following steps when the computer readable instructions are executed :

Obtaining request information of the user, where the request information includes a primary node identifier and a node parameter, where the node parameter is used to indicate a physical node or a virtual machine node;

Finding a Kubernetes cluster corresponding to the primary node identifier, and obtaining, from the database, a node identifier to be deployed corresponding to the node parameter;

The control server is invoked to find a node to be deployed corresponding to the node identifier to be deployed, and the node to be deployed is deployed as a Kubernetes slave node of the Kubernetes cluster.
The terminal device according to claim 11, wherein after the obtaining the node identifier to be deployed corresponding to the node parameter from the database, the method further includes:

Obtaining a plurality of available node identifiers of the plurality of available nodes in the node resource pool, and comparing the to-be-deployed node identifiers with the plurality of available node identifiers;

If the node identifier to be deployed is successfully matched with the one of the plurality of available node identifiers, the node corresponding to the successfully available node identifier is used as the node to be deployed;

If the node identifier to be deployed and the plurality of available node identifiers fail to match, an error prompt is output to the user.
The terminal device according to claim 11, wherein if the node to be deployed is installed with a proxy client, the call control server searches for a node to be deployed corresponding to the node identifier to be deployed, and The deployed node is deployed as a Kubernetes slave of the Kubernetes cluster, including:

Automatically transmitting a deployment instruction corresponding to the request information to the control server;

Establishing a socket connection with the proxy client, so that the control server, after receiving the deployment instruction, causes the proxy client to deploy the node to be deployed according to the deployment instruction. The Kubernetes slave node of the Kubernetes cluster.
The terminal device according to claim 13, wherein, if the deployment instruction includes an authentication signature value, before the establishing the socket connection between the control server and the proxy client, the method further includes:

Extracting parameters other than the authentication signature value from the deployment instruction, and calculating a calculated signature value of the parameter by using a parameter signature algorithm;

And if the authentication signature value is equal to the calculated signature value, performing an operation of establishing a socket connection between the control server and the proxy client;

If the authentication signature value is not equal to the calculated signature value, the subsequent operations are stopped.
The terminal device according to any one of claims 11 to 14, wherein the deploying the node to be deployed as a Kubernetes slave node of the Kubernetes cluster comprises:

Obtaining binary files related to the Kubernetes cluster from a file server;

Obtaining a slave node service file in the binary file, and acquiring a node address of the node to be deployed;

The slave node service is automatically configured based on the slave node service file and the node address.
A computer readable storage medium storing computer readable instructions, wherein the computer readable instructions, when executed by at least one processor, implement the following steps:

Obtaining request information of the user, where the request information includes a primary node identifier and a node parameter, where the node parameter is used to indicate a physical node or a virtual machine node;

Finding a Kubernetes cluster corresponding to the primary node identifier, and obtaining, from the database, a node identifier to be deployed corresponding to the node parameter;

The control server is invoked to find a node to be deployed corresponding to the node identifier to be deployed, and the node to be deployed is deployed as a Kubernetes slave node of the Kubernetes cluster.
The computer readable storage medium of claim 16, wherein the computer readable instructions are further executed by the at least one processor to:

Obtaining a plurality of available node identifiers of the plurality of available nodes in the node resource pool, and comparing the to-be-deployed node identifiers with the plurality of available node identifiers;

If the node identifier to be deployed is successfully matched with the one of the plurality of available node identifiers, the node corresponding to the successfully available node identifier is used as the node to be deployed;

If the node identifier to be deployed and the plurality of available node identifiers fail to match, an error prompt is output to the user.
The computer readable storage medium according to claim 16, wherein if the node to be deployed is installed with a proxy client, the computer readable instructions are executed by at least one processor to implement the following steps:

Automatically transmitting a deployment instruction corresponding to the request information to the control server;

Establishing a socket connection with the proxy client, so that the control server, after receiving the deployment instruction, causes the proxy client to deploy the node to be deployed according to the deployment instruction. The Kubernetes slave node of the Kubernetes cluster.
The computer readable storage medium of claim 18, wherein if the deployment instruction includes an authentication signature value, the computer readable instructions are further executed by the at least one processor to:

Extracting parameters other than the authentication signature value from the deployment instruction, and calculating a calculated signature value of the parameter by using a parameter signature algorithm;

And if the authentication signature value is equal to the calculated signature value, performing an operation of establishing a socket connection between the control server and the proxy client;

If the authentication signature value is not equal to the calculated signature value, the subsequent operations are stopped.
The computer readable storage medium according to any one of claims 16 to 19, wherein the computer readable instructions are executed by at least one processor to implement the following steps:

Obtaining binary files related to the Kubernetes cluster from a file server;

Obtaining a slave node service file in the binary file, and acquiring a node address of the node to be deployed;

The slave node service is automatically configured based on the slave node service file and the node address.