Deployment method and device of main and standby Kubernetes systems, electronic equipment and storage medium

Abstract

The invention discloses a deployment method and device of a main and standby Kubernetes system, electronic equipment and a storage medium, the method and device are applied to the electronic equipment, the main and standby Kubernetes system comprises a main node and at least one standby node, and specifically, the deployment method specifically comprises the steps that an instance configuration request of a user is responded, and the main node and the standby node are configured according to the instance configuration request; custom resource instances are configured for the main node and the standby node, wherein the custom resource instances comprise a resource synchronization strategy; and in response to a resource synchronization request of a user, executing a data synchronization operation based on the resource synchronization strategy so as to synchronize the synchronization data of the main node to the standby node. According to the scheme, operation and maintenance management personnel only need to configure installation and configuration of the user-defined resource instances in the main and standby Kubernetes systems once, and the applications can be deployed to the main and standby nodes at the same time, so that the operation steps are simplified, and large workload does not need to be consumed any more.

Description

Technical Field

[0001] The present application relates to the field of automation technology, and more specifically, to a method, device, electronic device and storage medium for deploying primary and backup resources. Background Art

[0002] With the development and progress of science and technology, modern industrial systems are increasingly dependent on IT infrastructure. In particular, the widespread application of industrial automation, intelligent manufacturing and the Internet of Things (IoT) has put forward higher requirements for the stability, reliability and flexibility of IT infrastructure. Kubernetes is a portable and scalable open source platform for managing containerized workloads and services, facilitating declarative configuration and automation, and has a large and rapidly growing ecosystem with a wide range of services, support and tools. Therefore, it is widely used in modern industrial systems. It can achieve data disaster recovery and disaster preparedness through the active-standby mode in the system to ensure the safe and stable operation of industrial systems.

[0003] The configuration of the active-standby mode of the Kubernetes system requires operation and maintenance personnel to not only master the complex concepts and configuration of the Kubernetes system, but also have a multi-faceted understanding of data resource synchronization. For example, they need to understand the state inclusiveness, resource dependencies, task-type workloads, and other issues of the Kubernetes system.

[0004] Status inclusion refers to how to ensure that the K8s resource status is included and processed accordingly during the synchronization process to ensure that the information is correctly copied and updated. For example, if the status of the xxxPod of the master node is "running", and the status of the backup node xxxPod already exists and is "pending", then there is no need to synchronize this data. You should wait until the backup node pod is Unknown or Failed before resynchronizing.

[0005] Resource dependency refers to how the Kubernetes system identifies and handles dependencies between resources during resource creation to avoid conflicts between resources. It can also reduce the performance occupied by invalid synchronization and ensure the stability and reliability of the system.

[0006] Task-based workloads refer to task-based workloads that are executed at scheduled times (such as CronJobs). In order to avoid problems that may occur when running on both the primary and standby nodes (such as repeated task execution, data conflicts, inconsistent states, etc.), a separate synchronization strategy is designed. After obtaining the role of the primary and standby nodes, the state machine controls the running state of the resource as needed, thereby avoiding execution on the standby node and being able to automatically restore execution when switching from the standby to the primary. This control mechanism allows the business code of the workload to avoid the need to additionally implement competition for the primary and standby running locks, thereby better ensuring the business logic.

[0007] In view of the above problems, operation and maintenance managers now need to perform a large number of complex operations when deploying the active and standby Kubernetes systems, which requires a large workload. Summary of the invention

[0008] In view of this, the present application provides a deployment method, device, electronic device and storage medium of a master-slave Kubernetes system to simplify the operation process when deploying the master-slave Kubernetes system, thereby reducing the workload of operation and maintenance management personnel.

[0009] In order to achieve the above objectives, the proposed solution is as follows:

[0010] A deployment method of a master-standby Kubernetes system is applied to an electronic device, wherein the master-standby Kubernetes system includes a master node and at least one standby node, and the deployment method includes the following steps:

[0011] In response to a user's instance configuration request, a custom resource instance is configured for the primary node and the backup node, wherein the custom resource instance includes a resource synchronization strategy;

[0012] In response to a resource synchronization request from a user, a data synchronization operation is performed based on the resource synchronization policy, so that the synchronization data of the primary node is synchronized to the backup node.

[0013] Optionally, the resource synchronization strategy includes a first synchronization strategy for resident service-type tasks and a second synchronization strategy for scheduled execution-type tasks.

[0014] Optionally, performing the data synchronization operation based on the resource synchronization strategy comprises the steps of:

[0015] Collecting and filtering the original data of the master node to obtain the synchronized data;

[0016] sending the synchronization data to the standby node;

[0017] Performing status verification on the synchronization data based on the standby node to obtain synchronization resources;

[0018] Performing attribute assignment processing on the synchronization resource;

[0019] The standby node is deployed with resources based on the synchronization resources after the attribute assignment processing.

[0020] Optionally, the following steps are also included:

[0021] In response to an active / standby switching event, active / standby switching is performed on the active node and the standby node.

[0022] A deployment device for a master-standby Kubernetes system is applied to an electronic device, wherein the master-standby Kubernetes system includes a master node and at least one standby node, wherein the master node includes a first executor and a first state machine, and the standby node includes a second executor and a second state machine, and the deployment device includes:

[0023] An instance configuration module is configured to respond to an instance configuration request from a user and configure a custom resource instance for the primary node and the backup node, wherein the custom resource instance includes a resource synchronization strategy;

[0024] The synchronization control module is configured to respond to a resource synchronization request from a user and perform a data synchronization operation based on the resource synchronization strategy so as to synchronize the synchronization data of the primary node to the backup node.

[0025] Optionally, the resource synchronization strategy includes a first synchronization strategy for resident service-type tasks and a second synchronization strategy for scheduled execution-type tasks.

[0026] Optionally, the synchronization notification module includes:

[0027] A collection and filtering unit, configured to collect and filter the original data of the master node to obtain the synchronization data;

[0028] a data synchronization unit, configured to send the synchronization data to the standby node;

[0029] A state checking unit, configured to perform a state check on the synchronization data based on the standby node to obtain a synchronization resource;

[0030] A policy assignment unit, configured to perform attribute assignment processing on the synchronization resource;

[0031] The resource deployment unit is configured to deploy resources to the standby node based on the synchronization resources after the attribute assignment processing.

[0032] Optionally, also include:

[0033] The switching control module is configured to respond to an active-standby switching event and perform active-standby switching on the primary node and the standby node.

[0034] An electronic device, comprising at least one processor and a memory connected to the processor, wherein:

[0035] The memory is used to store computer programs or instructions;

[0036] The processor is used to execute the computer program or instruction so that the electronic device implements the deployment method of the active-standby Kubernetes system as described above.

[0037] A computer-readable storage medium is applied to an electronic device, wherein the storage medium carries one or more computer programs, and the one or more computer programs can be executed by the electronic device, so that the electronic device implements the deployment method of the master-slave Kubernetes system as described above.

[0038] It can be seen from the above technical scheme that the present application discloses a deployment method, device, electronic device and storage medium of a master-slave Kubernetes system. The method and device are applied to electronic devices. The master-slave Kubernetes system includes a master node and at least one standby node. Specifically, the deployment method specifically responds to the user's instance configuration request, configures a custom resource instance for the master node and the standby node, and the custom resource instance includes a resource synchronization strategy; responds to the user's resource synchronization request, and performs a data synchronization operation based on the resource synchronization strategy to synchronize the synchronization data of the master node to the standby node. Through this solution, the operation and maintenance management personnel only need to install and configure the custom resource instance once in the master-slave Kubernetes system, and the application can be deployed to the master and standby nodes at the same time, thereby simplifying the operation steps and no longer consuming a large workload. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0040] Figure 1 This is a block diagram of the active-standby Kubernetes system of an embodiment of the present application;

[0041] Figure 2This is a flow chart of a method for deploying a master-slave Kubernetes system according to an embodiment of the present application;

[0042] Figure 3 A flowchart of a data synchronization operation according to an embodiment of the present application;

[0043] Figure 4 This is a flowchart of another method for deploying a master-slave Kubernetes system according to an embodiment of the present application;

[0044] Figure 5 A block diagram of a deployment device for a master-slave Kubernetes system according to an embodiment of the present application;

[0045] Figure 6 A block diagram of another deployment device of a master-slave Kubernetes system according to an embodiment of the present application;

[0046] Figure 7 A block diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0047] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0048] The technical solution of the present application provides a deployment method of a master-slave Kubernetes system, where the so-called master-slave Kubernetes system refers to an information device or system applied to an industrial system, which specifically includes a master node 100 and at least one standby node 200, such as Figure 1 The master node includes a first executor 101 and a first state machine 102 , and any standby node includes a second state machine 201 and a second executor 202 .

[0049] Figure 2 This is a flowchart of a method for deploying a master-slave Kubernetes system according to an embodiment of the present application.

[0050] like Figure 2 As shown, the deployment method used in this embodiment is applied to electronic devices, which can be understood as computers, servers, cloud platforms, etc. with data computing capabilities and information processing capabilities. The deployment method specifically includes the following steps:

[0051] S1. Configure custom resource instances for the primary node and the standby node according to the user's instance configuration request.

[0052] Users only need to deploy synchronization components for data synchronization on the master and slave nodes. These synchronization components will automatically register the description of the CRD (Custom Resource Definition) instance of the synchronization resource with the Kubernetes cluster, and each application service declares the relevant CRD instance.

[0053] This application provides the following CRD description case:

[0054]

[0055]

[0056]

[0057]

[0058]

[0059] According to the characteristics of different Kubernetes resources, their workloads are usually divided into two types: resident service workloads and scheduled execution workloads. These two types have differences in operation, so we need to define different synchronization strategies for these differences, namely the first synchronization strategy for resident service workloads and the second synchronization strategy for scheduled execution workloads.

[0060] (1) When synchronizing the primary and standby nodes, service workloads must avoid duplicate synchronization and verify the status. The following is an example of the first synchronization strategy for Pods:

[0061]

[0062] (2) Task-based workloads want scheduled tasks to run only on the master node during synchronization, and the standby node starts executing these tasks only when it takes over as the master node. The following is an example of the corresponding second synchronization strategy:

[0063]

[0064]

[0065] S2. Execute data synchronization operation according to the user's resource synchronization request.

[0066] That is, when the above custom resource instance is configured in place, the resource synchronization strategy is executed based on the user's resource synchronization request or automatic execution event, so that the synchronization data of the primary node is synchronized to the corresponding backup node. The specific process is as follows, Figure 3 As shown:

[0067] S201. Collect and filter the original data of the master node to obtain synchronized data.

[0068] The master node executor generates a list request for the corresponding resource (such as: / api / v1 / xxx) according to the syncRules in the synchronized CRD instance, and composes the returned data into a standard k8s resource addition event, and then performs the first filtering according to the operations in the syncRules. The filtered event is then calculated with the CEL expression defined in the expression field in the syncRules. If the result is true, the event is reported to the state machine. If the result is false, the event is filtered out. The executor then obtains the final resourceVersion and composes it into a watch request (such as: / api / v1 / xxx?watch=true&resourceVersion=xxx) to subscribe to subsequent incremental events of this resource type. When the subscribed resources are added, modified, or deleted, the executor will perform the same filtering and synchronization processing. The relevant components perform corresponding processing for the declarations in the above example:

[0069] (1) In the example of synchronizing CRD instances for service-class workloads, the executor will listen to the added, modified, and deleted events of all pods according to the syncRules in the example and filter them according to the expression. As shown in the example, the executor will determine whether the metadata.labels.app of the object in the event is equal to "my-pod" and has no ownerReferences attribute, and the namespace of the pod object cannot be kube-system. If all the above conditions are met, the executor will report the pod to the state machine; otherwise, it will be ignored.

[0070] (2) In the example of synchronizing the CRD instance of the task resource, the executor will listen to all cronjobs resource added, modified, and deleted events according to the syncRules of the example, and filter them according to the expression. As shown in the example, the executor will determine whether the metadata.labels.app of the object in the event is equal to "my-cronjob". If the condition is met, the executor will report the cronjobs data to the state machine; otherwise, it will be ignored.

[0071] S202: Send the synchronization data to the standby node.

[0072] The first state machine of the master node will periodically sort the cronjobs resource data collected by the first executor according to the resourceVersion in the event, and push it to the second state machine of the standby node through the interface. If a transmission failure occurs, the first state machine of the master node will record the number of failures. Once the threshold preset in the configuration file is reached, an alarm will be triggered to notify the administrator to check the network communication and the operation status of the second state machine of the standby node. The second state machine of the standby node will persist the synchronized events and provide the API interface for the second executor of the standby node to query and delete events.

[0073] S203: Perform status verification on the synchronization data based on the standby node to obtain synchronization resources.

[0074] The second executor of the standby node obtains the synchronization data synchronized from the master node by accessing the interface of the current node state machine, and extracts the object in the synchronization data to the masterObject. Then, according to the apiVersion, kind of the masterObject and the namespace and name in the matadata, the corresponding resource type is identified and the Kubernetes API of the current node is called to obtain the corresponding resource with the same name as the slaveObject. If the resource with the same name cannot be obtained, the slaveObject parameter is set to empty. The extracted masterObject, slaveObject and expression in compareRules are used together to perform CEL expression status verification. If the calculation result is false, this event is filtered out. If the calculation result is true or the verification rule for the resource in compareRules cannot be found, the following policy assignment and resource deployment steps are continued.

[0075] (1) In the example of synchronizing the CRD instance of the service class resource, the second executor of the standby node verifies whether there is no pod resource with the same name on the current node according to the compareRules statement of the example; or the pod resource status of the primary node is healthy but the pod with the same name on the standby node is unhealthy. If the conditions are met, the subsequent steps will be executed; otherwise, they will be ignored.

[0076] (2) In the example of task resource synchronization CRD instance, the second executor of the standby node will verify whether there is no cronjobs resource with the same name on the current node according to the compareRules statement of the example. If the condition is met, the subsequent steps will be executed; otherwise, they will be ignored.

[0077] S204: Perform attribute assignment processing on the synchronization resource.

[0078] The second executor of the standby node assigns attributes to the synchronization resources that have passed the status check according to the jsonPatch of compareRules in the CRD instance. Specifically:

[0079] (1) In the example of the service class resource synchronization CRD instance, compareRules does not declare jsonPatch, so the second executor of the standby node skips this step.

[0080] (2) In the example of task resource synchronization CRD instance, the second executor of the standby node will set the value of spec.supend in the corresponding cronjob object to true according to the compareRules.jsonPatch declaration to ensure that the synchronized cronjobs will not be scheduled for execution on the standby node.

[0081] S205: Deploy resources to the standby node based on the synchronization resources after the attribute assignment processing.

[0082] The second executor of the standby node converts the event type into the corresponding operation command (for example, when the event type is added or modified, an apply request is initiated for the resource data after the policy is assigned. When the event type is deleted, the name of the object is extracted and a delete request for the resource is initiated) to update the resources of the Kubermetes system of the standby node.

[0083] It can be seen from the above technical scheme that this embodiment provides a deployment method of a master-slave Kubernetes system, which is applied to electronic devices. The master-slave Kubernetes system includes a master node and at least one standby node. Specifically, the deployment method specifically responds to the user's instance configuration request, configures a custom resource instance for the master node and the standby node, and the custom resource instance includes a resource synchronization strategy; responds to the user's resource synchronization request, and performs a data synchronization operation based on the resource synchronization strategy to synchronize the synchronization data of the master node to the standby node. Through this solution, the operation and maintenance management personnel only need to install and configure the custom resource instance once in the master-slave Kubernetes system, and the application can be deployed to the master and standby nodes at the same time, thereby simplifying the operation steps and no longer consuming a large workload.

[0084] In addition, in a specific implementation of the present application, the following steps are also included: Figure 4 shown.

[0085] S3. Perform active / standby switching on the master node and the standby node according to the active / standby switching time.

[0086] Specifically, when a master-slave switch event generated by the master node occurs or is received, the master node and the backup node are switched, that is, the master node is switched to the backup node, and the original backup node is switched to the master node. According to the strategy of synchronizing CRD instances, the master node is migrated to the backup node, maintaining the consistency between the master and backup systems.

[0087] However, when the roles of the master and slave nodes are switched, some special workloads need a processing mechanism to passively perform some processing so that the corresponding switch can be completed. For example, the CronJob in the above example needs to support activating the CronJob in the original standby node and suspending the CronJob in the original master node when the master and slave nodes are switched. To solve this problem, we specially define the toMaster and toSlave rules in syncRules to ensure that resources can be executed on the correct node as expected, thereby ensuring the stable operation and efficient management of the system.

[0088] The following is a specific CRD example:

[0089]

[0090] As shown in the CRD example above, the master and slave executors will load the synchronization rules including toMaster and toSalve configurations in syncRules when they start. When the roles are switched, the resources that meet the syncRules conditions are selected and the patch requests of toMaster and toSalve are executed according to the current roles, ensuring that the task resources will only run on the master node.

[0091] This application adopts the CRD instance mechanism to dynamically increase, decrease or modify the judgment strategy of Kubernetes resources through declaration, which reduces the difficulty of use or expansion. Different business scenarios require different resources to be synchronized. Even at runtime, new synchronized resources may be added dynamically. This application provides a runtime synchronized CRD rule template, which allows you to flexibly configure matching rules and assign attributes to promote the master or demote the slave at runtime. It reduces the considerations of R&D personnel for dual-node high availability.

[0092] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present disclosure. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some implementations as replacements, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0093] Although operations are depicted in a particular order, this should not be understood as requiring that the operations be performed in the particular order shown or in a sequential order.Multitasking and parallel processing may be advantageous under certain circumstances.

[0094] It should be understood that the various steps described in the method embodiments of the present disclosure may be performed in different orders and / or in parallel. In addition, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present disclosure is not limited in this respect.

[0095] Computer program code for performing the operations of the present disclosure may be written in one or more programming languages ​​or a combination thereof, including, but not limited to, object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as C or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer.

[0096] Figure 5 A block diagram of a deployment device for a master-slave Kubernetes system according to an embodiment of the present application.

[0097] like Figure 5As shown, the deployment method of this embodiment is applied to an electronic device, which can be understood as a computer, server, cloud platform, etc. having data computing and information processing capabilities. The deployment device specifically includes an instance configuration module 10 and a synchronization control module 20 .

[0098] The instance configuration module is used to configure custom resource instances for the primary node and the standby node according to the user's instance configuration request.

[0099] Users only need to deploy synchronization components for data synchronization on the master and slave nodes. These synchronization components will automatically register the description of the CRD (Custom Resource Definition) instance of the synchronization resource with the Kubernetes cluster, and each application service declares the relevant CRD instance.

[0100] According to the characteristics of different Kubernetes resources, their workloads are usually divided into two types: resident service workloads and scheduled execution workloads. These two types have differences in operation, so we need to define different synchronization strategies for these differences, namely the first synchronization strategy for resident service workloads and the second synchronization strategy for scheduled execution workloads.

[0101] (1) When synchronizing the primary and standby nodes, service workloads must avoid duplicate synchronization and verify the status.

[0102] (2) Task-based workloads want scheduled tasks to run only on the master node during synchronization, and the standby node starts executing these tasks only when it takes over as the master node.

[0103] The synchronization control module is used to perform data synchronization operations according to the user's resource synchronization request.

[0104] That is, when the above-mentioned custom resource instance is configured in place, the resource synchronization strategy is executed based on the user's resource synchronization request or automatic execution event, so that the synchronization data of the master node is synchronized to the corresponding backup node. This module specifically includes a collection and filtering unit, a data synchronization unit, a state verification unit, a strategy assignment unit and a resource deployment unit.

[0105] The collection and filtering unit is used to collect and filter the original data of the master node to obtain synchronized data.

[0106] The master node executor generates a list request for the corresponding resource (such as: / api / v1 / xxx) according to the syncRules in the synchronized CRD instance, and composes the returned data into a standard k8s resource addition event, and then performs the first filtering according to the operations in the syncRules. The filtered event is then calculated with the CEL expression defined in the expression field in the syncRules. If the result is true, the event is reported to the state machine. If the result is false, the event is filtered out. The executor then obtains the final resourceVersion and composes it into a watch request (such as: / api / v1 / xxx?watch=true&resourceVersion=xxx) to subscribe to subsequent incremental events of this resource type. When the subscribed resources are added, modified, or deleted, the executor will perform the same filtering and synchronization processing. The relevant components perform corresponding processing for the declarations in the above example:

[0107] (1) In the example of synchronizing CRD instances for service-class workloads, the executor will listen to the added, modified, and deleted events of all pods according to the syncRules in the example and filter them according to the expression. As shown in the example, the executor will determine whether the metadata.labels.app of the object in the event is equal to "my-pod" and has no ownerReferences attribute, and the namespace of the pod object cannot be kube-system. If all the above conditions are met, the executor will report the pod to the state machine; otherwise, it will be ignored.

[0108] (2) In the example of synchronizing the CRD instance of the task resource, the executor will listen to all cronjobs resource added, modified, and deleted events according to the syncRules of the example, and filter them according to the expression. As shown in the example, the executor will determine whether the metadata.labels.app of the object in the event is equal to "my-cronjob". If the condition is met, the executor will report the cronjobs data to the state machine; otherwise, it will be ignored.

[0109] The data synchronization unit is used to send synchronization data to the standby node.

[0110] The first state machine of the master node will periodically sort the cronjobs resource data collected by the first executor according to the resourceVersion in the event, and push it to the second state machine of the standby node through the interface. If a transmission failure occurs, the first state machine of the master node will record the number of failures. Once the threshold preset in the configuration file is reached, an alarm will be triggered to notify the administrator to check the network communication and the operation status of the second state machine of the standby node. The second state machine of the standby node will persist the synchronized events and provide the API interface for the second executor of the standby node to query and delete events.

[0111] The state checking unit is used to perform state checking on the synchronization data based on the standby node to obtain the synchronization resource.

[0112] The second executor of the standby node obtains the synchronization data synchronized from the master node by accessing the interface of the current node state machine, and extracts the object in the synchronization data to the masterObject. Then, according to the apiVersion, kind of the masterObject and the namespace and name in the matadata, the corresponding resource type is identified and the Kubernetes API of the current node is called to obtain the corresponding resource with the same name as the slaveObject. If the resource with the same name cannot be obtained, the slaveObject parameter is set to empty. The extracted masterObject, slaveObject and expression in compareRules are used together to perform CEL expression status verification. If the calculation result is false, this event is filtered out. If the calculation result is true or the verification rule for the resource in compareRules cannot be found, the following policy assignment and resource deployment steps are continued.

[0113] (1) In the example of synchronizing the CRD instance of the service class resource, the second executor of the standby node verifies whether there is no pod resource with the same name on the current node according to the compareRules statement of the example; or the pod resource status of the primary node is healthy but the pod with the same name on the standby node is unhealthy. If the conditions are met, the subsequent steps will be executed; otherwise, they will be ignored.

[0114] (2) In the example of task resource synchronization CRD instance, the second executor of the standby node will verify whether there is no cronjobs resource with the same name on the current node according to the compareRules statement of the example. If the condition is met, the subsequent steps will be executed; otherwise, they will be ignored.

[0115] The policy assignment unit is used to perform attribute assignment processing on synchronization resources.

[0116] The second executor of the standby node assigns attributes to the synchronization resources that have passed the status check according to the jsonPatch of compareRules in the CRD instance. Specifically:

[0117] (1) In the example of the service class resource synchronization CRD instance, compareRules does not declare jsonPatch, so the second executor of the standby node skips this step.

[0118] (2) In the example of task resource synchronization CRD instance, the second executor of the standby node will set the value of spec.supend in the corresponding cronjob object to true according to the compareRules.jsonPatch declaration to ensure that the synchronized cronjobs will not be scheduled for execution on the standby node.

[0119] The resource deployment unit is used to deploy resources to the standby node based on the synchronization resources after the attribute assignment processing.

[0120] The second executor of the standby node converts the event type into the corresponding operation command (for example, when the event type is added or modified, an apply request is initiated for the resource data after the policy is assigned. When the event type is deleted, the name of the object is extracted and a delete request for the resource is initiated) to update the resources of the Kubermetes system of the standby node.

[0121] It can be seen from the above technical scheme that this embodiment provides a deployment device for a master-slave Kubernetes system, which is applied to electronic devices. The master-slave Kubernetes system includes a master node and at least one standby node. Specifically, the deployment method is to respond to the user's instance configuration request, configure a custom resource instance for the master node and the standby node, and the custom resource instance includes a resource synchronization strategy; respond to the user's resource synchronization request, and perform a data synchronization operation based on the resource synchronization strategy to synchronize the synchronization data of the master node to the standby node. Through this solution, the operation and maintenance management personnel only need to install and configure the custom resource instance once in the master-slave Kubernetes system, and the application can be deployed to the master and standby nodes at the same time, thereby simplifying the operation steps and no longer consuming a large workload.

[0122] In addition, in a specific embodiment of the present application, a switching control module 30 is also included, such as Figure 6 shown.

[0123] The switching control module is used to perform active / standby switching on the primary node and the standby node according to the active / standby switching time.

[0124] Specifically, when a master-slave switch event generated by the master node occurs or is received, the master node and the backup node are switched, that is, the master node is switched to the backup node, and the original backup node is switched to the master node. According to the strategy of synchronizing CRD instances, the master node is migrated to the backup node, maintaining the consistency between the master and backup systems.

[0125] However, when the roles of the master and slave nodes are switched, some special workloads need a processing mechanism to passively perform some processing so that the corresponding switch can be completed. For example, the CronJob in the above example needs to support activating the CronJob in the original standby node and suspending the CronJob in the original master node when the master and slave nodes are switched. To solve this problem, we specially define the toMaster and toSlave rules in syncRules to ensure that resources can be executed on the correct node as expected, thereby ensuring the stable operation and efficient management of the system.

[0126] This application adopts the CRD instance mechanism to dynamically increase, decrease or modify the judgment strategy of Kubernetes resources through declaration, which reduces the difficulty of use or expansion. Different business scenarios require different resources to be synchronized. Even at runtime, new synchronized resources may be added dynamically. This application provides a runtime synchronized CRD rule template, which allows you to flexibly configure matching rules and assign attributes to promote the master or demote the slave at runtime. It reduces the considerations of R&D personnel for dual-node high availability.

[0127] The units involved in the embodiments described in the present disclosure may be implemented by software or hardware. The name of a unit does not limit the unit itself in some cases. For example, the first acquisition unit may also be described as a "unit for acquiring at least two Internet Protocol addresses".

[0128] The functions described above herein may be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), complex programmable logic devices (CPLDs), and the like.

[0129] Figure 7 A block diagram of an electronic device according to an embodiment of the present application.

[0130] Reference below Figure 7, which shows a schematic diagram of the structure of an electronic device suitable for implementing the embodiments of the present disclosure. The terminal device in the embodiments of the present disclosure may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. The electronic device is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0131] The electronic device may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 701, which can perform various appropriate actions and processes according to a program stored in a read-only memory ROM 702 or a program loaded from an input device 706 into a random access memory RAM 703. In the RAM, various programs and data required for the operation of the electronic device are also stored. The processing device, ROM, and RAM are connected to each other via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0132] Typically, the following devices may be connected to the I / O interface: input devices including, for example, a touch screen, a touchpad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; output devices 707 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 708 including, for example, a magnetic tape, a hard disk, etc.; and communication devices 709. The communication device 709 may allow the electronic device to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows an electronic device with various devices, it should be understood that it is not required to implement or have all the devices shown. More or fewer devices may be implemented or have alternatively.

[0133] The present application also provides a computer-readable storage medium embodiment.

[0134] The computer-readable storage medium is applied to an electronic device and carries one or more computer programs. When the one or more computer programs are executed by the electronic device, the electronic device specifically responds to the user's instance configuration request, configures a custom resource instance for the primary node and the backup node, and the custom resource instance includes a resource synchronization strategy; responds to the user's resource synchronization request, and performs data synchronization operations based on the resource synchronization strategy to synchronize the synchronization data of the primary node to the backup node. Through this solution, the operation and maintenance management personnel only need to install and configure the custom resource instance once in the primary and backup Kubernetes systems, and the application can be deployed to the primary and backup nodes at the same time, thereby simplifying the operation steps and eliminating the need to consume a large amount of work.

[0135] It should be noted that the computer-readable medium disclosed above may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, device or device.

[0136] In the present disclosure, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, device, or device. The program code contained on the computer-readable medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

[0137] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0138] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present invention.

[0139] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or terminal device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or terminal device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or terminal device including the elements.

[0140] The technical solution provided by the present invention is introduced in detail above. Specific examples are used in this article to illustrate the principle and implementation mode of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea. At the same time, for those skilled in the art, according to the idea of ​​the present invention, there will be changes in the specific implementation mode and application scope. In summary, the content of this specification should not be understood as limiting the present invention.

Claims

1. A deployment method of a master-slave Kubernetes system, applied to an electronic device, wherein the master-slave Kubernetes system includes a master node and at least one standby node, characterized in that: The deployment method comprises the steps of: In response to a user's instance configuration request, a custom resource instance is configured for the primary node and the backup node, wherein the custom resource instance includes a resource synchronization strategy; In response to a resource synchronization request from a user, a data synchronization operation is performed based on the resource synchronization policy, so that the synchronization data of the primary node is synchronized to the backup node.

2. The deployment method according to claim 1, characterized in that: The resource synchronization strategy includes a first synchronization strategy for resident service-type tasks and a second synchronization strategy for scheduled execution-type tasks.

3. The deployment method according to claim 1, characterized in that: The performing of the data synchronization operation based on the resource synchronization strategy comprises the steps of: Collecting and filtering the original data of the master node to obtain the synchronized data; sending the synchronization data to the standby node; Performing status verification on the synchronization data based on the standby node to obtain synchronization resources; Performing attribute assignment processing on the synchronization resource; The standby node is deployed with resources based on the synchronization resources after the attribute assignment processing.

4. The deployment method according to any one of claims 1 to 3, characterized in that: Also includes the steps: In response to an active / standby switching event, active / standby switching is performed on the active node and the standby node.

5. A deployment device of a master-standby Kubernetes system, applied to an electronic device, wherein the master-standby Kubernetes system comprises a master node and at least one standby node, wherein the master node comprises a first executor and a first state machine, and the standby node comprises a second executor and a second state machine, wherein: The deployment device comprises: An instance configuration module is configured to respond to an instance configuration request from a user and configure a custom resource instance for the primary node and the backup node, wherein the custom resource instance includes a resource synchronization strategy; The synchronization control module is configured to respond to a resource synchronization request from a user and perform a data synchronization operation based on the resource synchronization strategy so as to synchronize the synchronization data of the primary node to the backup node.

6. The deployment device according to claim 5, characterized in that The resource synchronization strategy includes a first synchronization strategy for resident service-type tasks and a second synchronization strategy for scheduled execution-type tasks.

7. The deployment device according to claim 5, characterized in that The synchronization notification module includes: A collection and filtering unit, configured to collect and filter the original data of the master node to obtain the synchronization data; a data synchronization unit, configured to send the synchronization data to the standby node; A state checking unit, configured to perform a state check on the synchronization data based on the standby node to obtain a synchronization resource; A policy assignment unit, configured to perform attribute assignment processing on the synchronization resource; The resource deployment unit is configured to deploy resources to the standby node based on the synchronization resources after the attribute assignment processing.

8. The deployment device according to any one of claims 5 to 7, characterized in that: Also includes: The switching control module is configured to respond to an active-standby switching event and perform active-standby switching on the primary node and the standby node.

9. An electronic device, characterized in that: The electronic device comprises at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs or instructions; The processor is used to execute the computer program or instruction so that the electronic device implements the deployment method of the active-standby Kubernetes system as described in any one of claims 1 to 4.

10. A computer-readable storage medium, applied to an electronic device, characterized in that: The storage medium carries one or more computer programs, and the one or more computer programs can be executed by the electronic device, so that the electronic device implements the deployment method of the active-standby Kubernetes system as described in any one of claims 1 to 4.

Images