Design Method and System for Cloud Native Controller Applicable to Financial Distributed Architecture

Abstract

The present invention provides a design method and system for a cloud-native controller applicable to a financial distributed architecture, including: Step S1: Implement business deployment by submitting CibDeployment resources to a kubernetes cluster; Step S2: The controller triggers the mediation process of the CibDeployment resources by listening to the change events of the CibDeployment resources to complete the business deployment; Step S3: After the business deployment is completed in Step S2, the partition fault detection and scheduling component will regularly perform fault detection on all partitions. Once it detects that all nodes in a certain partition are faulty, it will transfer the replicas in that partition to other partitions. At the same time, it will detect whether the faulty partition has recovered. If the partition fault is recovered, it will automatically restore to the state without faults. The present invention can deploy a business on multiple partitions as needed and manage it uniformly.

Description

Technical Field

[0001] The present invention relates to the field of cloud computing technology, and in particular to a design method and system for a cloud-native controller suitable for a financial distributed architecture. Background Art

[0002] As an open-source container management platform, Kubernetes (K8s) has been increasingly used in the containerization field. However, its numerous components and complex configuration make its installation, deployment, and management complex.

[0003] Kubernetes has become the de facto standard for container orchestration. With its widespread adoption and entry into the financial technology (FinTech) sector, native components can meet most requirements. However, they still fall short in some specialized FinTech scenarios. Summary of the Invention

[0004] In response to the deficiencies in the prior art, the present invention provides a design method and system for a cloud-native controller suitable for a financial distributed architecture.

[0005] According to the present invention, a design method and system for a cloud-native controller applicable to a financial distributed architecture is provided. The solution is as follows:

[0006] First, a design method for a cloud-native controller suitable for a distributed financial architecture is provided. The method includes the following components: CibDeployment and InplaceSet. CibDeployment primarily implements partition control and controls multiple InplaceSets, each corresponding to a partition, while also controlling release policies, fault detection, and automatic failover. InplaceSets only implement replica retention and in-place upgrades.

[0007] Step S1: Submit CibDeployment resources to the k8s cluster to implement business deployment;

[0008] Step S2: The controller triggers the CibDeployment resource mediation process by monitoring CibDeployment resource change events to complete the service deployment;

[0009] Step S3: After the business deployment is completed in step S2, the partition fault detection and scheduling component will regularly perform fault detection on all partitions. Once it is detected that all nodes in a partition have failed, the replicas in the partition will be transferred to other partitions. At the same time, it will detect whether the failed partition has recovered. If the partition failure has recovered, it will automatically restore to the state before the failure.

[0010] Preferably, step S2 includes:

[0011] Step S2.1: The CibDeployment controller triggers the resource mediation process by monitoring the change events of the CibDeployment or InplaceSet resources. After entering the mediation process, the detailed information of the resource object is obtained through the resource identifier.

[0012] Step S2.2: Based on the CibDeployment resource information obtained in step S2.1, the partition deployment component traverses the CibDeployment partition configuration spec.regions, calls the partition reload component to complete the partition differentiation configuration, and then calls the release component to deploy the business to multiple partitions. The partition configuration includes the partition name, the number of partition replicas, and the partition label matchLabels.

[0013] Step S2.3: In step S2.2, the partition overload component reads the partition overload configuration spec.overrides and the common configuration template spce.template, generates a differentiated configuration for each partition using the partition overload strategy, and then creates an InplaceSet resource using the generated differentiated configuration.

[0014] Step S2.4 In step S2.3, the publishing component determines the number of replicas set when creating the InplaceSet through the publishing strategy, and then creates the InplaceSet resource;

[0015] Step S2.5: In step S2.4, after the first batch of releases is completed, if the number of replicas in the partitioned InplaceSet has not yet reached the desired number according to the release strategy, the InplaceSet needs to be expanded. This is controlled by the grouped rolling component, which divides the entire rolling process into multiple batches. The next batch of expansion will not begin until the current batch is completed.

[0016] Step S2.6: In step S2.4, if the waiting confirmation strategy spec.strategy.needWaitingForConfirm is set to true for the CibDeployment resource, manual confirmation is required before the next batch of capacity expansion can be started. Only after the confirmation is completed can the next batch of capacity expansion be started.

[0017] Step S2.7: In step 2.5, starting the next batch of expansion requires waiting for all partitions to be expanded. Expansion completion means that all Pods in the InplaceSet of that partition are in the Available state.

[0018] Step S2.8: In step S2.1, if the monitored CibDeployment resource is being upgraded and the configuration upgrade policy spec.strategy.updateStrategy is InPlaceIfPossible, it means that if the in-place upgrade conditions are met, the in-place upgrade will be executed, that is, the Pod will not be rebuilt, only the containers in the Pod will be replaced, and the IP, disk mounts, and network configurations of the Pod will remain unchanged.

[0019] Preferably, the step S2.2 includes:

[0020] Step S2.2.1: In step S2.2, an InplaceSet resource is created for each partition. The InplaceSet resource contains the following important information:

[0021] replicas: The desired number of pod replicas;

[0022] minReadySeconds: The minimum time to wait in the ready state before the pod status becomes available;

[0023] updateStrategy: Set the in-place upgrade strategy, which contains the following fields:

[0024] type: The value is Roll or InplaceIfPossible. Roll means rolling upgrade, and InplaceIfPossible means in-place upgrade if possible, otherwise no in-place upgrade;

[0025] gracePeriodSeconds: The time to wait for traffic switching before in-place upgrade;

[0026] template: Describe the resource object of the pod, which is a built-in resource object in k8s;

[0027] Step S2.2.2: The InplaceSet controller listens for change events of InplaceSet and Pod resources. If it is a Pod resource, the corresponding InplaceSet resource is obtained through the OwnerReference attribute of the Pod, thereby triggering the mediation process of the InplaceSet resource; in step S2.2.1, the creation event of the InplaceSet resource is monitored, triggering the mediation process of the InplaceSet resource. First, the replica synchronization is completed through the replica retention component, and then the in-place upgrade is completed through the in-place upgrade component;

[0028] Step S2.2.3: In Step S2.2.2, the replica retention component filters the corresponding Pod list through the label selector of InplaceSet, and then filters out Pods in the Succeed and Failed states. These two types of Pods have completed their life cycles. In this way, the Pod list under the current InplaceSet is obtained. After obtaining the Pod list, compare it with the expected number of replicas of the InplaceSet. If the actual number of Pods is less than the expected number of replicas of the InplaceSet, Pods need to be created to fill the gap. If the actual number of Pods is greater than the expected number of replicas of the InplaceSet, redundant Pods need to be deleted. If the actual number of Pods is equal to the expected number of replicas of the InplaceSet, no deletion or creation operations need to be performed on the Pods.

[0029] Step S2.2.4: In Step S2.2.2, the in-place upgrade component first traverses the Pod list obtained in Step S2.2.3 to synchronize the in-place upgrade status of the Pods, and then checks the upgrade strategy configuration spec.updateStrategy.type. If the upgrade strategy is InPlaceIfPossible, it means that in-place upgrade can be performed. Then check whether there is an in-place upgrade annotation cib.inplaceset.io / inplaceset-update-spec in the InplaceSet. If it exists, it means that an in-place upgrade needs to be performed currently.

[0030] Step S2.2.5: In Step S2.2.4, when the existence of the in-place upgrade annotation is detected, the in-place upgrade process starts. Traverse the Pod list obtained in Step S2.2.3. According to the in-place upgrade annotation in the Pod annotation, three Pod lists are obtained, namely the Pod list in the in-place upgrade state, the Pod list that has completed the in-place upgrade, and the Pod list that has not yet performed the in-place upgrade. Then judge whether the total number of Pods that have completed the in-place upgrade and are in the in-place upgrade state reaches the expected number of in-place upgrade replicas. If not, take out the difference in the number of Pods from the Pod list that has not yet performed the in-place upgrade, and then traverse and execute the in-place upgrade.

[0031] Preferably, the Step S2.2.5 includes:

[0032] Step S2.2.5.1: In step S2.2.5, when performing an in-place upgrade on a Pod, first obtain the delay time spec.updateStrategy.inPlaceUpdateStrategy.gracePeriodSeconds. If it is not set, fill it with the default value 1. Then set the in-place upgrade annotation for the Pod, and at the same time set the Pod status InPlaceUpdateReady to false. After setting, if InPlaceUpdateReady is set in the Pod ReadinessGate, then the Pod status will change from Ready to NotReady, and the address of the Pod will be removed from the endpoints, and new network connections will no longer enter this Pod; then during subsequent reconciliation, re-enter the in-place upgrade component to complete the subsequent process of the in-place upgrade.

[0033] Preferably, the step S2.4 of creating an InplaceSet resource includes: by obtaining the release strategy configuration spec.strategy.rolloutStrategy in the CibDeployment configuration, for Beta and Group, which represent Beta release and grouped release respectively. In a Beta release, when releasing for the first time, first create a Pod in each partition, that is, set the replica count of the partition InplaceSet to 1, and then wait for this Pod to start successfully before continuing; while in a grouped release, the number of Pods created in each partition during the first release is the release step size spec.strategy.batchSize.

[0034] Preferably, the step S2.5 further includes: in each batch, all partitions that need to be scaled out need to perform a scaling-out operation, and the number of replicas for a single scaling-out is controlled by the step size spec.strategy.batchSize. Only when all partitions that need to be scaled out have been scaled out and the scaling-out is completed can the scaling-out of the next batch be started.

[0035] Preferably, the in-place upgrade condition in the step S2.8 is that only the container image is modified during the upgrade. If the condition is met, the Pod template of the InplaceSet under the partition will be modified, and at the same time the in-place upgrade annotation cib.inplaceset.io / inplaceset-update-spec will be set, and its content is to describe the expected status of the in-place upgrade, including the number of replicas to be upgraded and the upgrade version identifier hash.

[0036] Preferably, the step S2.2.4 includes:

[0037] Step S2.2.4.1: In step S2.2.4, for synchronizing the Pod status, first obtain the in-place upgrade annotation of the Pod. If the annotation does not exist, it indicates that the Pod has not been upgraded in place, and the Pod status synchronization is ended; if the annotation exists, it indicates that the Pod has been upgraded in place, then step S2.2.4.2 is executed;

[0038] Step S2.2.4.2: The Pod is in the in-place upgrade state. Determine whether the Pod has a delayed in-place upgrade, that is, whether the Pod container image has not been modified. If not, step S2.2.4.4 is executed; if so, check whether the delay time has been met. If it has been met, step S2.2.4.3 is executed; if it has not been met, the Pod status synchronization is ended;

[0039] Step S2.2.4.3: The delay of the Pod's in-place upgrade has been met. Modify the container image of the Pod and end the Pod status synchronization;

[0040] Step S2.2.4.4: The container image of the Pod has been modified. Determine whether the container image used by the Pod is the same as the modified container image. If they are the same, it indicates that the in-place upgrade of the Pod has been completed, and step S2.2.4.5 is executed; if they are not the same, the Pod status synchronization is ended;

[0041] Step S2.2.4.5: The in-place upgrade of the Pod has been completed. Set the Pod status InPlaceUpdateReady to true and end the Pod status synchronization.

[0042] Preferably, the said step S3 includes:

[0043] Step S3.1: In step S3, the partition failure check and scheduling component will start a background coroutine to detect partition failures. The coroutine will listen for Node change events. Once a Node changes, the partition failure detection process step S3.2 will be triggered. And at startup, the Node status will be pulled in full once and then cached as a Node status table, triggering a partition failure detection process;

[0044] Step S3.2: In step S3.1, the partition fault detection process is triggered. The process updates the cached Node status table based on the received Node status event, then pulls the entire CibDeployment resource list and traverses the list. For each CibDeployment, it traverses its partitions and checks whether the partition is faulty according to step S3.3. Once a partition fault is detected, it determines whether CibDeployment already has a partition fault annotation. If not or it is inconsistent with the current partition fault, it sets a fault annotation for CibDeployment and performs failover according to step S3.5. If all partitions are not faulty, it checks whether CibDeployment has a partition fault annotation. If so, it checks whether the partition fault is recovered according to step S3.4. If recovered, it deletes the partition fault annotation. Then the resource triggers the mediation process S2, and finally reaches the desired state.

[0045] Step S3.3: In step S3.2, detect whether a partition of CibDeployment has failed. Pull a matching node list based on the partition's node affinity label and then determine the node status in the list. If all nodes are in the NotReady state, the partition is considered to be faulty.

[0046] Step S3.4: In step S3.2, check whether a partition of CibDeployment has recovered from the failure. Use the partition node affinity label to pull a matching node list and then determine the node status in the list. If all nodes are in the Ready state, the partition is considered to have recovered from the failure.

[0047] Step S3.5: In step S3.2, failover is performed on the CibDeployment with the faulty partition. First, a list of healthy partitions is obtained. Then, the list is traversed and the partitions are scored according to step S3.6. The partition with the highest score is selected as the transfer target. All replicas of the faulty partition are transferred to the target partition. In other words, the number of InplaceSet replicas of the faulty partition is set to 0. The number of InplaceSet replicas of the transfer target partition is the sum of the number of replicas of the original partition and the number of replicas of the faulty partition.

[0048] Step S3.6: In step S3.5, a partition needs to be scored. First, the matching node list is pulled through the partition node affinity label, and a mapping table is built according to the node name. Then, the Pod list is pulled and the Pod list is traversed. According to the node where the Pod is located, the Pod that falls in the node mapping table is filtered and the requested resources are counted. After the traversal is completed, the total allocatable resources of all nodes in the node mapping table are counted, and the total partitioned resources are subtracted to obtain a score, which is recorded as the partition score.

[0049] In a second aspect, a design system applicable to a cloud-native controller for a financial distributed architecture is provided. The system includes components CibDeployment and InplaceSet. Among them, CibDeployment mainly implements partition control, controls multiple InplaceSets below it, each InplaceSet corresponds to a partition, and at the same time controls the release policy, fault awareness, and automatic transfer. InplaceSet only implements the functions of replica retention and in-place upgrade.

[0050] Module M1: Realize business deployment by submitting CibDeployment resources to the k8s cluster.

[0051] Module M2: The controller triggers the mediation process of CibDeployment resources by listening to the CibDeployment resource change event to complete business deployment.

[0052] Module M3: After Module M2 completes business deployment, the partition fault detection and scheduling component will regularly detect faults in all partitions. Once it detects that all nodes in a certain partition are faulty, it will transfer the replicas in that partition to other partitions. At the same time, it will detect whether the faulty partition has recovered. If the partition fault is recovered, it will automatically restore to the state without faults.

[0053] Compared with the prior art, the present invention has the following beneficial effects:

[0054] 1. The present invention can deploy services to multiple partitions simultaneously through configured partition deployment, achieving the purpose of high availability and disaster tolerance for multi-site active-active services.

[0055] 2. The present invention can achieve differential deployment of partitions through partition reload configuration; it can achieve grouped deployment by configuring the deployment policy, control the deployment step size, and enable the manual confirmation mechanism to facilitate problem discovery and quick loss prevention.

[0056] 3. The present invention can achieve in-place upgrade of Pods through configured deployment policies, keep the IP unchanged, and be compatible with some business systems that depend on IP.

[0057] 4. The present invention can configure automatic scheduling to automatically schedule to partitions with sufficient resources when the partition resources are insufficient; it can also automatically detect partition faults and automatically transfer services to normal partitions during faults to ensure service reliability. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] By reading the following detailed description of non-limiting embodiments with reference to the accompanying drawings, other features, objects, and advantages of the present invention will become more apparent:

[0059] Figure 1 This is a model diagram of the main components of the present invention;

[0060] Figure 2 This is a schematic diagram of the release strategy of the present invention;

[0061] Figure 3 This is a diagram of the overall components of the present invention;

[0062] Figure 4 This is a diagram of normal partition deployment;

[0063] Figure 5 This is a schematic diagram of replica transfer for partition failure;

[0064] Figure 6 This is a comparison diagram of k8s deployment and partition deployment. DETAILED DESCRIPTION

[0065] The present invention is described in detail below in conjunction with specific embodiments. The following embodiments will help those skilled in the art to further understand the present invention, but are not intended to limit the present invention in any form. It should be noted that, for those of ordinary skill in the art, several changes and improvements can also be made without departing from the concept of the present invention. These all belong to the protection scope of the present invention.

[0066] The embodiment of the present invention provides a design method for a cloud native controller suitable for a financial distributed architecture. Figure 1 As shown, the main components are CibDeployment (deployment resource component) and InplaceSet (partition resource component), the model is as follows Figure 1 As shown in the figure, CibDeployment mainly implements partition control, controlling multiple InplaceSets, each of which corresponds to a partition, and also controls release strategies, fault awareness, and automatic transfer. InplaceSet only implements replica retention and in-place upgrade functions.

[0067] Functional design:

[0068] 1) Partition deployment

[0069] Partition deployment means deploying the business to a specified group of nodes, and the k8s scheduler has implemented the ability to schedule Pods to qualified nodes by setting node affinity. You only need to set appropriate partition labels for all nodes first, and then set corresponding labels for the partitions to be deployed when deploying the business. When the CibDeployment controller parses multiple partitions, it will create an InplaceSet for each partition and set the node affinity parameters to the PodTemplate of the InplaceSet. After the InplaceSet creates the Pod, the k8s scheduler will automatically select the node of the correct partition and bind it to the Pod.

[0070] A partition in this embodiment is a logical collection of nodes, which are selected by filtering based on configured labels.

[0071] 2) Partition reload

[0072] For each partition, you can set a reload strategy. The reload strategy refers to the JSON patch syntax. When parsing each partition configuration, the CibDeployment controller will first obtain the unified configuration, then traverse the reload strategies of the partition, and apply each reload strategy to the configuration to generate a new configuration, thus achieving differentiated configuration of multiple partitions.

[0073] 3) Release Strategy

[0074] Reference Figure 2 As shown in the figure, the release strategy is divided into Batch group release and Beta release, and a group confirmation mechanism is set up.

[0075] Batch group release: For each partition, Pods are divided into multiple batches according to batchSize (step size), and Pods in each batch are released simultaneously. If no user confirmation is required (needWaitingForConfirm=false), the next batch will be released after all Pods in this batch in all partitions are in available state. If user confirmation is required, the release is completed and awaits user confirmation (needWaitingForConfirm=true). The next batch will be released only after all Pods in this batch in all partitions are in available state and awaiting user confirmation (set the annotation cib.deployment.io / upgrade-confirm=true).

[0076] The only difference between Beta release and Batch group release is that during the first grouping, the step size is 1 instead of batchSize. At this time, one Pod is released in each partition to reduce the impact of incorrect configuration. If the user confirms that everything is correct, you can continue and enter the normal Batch release process.

[0077] 4) Group expansion

[0078] To prevent incorrect configuration from causing a large number of incorrect Pods to be created simultaneously, consuming significant resources, and other unexpected situations, we've implemented grouped scaling to mitigate risk. At the start of scaling, the Pods to be scaled are divided into batches based on the batch size within each partition. Scaling is then performed in batches, and scaling the next batch begins only after all Pods in a batch are in the Available state. Similar to releases, a confirmation mechanism can be configured; after all Pods in a batch are Available, manual confirmation is required before scaling the next batch.

[0079] 5) In-place upgrade

[0080] Generally, upgrading a pod involves deleting it and then recreating a new one. This entire process involves deletion, rescheduling, assigning an IP address, and mounting a disk, which takes considerable time. However, upgrading in place only requires re-pulling the image and restarting the container, which reduces upgrade time while keeping the IP address unchanged, meeting the requirements of some applications that rely on an unchanged IP address.

[0081] 6) Partition fault perception and automatic transfer

[0082] CibDeployment can be deployed in multiple partitions. When all nodes corresponding to a partition are NotReady, the failover strategy is activated. The optimal partition will be selected from the remaining partitions for transfer. When the failure is recovered, the transferred replicas will be reconciled back to the original partition. The optimal partition in this embodiment is the partition with the highest score. When calculating the partition score, the total resource situation of each node in the partition and the actual allocation to the Pod are calculated. The score is calculated by the difference between the two. The total score of the partition is the sum of the scores of all nodes in the partition.

[0083] The relationship between the fault logic and the CibDeployment master control logic: When a partition of a CibDeployment is judged to be faulty, the CibDeployment enters the fault logic. At this time, the normal reconciliation logic, such as maintaining the number of replicas and partitions, will not be performed. The reconciliation logic will only be activated when the CibDeployment is no longer faulty.

[0084] Fault diagnosis is when all nodes in a partition are NotReady, the partition is considered to have failed; at the same time, fault recovery is when all nodes in the partition are Ready, the partition is considered to have recovered.

[0085] Next, the present invention will be described in more detail.

[0086] The present invention provides a design method for a cloud native controller suitable for a financial distributed architecture, referring to Figure 3 As shown, the specific steps of this method are as follows:

[0087] Step S1: Submit the CibDeployment resource to the Kubernetes cluster to implement business deployment. The resource object contains the following important information:

[0088] strategy (object): update strategy;

[0089] batchSize (integer): batch publishing step size;

[0090] needWaitingForConfirm (Boolean): whether to enable the confirmation mechanism;

[0091] rolloutStrategy (string): release strategy, either Beta or Batch;

[0092] updateStrategy (string): update strategy, which can be Roll or InPlaceIfPossible. Roll indicates rolling upgrade, and InplaceIfPossible indicates in-place upgrade if possible, otherwise in-place upgrade.

[0093] regions (array): partition configuration;

[0094] replicas (integer): number of partition replicas;

[0095] matchLabels (dictionary): partition node affinity labels;

[0096] overrides (array): Partition override configuration.

[0097] Step S2: The controller triggers the mediation process of CibDeployment resources by monitoring CibDeployment resource change events to complete the deployment of the service.

[0098] Step S3: After the business deployment is completed in Step S2, the partition fault detection and scheduling component will regularly detect faults in all partitions. Once it detects that all nodes in a certain partition fail, it will transfer the replicas in that partition to other partitions. At the same time, it will detect whether the failed partition has recovered. If the partition fault is recovered, it will automatically restore to the state without faults.

[0099] Among them, Step S2 specifically includes:

[0100] Step S2.1: The CibDeployment controller triggers the resource mediation process by listening to the change events of CibDeployment or InplaceSet resources. After entering the mediation process, it first obtains the detailed information of the resource object through the resource identifier.

[0101] Step S2.2: Through the CibDeployment resource information obtained in Step S2.1, the partition deployment component traverses the partition configuration spec.regions of CibDeployment, calls the partition reload component to complete the partition differential configuration, and then calls the publishing component to deploy the business to multiple partitions. The partition configuration includes the partition name name (string), the number of partition replicas replicas (integer), and the partition label matchLabels (dictionary).

[0102] This Step S2.2 specifically includes:

[0103] Step S2.2.1: In Step S2.2, create an InplaceSet resource for each partition. The InplaceSet resource contains the following important information:

[0104] replicas (integer): The expected number of pod replicas;

[0105] minReadySeconds: The minimum time to wait in the Ready state before the Pod status becomes available (a state of the Pod);

[0106] updateStrategy (object): Set the in-place upgrade strategy, which contains the following fields:

[0107] type (string): The value is Roll or InplaceIfPossible. Roll means rolling upgrade, and InplaceIfPossible means in-place upgrade if possible, otherwise no in-place upgrade;

[0108] gracePeriodSeconds (integer): The time to wait for traffic switching before in-place upgrade;

[0109] template (Object): Describes the resource object of a Pod, which is a built-in resource object in k8s;

[0110] Step S2.2.2: The InplaceSet controller listens for change events of InplaceSet and Pod resources. If it is a Pod resource, it obtains the corresponding InplaceSet resource through the OwnerReference (owner) attribute of the Pod, thereby triggering the reconciliation process of the InplaceSet resource; in Step S2.2.1, the creation event of the InplaceSet resource is listened for, triggering the reconciliation process of the InplaceSet resource. First, the replica maintenance component completes the replica number synchronization, and then the in-place upgrade component completes the in-place upgrade.

[0111] Step S2.2.3: In Step S2.2.2, the replica maintenance component filters the corresponding Pod list through the label selector of InplaceSet (a general mechanism in k8s for filtering objects by labels), and then filters out Pods in the Succeed and Failed states. These two types of Pods have completed their life cycles, thus obtaining the Pod list under the current InplaceSet; after obtaining the Pod list, it is compared with the expected replica number of InplaceSet. If the actual number of Pods is less than the expected replica number of InplaceSet, Pods need to be created to fill the gap; if the actual number of Pods is greater than the expected replica number of InplaceSet, redundant Pods need to be deleted; if the actual number of Pods is equal to the expected replica number of InplaceSet, no deletion or creation operations need to be performed on the Pods.

[0112] Step S2.2.4: In Step S2.2.2, the in-place upgrade component first traverses the Pod list obtained in Step S2.2.3 to synchronize the in-place upgrade status of the Pods, and then checks the upgrade strategy configuration spec.updateStrategy.type (string). If the upgrade strategy is InPlaceIfPossible, it means that in-place upgrade can be performed, and then it checks whether the in-place upgrade annotation cib.inplaceset.io / inplaceset-update-spec exists in InplaceSet. If it exists, it means that in-place upgrade needs to be performed currently.

[0113] This Step S2.2.4 specifically includes:

[0114] Step S2.2.4.1: In step S2.2.4, synchronize the Pod status. First, obtain the Pod in-place upgrade annotation. If the annotation does not exist, it means that the Pod has not been upgraded in-place, and the Pod status synchronization ends. If the annotation exists, it means that the Pod has been upgraded in-place, and then execute step S2.2.4.2.

[0115] Step S2.2.4.2: The Pod is in the in-place upgrade state. Determine whether the Pod is delayed in-place upgrade, that is, the Pod container image has not been modified. If not, execute step S2.2.4.4. If yes, check whether the delay time has been met. If so, execute step S2.2.4.3. If not, end the Pod status synchronization.

[0116] Step S2.2.4.3: The Pod delayed in-place upgrade delay has been met, the Pod's container image is modified, and the Pod status synchronization is completed.

[0117] Step S2.2.4.4: The container image of the Pod has been modified. Determine whether the container image used by the Pod is consistent with the modified container image. If they are consistent, it means that the Pod in-place upgrade has been completed. Execute step S2.2.4.5. If they are inconsistent, end the Pod status synchronization.

[0118] Step S2.2.4.5: The Pod in-place upgrade is complete, and the Pod status InPlaceUpdateReady (in-place upgrade Ready status) is set to true, ending the Pod status synchronization.

[0119] Step S2.2.5: In step S2.2.4, the presence of an in-place upgrade annotation is detected, and the in-place upgrade process is started. The Pod list obtained in step S2.2.3 is traversed, and three Pod lists are obtained according to the in-place upgrade annotation in the Pod annotation, namely, a list of Pods in the in-place upgrade state, a list of Pods that have completed the in-place upgrade, and a list of Pods that have not yet performed the in-place upgrade. Then, it is determined whether the total number of Pods that have completed the in-place upgrade and are in the in-place upgrade state reaches the expected number of in-place upgrade copies. If not, the difference number of Pods is taken out from the list of Pods that have not yet performed the in-place upgrade, and then the in-place upgrade is traversed.

[0120] This step S2.2.5 includes:

[0121] Step S2.2.5.1: In step S2.2.5, when performing an in-place upgrade on a Pod, first obtain the delay time spec.updateStrategy.inPlaceUpdateStrategy.gracePeriodSeconds (an integer in seconds). If not set, fill it with the default value 1. Then set the in-place upgrade annotation for the Pod, and at the same time set the Pod status InPlaceUpdateReady to false. After setting, if InPlaceUpdateReady is set in the Pod ReadinessGate, the Pod status will change from Ready to NotReady, and the Pod's address will be removed from the endpoints. New network connections will no longer enter this Pod. Then, during subsequent reconciliation, re-enter the in-place upgrade component to complete the subsequent process of the in-place upgrade.

[0122] Step S2.3: In step S2.2, the partition reload component will read the partition reload configuration spec.overrides and the general configuration template spce.template, and then generate respective differentiated configurations for each partition through the partition reload strategy. Then use the generated differentiated configurations to create InplaceSet resources to achieve multi-partition differentiated deployment of the service. The content included in the reload strategy is: the name of the reload target partition (string), the reload configuration path (string), the reload operator op (string), and the value after reload (string). Among them, the reload operator op can be add, replace, or remove, representing addition, replacement, and deletion respectively. When op is remove, the value after reload can be empty.

[0123] Step S2.4: In step S2.3, the publishing component will determine the number of replicas set when creating an InplaceSet through the publishing strategy, and then create the InplaceSet resource. First, obtain the publishing strategy configuration spec.strategy.rolloutStrategy (string) in the CibDeployment configuration, which can be Beta and Group, representing Beta publishing and grouped publishing respectively. Beta publishing means that when publishing for the first time, a Pod will be created in each partition first, that is, set the number of replicas of the partition InplaceSet to 1, and then wait for this Pod to start successfully before continuing. Grouped publishing means that when publishing for the first time, the number of Pods created in each partition is the publishing step size spec.strategy.batchSize (an integer).

[0124] Step S2.5: In step S2.4, after the release of the first batch is completed according to the release strategy, if the number of replicas of the partition InplaceSet has not reached the expected number of replicas, then the InplaceSet needs to be expanded. This will be controlled by the grouped rolling component, and the entire rolling process will be divided into multiple batches. And only after the current batch is completed will the expansion of the next batch start; in each batch, all partitions that need to be expanded need to perform an expansion operation once. The number of replicas expanded each time is controlled by the step size spec.strategy.batchSize (the number of replicas after expansion cannot exceed the expected value). Only when all partitions that need to be expanded have been expanded and the expansion is completed can the expansion of the next batch be started.

[0125] Step S2.6: In step S2.4, if the CibDeployment resource sets the waiting confirmation strategy spec.strategy.needWaitingForConfirm to true, then before starting the expansion of the next batch, manual confirmation is also required. At this time, it can be seen in the annotation of CibDeployment that cib.deployment.io / upgrade-confirm: "false". Confirmation means changing the false in this annotation to true through the edit command. Only after the confirmation is completed will the expansion of the next batch start.

[0126] Step S2.7: In step 2.5, starting the expansion of the next batch requires waiting for all partitions to be expanded. Completion of the expansion means that all Pods under the InplaceSet of this partition should be in the available state. If there is insufficient partition resources and the Pods are always in the Pending state, it will cause the blockage of the expansion process. At this time, if the user enables the automatic scheduling strategy, that is, sets spec.strategy.autoReschedule.enable (boolean) to true, then the resource automatic scheduling component will handle the resource automatic scheduling logic; during automatic scheduling, it will first check if the Pod has been in the Pending state due to insufficient resources for more than the set timeout spec.strategy.autoReschedule.gracePeriodSeconds (integer) seconds. Then, it will check all partitions under CibDeployment and select the partition with the most resources. It will transfer the replicas that are in the Pending state due to insufficient resources and the number of replicas that have not completed the expansion in the current partition with insufficient resources to this partition with the most resources. When transferring, only the expected number of replicas of the partition is set through the annotation, and its expansion process still follows the process described in steps S2.3, S2.4, and S2.5.

[0127] Step S2.8: In Step S2.1, if the monitored CibDeployment resource is being upgraded and the configuration upgrade policy spec.strategy.updateStrategy is InPlaceIfPossible, it means that under the condition of meeting the in-place upgrade conditions, the in-place upgrade will be executed, that is, the Pod will not be rebuilt, only the containers in the Pod will be replaced, and the IP, disk mounts, and network configurations of the Pod will remain unchanged. And the in-place upgrade condition here is that only the container image is modified during the upgrade. If the condition is met, the Pod template of InplaceSet under the partition will be modified, and at the same time, the in-place upgrade annotation cib.inplaceset.io / inplaceset-update-spec will be set, and its content is to describe the expected state of the in-place upgrade, including the number of replicas to be upgraded and the upgrade version identifier hash.

[0128] Specifically, Step S3 specifically includes:

[0129] Step S3.1: In Step S3, the partition fault check and scheduling component will start a background coroutine to detect partition faults. The coroutine will listen for Node change events. Once a Node changes, the partition fault detection process Step S3.2 will be triggered. And at startup, the Node status will be pulled in full once and then cached as a Node status table, triggering a partition fault detection process.

[0130] Step S3.2: In Step S3.1, the partition fault detection process is triggered. The process updates the cached Node status table according to the received Node status event, then pulls the CibDeployment resource list in full and traverses the list. For each CibDeployment, its partitions are traversed, and it is detected whether there are faults in the partitions according to Step S3.3. Once a partition fault is detected, it is judged whether the CibDeployment already has a partition fault annotation. If not or it is inconsistent with the current partition fault, the fault annotation of the CibDeployment will be reset and the fault transfer will be executed according to Step S3.5; if there are no faults in all partitions, it is checked whether the CibDeployment has a partition fault annotation. If so, it is detected according to Step S3.4 whether the partition fault has been recovered. If it has been recovered, the partition fault annotation will be deleted, and then the resource will trigger the reconciliation process S2, and finally reach the expected state.

[0131] Step S3.3: In Step S3.2, it is detected whether a partition of the CibDeployment has a fault. By the partition Node affinity label, the matching Node list is pulled, and then the status of the Nodes in the list is judged. If all Nodes are in the NotReady state, it is considered that the partition has a fault.

[0132] Step S3.4: In step S3.2, detect whether a partition of CibDeployment has recovered from a failure. Pull the matching Node list through the partition Node affinity label, and then judge the status of the Nodes in the list. If all Nodes are in the Ready state, it is considered that the partition failure has been recovered.

[0133] Step S3.5: In step S3.2, perform a failover on the CibDeployment with a failed partition. First, obtain the list of partitions with normal status, then traverse the list, score the partitions according to step S3.6, and take the partition with the highest score as the transfer target. Transfer all replicas of the failed partition to the target partition, that is, set the number of replicas of the InplaceSet of the failed partition to 0, and set the number of replicas of the InplaceSet of the transfer target partition to the sum of the number of replicas of the original partition and the number of replicas of the failed partition.

[0134] Step S3.6: In step S3.5, it is necessary to score a partition. First, pull the matching Node list through the partition Node affinity label, construct a mapping table according to the Node names, then pull the Pod list, traverse the Pod list, filter the Pods that fall in the Node mapping table according to the Node where the Pod is located, and count the request resources; after the traversal is completed, count the total allocable resources of all Nodes in the Node mapping table, and subtract the total partitioned resources to obtain a score, which is recorded as the partition score.

[0135] Refer to Figure 4 As shown, the service is deployed on 3 partitions, region1, region2, and region3, with 2, 2, and 1 replicas respectively. Refer to Figure 5 As shown, when all Nodes in region1 fail, the replicas in the partition are transferred. Region3 has more resources, so they are transferred to region3. When region1 recovers, the replica transfer will automatically recover to the state before the failure.

[0136] Main functions and highlights of the present invention:

[0137] 1) Cross-region multi-active high availability and disaster tolerance for services:

[0138] To ensure cross-region multi-active services, if native components are used for deployment, it is necessary to maintain almost the same Deployment / StatefulSet in each partition to ensure that Pods will definitely be bound to the servers in the specified partition. After the scale increases, it will undoubtedly greatly increase the complexity of operation and maintenance management and cost consumption.

[0139] The controller we designed can deploy a service to multiple partitions as needed through configuration partitioning and manage it uniformly. Refer to Figure 6 as shown.

[0140] 2) Quickly stop losses after discovering problems

[0141] Use flexible release strategy control. When releasing and upgrading an application, through configuration group release confirmation, after releasing a group, the release will pause. When the user confirms that there is no error in the service, the subsequent release can continue; if an error is found, the error can be excluded in time to avoid the spread of the error and cause a greater impact.

[0142] 3) Pod IP retention

[0143] In some business systems, the service frameworks, monitoring, and operation and maintenance systems used rely heavily on IP. For services deployed using Deployment / StatefulSet, the IP cannot be guaranteed to remain unchanged during the upgrade, which will undoubtedly affect the existing operation and maintenance and monitoring systems.

[0144] Therefore, we designed to maintain the existing IP unchanged when releasing an application and only update the images in the Pod to achieve compatibility with the existing business system.

[0145] 4) Partition reload

[0146] A partition is a logical concept and a collection of Nodes that meet specific conditions. Physically, a partition can be a city, a data center, a computer room, or a rack; from the CPU architecture perspective, a partition can be a type of CPU architecture, such as amd or arm; regardless of the dimension of division, there may be some differences in these partitions. Then, when deploying a service to multiple partitions simultaneously, there will also be some differences, such as different images used in partitions with different architectures, and different numbers of service Pods deployed in partitions in different regions due to different business volumes.

[0147] For this demand for differential deployment, a partition reload function is designed. By combining unified configuration with partition reload configuration, differential configuration of partitions is obtained, and finally differential deployment of multiple partitions is achieved.

[0148] 5) Fault perception and automatic transfer

[0149] It can automatically perceive partition faults and simultaneously automatically transfer the application to other normal partitions after perceiving the faults. The selected partition for transfer is the optimal partition calculated in real time based on resource usage to improve the reliability of the application.

[0150] An embodiment of the present invention provides a design method and system for a cloud-native controller applicable to a financial distributed architecture. Through partitioned deployment configuration, services can be deployed to multiple partitions simultaneously, achieving the goal of high availability and disaster tolerance for business multi-site active-active operation. Through partition reload configuration, differential deployment of partitions can be achieved. By configuring deployment strategies, grouped deployment can be realized, controlling the deployment step size and enabling a manual confirmation mechanism to facilitate problem discovery and rapid loss prevention. By configuring deployment strategies, in-place upgrade of Pods can be achieved with the IP remaining unchanged, being compatible with some business systems that rely on IP. Automatic scheduling can be configured to automatically schedule to partitions with sufficient resources when a partition has insufficient resources. Partition failures can be automatically detected, and services can be automatically transferred to normal partitions during a failure to ensure service reliability.

[0151] Those skilled in the art know that in addition to implementing the system and its various devices, modules, and units provided by the present invention in the form of pure computer-readable program code, the method steps can be logically programmed to enable the system and its various devices, modules, and units provided by the present invention to be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers, etc., to achieve the same functions. Therefore, the system and its various devices, modules, and units provided by the present invention can be considered as a hardware component, and the devices, modules, and units included therein for implementing various functions can also be regarded as the structure within the hardware component; the devices, modules, and units for implementing various functions can also be regarded as either software modules for implementing the method or the structure within the hardware component.

[0152] The specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the above specific implementation manners, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Without conflict, the embodiments of the present application and the features in the embodiments can be combined with each other arbitrarily.

Claims

1. A design method for a cloud-native controller applicable to a financial distributed architecture, characterized in that, Including: Components CibDeployment and InplaceSet; among them, CibDeployment mainly implements partition control, controls multiple InplaceSets below it, each InplaceSet corresponds to a partition, and at the same time controls the release policy, fault perception, and automatic transfer; InplaceSet only implements the function of replica retention and in-place upgrade; Step S1: Implement business deployment by submitting CibDeployment resources to the kubernetes cluster; Step S2: The controller triggers the mediation process of the CibDeployment resources by listening to the CibDeployment resource change event to complete the business deployment; Step S3: After the business deployment is completed in Step S2, the partition fault detection and scheduling component regularly detects faults for all partitions. Once it detects that all nodes in a certain partition are faulty, it will transfer the replicas in that partition to other partitions, and at the same time detect whether the faulty partition has recovered. If the partition fault recovers, it will automatically restore to the state when there is no fault.

2. The design method of the cloud native controller applicable to the financial distributed architecture according to claim 1, characterized in that The said Step S2 includes: Step S2.1: The CibDeployment controller triggers the resource mediation process by listening to the change event of the CibDeployment or InplaceSet resource. After entering the mediation process, it first obtains the detailed information of the resource object through the resource identifier; Step S2.2: Through the CibDeployment resource information obtained in Step S2.1, the partition deployment component traverses the partition configuration spec.regions of CibDeployment, calls the partition reload component to complete the partition differential configuration, and then calls the release component to deploy the business to multiple partitions. The partition configuration includes the partition name name, the number of partition replicas replicas, and the partition label matchLabels; Step S2.3: In Step S2.2, the partition reload component reads the partition reload configuration spec.overrides and the general configuration template spce.template, and then generates respective differential configurations for each partition through the partition reload policy, and then creates InplaceSet resources using the generated differential configurations; Step S2.4: In Step S2.3, the release component determines the number of replicas set when creating InplaceSet through the release policy, and then creates InplaceSet resources; Step S2.5: In Step S2.4, according to the release policy, after the first batch of releases is completed, if the number of replicas of the partition InplaceSet has not reached the expected number of replicas, then the InplaceSet needs to be expanded. Controlled by the grouped rolling component, the entire rolling process is divided into multiple batches, and only after the current batch is completed will the next batch of expansion start; Step S2.6: In step S2.4, if the CibDeployment resource sets the waiting confirmation policy spec.strategy.needWaitingForConfirm to true, then before starting the expansion of the next batch, manual confirmation is required. After the confirmation is completed, the expansion of the next batch can begin; Step S2.7: In step 2.5, starting the expansion of the next batch requires waiting for all partitions to be expanded. The expansion is considered complete when all Pods under the InplaceSet of the partition are in the available state; Step S2.8: In step S2.1, if it is monitored that the CibDeployment resource is being upgraded and the configuration upgrade policy spec.strategy.updateStrategy is set to InPlaceIfPossible, it means that if the in-place upgrade conditions are met, the in-place upgrade will be executed, that is, the Pod will not be rebuilt, only the containers in the Pod will be replaced, and the IP, disk mounts, and network configurations of the Pod will remain unchanged.

3. The design method of the cloud native controller applicable to the financial distributed architecture according to claim 2, characterized in that, The said step S2.2 includes: Step S2.2.1: In step S2.2, an InplaceSet resource is created for each partition. The InplaceSet resource contains the following important information: replicas: The desired number of pod replicas; minReadySeconds: The minimum time to wait in the ready state before the pod status becomes available; updateStrategy: Set the in-place upgrade strategy, which contains the following fields: type: The value is Roll or InplaceIfPossible. Roll means rolling upgrade, and InplaceIfPossible means in-place upgrade if possible, otherwise no in-place upgrade; gracePeriodSeconds: The time to wait for traffic switching before in-place upgrade; template: Describes the resource object of the pod, which is a built-in resource object in k8s; Step S2.2.2: The InplaceSet controller listens for change events of InplaceSet and Pod resources. If it is a Pod resource, the corresponding InplaceSet resource is obtained through the OwnerReference attribute of the Pod, thereby triggering the reconciliation process of the InplaceSet resource; in step S2.2.1, when the creation event of the InplaceSet resource is monitored, the reconciliation process of the InplaceSet resource is triggered. First, the replica number synchronization is completed through the replica retention component, and then the in-place upgrade is completed through the in-place upgrade component; Step S2.2.3: In step S2.2.2, the replica retention component filters the corresponding Pod list through the label selector of InplaceSet, and then filters out the Pods in the Succeed and Failed states. These two types of Pods have completed their own life cycles, obtaining the Pod list under the current InplaceSet; after obtaining the Pod list, compare it with the expected number of replicas of the InplaceSet. If the actual number of Pods is less than the expected number of replicas of the InplaceSet, Pods need to be created to fill the gap; if the actual number of Pods is greater than the expected number of replicas of the InplaceSet, the redundant Pods need to be deleted; if the actual number of Pods is equal to the expected number of replicas of the InplaceSet, no deletion and creation operations need to be performed on the Pods. Step S2.2.4: In step S2.2.2, the in-place upgrade component first traverses the Pod list obtained in step S2.2.3 to synchronize the in-place upgrade status of the Pods, and then checks the upgrade strategy configuration spec.updateStrategy.type. If the upgrade strategy is InPlaceIfPossible, it means that in-place upgrade can be performed. Then check whether there is an in-place upgrade annotation cib.inplaceset.io / inplaceset-update-spec in the InplaceSet. If it exists, it means that in-place upgrade needs to be performed currently. Step S2.2.5: In step S2.2.4, when the existence of the in-place upgrade annotation is detected, the in-place upgrade process starts. Traverse the Pod list obtained in step S2.2.

3. According to the in-place upgrade annotation in the Pod annotation, three Pod lists are obtained, namely the Pod list in the in-place upgrade state, the Pod list that has completed the in-place upgrade, and the Pod list that has not yet performed the in-place upgrade. Then judge whether the total number of Pods that have completed the in-place upgrade and are in the in-place upgrade state reaches the expected number of in-place upgrade replicas. If not, take out the difference number of Pods from the Pod list that has not yet performed the in-place upgrade, and then traverse and execute the in-place upgrade.

4. The design method of the cloud native controller applicable to the financial distributed architecture according to claim 2, wherein The creation of the InplaceSet resource in step S2.4 includes: by obtaining the release strategy configuration spec.strategy.rolloutStrategy in the CibDeployment configuration, which is Beta and Group, representing Beta release and grouped release respectively. For Beta release, at the first release, one Pod is created in each partition, that is, the number of InplaceSet replicas in the partition is set to 1, and then wait for this Pod to start successfully before continuing; for grouped release, the number of Pods created in each partition at the first release is the release step size spec.strategy.batchSize.

5. The design method of the cloud native controller applicable to the financial distributed architecture according to claim 2, wherein The step S2.5 further includes: in each batch, all partitions that need to be scaled up need to perform a scaling-up operation once, and the number of replicas for a single scaling-up is controlled by the step size spec.strategy.batchSize. Only when all partitions that need to be scaled up have been scaled up and the scaling-up is completed can the scaling-up of the next batch be started.

6. The design method of the cloud native controller applicable to the financial distributed architecture according to claim 2, wherein The in-place upgrade condition in the step S2.8 is that only the container image is modified during the upgrade. If the condition is met, the Pod template of the InplaceSet under the partition will be modified, and at the same time, the in-place upgrade annotation cib.inplaceset.io / inplaceset-update-spec will be set, and its content is to describe the expected state of the in-place upgrade, including the number of replicas to be upgraded and the upgrade version identifier hash.

7. The design method of the cloud native controller applicable to the financial distributed architecture according to claim 3, wherein The step S2.2.4 includes: Step S2.2.4.1: In the step S2.2.4, synchronize the Pod status. First, obtain the in-place upgrade annotation of the Pod. If the annotation does not exist, it means that the Pod has not performed an in-place upgrade, and the Pod status synchronization ends; if the annotation exists, it means that the Pod has performed an in-place upgrade, and then execute step S2.2.4.2; Step S2.2.4.2: The Pod is in the in-place upgrade state. Determine whether the Pod has a delayed in-place upgrade, that is, the Pod container image has not been modified yet. If not, execute step S2.2.4.

4. If so, check whether the delay time has been met. If it has been met, execute step S2.2.4.

3. If it has not been met, end the Pod status synchronization; Step S2.2.4.3: The delay of the Pod's in-place upgrade has been met. Modify the container image of the Pod and end the Pod status synchronization; Step S2.2.4.4: The container image of the Pod has been modified. Determine whether the container image used by the Pod is the same as the modified container image. If they are the same, it means that the in-place upgrade of the Pod has been completed, and execute step S2.2.4.

5. If they are not the same, end the Pod status synchronization; Step S2.2.4.5: The in-place upgrade of the Pod has been completed. Set the Pod status InPlaceUpdateReady to true and end the Pod status synchronization.

8. The design method of the cloud native controller applicable to the financial distributed architecture according to claim 3, characterized in that, The step S2.2.5 includes: Step S2.2.5.1: In step S2.2.5, perform an in-place upgrade on the Pod. First, obtain the delay time spec.updateStrategy.inPlaceUpdateStrategy.gracePeriodSeconds. If it is not set, fill it with the default value 1. Then set the in-place upgrade annotation for the Pod, and at the same time set the Pod status InPlaceUpdateReady to false. After setting, if InPlaceUpdateReady is set in the Pod ReadinessGate, then the Pod status will change from Ready to NotReady, and the Pod's address will be removed from the endpoints, and new network connections will no longer enter this Pod; then during subsequent reconciliation, re-enter the in-place upgrade component to complete the subsequent process of the in-place upgrade.

9. The design method of the cloud native controller applicable to the financial distributed architecture according to claim 3, characterized in that The said step S3 includes: Step S3.1: In step S3, the partition failure check and scheduling component starts a background coroutine to detect partition failures. The coroutine listens for Node change events. Once a Node changes, it triggers the partition failure detection process step S3.2, and at startup, pulls the Node status in full once and then caches it as a Node status table, triggering a partition failure detection process; Step S3.2: In step S3.1, trigger the partition failure detection process. The process updates the cached Node status table according to the received Node status event, then pulls the CibDeployment resource list in full and traverses the list. For each CibDeployment, traverse its partitions and detect whether there are failures in the partitions according to step S3.

3. Once a partition failure is detected, judge whether the CibDeployment already has a partition failure annotation. If not or it is inconsistent with the current partition failure, re-set the failure annotation for the CibDeployment and perform a failover according to step S3.5; if all partitions have no failures, check whether the CibDeployment has a partition failure annotation. If so, detect whether the partition failure has been recovered according to step S3.

4. If it has been recovered, delete the partition failure annotation, and then the resource triggers the reconciliation process S2 to finally reach the desired state; Step S3.3: In step S3.2, detect whether a partition of the CibDeployment has failed. By the partition Node affinity label, pull the list of matching Nodes, and then judge the status of the Nodes in the list. If all Nodes are in the NotReady state, it is considered that the partition has failed; Step S3.4: In step S3.2, detect whether a partition of the CibDeployment has recovered from a failure. By the partition Node affinity label, pull the list of matching Nodes, and then judge the status of the Nodes in the list. If all Nodes are in the Ready state, it is considered that the partition failure has been recovered; Step S3.5: In step S3.2, for the CibDeployment with a faulty partition, perform a failover. First, obtain the list of partitions with normal status, then traverse the list, score the partitions according to step S3.6, select the partition with the highest score as the transfer target, and transfer all replicas of the faulty partition to the target partition, that is, set the number of replicas of the InplaceSet of the faulty partition to 0, and set the number of replicas of the InplaceSet of the transfer target partition to the sum of the number of replicas of the original partition and the number of replicas of the faulty partition; Step S3.6: In step S3.5, it is necessary to score a partition. First, pull the matching Node list through the partition Node affinity label, construct a mapping table according to the Node name, then pull the Pod list, traverse the Pod list, filter the Pods that fall in the Node mapping table according to the Node where the Pod is located, and count the request resources; after the traversal is completed, count the total allocable resources of all Nodes in the Node mapping table, subtract the total partitioned resources, and obtain a score, which is recorded as the partition score.

10. A design system for a cloud-native controller applicable to a financial distributed architecture, characterized in that, Including: Components CibDeployment and InplaceSet; among them, CibDeployment mainly realizes partition control, controls multiple InplaceSets below it, each InplaceSet corresponds to a partition, and at the same time controls the release policy, fault perception and automatic transfer; InplaceSet only realizes the functions of replica retention and in-place upgrade; Module M1: Realize business deployment by submitting CibDeployment resources to the kubernetes cluster; Module M2: The controller triggers the mediation process of the CibDeployment resources by listening to the CibDeployment resource change event to complete the business deployment; Module M3: After module M2 completes the business deployment, the partition fault detection and scheduling component regularly detects all partitions for faults. Once it detects that all nodes of a certain partition are faulty, it transfers the replicas in the partition to other partitions, and at the same time detects whether the faulty partition has recovered. If the partition fault recovers, it automatically restores to the state without faults.

Images