CN113169952A - Container cloud management system based on block chain technology - Google Patents
Container cloud management system based on block chain technology Download PDFInfo
- Publication number
- CN113169952A CN113169952A CN201880097738.0A CN201880097738A CN113169952A CN 113169952 A CN113169952 A CN 113169952A CN 201880097738 A CN201880097738 A CN 201880097738A CN 113169952 A CN113169952 A CN 113169952A
- Authority
- CN
- China
- Prior art keywords
- application
- user
- node
- master
- container cloud
- 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.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
Abstract
The invention discloses a container cloud management system based on a block chain technology, which comprises a plurality of management Node masters and a plurality of working nodes, wherein each management Node Master provides a cluster distributed storage database etcd; when the user deploys or deletes the application to the container cloud management system through the working Node, the management Node Master performs user signature verification and/or data consistency verification based on a block chain technology consensus algorithm. The container cloud management system can effectively improve the system security, gives the user the management authority to own resources, and the platform side and any third party can not operate the application of the user and read the operation record of the user and the data of the user, so that the user can conveniently use the independent public cloud platform provided by the third party on the premise of not worrying about the application and data security problems, and the use cost of the user is effectively reduced.
Description
The invention belongs to the technical field of computer cloud computing, and particularly relates to a container cloud management system based on a block chain technology.
Cloud computing technology can provide available, convenient, and on-demand network access into a shared pool of configurable computing resources (resources including networks, servers, storage, applications, etc.) that can be provisioned quickly with little administrative effort or interaction with service providers.
Currently, the cloud computing has the following forms: public clouds, private clouds, and hybrid clouds, where public clouds are considered the primary modality of cloud computing. The public cloud generally refers to a cloud which is provided by a third-party provider for a user and can be used for free or at low cost, the cloud can be generally used through the Internet, and the core attribute of the public cloud is a shared resource service.
In the field of cloud computing, cloud computing platforms can be classified into three types, i aas (infrastructure as a service), PaaS (platform as a service), and SaaS (software as a service), according to their functions. Among them, in the PaaS (platform as a service) field, there are currently mainly three service schemes:
1. the PaaS service is an application management platform provided by an IaaS service provider for users, and aims to enable the users to manage the applications of the users more conveniently and provide value-added services.
2. The PaaS public cloud services, such as gae (google App engine) of google, sae (sina App engine) of new waves, and the like, can allow users to complete all life cycles from application development, construction, testing, deployment, and the like in the PaaS platform, but only support limited development languages, and all applications and data are on the PaaS common cloud platform.
3. In the PaaS private cloud service, some users do not want to use an application management platform provided by a PaaS public cloud platform and an IaaS service provider in order to protect the application security and data security developed by the users, but select a self-built PaaS private cloud platform, and the platform can be developed by the users and can also select a service provider in a project implementation mode.
The above schemes 1-3 all require the user to bind the resources, applications, data, and platforms together for installation, deployment, operation, and maintenance. Among them, the solutions 1 and 2 need to tightly couple the resources, the applications, the data, and the platform, so neither of the solutions 1 and 2 can be adopted by the user who is concerned about the security of the applications and the data.
Although the scheme 3 is a preferred option for users who pay attention to application and data security, in the process of building the cloud platform, not only the self-building of the platform needs to invest higher personnel cost and server cost, but also the selection of external providers needs project implementation cost with a high price, and the cost and the platform implementation period are higher than those of the schemes 1 and 2.
However, it is expected that, with the continuous development of cloud computing technology, the PaaS public cloud platform will be accepted by more and more users due to the advantages of flexibility, low cost, payment according to usage amount, and the like, and as long as the security problem of the existing PaaS public cloud platform can be solved, the PaaS public cloud platform will be expected to become a preferred option for users to deploy internet applications.
Therefore, how to solve the security problem of the PaaS public cloud platform which is most worried by the user at present and how to enable the user to conveniently apply the independent PaaS public cloud platform provided by the third party on the premise of not worrying about the application and data security problems is a problem to be solved by the invention.
Disclosure of Invention
The invention aims to provide a container cloud management system based on a block chain technology, which is used for removing the tight coupling among resources, applications, data and a platform, reducing the use cost of a user and solving the safety problem of the resources, the applications and the data. The security issues here may relate to: 1. in a container cloud management platform, how to solve the problem of management authority of a user on own resources is solved, so that a platform side cannot operate the resources of the user; 2. in a container cloud management platform, how to solve the problem of operation authority of a user on application and data, so that a platform side cannot operate the application of the user and read operation records of the user and the data of the user with minimum authority; 3. the problem of how to ensure that the normal use of the platform is not influenced and the application service and the data security of a user are not influenced when part of management nodes of the container cloud management platform are crashed or invaded is solved; 4. how to solve the auditing problem of the operation records of the user applied to the container cloud management platform.
The purpose of the invention is realized by the following technical scheme:
the invention discloses a container cloud management system based on a block chain technology, which comprises a plurality of management Node masters, wherein each of the management Node masters can be communicated with other management Node masters through a network, each of the management Node masters can receive and process an access request of a working Node, and the access request is a request of the working Node for adding into the container cloud management system; before the working Node sends the access request to the Master, the user generates a public and private key account for the access request based on the working Node.
Further, the access request includes that the working Node registers self information to the Master; the self information comprises a host name, a kernel version, operating system information and a docker version of the working Node; the management Node Master processes the access request of the working Node, and the management Node Master brings the working Node into cluster scheduling, and monitors the state of the working Node in the cluster scheduling in real time.
Further, the real-time monitoring specifically comprises: the working Node sends the state information to the Master Node at regular time, and the Master Node writes the received state information into the etcd database, and analyzes and processes the state information.
Further, each of the plurality of Master management nodes provides a cluster distributed storage database etcd, and the Master management Node processing the access request of the working Node includes the Master management Node writing the self information of the working Node into the cluster distributed storage database etcd.
Further, after the access request, the Master of the management Node synchronizes the information and the state information of the accessed working Node to all the masters of other management nodes in the container cloud management system.
Preferably, after the access request, the accessed working Node may communicate with each of the plurality of management nodes masters through a network, and the communicating between the working Node and each of the plurality of management nodes masters includes the working Node monitoring an operation of the management Node masters for an application.
Preferably, the operation for the application includes: creating an application, modifying an application, and deleting an application; when the operation aiming at the application is to create the application, the working Node creates the application according to the creation requirement; when the operation aiming at the application is to modify the application, the working Node modifies the application according to modification requirements; when the operation for the application is to delete the application, the working Node deletes the application according to a deletion requirement, the application is based on Pod, and the operation for the application includes: create Pod, modify Pod, and delete Pod.
In the invention, a user can access own equipment into a container cloud management system to become a working Node of the system, and the user can send an application creation request to any one of a plurality of management nodes Master through the accessed working Node, wherein the application creation request carries a user public key, signature information signed by the user using a private key and original template data used for creating application.
Further, the management node Master can receive and respond to the application creation request, the management node Master responding to the application creation request includes performing user signature verification on the application creation request by using a user public key, and if the user signature verification fails, the management node Master refuses to create the application and prompts that the user application creation fails.
Further, if the user signature is successfully verified, the management node Master performs a write operation of writing the application creation request into the cluster distributed storage database etcd of the management node Master, wherein the write operation includes distributing the application creation request to all other management node masters.
Preferably, the write operation further includes verifying, by using a block chain consensus algorithm, data consistency and signature data of all cluster distributed storage databases etcd in the container cloud management system based on the application creation request, where the verifying specifically includes: if the number of the cluster distributed storage databases etcd passing the verification in the container cloud management system is more than half, writing the application creation request into each cluster distributed storage database etcd in the container cloud management system; otherwise, each cluster distributed storage database etcd in the container cloud management system refuses to write the application creation request, and prompts a user that the application creation fails.
Further, the screening, by the management Node Master, of the working nodes meeting the conditions is used for creating an application, and the screening, by the management Node Master, of the working nodes meeting the conditions is used for creating an application specifically as follows: and the management Node Master screens the working nodes meeting the conditions according to the scheduling rules.
Further, the management node Master writes the screening result into the cluster distributed storage database etcd.
Further, the work Node acquires and processes the creation application through a Watch mechanism, where the acquiring the creation application includes: the working Node obtains the user public key carried by the application creation request, the signature information signed by the user using the private key, and the original template data used for creating the application.
Further, the processing the create application comprises: the working Node uses the user public key to verify the user signature based on the application creation request, if the user signature is verified successfully, the application is created, and the user application is prompted to be created successfully; and if the user signature verification fails, refusing to create the application and prompting the user that the application creation fails.
Further, the working Node sends the created result state and the subsequent operation state to the Master, and the Master can monitor the state of the system resource in real time, judge and process the system resource according to the current state, and restore the resource state to the expected state.
In addition, the user can also send an application deletion request to any one of the management nodes Master through the accessed working Node, wherein the application deletion request carries a user public key and signature information signed by the user using a private key.
Further, the management node Master can receive and respond to the application deletion request, the management node Master responds to the application deletion request and includes user public key to conduct user signature verification on the application deletion request, and if the user signature verification fails, the management node Master refuses to delete the application and prompts the user that the application deletion fails.
Further, if the user signature is verified successfully, the management node Master queries a target application resource object in all cluster distributed storage databases etcd in the container cloud management system.
Preferably, if the user signature is successfully verified, the management node Master distributes the application deletion request to all other management node masters.
Further, all cluster distributed storage databases etcd in the container cloud management system use a block chain consensus algorithm to verify data consistency and signature data based on the application deletion request, where the verification specifically includes: if the number of the cluster distributed storage databases etcd passing the verification in the container cloud management system is more than half, the management Node Master sends the application deletion request to the corresponding working Node; otherwise, the management node Master refuses the application deletion request and prompts the user that the application creation fails.
Further, the corresponding work Node receives and processes the application deletion request, where the processing of the application deletion request specifically includes: the working Node uses the user public key to verify the user signature based on the application deletion request, if the user signature verification fails, the application deletion is refused, and the user application deletion failure is prompted; and if the user signature is successfully verified, deleting the application.
Further, after the application is deleted, the corresponding working Node sends the deletion result to the Master, and the Master executes a write operation of writing the deletion result into the clustered distributed storage database etcd.
Further, the write operation further includes that all cluster distributed storage databases etcd in the container cloud management system use a block chain consensus algorithm to verify the data consistency and signature data of the deletion result, where the verification specifically includes: if the number of the cluster distributed storage databases etcd passing the verification in the container cloud management system is more than half, writing the deletion result into each cluster distributed storage database etcd in the container cloud management system, and prompting a user that the application deletion is successful; otherwise, each cluster distributed storage database etcd in the container cloud management system refuses to write the deletion result, and prompts a user to delete application failure.
Preferably, the application to which the present invention relates is Pod based.
Compared with the prior art, the container cloud management system based on the block chain technology provided by the invention can enable a user to have own management authority on own resources, and a platform side and any third party cannot operate the application of the user and read the operation record of the user and the data of the user, so that the user can conveniently apply the container cloud management platform independent of the third party on the premise of not worrying about the application and data safety problems, and the use cost of the user can be effectively reduced.
FIG. 1 is a schematic diagram of a cluster architecture of a prior art container cloud management system;
FIG. 2 is a business flow diagram of a prior art container cloud management system;
fig. 3 is a service flow diagram of a container cloud management system based on a blockchain technique according to an embodiment of the present invention.
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention will be described in detail with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and should not be taken to be limiting.
As is known, the container technology is increasingly used in cloud computing, and the container as referred to herein is essentially a virtualization technology, which is different from a virtual machine in that the virtual machine is a hardware virtualization and the container is a virtualization for an operating system. Generally, a container packages applications and application execution environments together, and when the applications are deployed, the whole container is directly deployed, because the container is provided with the application execution environments, the problem that the applications are deployed abnormally due to environment changes in the deployment process does not exist, and one-time construction and all-around execution can be realized.
In general, the existing container cloud management system is based on a container management platform for managing containers, and the existing container management platform includes a kubernets container management platform, a mess container management platform, and a Swarm container management platform.
The Kubernetes container management platform is the most popular distributed architecture leading scheme based on the container technology at present, and adopts a distributed architecture to divide machines in a cluster into a management Node Master and a group of working nodes Node. The main functions of the kubernets container management platform include: the Docker is used for packaging, instantiating and running the application program, running and managing containers across hosts in a cluster mode, solving the communication problem between the containers running among different hosts and the like.
For convenience of description and illustration, the improved container cloud management system based on the blockchain technology provided by the embodiments of the present invention will be described below based on the kubernets container management platform, but it will be understood by those skilled in the art that the container cloud management system based on the blockchain technology of the present invention may also be based on other types of container management platforms.
Fig. 1 shows a cluster architecture of a container cloud management system of the prior art. Taking Kubernetes container management platform as an example, in fig. 1, a cluster architecture of the Kubernetes container management platform mainly includes a management Node Master, a work Node, and a Storage Node Storage.
Typically, the management node Master provides: providing an API Server of service through a kube-API Server process, wherein the kube-API Server process is an API interface of a cluster and is a unique entry for performing operations such as adding, deleting, modifying and searching on all resources; providing a Scheduler for service through a kube-Scheduler process, wherein the kube-Scheduler process is responsible for scheduling cluster resources, such as binding Pod (the smallest management element in Kubernetes) to a working Node; providing a Controller Manager of service through a kube-Controller-Manager process, wherein the kube-Controller-Manager process is an automatic management control center of a cluster and is responsible for management and automatic repair processes of a working Node, a Pod copy, a service end point, a name space, a service account, a resource quota and the like in the cluster, and ensuring that the cluster is in an expected working state; and the etcd is used as a Storage node Storage, and the etcd is a cluster distributed Storage database which is responsible for storing persistent data information.
The processes in the management node Master are used for realizing management functions of resource management, Pod scheduling, elastic expansion, safety control, system monitoring and error correction and the like of the whole cluster, and are all completed automatically.
Further, the working Node provides: the method comprises the following steps that firstly, a kubel process is used for managing Pods, containers, mirror images, volumes and the like, and the management of nodes is achieved; a kube-proxy process which provides network agent and load balance to realize communication with the kube-api in the Master of the management node; and thirdly, a docker engine process which is responsible for the container management work of the nodes.
These processes in the working Node are responsible for the creation, starting, monitoring, restarting, destruction of Pod, and implementing a load balancer in software mode.
Fig. 2 shows a business flow of a container cloud management system of the related art. Taking a kubernets container management platform as an example, as shown in fig. 2, the service flow of the conventional kubernets container management platform mainly includes:
(1) the working Node access flow is as follows:
in the access process, firstly, a kubel process service is started by a working Node to be accessed, the working Node is actively registered to a management Node Master in a container cloud management system by means of an automatic registration mechanism of the kubel process service, data such as a host name, a kernel version, operating system information, a docker version and the like of the working Node are carried during registration, and after the management Node Master receives registration information of the working Node, the registration information is written into an etcd in the management Node Master and the working Node which is successfully registered is brought into cluster scheduling.
Further, the kube-controller-manager process in the Master of the management Node monitors the status of the registered work Node in real time.
Further, after the kubel process completes registration, the state information of the working Node of the kubel process is reported to the Master of the management Node at regular time, the Master of the management Node writes the received state information into the etcd of the Master of the management Node, and meanwhile, corresponding analysis processing is carried out based on the state information of the working Node.
Further, the kubel process of the working Node may simultaneously monitor the/registry/posts/$ nodame and/registry/posts directory in the etcd of the Master of the management Node through the API Server of the Master of the management Node by means of the Watch mechanism (observation notification mechanism), and all operations for Pod will be monitored by the kubel process.
Normally, the working Node will respond to the above mentioned snooping as follows: if finding the Pod newly bound to the working Node, then creating the Pod according to the requirement of the Pod list; if the modification of the created Pod in the working Node is found, the Pod is modified correspondingly; and executing corresponding Pod deleting operation if finding that the Pod in the working Node needs to be deleted.
(2) An application deployment process:
step S1: a user uses a client on a working Node to submit a Pod creation request (supporting data in JSON or YAML format) to a management Node Master through a kubecect (a Kubernetes client can be used for directly operating Kubernetes) or a RESTful API interface;
step S2: a kube-api server process in the management node Master receives and processes the Pod creation request submitted by a user, and stores original template data to an etcd in the management node Master;
step S3: the kube-seciduler process in the management Node Master tries to distribute a working Node for the Pod by discovering that a new unbound Pod is generated;
step S4: the kube-scheduler process filters and screens working nodes (such as CPU and Memory required by Pod) meeting conditions according to a scheduling rule, selects the working Node with the highest score according to the current running state of the screened working Node, binds the Pod to the working Node, and then writes the binding result into the etcd in the management Node Master;
step S5: a kubel process in a working Node discovers and acquires a newly created Pod task through a Watch mechanism (an observation notification mechanism), and then calls a Docker API (the Docker API is an external operation interface provided by a Docker engine process) to create and start the Pod;
step S6: the kubel process will report the created result state and the subsequent running state to the Master of the management node periodically;
step S7: and simultaneously monitoring the state of the resources in the cluster in real time by using a kube-controller-manager process in the Master of the management node, judging and processing according to the current state, and trying to restore the state of the resources to the expected state.
As follows, table 1 shows a specific format of kubecect sending data in the prior art:
TABLE 1
(3) And (3) application deletion flow:
step S1: a user uses a client to submit a Pod deletion request to a Master of a management node through a kubecect or RESTful API (application program interface);
step S2: a kube-api server process in the management Node Master receives and processes the Pod delete request submitted by a user, queries a resource object matched with the Pod delete request in an etcd in the management Node Master, generates a delete task and issues the delete task to a kube process in a working Node;
step S3: a kubel process in the working Node calls a Docker API (the Docker API is an external operation interface provided by a Docker engine process) to delete Pod related containers, clear Pod related data and release resources;
step S4: the kubel process reports the deletion result to a kube-api server process in a Master of a management node;
step S5: and the kube-apiserver process updates the result to the etcd in the Master of the management node and cleans the resource object.
Based on the above contents, it can be seen from the specific service process of the existing container cloud management system that the whole process requires close coupling between resources, applications, data and a platform, and has a potential safety hazard, a user has no control right on the management right of own resources, the operation right of applications and data, and the like, and the platform side can operate the resources of the user or operate the applications of the user and read the operation records of the user and the data of the user, and if a certain management node or management nodes Master in the container cloud management system crashes or is overcome, the use and safety of the whole system can be affected, and the application and service safety of all users can be further affected.
Nowadays, the blockchain technology is increasingly used for its high security. The blockchain technology is a brand new distributed infrastructure and computing mode that uses blockchain data structures to verify and store data, uses distributed node consensus algorithms to generate and update data, uses cryptography to secure data transmission and access, and uses intelligent contracts composed of automated script codes to program and manipulate data. The block chain technology has the obvious decentralization characteristic and is open, autonomous and information cannot be tampered. The block chain technology realizes trust establishment and rights and interests acquisition among different nodes through a consensus algorithm, and ensures that data in all nodes in a cluster in a distributed system are completely the same and can reach a certain proposal. Common block chain consensus algorithms include a Raft consensus algorithm, a Paxos consensus algorithm, a workload attestation (POW), a rights and interests attestation (POS), a delegation rights and interests attestation (DPOS), and the like.
From the above, the blockchain technology can effectively improve the security and consistency of the distributed system. Based on the knowledge, in order to further optimize the business process of the container cloud management system and improve the use safety and reliability of the system, the embodiment of the invention aims to provide an improved container cloud management system based on the block chain technology.
Specifically, the container cloud management system provided in the embodiment of the present invention includes: the system comprises at least three management nodes Master, wherein the management nodes Master can provide a kube-api server process, a kube-scheduler process and a kube-controller-manager process and is provided with a cluster distributed storage database etcd; at least one work Node, which can provide a kubel process, a kube-proxy process, and a docker engine process.
Further, in the container cloud management system based on the block chain technology according to the embodiment of the present invention, at least three management nodes masters may communicate with each other through a network, and each working Node may communicate with any one of the management nodes masters through the network.
Fig. 3 shows a business process of the container cloud management system according to the embodiment of the present invention, where the process specifically includes:
(1) the working Node access flow is as follows:
before a user wants to access a container cloud management system by using equipment thereof as a working Node, each user needs to generate a public and private key account in advance, wherein the public key can be public to all persons, the private key is kept by the user and cannot be leaked out, and once the private key is leaked out, the safety cannot be guaranteed.
In the access process, firstly, each working Node to be accessed starts a kubbelet process, the working Node is actively registered to one management Node Master in a container cloud management system by means of an automatic registration mechanism of the kubbelet process, data such as a host name, a kernel version, operating system information, a docker version and the like of the working Node are carried during registration, and after the management Node Master receives registration information of the working Node, the registration information is written into an etcd in the management Node Master, and the working Node which is successfully registered is brought into cluster scheduling.
Further, the kube-controller-manager process in the Master of the management Node monitors the status of the registered work Node in real time.
Further, after the kubel process completes registration, the state information of the corresponding working Node is reported to the Master of the management Node at regular time, and the Master of the management Node also writes the received state information into the etcd and performs corresponding analysis processing based on the state information of the working Node.
Further, the kubel process in the working Node simultaneously listens to the/registry/posts/$ nodame and/registry/posts directory in the etcd in the Master of the management Node through the API Server of the Master of the management Node by means of the Watch mechanism (observation notification mechanism), and all operations for Pod will be monitored by the kubel process.
Normally, the working Node will respond to the above mentioned snooping as follows: if finding the Pod newly bound to the working Node, then creating the Pod according to the requirement of the Pod list; if the modification of the created Pod in the working Node is found, the created Pod is modified correspondingly; and executing corresponding Pod deleting operation to delete the Pod if the Pod in the working Node is found to be required to be deleted.
Particularly, after any working Node in the container cloud management system according to the embodiment of the present invention accesses itself to one of the management nodes Master in the system through the access process, the registration information data may be synchronized to all other management nodes masters in the system through the kube-api server process and etcd in the management Node Master, so that one working Node does not need to correspond to a specific management Node or management nodes Master, but can flexibly select any management Node Master in the network to access.
Further, although the working Node is accessed through one of the management nodes Master, after the working Node is accessed to the container cloud management system, the working Node can communicate with all other management nodes Master in the system through the network, and a user can deploy an application in the system through the other management nodes Master in the system based on the working Node.
(2) An application deployment process:
step S1: when application deployment is needed, a user uses a client on a working Node accessed to a container cloud management system to submit a Pod creation request (supporting data in a JSON or YAML format) to one management Node Master in the container cloud management system through a kubecect (a Kubernetes self-contained client can be used for directly operating the Kubernetes) or a RESTful API interface, wherein the Pod creation request carries a user public key, signature information signed by the user using a private key and original template data used for creating a Pod;
step S2: a kube-api server process in the Master of the management node receives, processes and analyzes the Pod creation request submitted by a user;
step S3: the kube-api server process uses a user public key to carry out user signature verification on the Pod creation request, if the user signature verification fails, the creation of a corresponding Pod is refused, and the user is prompted to fail in the Pod creation;
step S4: if the kube-api server process successfully verifies the user signature, a write operation of attempting to write the Pod creation request into the etcd in the Master of the management node is executed, and correspondingly, the etcd also distributes the Pod creation request to the etcd in all the masters of other management nodes according to an internal consensus algorithm;
step S5: if the write operation is successfully executed, the kube-sechdler process in the Master of the management Node finds that a new unbound Pod is generated, and tries to allocate a required working Node to the Pod;
step S6: the kube-scheduler process screens working nodes meeting conditions (such as CPU, Memory and other resources required by Pod) according to a scheduling rule, selects the best working Node according to the current running state of the screened working nodes, selects the working Node with the highest score, binds the Pod to the working Node, and then writes the binding result into an etcd in a management Node Master;
step S7: a kubel process in a working Node discovers and acquires a new Pod creation task through a Watch mechanism (observation notification mechanism);
step S8: the kubelet process receives the Pod creation task, uses a user public key to verify the user signature, refuses to create the Pod if the user signature is verified to be failed, and prompts the user that the Pod creation is failed;
step S9: if the kubelet process successfully verifies the user signature, a Docker API (the Docker API is an external operation interface provided by a Docker engine process) is called to create and start the Pod, and the user is prompted that the Pod is successfully created;
step S10: the kubel process will report the created result state and the subsequent running state to the Master of the management node periodically;
step S11: and a kube-controller-manager process in the Master of the management node monitors the state of the resources in the cluster in real time, judges and processes the resources according to the current state and tries to restore the resource state to the expected state.
Specifically, in the above step S4: when the kube-api server process tries to write the Pod creation request into the etcd in the Master, the etcd performs the second verification of data consistency and signature data in the etcd in all other masters in the system through the Raft consensus algorithm.
Specifically, the etcd in all the management nodes Master in the container cloud management system in the embodiment of the present invention is integrally regarded as an etcd cluster, and the secondary verification specifically includes: when the quantity of etcds larger than 1/2 in the etcd cluster passes the secondary verification, the Pod creation requester can be successfully written into each etcd in the etcd cluster, then the etcd in the management node Master returns the successful data writing information to the kube-api process, and the step S5 is continuously executed; if the quantity of etcds larger than or equal to 1/2 in the etcd cluster does not pass the secondary verification, the data and operation consensus fails, the etcd cluster refuses to write the Pod creation request sent by the kube-api server process, and then the etcd in the management node Master returns data write failure information to the kube-api server process to prompt a user that the Pod creation fails.
Based on the above, in the step S3, if the kube-api server process fails to verify the user signature, the Pod creation request is directly rejected; in the step S4, if the data write failure information is returned to the kube-apiserver process, it means that the kube-apiserver process has no right to write the Pod creation request into the etcd cluster, and at this time, the kube-apiserver process also directly refuses to accept the Pod creation request.
Preferably, although the step S4 uses the Raft consensus algorithm, those skilled in the art will understand that other suitable block chain consensus algorithms can be applied to the step S4.
As follows, table 2 shows a specific format of kubecect sending data in the embodiment of the present invention:
TABLE 2
(3) And (3) application deletion flow:
step S1: a user uses a client to submit a Pod deletion request to one management node Master in a container cloud management system through a kubecect or RESTful API (application programming interface), wherein the Pod deletion request carries a user public key and signature information signed by a user using a private key;
step S2: a kube-api server process in the Master of the management node receives, processes and analyzes the Pod delete request submitted by a user;
step S3: the kube-apiserver process uses a user public key to carry out user signature verification on the Pod deletion request, if the user signature verification fails, the Pod deletion is refused, and the user is prompted to fail in the Pod deletion;
step S4: if the kube-apiserver process successfully verifies the user signature, a resource object matched with the kube-apiserver process in the etcd in the container cloud management system is inquired, and a Pod deletion task is generated, the etcd cluster also verifies the data consistency and signature data of the Pod-apiserver Pod deletion task through a Raft consensus algorithm, and the verification specifically comprises the following steps: firstly, when the etcd more than 1/2 in the etcd cluster passes the verification, responding to the kube-apiserver process that the verification is successful, and the kube-apiserver process issues the Pod deleting task to the kube process in the corresponding working Node; if the quantity of the etcds larger than or equal to 1/2 in the etcd cluster does not pass the verification, directly rejecting the Pod delete task and prompting the user that the Pod delete fails;
step S5: the kubelet process in the corresponding working Node receives the Pod deleting task, and uses the user public key again to verify the user signature, if the user signature is failed to verify, the kubelet process refuses to delete the corresponding Pod, and prompts the user that the Pod deletion is failed;
step S6: if the kubel process is successful in verifying the user signature, calling a Docker API (the Docker API is an external operation interface provided by a Docker engine process) to delete the corresponding Pod, cleaning related data of the Pod, and releasing resources;
step S7: the kubel process reports the deletion result to the kube-apiserver process;
step S8: the kube-apiserver process writes the Pod deletion result into the etcd cluster, and the etcd cluster verifies the data consistency and the signature data through the Raft consensus algorithm again, wherein the verification specifically comprises the following steps: when the quantity of etcds larger than 1/2 in the etcd cluster passes the verification, the etcd cluster receives the writing of the Pod deletion result, responds to the kube-apiserver process, the writing of the Pod deletion result is successful, and prompts a user that the Pod deletion is successful; and if the quantity of the etcds larger than or equal to 1/2 in the etcd cluster does not pass the verification, directly rejecting the writing of the Pod delete result and prompting the user that the Pod delete fails.
Preferably, although the step S8 uses the Raft consensus algorithm, those skilled in the art will understand that other suitable block chain consensus algorithms can be applied in the step S8.
(4) The user log auditing function is as follows:
all the operation logs in the etcd in the container cloud management system adopt an additional mode and do not support log deletion operation, so that the individual operation logs can be checked and tracked at any time to complete related log auditing operation.
The container cloud management system provided by the invention is improved based on the block chain technology and the consensus algorithm, the safety problems of resources, applications and data are well solved, a user has the management authority of own resources, the platform side cannot operate the applications of the user and read the operation records of the user and the data of the user, and the user can conveniently apply an independent public cloud platform provided by a third party on the premise of not worrying about the safety problems of the applications and the data.
Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention, and that variations, modifications, substitutions and alterations can be made in the above embodiments by those of ordinary skill in the art without departing from the principle and spirit of the present invention.
Claims (43)
- A container cloud management system based on a block chain technology comprises a plurality of management Node masters, wherein each of the management Node masters can be communicated with other management Node masters through a network, each of the management Node masters can receive and process an access request of a working Node, and the access request is that the working Node requests to join the container cloud management system; before the working Node sends the access request to the Master, the user generates a public and private key account for the access request based on the working Node.
- The system according to claim 1, wherein the access request includes information that the worker Node registers itself with the Master.
- The system according to claim 2, wherein the self information includes a host name, a kernel version, operating system information, and a docker version of the work Node.
- The system according to claim 2 or 3, wherein each of the plurality of management Node masters provides a cluster distributed storage database etcd, and the processing of the access request of the working Node by the management Node Master includes the writing of the self information of the working Node into the cluster distributed storage database etcd by the management Node Master.
- A container cloud management system according to any of claims 1-4, wherein the processing of the access request of the worker Node by the Master of the management Node comprises the Master of the management Node including the worker Node in a cluster schedule.
- The system of claim 5, wherein the Master monitors the status of the worker Node incorporated in the cluster scheduling in real time.
- The system according to claim 6, wherein the real-time monitoring specifically comprises: the working Node sends the state information to the Master Node at regular time, and the Master Node writes the received state information into the etcd database, and analyzes and processes the state information.
- A container cloud management system based on block chain technology according to any of claims 1-7, characterized in that after the access request, the management Node Master synchronizes the self-information and state information of the accessed working Node to all other management Node masters in the container cloud management system.
- A container cloud management system according to any of claims 1-8, wherein said accessed working nodes Node can communicate with each of said plurality of management nodes Master via a network after said access request.
- The system of claim 9, wherein the working Node communicates with each of the plurality of masters, and the working Node listens to an application specific operation of the masters.
- The system according to claim 10, wherein the operations for the application comprise: create applications, modify applications, and delete applications.
- A container cloud management system based on block chain technology according to claim 10 or 11, wherein when the operation for application is creating application, the worker Node creates application according to creation requirement; when the operation aiming at the application is to modify the application, the working Node modifies the application according to modification requirements; when the operation for the application is to delete the application, the working Node deletes the application according to the deletion requirement.
- A container cloud management system based on blockchain technology according to any one of claims 10 to 12, wherein the application is Pod based, and the operation on the application comprises: create Pod, modify Pod, and delete Pod.
- A container cloud management system based on block chain technology according to any of claims 1-13, characterized in that a user can send an application creation request to any of the management nodes Master through the working Node to which the user is connected.
- The system of claim 14, wherein the application creation request carries signature information of a user public key and a user signature using a private key, and original template data for creating the application.
- A container cloud management system based on block chaining technology according to claim 14 or 15, wherein said management node Master is capable of receiving and responding to said application creation request.
- The system of claim 16, wherein the management node Master responds to the application creation request by performing user signature verification on the application creation request using a user public key, and if the user signature verification fails, rejecting creation of the application and prompting a user of the application creation failure.
- The system of claim 17, wherein if the user signature is successfully verified, the Master performs a write operation of writing the application creation request to the clustered and distributed storage database etcd.
- The system according to claim 18, wherein the write operation comprises distributing the application creation request to all other management nodes masters.
- The system according to claim 19, wherein the write operation further comprises a verification of data consistency and signature data by all clustered distributed storage databases etcd in the system based on the application creation request by using a block chain consensus algorithm, wherein the verification specifically comprises: if the number of the cluster distributed storage databases etcd passing the verification in the container cloud management system is more than half, writing the application creation request into each cluster distributed storage database etcd in the container cloud management system; otherwise, each cluster distributed storage database etcd in the container cloud management system refuses to write the application creation request, and prompts a user that the application creation fails.
- A container cloud management system based on block chain technology according to claim 20, wherein said block chain consensus algorithm is a Raft consensus algorithm.
- The system according to claim 20 or 21, wherein the Master screens qualified working nodes for creating applications.
- The system according to claim 22, wherein the management Node Master filters the qualified work nodes to create an application specifically as follows: and the management Node Master screens the working nodes meeting the conditions according to the scheduling rules.
- The system according to claim 23, wherein the Master writes the filter result into its clustered and distributed storage database etcd.
- A container cloud management system according to any of claims 22-24, wherein said work Node acquires and processes said create application through a Watch mechanism.
- The system according to claim 25, wherein said obtaining the creation application comprises: the working Node obtains the user public key carried by the application creation request, the signature information signed by the user using the private key, and the original template data used for creating the application.
- A container cloud management system based on blockchain technology according to claim 25 or 26, wherein said processing said create application comprises: the working Node uses the user public key to verify the user signature based on the application creation request, if the user signature is verified successfully, the application is created, and the user application is prompted to be created successfully; and if the user signature verification fails, refusing to create the application and prompting the user that the application creation fails.
- The system of claim 27, wherein after the application is successfully created, the worker Node periodically sends a creation result status and a subsequent operation status to the Master.
- A container cloud management system according to any one of claims 14 to 28, wherein the management node Master is capable of monitoring the state of system resources in real time, determining processing according to the current state, and restoring the resource state to a desired state.
- A container cloud management system according to any of claims 1-29, wherein a user can send an application deletion request to any of said plurality of management nodes masters via said working Node to which the user is connected.
- The system according to claim 30, wherein the application deletion request carries signature information of a public key of the user and a signature of the user using a private key.
- The system according to claim 31, wherein the management node Master is capable of receiving and responding to the application deletion request.
- The system of claim 32, wherein the management node Master responds to the application deletion request by performing user signature verification on the application deletion request using a user public key, and if the user signature verification fails, refusing to delete the application and prompting the user that the application deletion fails.
- The system of claim 33, wherein if the user signature is successfully verified, the Master queries target application resource objects in all cluster distributed storage databases etcd in the system.
- The system according to claim 34, wherein if the user signature is successfully verified, the Master distributes the application deletion request to all other masters.
- The system according to claim 35, wherein all clustered distributed storage databases etcd in the system perform verification of data consistency and signature data based on the application deletion request by using a block chain consensus algorithm, and the verification specifically comprises: if the number of the cluster distributed storage databases etcd passing the verification in the container cloud management system is more than half, the management Node Master sends the application deletion request to the corresponding working Node; otherwise, the management node Master refuses the application deletion request and prompts the user that the application creation fails.
- The system of claim 36, wherein the blockchain consensus algorithm is a Raft consensus algorithm.
- The system according to claim 36 or 37, wherein the corresponding work Node receives and processes the application deletion request, and the processing of the application deletion request specifically includes: the working Node uses the user public key to verify the user signature based on the application deletion request, if the user signature verification fails, the application deletion is refused, and the user application deletion failure is prompted; and if the user signature is successfully verified, deleting the application.
- The system according to claim 38, wherein after deleting an application, the corresponding work Node sends a deletion result to the Master.
- The system according to claim 39, wherein the Master performs a write operation to write the delete result to the clustered and distributed storage database etcd.
- The system according to claim 40, wherein the write operation further comprises a verification of data consistency and signature data of the deletion result by all clustered distributed storage databases etcd in the system using a block chain consensus algorithm, wherein the verification specifically comprises: if the number of the cluster distributed storage databases etcd passing the verification in the container cloud management system is more than half, writing the deletion result into each cluster distributed storage database etcd in the container cloud management system, and prompting a user that the application deletion is successful; otherwise, each cluster distributed storage database etcd in the container cloud management system refuses to write the deletion result, and prompts a user to delete application failure.
- A container cloud management system based on block chain technology according to claim 41, wherein said block chain consensus algorithm is a Raft consensus algorithm.
- A container cloud management system based on blockchain technology according to any one of claims 14 to 42, wherein said application is Pod based.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/CN2018/108575 WO2020062131A1 (en) | 2018-09-29 | 2018-09-29 | Container cloud management system based on blockchain technology |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113169952A true CN113169952A (en) | 2021-07-23 |
| CN113169952B CN113169952B (en) | 2022-12-02 |
Family
ID=69952642
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201880097738.0A Active CN113169952B (en) | 2018-09-29 | 2018-09-29 | Container cloud management system based on block chain technology |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN113169952B (en) |
| WO (1) | WO2020062131A1 (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113656148A (en) * | 2021-08-20 | 2021-11-16 | 北京天融信网络安全技术有限公司 | Container management method and device, electronic equipment and readable storage medium |
| CN115499442A (en) * | 2022-11-15 | 2022-12-20 | 四川华西集采电子商务有限公司 | Rapid deployment type cloud computing architecture based on container arrangement |
| CN115550375A (en) * | 2022-08-31 | 2022-12-30 | 云南电网有限责任公司信息中心 | System, method and equipment for realizing block chain lightweight based on containerization technology |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111580930A (en) * | 2020-05-09 | 2020-08-25 | 山东汇贸电子口岸有限公司 | Native cloud application architecture supporting method and system for domestic platform |
| CN112333004A (en) * | 2020-10-13 | 2021-02-05 | 北京京东尚科信息技术有限公司 | Container cluster gene-based proprietary cloud streaming type reconstruction and verification method and device |
| US11575499B2 (en) | 2020-12-02 | 2023-02-07 | International Business Machines Corporation | Self auditing blockchain |
| CN112634058A (en) * | 2020-12-22 | 2021-04-09 | 无锡井通网络科技有限公司 | Data mutual trust and mutual sharing and intercommunication platform based on block chain |
| CN112995335B (en) * | 2021-04-07 | 2022-09-23 | 上海道客网络科技有限公司 | Position-aware container scheduling optimization system and method |
| CN113296711B (en) * | 2021-06-11 | 2022-10-28 | 中国科学技术大学 | Method for optimizing distributed storage delay in database scene |
| CN113312429B (en) * | 2021-06-22 | 2023-01-17 | 工银科技有限公司 | Intelligent contract management system, method, medium, and article in a blockchain |
| CN114625320B (en) * | 2022-03-15 | 2024-01-02 | 江苏太湖慧云数据系统有限公司 | Hybrid cloud platform data management system based on characteristics |
| CN114968092B (en) * | 2022-04-28 | 2023-10-17 | 安超云软件有限公司 | Method for dynamically supplying storage space based on QCOW2 technology under container platform and application |
| CN117714386A (en) * | 2022-09-06 | 2024-03-15 | 中兴通讯股份有限公司 | Distributed system deployment method, distributed system deployment configuration method, distributed system deployment system, distributed system deployment equipment and medium |
| CN115189995B (en) * | 2022-09-07 | 2022-11-29 | 江苏博云科技股份有限公司 | Multi-cluster network federal communication establishing method, equipment and storage medium in Kubernetes environment |
| CN115834595A (en) * | 2022-11-17 | 2023-03-21 | 浪潮云信息技术股份公司 | Management method and system of Kubernetes control assembly |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106027643A (en) * | 2016-05-18 | 2016-10-12 | 无锡华云数据技术服务有限公司 | Resource scheduling method based on Kubernetes container cluster management system |
| US20160359955A1 (en) * | 2015-06-05 | 2016-12-08 | Nutanix, Inc. | Architecture for managing i/o and storage for a virtualization environment using executable containers and virtual machines |
| CN106850621A (en) * | 2017-02-07 | 2017-06-13 | 南京云创大数据科技股份有限公司 | A kind of method based on container cloud fast construction Hadoop clusters |
| US20180173562A1 (en) * | 2016-12-16 | 2018-06-21 | Red Hat, Inc. | Low impact snapshot database protection in a micro-service environment |
-
2018
- 2018-09-29 CN CN201880097738.0A patent/CN113169952B/en active Active
- 2018-09-29 WO PCT/CN2018/108575 patent/WO2020062131A1/en active Application Filing
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20160359955A1 (en) * | 2015-06-05 | 2016-12-08 | Nutanix, Inc. | Architecture for managing i/o and storage for a virtualization environment using executable containers and virtual machines |
| CN106027643A (en) * | 2016-05-18 | 2016-10-12 | 无锡华云数据技术服务有限公司 | Resource scheduling method based on Kubernetes container cluster management system |
| US20180173562A1 (en) * | 2016-12-16 | 2018-06-21 | Red Hat, Inc. | Low impact snapshot database protection in a micro-service environment |
| CN106850621A (en) * | 2017-02-07 | 2017-06-13 | 南京云创大数据科技股份有限公司 | A kind of method based on container cloud fast construction Hadoop clusters |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113656148A (en) * | 2021-08-20 | 2021-11-16 | 北京天融信网络安全技术有限公司 | Container management method and device, electronic equipment and readable storage medium |
| CN113656148B (en) * | 2021-08-20 | 2024-02-06 | 北京天融信网络安全技术有限公司 | Container management method, device, electronic equipment and readable storage medium |
| CN115550375A (en) * | 2022-08-31 | 2022-12-30 | 云南电网有限责任公司信息中心 | System, method and equipment for realizing block chain lightweight based on containerization technology |
| CN115550375B (en) * | 2022-08-31 | 2024-03-15 | 云南电网有限责任公司信息中心 | System, method and equipment for realizing block chain light weight based on containerization technology |
| CN115499442A (en) * | 2022-11-15 | 2022-12-20 | 四川华西集采电子商务有限公司 | Rapid deployment type cloud computing architecture based on container arrangement |
| CN115499442B (en) * | 2022-11-15 | 2023-01-31 | 四川华西集采电子商务有限公司 | Rapid deployment type cloud computing architecture based on container arrangement |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2020062131A1 (en) | 2020-04-02 |
| CN113169952B (en) | 2022-12-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113169952B (en) | Container cloud management system based on block chain technology | |
| US11709735B2 (en) | Workflows for automated operations management | |
| US11615195B2 (en) | Systems and methods for providing multi-node resiliency for blockchain peers | |
| EP3271819B1 (en) | Executing commands within virtual machine instances | |
| US10042628B2 (en) | Automated upgrade system for a service-based distributed computer system | |
| EP3149591B1 (en) | Tracking application deployment errors via cloud logs | |
| RU2585981C2 (en) | Large-scale data storage system | |
| US9866547B2 (en) | Controlling a discovery component, within a virtual environment, that sends authenticated data to a discovery engine outside the virtual environment | |
| US20200026786A1 (en) | Management and synchronization of batch workloads with active/active sites using proxy replication engines | |
| US8423734B2 (en) | Making automated use of data volume copy service targets | |
| WO2014039918A1 (en) | Ldap-based multi-customer in-cloud identity management system | |
| WO2017107827A1 (en) | Method and apparatus for isolating environment | |
| CN114168179A (en) | Micro-service management method, device, computer equipment and storage medium | |
| CN112035062B (en) | Migration method of local storage of cloud computing, computer equipment and storage medium | |
| US10001939B1 (en) | Method and apparatus for highly available storage management using storage providers | |
| CN111683164A (en) | IP address configuration method and VPN service system | |
| US20240095099A1 (en) | Decentralized framework for providing application programming interface gateways | |
| CN116962260A (en) | Cluster security inspection method, device, equipment and storage medium | |
| TW201828655A (en) | Environment isolation method and device resolves the problem of high complexity and incomplete isolation carried at environmental isolation during the RPC call process |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |