Configuration method and device of cloud native network, equipment and medium

Abstract

The invention relates to the technical field of development, can be applied to financial network scenes, and discloses a cloud native network configuration method and device, equipment and a medium, and the method comprises the steps: storing full node information in a network cluster to a distributed key value storage system through a command line interface; performing self-defined plug-in connection with the distributed key value storage system in response to the operation and maintenance tool, and performing deployment marking on a target node in the network cluster to obtain a deployment label of the target node; and associating and deploying the cloud native network and the routing daemon process on the target node in the network cluster according to the deployment label of the target node, so that the target node realizes bidirectional transmission of routing information through component linkage. According to the process, the cloud native network configuration process needing manual operation can be converted into an automatic process capable of being repeatedly executed, so that the configuration process of the cloud native network adapts to the dynamic characteristics of the cloud native environment, and the flexibility of the cloud native network in the deployment stage is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the development technical field, which can be applied to the financial network scene, and particularly relates to a cloud native network configuration method and device, equipment and medium. BACKGROUND

[0002] With the wide application of containerization technology, cloud native network as a high-performance container network solution is adopted by more and more enterprises. In the financial network scene, the essence of cloud native network is the balance between industry core demands and cloud native technology characteristics. However, different business scenarios have significant differences in network requirements, which requires cloud native network to configure differentiated network strategies for different businesses, so that the deployment and management of cloud native network still face many challenges, such as complex configuration process, consistency management in multi-node environment, and collaborative operation with network services such as routing daemon.

[0003] In related technologies, the configuration of cloud native network usually works with routing daemon service to realize the automatic management of border gateway protocol routing. However, the existing configuration process needs to manually install key components of cloud native network for each node, configure filtering package parameters, and set routing protocol, synchronization node address and node allocation network address range for routing daemon, which is difficult to adapt to the dynamic characteristics of cloud native environment, making cloud native network lack flexibility in the deployment stage. SUMMARY

[0004] The present application provides a cloud native network configuration method, device, computer equipment and medium to solve the technical problem that the manual configuration process in related technologies is difficult to adapt to the dynamic characteristics of cloud native environment, making cloud native network lack flexibility in the deployment stage.

[0005] In a first aspect, a cloud native network configuration method is provided, comprising:

[0006] Storing full node information in a network cluster to a distributed key-value storage system using a command line interface to track the state of node deployment progress through the distributed key-value storage system;

[0007] In response to the self-defined plug-in connection between the operation and maintenance tool and the distributed key-value storage system, marking the target node in the network cluster for deployment to obtain the deployment label of the target node;

[0008] According to the deployment label of the target node, the cloud native network and the routing daemon are associated and deployed on the target node in the network cluster, so that the target node realizes the bidirectional transmission of routing information through component linkage.

[0009] In a second aspect, a cloud native network configuration device is provided, comprising:

[0010] a storage module configured to store full node information in a network cluster to a distributed key-value storage system using a command line interface, to track a state of a node deployment progress via the distributed key-value storage system;

[0011] a marking module configured to mark a target node in the network cluster to obtain a deployment label of the target node in response to a self-defined plug-in connection between an operation and maintenance tool and the distributed key-value storage system;

[0012] a deployment module configured to associate and deploy a cloud-native network and a routing daemon on the target node in the network cluster according to the deployment label of the target node, so that the target node realizes bidirectional transmission of routing information through component linkage.

[0013] In a third aspect, a computer device is provided, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the steps of the cloud-native network configuration method when executing the computer program.

[0014] In a fourth aspect, a computer readable storage medium is provided, which stores a computer program, and the computer program implements the steps of the cloud-native network configuration method when executed by a processor.

[0015] In the cloud-native network configuration method, apparatus, computer device, and storage medium, the server stores full node information in a network cluster to a distributed key-value storage system using a command line interface, to track a state of a node deployment progress via the distributed key-value storage system; a target node in the network cluster is marked to obtain a deployment label of the target node in response to a self-defined plug-in connection between an operation and maintenance tool and the distributed key-value storage system; and a cloud-native network and a routing daemon are associated and deployed on the target node in the network cluster according to the deployment label of the target node, so that the target node realizes bidirectional transmission of routing information through component linkage. In the present application, the self-defined plug-in connection between the operation and maintenance tool and the distributed key-value storage system converts a cloud-native network configuration process that needs manual operation into a repeatable automatic process, avoids randomness of manual operation, and adapts the cloud-native network configuration process to dynamic characteristics of a cloud-native environment, thereby improving flexibility of the cloud-native network in a deployment stage. BRIEF DESCRIPTION OF DRAWINGS

[0016] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments of the present invention. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0017] Figure 1 This is a schematic diagram of an application environment of a method for configuring a cloud native network in one embodiment of the present invention;

[0018] Figure 2 This is a flow chart of a method for configuring a cloud native network according to an embodiment of the present invention;

[0019] Figure 3 yes Figure 2 A schematic flow chart of a specific implementation of step S10;

[0020] Figure 4 1 is a flow chart of a method for configuring a cloud native network in another embodiment of the present invention;

[0021] Figure 5 yes Figure 2 A schematic flow chart of a specific implementation of step S20;

[0022] Figure 6 yes Figure 2 A schematic flow chart of a specific implementation of step S30;

[0023] Figure 7 1 is a schematic diagram of a configuration device for a cloud native network according to an embodiment of the present invention;

[0024] Figure 8 is a structural diagram of a computer device in one embodiment of the present invention;

[0025] Figure 9 FIG. 2 is another structural diagram of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0026] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0027] The cloud native network configuration method provided by the embodiment of the present invention can be applied in Figure 1In an application environment, the server uses a command line interface to store all node information in the network cluster into a distributed key-value storage system, so as to track the status of the node deployment progress through the distributed key-value storage system; in response to the operation and maintenance tool and the distributed key-value storage system, a custom plug-in is connected, and the target node in the network cluster is deployed with a deployment mark to obtain the deployment label of the target node; according to the deployment label of the target node, the cloud native network and the routing daemon are associated and deployed on the target node in the network cluster, so that the target node can realize two-way transmission of routing information through component linkage on the client. In the present invention, the cloud native network configuration process that requires manual operation is converted into an automated process that can be executed repeatedly, avoiding the randomness of manual operation, so that the configuration process of the cloud native network adapts to the dynamic characteristics of the cloud native environment, and improves the flexibility of the cloud native network in the deployment stage. Among them, the client can be but is not limited to various personal computers, laptops, smart phones, tablets and portable wearable devices. The server can be implemented with an independent server or a server cluster composed of multiple servers. The present invention is described in detail below through specific embodiments.

[0028] See also Figure 2 As shown, Figure 2 A flowchart of a method for configuring a cloud-native network provided in an embodiment of the present invention includes the following steps:

[0029] S10: Using a command line interface, store all node information in the network cluster into a distributed key-value storage system, so as to track the status of node deployment progress through the distributed key-value storage system.

[0030] The cloud-native network configuration method provided by the application can be applied to the cloud-native component configuration scene of a financial network. Since the network response speed is extremely high for financial transactions, the cloud-native network and routing process are deployed to the local node, which can reduce the forwarding level of cross-node communication, reduce data transmission delay, and avoid transaction timeout caused by remote calls. Specifically, the cloud-native network and routing daemon process can be packaged by a container image, and the node rules of the container orchestration platform can be combined to specify that the process is only deployed on the financial core node, such as a server carrying a transaction system, to ensure that resources are preferentially allocated. When the node starts, the deployment process of the daemon process is triggered by an automated script, including installing dependent components and loading financial special network rules, such as an encrypted transmission protocol and a port access whitelist, to ensure that the process meets the security standards when it starts. Further, the daemon process is bound to the node state, such as being automatically deployed when the node joins the cluster, and the process is stopped before the node goes offline and the network state is synchronized to the management platform to avoid network conflicts caused by residual configurations. After deployment, the node-level monitoring tool is used to check the running state of the process in real time, and if an abnormality is found, the process is automatically restarted or switched to a standby process to ensure continuous availability.

[0031] In the embodiment, the full-node information is the basic data of all nodes, such as hostnames, IP addresses, and deployment states. These full-node information can be arranged into a text in a unified format to ensure that each record contains a unique node identifier and a current state. The collected text can also be processed by a command line tool to be converted into a structure supported by a distributed key-value storage system.

[0032] It can be understood that the distributed key-value storage system stores data in the form of key-value pairs, and the data is dispersed on multiple nodes, which is suitable for storing structured or unstructured data without complex association relationships. During node deployment, the deployment tool or script writes / updates data to the distributed key-value storage system in real time. For example, when the node starts to deploy, its value is set to deploying, after the configuration is completed, it is updated to completed, and if an error occurs, specific fault information is recorded. Correspondingly, for a single node, the current deployment state of the node can be directly obtained by querying the key of the specific node, and the abnormal node can be quickly located; for multiple nodes, the keys of all nodes are traversed, the number of nodes in different states is summarized, the completion ratio is calculated, and the real-time monitoring of the global progress of the cluster deployment is realized.

[0033] Further, in order to ensure that the node state data is not lost, the redundant mechanism of the distributed key-value storage system can be used for multi-copy storage, so that even if part of the storage nodes fail, the deployment progress can still be normally queried and updated.

[0034] Specifically, as Figure 3As shown, in step S10, that is, using the command line interface to store all node information in the network cluster into the distributed key-value storage system, so as to track the status of the node deployment progress through the distributed key-value storage system, the following steps are included:

[0035] S11: Perform structured processing on all node information exported from the network cluster in advance to obtain the full amount of node information in the network cluster.

[0036] S12: Use a command line interface to create a unique storage path for each node, so as to store all node information in the network cluster into the distributed key-value storage system through the storage path.

[0037] S13: defining a deployment state of a node in the distributed key-value storage system, so as to track the node deployment progress according to the deployment state.

[0038] In step S11, all node information exported by the network cluster is a collection of various raw data related to the nodes output by the cluster system through logs, configuration files, or management tools, which generally includes but is not limited to basic identification information, network attribute information, hardware and resource information, and association relationship information.

[0039] It should be noted that the full node information exported by a network cluster is often in a disorganized format, such as mixed text, table fragments, and log snippets. This information can be duplicated, redundant, or inconsistently expressed. Further structuring is required to transform this disorganized raw information into standardized data with a unified format and well-defined fields, ready for storage and analysis. Specifically, key fields to be retained should be identified, and clear meanings and value ranges should be defined for each field. For example, deployment status should include key fields such as Not Started / Deploying / Configuration Verification / Completed / Failed. Memory capacity should be uniformly expressed in GB and formatted as a number. The full node information is then cleaned, including invalid information removal and data error correction. Invalid information removal removes duplicate node records, meaningless redundant content, and information unrelated to the target field. Data error correction corrects and / or supplements incorrect values. For example, if IP addresses of the same node conflict, the correct value can be confirmed by the actual cluster network configuration. Alternatively, if a node's cluster is not recorded, its physical location can be used to associate it with the node. Finally, the retained full node information is processed uniformly according to the preset format. For text fields, the language and expression are unified, and unnecessary spaces or symbols are removed; for numerical fields, the units are unified and reasonable accuracy is retained; for time fields, they are unified into the year-month-day format and the minute-second format.

[0040] In step S12, the storage path format is designed in combination with the unique identifier of the node. For example, the cluster name / node type / node unique identifier is used as the hierarchical structure to ensure that the path of each node is not repeated, which is convenient for subsequent positioning and management. Then, the command line function of the cluster management tool is used to traverse the unique identifiers of all nodes, call the path creation command of the distributed key-value storage system, and generate a dedicated storage path for each node according to the preset rules. Then, the node information is associated with the storage path, and the structured node information is bound to the unique path of the corresponding node. The information is written to the path through the command line client, with the path as part of the key and the node information as the value, to ensure that each piece of information accurately corresponds to the node.

[0041] In step S13, the node deployment status accurately describes the specific stage or state of the node in the network cluster during the entire deployment process. Through standardized status definitions, it can clearly reflect each step of the node's progress from the initial to the final availability or failure. Specifically, according to the entire life cycle of the node deployment, the status can be broken down into quantifiable and unambiguous types, covering all key links from the initial to the final, including the initial state, process state, verification state, and result state. Then, using the key-value storage structure, the node status is bound to the node's unique identifier, and the overall progress can be monitored and analyzed through real-time updates and queries. For the dynamic status update process, when the node status changes, the deployment tool immediately calls the key-value storage interface to update the status and related fields of the corresponding node to ensure that the status is synchronized with the actual deployment progress.

[0042] S20: In response to the operation and maintenance tool establishing a custom plug-in connection with the distributed key-value storage system, a target node in the network cluster is deployed and marked to obtain a deployment label of the target node.

[0043] In this embodiment, the operation and maintenance tool implements batch configuration management, deployment and operation, task execution, and other operations for nodes such as server clusters and network devices in a modular manner. There is no need to install a client on the target node. It mainly interacts with the node by setting a protocol and writing automated task scripts to define the operation and maintenance logic, thereby realizing a standardized and automated operation and maintenance process. In the interaction with the distributed key-value storage system, the operation and maintenance tool acts as the initiator of the operation and maintenance operation, and uses a custom plug-in to open a connection with the storage system, thereby passing operation and maintenance information such as node deployment labels to the distributed key-value storage system, or obtaining node status data from the distributed key-value storage system to achieve status tracking of the cluster node deployment process.

[0044] Specifically, the tagging logic can be defined using the automated task scripts of the operation and maintenance tool. The tagging instructions are then passed to the distributed key-value storage system through a connected custom plug-in. This process involves specifying the target node to be tagged in the node list of the operation and maintenance tool. Then, in the automated task script, a tagging request is sent to the distributed key-value storage system through the custom plug-in. This task includes the unique identifier of the target node, ensuring that the storage system can accurately define the node. It also includes passing preset deployment labels, which the plug-in converts into a format recognizable by the storage system. Accordingly, after receiving the information from the plug-in, the distributed storage system completes the storage and association of the labels.

[0045] In actual application scenarios, when operation and maintenance tools need to interact with distributed key-value storage systems for customized data, such as specific formats, protocols, business logic, etc., and the default functions cannot meet the requirements, custom plug-ins can fill the gap in interaction capabilities and achieve real-time data reading and writing, state collaboration, or cross-tool sharing. Figure 4 As shown, before step S20, the method further includes the following steps:

[0046] S40: placing the pre-developed custom plug-in into the detection directory of the operation and maintenance tool, so that the operation and maintenance tool can obtain the custom plug-in according to the detection directory during operation.

[0047] S50: In the configuration file of the operation and maintenance tool, pre-fill the connection parameters of the distributed key-value storage system.

[0048] S60: If an execution task of calling a custom plug-in is identified in the configuration file of the operation and maintenance tool, the operation and maintenance tool is triggered to connect the custom plug-in to the distributed key-value storage system according to the connection parameters.

[0049] In step S40, the default detection directories of different tools are different. It is necessary to consult the official documents according to the specific tool to confirm the path to determine the location of the plug-in detection directory of the operation and maintenance tool. Then organize the custom plug-in files to ensure that the plug-in file format meets the tool requirements and avoid duplication with the tool's built-in plug-ins. At the same time, check whether the plug-in has dependent auxiliary files. If so, they need to be placed in an associated directory that the tool can recognize. Then, through the file management tool or command line operation, move the plug-in and related dependent files to the previously confirmed detection directory, and set the file permissions to ensure that the operation and maintenance tool can access it normally. Finally, run the basic commands of the operation and maintenance tool to check whether the plug-in appears in the list of available plug-ins of the tool; you can also execute a simple task to call the plug-in. If the task can be executed normally, it means that the tool has successfully obtained the custom plug-in from the detection directory.

[0050] In step S50, different operation and maintenance tools have different configuration file paths and formats. Based on the characteristics of the distributed key-value storage system, at least one connection parameter is filled in the configuration file according to the format. The connection parameter includes at least one of an access address, an authentication method, and a communication protocol.

[0051] In step S60, when the operation and maintenance tool loads the configuration file, it scans and identifies the task to be executed, determining whether the task relies on a custom plug-in. The operation and maintenance tool then reads the connection information for the distributed key-value storage system from the configuration file. These parameters are temporarily cached and serve as the core credentials for the plug-in connection. The operation and maintenance tool then activates the pre-set custom plug-in and injects the extracted connection parameters into the plug-in. The plug-in then establishes a communication link with the storage system based on these parameters. Finally, the plug-in uses the connection parameters to attempt to establish a connection with the distributed key-value storage system. If authentication succeeds and communication is normal, the connection is confirmed to be successful, and the task is executed. If the connection fails, the operation and maintenance tool returns an error message, indicating a parameter configuration issue.

[0052] Specifically, if Figure 5 As shown, in step S20, that is, marking the target node in the network cluster for deployment to obtain the deployment label of the target node, the following steps are included:

[0053] S21: Based on the attribute information of all nodes in the network cluster, a multi-dimensional mapping relationship between node attributes and deployment labels is pre-established.

[0054] S22: Attribute association is performed on all nodes in the network cluster using the multi-dimensional mapping relationship to obtain a target node with attribute association.

[0055] S23: Using the multi-dimensional mapping relationship, label mapping is performed on the target node with attribute association to obtain a deployment label of the target node.

[0056] In step S21, a multidimensional mapping relationship is used to reflect the complex associations between node attribute combinations and multiple deployment tags. First, a comprehensive review of the various node attributes is conducted, covering multiple dimensions, including hardware, business, environment, and operational status. Hardware attributes include the number of CPU cores, memory size, and disk type; business attributes include service type and service priority; environment attributes include data center location and network domain; and operational status includes resource utilization and fault history. Next, a multi-category deployment tag system is designed to address diverse operational and maintenance requirements. For example, resource adaptation tags identify node resource capabilities; business-specific tags bind nodes to their business roles; policy execution tags guide deployment policies; and compliance and security tags meet compliance requirements. Next, a mapping relationship is constructed to clearly define the set of tags corresponding to each attribute combination. This mapping relationship typically involves a complex association between a combination of multiple attributes and multiple tags. For example, the effectiveness of a tag may require the fulfillment of attribute conditions across multiple dimensions, such as hardware, business, and environment. A single attribute combination may also correspond to multiple tags of different categories. At the same time, considering that node attributes will change over time, it is also necessary to establish a dynamic maintenance mechanism to ensure that the mapping relationship can timely reflect the actual situation of the node through regular verification updates, event-triggered adjustments, and manual intervention, so as to ensure its effectiveness and accuracy.

[0057] In step S22, the node features that need to be screened are determined according to the operation and maintenance requirements. These targets will correspond to specific label combinations in the multidimensional mapping relationship, and then the attribute combination conditions corresponding to the target labels are extracted from the preset multidimensional mapping rules. For example, if the target label is "core service carrying node + cross-region disaster recovery node", the corresponding attribute combination may be "CPU ≥ 16 cores + memory ≥ 64GB + core payment business + production environment + distributed in two computer rooms A and B". Then traverse the attribute information of all nodes in the cluster and compare them one by one to see if they meet the above attribute combination items, for example, whether the node has enough CPU and memory, whether it belongs to the core business, whether it is in the production environment and distributed across computer rooms. Further aggregate the nodes that meet the conditions to form a target node set with attribute associations, so that nodes that meet the same attribute combination conditions are mapped to the same set of deployment labels, and these nodes have clear association characteristics.

[0058] In step S23, based on the target nodes with attribute associations screened in the early stage, the attribute combinations shared by these nodes are sorted out to form a clear attribute association description, and then the preset multi-dimensional mapping relationship rules are called to find the rule entries that match the above attribute association characteristics from the established mapping rules. Then, the labels are matched in batches for the target nodes according to the rules to bind the found label set to the target nodes. Each node is assigned the same deployment label. Since these nodes have consistent attribute associations, they will be mapped to the same set of labels. Finally, by comparing the actual attributes of the target node with the meaning of the label, it is ensured that the label can accurately reflect the attribute association characteristics of the node, avoiding the mismatch between the label and the actual situation of the node due to deviation in the mapping rules.

[0059] S30: Deploy a cloud native network and a routing daemon process on the target node in the network cluster according to the deployment label of the target node, so that the target node can achieve bidirectional transmission of routing information through component linkage.

[0060] Specifically, network and routing requirements are parsed based on deployment labels. This process extracts specific network characteristics and routing policies from the target node's deployment labels. These labels include at least the following types: network type labels, which specify the network architecture the node must support; routing protocol labels, which specify the protocol standard for routing information transmission; functional feature labels, which define the security requirements and redundancy mechanisms for routing transmission; and linkage scope labels, which define the boundaries of routing information transmission. By parsing these labels, the specific types and configuration instructions of the cloud-native network components and routing daemons required for the target node are determined. Components are then matched according to the labels and their associations are bound. Based on the label parsing results, the corresponding cloud-native network components and routing daemons are deployed to the target nodes in batches, and the linkage between them is bound using pre-set rules. Furthermore, component linkage enables bidirectional routing information transmission.

[0061] In actual application scenarios, bidirectional transmission of routing information is achieved through component linkage, which includes two directions. This process binds node attributes with component deployment and collaborative logic through deployment labels, which not only ensures the accuracy of component deployment, but also realizes the real-time bidirectional flow of routing information through component linkage, providing underlying support for network cluster traffic scheduling, fault self-healing and other scenarios. Specifically, Figure 6 As shown, step S30, that is, associating and deploying the cloud native network and the routing daemon on the target node in the network cluster according to the deployment label of the target node, so that the target node can realize bidirectional transmission of routing information through component linkage, includes the following steps:

[0062] S31: configuring a first component linkage for transmitting routing information from a cloud native network to a routing daemon according to a deployment label of the target node;

[0063] S32: Configure the second component linkage of the routing daemon to transmit routing information to the cloud native network according to the deployment label of the target node.

[0064] S33: Establish an association between the cloud native network and the routing daemon in the service configuration of the network cluster.

[0065] S34: Associating the first component linkage and the second component linkage with each other in state according to the association relationship, so that the target node can realize bidirectional transmission of routing information through the component linkage.

[0066] On the one hand, bidirectional transmission includes transmission from the network cluster to the target node. When the network status of the target node changes, such as the addition / deletion of a neighboring node or a link failure, the cloud-native network component sends the change information to the routing daemon through the linkage interface; the routing daemon calculates and updates the routing table according to the preset protocol and distributes the new routing information to other associated nodes in the cluster. Specifically, in step S31, routing information can be generated in the cloud-native network based on the deployment tag of the target node; the routing information is directed and pushed to the routing daemon through the first protocol format, so that the routing daemon receives the routing information through the target node association and performs network verification based on the routing information.

[0067] On the other hand, bidirectional transmission includes transmission from the target node to the network cluster. When the routing information of other nodes in the cluster is updated, such as adding a new service address or adjusting the routing priority, the routing daemon obtains this information through protocol monitoring and then synchronizes it to the local network component through the linkage interface. The network component adjusts the local forwarding rules based on the received routing table entries to ensure that the external routing information can be accurately mapped to the network path within the node. Specifically, in step S32, the routing information matching the target node can be extracted from the routing daemon based on the deployment tag of the target node; the routing information is pushed to the cloud native network through the second protocol format, so that the cloud native network receives the routing information on the target node and performs network configuration based on the routing information.

[0068] In step S33, the association relationship is used to ensure the state coordination between the cloud native network and the routing daemon. This association relationship means that through a series of settings in the service configuration, the cloud native network and the routing daemon can perceive each other's state changes in real time. When the state of the cloud native network changes, for example, the network connection fluctuates, a network node is added or removed, etc., the routing daemon can know in time and make corresponding adjustments; conversely, when the state of the routing daemon changes, such as routing rule updates, routing path switching, etc., the cloud native network can also synchronously obtain information and adapt. The realization of this state coordination ensures that the actual operating state of the cloud native network is always consistent with the routing rules maintained by the routing daemon, avoiding problems such as network communication anomalies and routing failures caused by the disconnection of the two states, thereby providing a solid guarantee for the stable and efficient operation of the network cluster.

[0069] In practical applications, cloud-native network configuration can be applied to financial network development scenarios. This process requires deeply embedding the financial industry's security and compliance requirements, business priority rules, and disaster recovery standards throughout the entire configuration process, forming an adaptation logic that prioritizes scenario constraints, accurately implements configuration, and continuously verifies compliance. During the configuration startup phase, network domains are first divided based on the risk level of financial services. During the configuration implementation phase, technical adaptation is performed to address financial characteristics. During the configuration verification phase, a focus is placed on the unique verification dimensions of financial scenarios. This combination creates a dynamic balance between the elastic configuration capabilities of cloud-native networks and the rigid constraints of financial scenarios. This approach preserves the flexibility of containerized deployment while strengthening the network security defenses of financial services through detailed configuration.

[0070] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0071] In one embodiment, a configuration device for a cloud native network is provided, and the configuration device for the cloud native network corresponds one-to-one with the configuration method for the cloud native network in the above embodiment. Figure 7 As shown, the configuration device of the cloud native network includes a storage module 101, a marking module 102 and a deployment module 103. The functional modules are described in detail as follows:

[0072] The storage module 101 is configured to store all node information in the network cluster to a distributed key-value storage system using a command line interface, so as to track the status of node deployment progress through the distributed key-value storage system;

[0073] The marking module 102 is configured to mark the target node in the network cluster for deployment in response to the operation and maintenance tool performing a custom plug-in connection with the distributed key-value storage system, thereby obtaining a deployment label of the target node;

[0074] The deployment module 103 is used to associate and deploy the cloud native network and the routing daemon on the target node in the network cluster according to the deployment label of the target node, so that the target node can realize bidirectional transmission of routing information through component linkage.

[0075] In one embodiment, the storage module 101 is specifically configured to:

[0076] All node information exported from the network cluster is structured in advance to obtain the full amount of node information in the network cluster;

[0077] Use the command line interface to create a unique storage path for each node, so as to store all node information in the network cluster in the distributed key-value storage system through the storage path;

[0078] The deployment status of the node is defined in the distributed key-value storage system, so as to track the node deployment progress according to the deployment status.

[0079] In one embodiment, the apparatus further comprises:

[0080] an acquisition module, configured to place a pre-developed custom plug-in in a detection directory of an operation and maintenance tool before marking the target node in the network cluster for deployment and obtaining the deployment tag of the target node, so that the operation and maintenance tool can obtain the custom plug-in according to the detection directory during runtime;

[0081] A filling module is used to pre-fill the connection parameters of the distributed key-value storage system in the configuration file of the operation and maintenance tool, wherein the connection parameters include at least one of an access address, an authentication method, and a communication protocol;

[0082] The plug-in connection module is used to trigger the operation and maintenance tool to connect the custom plug-in with the distributed key-value storage system according to the connection parameters if an execution task calling the custom plug-in is identified in the configuration file of the operation and maintenance tool.

[0083] In one embodiment, the marking module 102 is specifically configured to:

[0084] Based on the attribute information of all nodes in the network cluster, a multi-dimensional mapping relationship between node attributes and deployment labels is pre-established. The multi-dimensional mapping relationship is used to reflect the complex associations formed between node attribute combinations and multiple deployment labels.

[0085] Performing attribute association on all nodes in the network cluster using the multi-dimensional mapping relationship to obtain a target node with attribute association;

[0086] The target node with attribute association is subjected to label mapping using the multi-dimensional mapping relationship to obtain a deployment label of the target node.

[0087] In one embodiment, the deployment module 103 is specifically configured to:

[0088] A first component linkage is configured to transmit routing information from a cloud native network to a routing daemon according to a deployment tag of the target node;

[0089] A second component linkage is configured to configure a routing daemon to transmit routing information to a cloud native network according to a deployment label of the target node;

[0090] Establishing an association between the cloud native network and the routing daemon in the service configuration of the network cluster. The association is used to ensure state coordination between the cloud native network and the routing daemon.

[0091] The first component linkage and the second component linkage are state-associated according to the association relationship, so that the target node can achieve bidirectional transmission of routing information through component linkage.

[0092] In one embodiment, the deployment module 103 is further configured to:

[0093] Generating routing information in the cloud native network according to the deployment label of the target node;

[0094] The routing information is directed and pushed to the routing daemon process through the first protocol format, so that the routing daemon process receives the routing information through the target node association and performs network verification according to the routing information.

[0095] In one embodiment, the deployment module 103 is further configured to:

[0096] Extracting routing information matching the target node in the routing daemon according to the deployment label of the target node;

[0097] The routing information is directed and pushed to the cloud native network through the second protocol format, so that the cloud native network receives the routing information on the target node and performs network configuration according to the routing information.

[0098] The present invention provides a configuration device for a cloud-native network, which connects a custom plug-in with an operation and maintenance tool and a distributed key-value storage system, converts the cloud-native network configuration process that requires manual operation into a repeatable automated process, avoiding the randomness of manual operation, making the cloud-native network configuration process adapt to the dynamic characteristics of the cloud-native environment, and improving the flexibility of the cloud-native network during the deployment stage.

[0099] The specific limitations of the cloud-native network configuration device can refer to the limitations of the intelligent question and answer method described above, which will not be described here. Each module in the cloud-native network configuration device described above can be implemented by software, hardware, and combinations thereof, in whole or in part. The above-mentioned modules can be embedded in or independent of the processor in the computer device in hardware form, or can be stored in the memory of the computer device in software form, so that the processor calls and executes the operations corresponding to each of the above modules.

[0100] In one embodiment, a computer device is provided, which can be a server, and its internal structure diagram can be as shown in Figure 8 The computer device includes a processor, a memory, a network interface, and a database connected by a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile and / or volatile storage medium, an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with the external client through the network connection. The computer program is executed by the processor to implement the functions or steps of the cloud-native network configuration method on the server side.

[0101] In one embodiment, a computer device is provided, which can be a client, and its internal structure diagram can be as shown in Figure 9 The computer device includes a processor, a memory, a network interface, a display screen, and an input device connected by a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with the external server through the network connection. The computer program is executed by the processor to implement the functions or steps of the cloud-native network configuration method on the client side

[0102] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored on the memory and executable on the processor, and the processor executes the computer program to implement the following steps:

[0103] Using a command line interface to store full node information in a network cluster to a distributed key-value storage system to track the state of node deployment progress through the distributed key-value storage system;

[0104] In response to the operation and maintenance tool connecting with the distributed key-value storage system through a self-defined plug-in, a target node in the network cluster is marked for deployment to obtain a deployment label of the target node.

[0105] According to the deployment label of the target node, a cloud-native network and a routing daemon are associated and deployed on the target node in the network cluster, so that the target node realizes bidirectional transmission of routing information through component linkage.

[0106] In one embodiment, a computer-readable storage medium is provided, and the computer-readable storage medium stores a computer program. When the computer program is executed by a processor, the following steps are implemented:

[0107] The full-node information in the network cluster is stored into the distributed key-value storage system using a command line interface, so as to track the deployment progress of the nodes through the distributed key-value storage system.

[0108] In response to the operation and maintenance tool connecting with the distributed key-value storage system through a self-defined plug-in, a target node in the network cluster is marked for deployment to obtain a deployment label of the target node.

[0109] According to the deployment label of the target node, a cloud-native network and a routing daemon are associated and deployed on the target node in the network cluster, so that the target node realizes bidirectional transmission of routing information through component linkage.

[0110] It should be noted that the functions or steps that the computer-readable storage medium or the computer device can implement are described above with reference to the related descriptions of the server side and the client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0111] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0112] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0113] The embodiments described above are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present invention, and should all be included in the protection scope of the present invention.

Claims

1. A method for configuring a cloud native network, characterized in that: include: Use the command line interface to store all node information in the network cluster to a distributed key-value storage system, so as to track the status of node deployment progress through the distributed key-value storage system; In response to the operation and maintenance tool connecting to the distributed key-value storage system through a custom plug-in, a target node in the network cluster is deployed and a deployment label of the target node is obtained; The cloud native network and the routing daemon are associated and deployed on the target node in the network cluster according to the deployment label of the target node, so that the target node can realize bidirectional transmission of routing information through component linkage.

2. The method for configuring a cloud native network according to claim 1, wherein: The method of using a command line interface to store all node information in a network cluster in a distributed key-value storage system so as to track the status of node deployment progress through the distributed key-value storage system includes: All node information exported from the network cluster is structured in advance to obtain the full amount of node information in the network cluster; Use the command line interface to create a unique storage path for each node, so as to store all node information in the network cluster in the distributed key-value storage system through the storage path; The deployment status of the node is defined in the distributed key-value storage system, so as to track the node deployment progress according to the deployment status.

3. The method for configuring a cloud native network according to claim 1, wherein: Before marking the target node in the network cluster for deployment to obtain the deployment label of the target node, the method further includes: Place the pre-developed custom plug-in in the detection directory of the operation and maintenance tool, so that the operation and maintenance tool can obtain the custom plug-in according to the detection directory during operation; In a configuration file of the operation and maintenance tool, connection parameters of the distributed key-value storage system are pre-filled, wherein the connection parameters include at least one of an access address, an authentication method, and a communication protocol; If an execution task that calls a custom plug-in is identified in the configuration file of the operation and maintenance tool, the operation and maintenance tool is triggered to connect the custom plug-in to the distributed key-value storage system according to the connection parameters.

4. The method for configuring a cloud native network according to claim 1, wherein: The step of marking the target node in the network cluster for deployment to obtain the deployment label of the target node includes: Based on the attribute information of all nodes in the network cluster, a multi-dimensional mapping relationship between node attributes and deployment labels is pre-established. The multi-dimensional mapping relationship is used to reflect the complex associations formed between node attribute combinations and multiple deployment labels. Performing attribute association on all nodes in the network cluster using the multi-dimensional mapping relationship to obtain a target node with attribute association; The target node with attribute association is subjected to label mapping using the multi-dimensional mapping relationship to obtain a deployment label of the target node.

5. The method for configuring a cloud native network according to any one of claims 1 to 4, wherein: The associating and deploying a cloud native network and a routing daemon on a target node in a network cluster according to the deployment label of the target node, so that the target node implements bidirectional transmission of routing information through component linkage, includes: A first component linkage is configured to transmit routing information from a cloud native network to a routing daemon according to a deployment tag of the target node; A second component linkage is configured to configure a routing daemon to transmit routing information to a cloud native network according to a deployment label of the target node; Establishing an association between the cloud native network and the routing daemon in the service configuration of the network cluster. The association is used to ensure state coordination between the cloud native network and the routing daemon. The first component linkage and the second component linkage are state-associated according to the association relationship, so that the target node can achieve bidirectional transmission of routing information through component linkage.

6. The method for configuring a cloud native network according to any one of claim 5, wherein: The first component linkage of configuring the cloud native network to transmit routing information to the routing daemon process according to the deployment label of the target node includes: Generating routing information in the cloud native network according to the deployment label of the target node; The routing information is directed and pushed to the routing daemon process through the first protocol format, so that the routing daemon process receives the routing information through the target node association and performs network verification according to the routing information.

7. The method for configuring a cloud native network according to claim 5, wherein: The second component linkage of configuring the routing daemon to transmit routing information to the cloud native network according to the deployment label of the target node includes: Extracting routing information matching the target node in the routing daemon according to the deployment label of the target node; The routing information is directed and pushed to the cloud native network through the second protocol format, so that the cloud native network receives the routing information on the target node and performs network configuration according to the routing information.

8. A configuration device for a cloud native network, characterized in that: include: A storage module is used to store all node information in the network cluster to a distributed key-value storage system using a command line interface, so as to track the status of node deployment progress through the distributed key-value storage system; a marking module, configured to mark a target node in the network cluster for deployment in response to the operation and maintenance tool performing a custom plug-in connection with the distributed key-value storage system, and obtain a deployment label of the target node; The deployment module is used to associate and deploy the cloud native network and the routing daemon on the target node in the network cluster according to the deployment label of the target node, so that the target node can realize bidirectional transmission of routing information through component linkage.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the cloud native network configuration method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the cloud native network configuration method according to any one of claims 1 to 7 are implemented.

Images