A method for realizing network management of a cloud native super-converged integrated machine in a Xingcheng environment

Abstract

The application discloses a kind of methods for realizing network management of Xinyuan environment cloud native super-converged integrated machine, belong to cloud native container network technical field, the implementation of the method includes the following steps: in Xinyuan environment cloud native super-converged integrated machine, it is connected to external ovs on kube-ovn, so that the ovs service on host computer can also be managed uniformly;In Xinyuan environment cloud native super-converged integrated machine, access and connection of storage net are realized by longhorn.The application can provide higher flexibility, scalability and manageability, combine cloud native and super-converged technology, can be realized in Xinyuan environment Efficient management and optimization integrated machine network.

Description

Technical Field

[0001] This invention relates to the field of cloud-native container network technology, specifically a method for implementing cloud-native hyperconverged infrastructure network management in a domestically developed information technology environment. Background Technology

[0002] With the increasingly widespread application of container technology in public, private, and hybrid clouds, the latest container technologies have gained significant use in the cloud computing field due to their superior performance and ease of use. The "Information Technology Innovation Environment" refers to the environment for the information technology application innovation industry, encompassing areas such as data security and network security. In the current development of information and communication technologies, cloud computing and hyperconverged infrastructure have become crucial means for enterprises and organizations to achieve flexible and efficient information technology infrastructure. Cloud computing provides resource sharing and elastic scaling capabilities, while hyperconverged infrastructure integrates computing, storage, and networking resources into a unified hardware platform to provide higher integration and performance optimization.

[0003] However, in domestically developed (edge) environments, such as the Industrial Internet, intelligent transportation, and intelligent manufacturing, the requirements for the real-time performance and reliability of computing and storage resources are higher, and traditional cloud computing and hyperconverged solutions may not be able to meet these requirements. Furthermore, network management in domestically developed environments also faces several challenges, including network topology complexity, dynamically changing network connections, security requirements, and performance optimization. Summary of the Invention

[0004] The technical objective of this invention is to address the above-mentioned shortcomings by providing a method for managing cloud-native hyperconverged integrated appliance networks in a domestically developed information technology environment. This method offers greater flexibility, scalability, and manageability, combining cloud-native and hyperconverged technologies to achieve efficient management and optimization of integrated appliance networks in a domestically developed information technology environment.

[0005] The technical solution adopted by this invention to solve its technical problem is:

[0006] A method for implementing network management of cloud-native hyperconverged infrastructure in a domestic IT innovation environment, the method comprising the following steps:

[0007] (1) Connect kube-ovn to external OVS in the cloud-native hyperconverged appliance of the information technology innovation environment so that the OVS service on the host machine can also be managed in a unified manner.

[0008] (2) In the cloud-native hyperconverged appliance of the information technology innovation environment, the storage network is accessed and connected through longhorn.

[0009] This method utilizes the kube-ovn network plugin to manage both containers and virtual machines simultaneously. By adopting this technical solution, domestically developed environments can achieve comprehensive management of cloud-native hyperconverged infrastructure networks, improving network reliability, performance, and security. Furthermore, leveraging cloud-native CRD+controller technology, it enables management of underlying resources based on abstracted resources, offering flexible scalability and efficient resource utilization. This adapts to the ever-changing needs of domestically developed environments and enhances network efficiency and sustainability.

[0010] Furthermore, in step (1), kube-ovn is modified to change the mount path of the pod to the installation path of the OVS already installed on the host machine. At the same time, the initialization command script is modified to avoid overwriting the external OVS, so that it can take over the external OVS service and transform network resources and devices into cloud-native CRD resources.

[0011] Furthermore, in step (2), Longhorn is modified by deploying the pods Longhorn-manager, Instance-manager-e, and Instance-manager-r with dual network cards. At the same time, the source code of Longhorn itself is modified to change the network used by iSCSI to the storage network, so that its access to the management container uses the container's default network, data synchronization between Longhorn pods uses the storage network, and iSCSI mounting also uses the storage network, maximizing the utilization of storage network resources.

[0012] Furthermore, the specific implementation process of this method is as follows:

[0013] S1: Overall network planning and network segmentation;

[0014] S2. Configure the container's default network;

[0015] S3. Configure virtual machine network;

[0016] S4. Configure the storage network;

[0017] S5, modified from kube-ovn, with external OVS.

[0018] Furthermore, the overall network planning and network segmentation are divided into several parts: management network (out-of-band management IPMI), control network (in-band management network k8s), storage network (10 Gigabit), data access network (10 Gigabit), and network plug-in (kube-ovn+multus). At the same time, in order to avoid network segment conflicts, the network segments are planned in advance.

[0019] Management network (out-of-band management IPMI): Used for IPMI connection to physical machines; the network segment is configured according to the actual scenario.

[0020] Control network (in-band management network Kubernetes): Used to manage Kubernetes nodes, network segment 100.64.0.0 / 24;

[0021] Storage network (10 Gigabit): A network used for data storage, network segment 100.65.0.0 / 24;

[0022] Data Access Network (Business Network 10 Gigabit): Used for customers to access virtual machine services, using three reserved private network segments, specifically allocated by the customer: 10.0.0.0 / 8, 172.16.0.0 / 12, 192.168.0.0 / 16;

[0023] Docker network segment: The network segment of the Docker container is 100.102.0.0 / 16;

[0024] Pod network segment: The network segment of the pod containers in the cluster, 100.103.0.0 / 16;

[0025] Service network segment: The network segment of service resources in the cluster, 100.105.0.0 / 16;

[0026] The default network for containers is a single network interface card (NIC) for ordinary pods in the cluster. You can create pods and use them directly. These container networks are automatically assigned IPs by kube-ovn's overlay mode, using the default ovn-default subnet (100.103.0.0 / 16).

[0027] Furthermore, the virtual machine network configuration involves pre-configuring VLANs and planning network segments on the switch, adding the data access network to the VLANs, using the container's default network for the primary network interface card (NIC), and using the VLAN for the secondary NIC, implemented by kube-ovn and multus; the specific process is as follows:

[0028] S3.1. Create a ProviderNetwork resource and specify the network interface name for the data access network;

[0029] S3.2 Create a VLAN resource, associate it with the ProviderNetwork resource in step S3.1, and specify an available vlanId;

[0030] S3.3 Create a NetworkAttachmentDefinition resource for use with multiple network cards, and specify the provider according to the rules;

[0031] S3.4 Create a Subnet resource, specifying the network segment to be used and the corresponding provider, and associate it with the provider of NetworkAttachmentDefinition in step S3.3;

[0032] S3.5 When creating a virtual machine using kubevirt, you can directly specify the names of multiple network interfaces on the vm or vmi resource using multus.

[0033] The resulting virt-launcher pod will have two network interfaces: the primary interface will be the container default network assigned by kube-ovn, and the secondary interface will be the VLAN network. The virtual machine itself will have only one network interface, which will be the VLAN network. Clients can directly access the services of this virtual machine from the outside via the VLAN.

[0034] Furthermore, the configuration of the storage network involves planning a separate network for storing data. If conditions are insufficient or a simpler network model is desired, the storage network can be merged with the virtual machine network. Using kube-ovn and the multus plugin, the primary network interface card (NIC) uses the container's default network, while the secondary NIC uses the storage network.

[0035] When deploying Longhorn, configure the following pods as having dual network interfaces:

[0036] longhorn-manager, instance-manager-e, instance-manager-r;

[0037] The implementation method is similar to that of the virtual machine network in the previous step, and will not be described in detail again;

[0038] However, in this way, the pods that are built will synchronize data with each other through the storage network, but when the business pods access the longhorn through iSCSI, they will still use the container's default network. It would be best to access it directly through the storage network. This requires the storage network to be used as the primary network interface card for the longhorn pods. At the same time, in order for the longhorn to communicate normally with other pods, the container's default network should be retained as the secondary network interface card.

[0039] This means modifying the above solution and reversing the two network cards. However, even if this method works, the original container default network becomes the second network card again, and data synchronization between longhorns reverts to using the container default network, which is not ideal, as the storage network is still not fully utilized.

[0040] Therefore, we will restore the original approach: the primary network interface uses the container's default network, and the second network interface uses the storage network. We will directly modify the source code of Longhorn to change the network used by iSCSI to a configurable form. In the domestically developed hyper-converged appliance environment, when a business pod accesses iSCSI, it will do so through the storage network (the second network interface).

[0041] Furthermore, the kube-ovn modification includes an external OVS connection:

[0042] Change the mount path of the kube-ovn related pods to the installation path of the OVS already installed on the host machine, and modify the initialization command script to avoid overwriting the existing OVS externally.

[0043] With these in place, we can ensure that the components of kube-ovn can run smoothly. We also need to check what resources are already on this external OVS and convert them into CRD resources managed by kube-ovn.

[0044] The present invention also claims a device for implementing cloud-native hyperconverged infrastructure network management in a domestically developed information technology environment, comprising: at least one memory and at least one processor;

[0045] The at least one memory is used to store a machine-readable program;

[0046] The at least one processor is used to call the machine-readable program to implement the above method.

[0047] The present invention also claims protection for a computer-readable medium storing computer instructions that, when executed by a processor, cause the processor to perform the method described above.

[0048] Compared with existing technologies, the method for implementing network management of cloud-native hyperconverged infrastructure in a domestically developed information technology environment, as proposed in this invention, has the following advantages:

[0049] This method can utilize the kube-ovn network plugin to manage both containers and virtual machines simultaneously. It enables network topology discovery and automated configuration, which helps simplify the network configuration process, reduce manual intervention, and improve network reliability and flexibility. It also supports security management and policy control, providing management and configuration of security functions such as network access control, traffic filtering, and intrusion detection. This module has powerful security policy definition and enforcement capabilities to protect the network from potential security threats.

[0050] It also has flexible scalability and adaptability, adopting cloud-native CRD+controller technology, which can manage underlying resources based on the abstracted resources, and has good flexibility and scalability, and can adapt to the ever-changing needs of the information technology innovation environment.

[0051] It supports network deployments of different sizes and types, and provides a scalable architecture and interfaces for future expansion and integration. Attached Figure Description

[0052] Figure 1 This is a diagram illustrating the network design model for a cloud-native hyperconverged integrated machine in a domestically developed information technology environment, provided by an embodiment of the present invention.

[0053] Figure 2 This is a diagram of a switch and VLAN model provided in an embodiment of the present invention. Detailed Implementation

[0054] The present invention will be further described below with reference to the accompanying drawings and specific embodiments.

[0055] This invention provides a method for network management of a cloud-native hyperconverged appliance in a domestically developed IT innovation environment. In this method, a container network plugin is used to manage pods and virtual machines (VMs) within the hyperconverged appliance environment. Kube-ovn is used to connect to the physical machine's OVS, Longhorn is used to connect to the storage network ISCSI, and Mutus+Kube-ovn+Kubevirt is used to manage the allocation of multiple network interface cards (NICs) for VM pods. Switches are used to configure VLANs and perform the division and isolation of multiple VLAN subnets.

[0056] The implementation of this method includes the following steps:

[0057] (1) Connect kube-ovn to external OVS in the cloud-native hyperconverged appliance of the information technology innovation environment so that the OVS service on the host machine can also be managed in a unified manner.

[0058] (2) In the cloud-native hyperconverged appliance of the information technology innovation environment, the storage network is accessed and connected through longhorn.

[0059] In step (1), kube-ovn is modified by changing the mount path of the pod to the installation path of OVS that has already been installed on the host machine. At the same time, the initialization command script is modified to avoid overwriting the external OVS, so that it can take over the external OVS service and transform network resources and devices into cloud-native CRD resources.

[0060] In step (2), Longhorn is modified by deploying the pods Longhorn-manager, Instance-manager-e, and Instance-manager-r with dual network cards. At the same time, the source code of Longhorn itself is modified to change the network used by iSCSI to the storage network, so that its access to the management container uses the container's default network, data synchronization between Longhorn pods uses the storage network, and iSCSI mounting also uses the storage network, maximizing the utilization of storage network resources.

[0061] This method utilizes the kube-ovn network plugin to manage both containers and virtual machines simultaneously. By adopting this technical solution, domestically developed environments can achieve comprehensive management of cloud-native hyperconverged infrastructure networks, improving network reliability, performance, and security. Furthermore, leveraging cloud-native CRD+controller technology, it enables management of underlying resources based on abstracted resources, offering flexible scalability and efficient resource utilization. This adapts to the ever-changing needs of domestically developed environments and enhances network efficiency and sustainability.

[0062] The implementation of this method mainly consists of five parts:

[0063] Step 1: Overall network planning and network segmentation, refer to Figure 1 As shown:

[0064] It is divided into several parts: management network (out-of-band management IPMI), control network (in-band management network k8s), storage network (10 Gigabit), data access network (10 Gigabit) and network plug-in (kube-ovn+multus). At the same time, in order to avoid network segment conflicts, the network segments are planned in advance.

[0065] 1. Management Network (Out-of-Band Management IPMI): Used for IPMI connection to physical machines; the network segment is configured according to the actual scenario.

[0066] 2. Control network (in-band management network Kubernetes): Used to manage Kubernetes nodes, network segment 100.64.0.0 / 24;

[0067] 3. Storage Network (10 Gigabit): A network used for data storage, network segment 100.65.0.0 / 24;

[0068] 4. Data Access Network (Business Network 10 Gigabit): Used for customers to access virtual machine services, using three reserved private network segments, specifically allocated by the customer: 10.0.0.0 / 8, 172.16.0.0 / 12, 192.168.0.0 / 16;

[0069] 5. Docker network segment: The network segment of the Docker container is 100.102.0.0 / 16;

[0070] 6. Pod network segment: The network segment of the pod containers in the cluster is 100.103.0.0 / 16;

[0071] 7. Service network segment: The network segment of service resources in the cluster is 100.105.0.0 / 16.

[0072] Step 2: Container default network:

[0073] The default network of a regular pod in the cluster is a single network interface card. You can create a pod and use it normally. The IP address of these containers is automatically assigned by kube-ovn's overlay mode, using the default ovn-default subnet (100.103.0.0 / 16).

[0074] Step 3: Virtual Network:

[0075] VLANs need to be pre-configured on the switch, network segments need to be planned, and the data access network needs to be added to the VLAN. The primary network interface card (NIC) uses the container's default network, and the secondary NIC uses a VLAN, implemented using kube-ovn and multus. The specific process is as follows:

[0076] 1. Create a ProviderNetwork resource and specify the network interface name for the data access network;

[0077] 2. Create a VLAN resource, associate it with the ProviderNetwork resource from the previous step, and specify an available VLAN ID;

[0078] 3. Create a NetworkAttachmentDefinition resource for use with multiple network cards, and specify the provider according to the rules;

[0079] 4. Create a Subnet resource, specifying the network segment to be used and the corresponding provider, associating it with the provider of the NetworkAttachmentDefinition from the previous step;

[0080] 5. When creating a virtual machine using kubevirt, you can directly specify the names of multiple network interfaces on the VM or VMI resource using multus;

[0081] The resulting virt-launcher pod will have two network interfaces: the primary interface will be the container default network assigned by kube-ovn, and the secondary interface will be the VLAN network. The virtual machine itself will have only one network interface, which will be the VLAN network. Clients can directly access the services of this virtual machine from the outside via the VLAN.

[0082] Step 4: Storage Network

[0083] Similar to virtual machine networks, a separate network is planned for storing data. If conditions are insufficient or a simpler network model is desired, the storage network can be merged with the virtual machine network. Using kube-ovn and the multus plugin, the primary network interface uses the container's default network, and the secondary network interface uses the storage network.

[0084] When deploying Longhorn, configure the following pods as having dual network interfaces:

[0085] longhorn-manager, instance-manager-e, instance-manager-r.

[0086] The implementation method is similar to that of the virtual machine network in the previous step, so it will not be described again.

[0087] However, in this way, the pods that are built will synchronize data with each other through the storage network, but when the business pods access the longhorn through iSCSI, they will still use the container's default network. Ideally, they should be able to access the longhorn directly through the storage network. This requires the storage network to be used as the primary network interface card for the longhorn pods. At the same time, in order for the longhorn to be able to communicate normally with other pods, the container's default network should be retained as the secondary network interface card.

[0088] This means modifying the above solution and reversing the two network cards. However, even if this method works, the original container default network becomes the second network card again, and data synchronization between longhorns reverts to using the container default network, which is not ideal, as the storage network is still not fully utilized.

[0089] Therefore, we will restore the original approach: the primary network interface uses the container's default network, and the second network interface uses the storage network. We will directly modify the source code of Longhorn to change the network used by iSCSI to a configurable form. In the domestically developed hyper-converged appliance environment, when a business pod accesses iSCSI, it will do so through the storage network (the second network interface).

[0090] Step 5: Modify kube-ovn to connect to external OVS:

[0091] The original deployment logic of kube-ovn was that the container image came with the OVS service, and the deployed network plugin was not related to the underlying network environment;

[0092] However, now we need to be able to manage the OVS service that is already installed on the physical machine, so we need to be able to associate kube-ovn with external OVS.

[0093] This requires some modifications to the kube-ovn deployment. The mount path of the relevant kube-ovn pods should be changed to the installation path of the OVS already installed on the host machine. At the same time, the initialization command script should be modified to avoid overwriting the existing external OVS.

[0094] With these in place, we can ensure that the components of kube-ovn can run smoothly. We also need to check what resources are already on this external OVS and convert them into CRD resources managed by kube-ovn.

[0095] Cloud-native is an application development and deployment paradigm based on containerization, microservices, and automation, offering greater flexibility, scalability, and manageability. Combining cloud-native and hyperconverged technologies enables efficient management and optimization of integrated appliance networks in domestically developed IT environments. This approach achieves comprehensive management of cloud-native hyperconverged appliance networks in domestically developed IT environments through the collaborative work of modules such as network topology discovery, network configuration management, network performance monitoring, security management and policy control, and automated operation and maintenance optimization. This will help improve network reliability, security, and performance to meet the real-time and reliability requirements of domestically developed IT environments.

[0096] The terms used in this embodiment are explained as follows:

[0097] Container privilege escalation and escape refer to the behavior of malicious programs or users in a container gaining higher privileges or accessing the host system through vulnerabilities or misconfigurations.

[0098] Cloud computing: This involves the application of cloud computing technology and related infrastructure, including resource sharing, elastic scaling, and virtualization.

[0099] Hyperconverged infrastructure (HCI): This refers to hyperconverged technologies that integrate resources such as computing, storage, and networking into a unified hardware platform to provide greater integration and performance optimization.

[0100] Information technology innovation environment: This refers to information innovation environments involving fields such as edge computing, industrial internet, intelligent transportation, and intelligent manufacturing, which have higher requirements for the real-time performance and reliability of computing and storage resources.

[0101] Cloud-native: refers to cloud-native technologies that provide greater flexibility, scalability, and manageability by adopting application development and deployment paradigms based on containerization, microservices, and automation.

[0102] This invention also provides an apparatus for implementing network management of a cloud-native hyperconverged integrated machine in a domestically developed information technology environment, comprising: at least one memory and at least one processor;

[0103] The at least one memory is used to store a machine-readable program;

[0104] The at least one processor is used to call the machine-readable program to implement the method for network management of cloud-native hyperconverged integrated machine in the above embodiments.

[0105] This invention also provides a computer-readable medium storing computer instructions. When executed by a processor, the computer instructions cause the processor to perform the method for implementing cloud-native hyperconverged infrastructure network management in the above embodiments. Specifically, a system or device equipped with a storage medium storing software program code that implements the functions of any of the above embodiments can be provided, and the computer (or CPU or MPU) of the system or device can read and execute the program code stored in the storage medium.

[0106] In this case, the program code read from the storage medium can itself implement the function of any of the above embodiments, and therefore the program code and the storage medium storing the program code constitute part of the present invention.

[0107] Examples of storage media used to provide program code include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, program code can be downloaded from a server computer via a communication network.

[0108] Furthermore, it should be clear that not only can the program code read by the computer be executed, but also the operating system or other components operating on the computer can be instructed based on the program code to perform some or all of the actual operations, thereby realizing the function of any of the embodiments described above.

[0109] Furthermore, it is understood that the program code read from the storage medium is written to the memory set in the expansion board inserted into the computer or to the memory set in the expansion unit connected to the computer. Then, based on the instructions of the program code, the CPU or other components installed on the expansion board or expansion unit execute some and all of the actual operations, thereby realizing the function of any of the embodiments described above.

[0110] The present invention has been shown and described in detail above with reference to the accompanying drawings and preferred embodiments. However, the present invention is not limited to these disclosed embodiments. Based on the above embodiments, those skilled in the art will know that more embodiments of the present invention can be obtained by combining the code review methods in the different embodiments. These embodiments are also within the protection scope of the present invention.

Claims

1. A method for implementing network management of cloud-native hyperconverged infrastructure in a domestically developed information technology environment, characterized in that: The implementation of this method includes the following steps: (1) Connect kube-ovn to the external OVS in the cloud-native hyperconverged appliance in the information technology innovation environment so that the OVS service on the host machine can also be managed in a unified manner; (2) In the cloud-native hyperconverged appliance of the information technology innovation environment, the storage network is accessed and connected through Longhorn; In step (1), kube-ovn is modified to change the mount path of the pod to the installation path of the OVS that has been installed on the host machine. At the same time, the initialization command script is modified to avoid overwriting the external OVS, so that it can take over the external OVS service and transform network resources and devices into cloud-native CRD resources. In step (2), Longhorn is modified so that the pods Longhorn-manager, Instance-manager-e, and Instance-manager-r are deployed with dual network cards. At the same time, the source code of Longhorn itself is modified so that the network used by iSCSI is changed to the storage network, so that the access between it and the management container uses the container's default network, the data synchronization between Longhorn uses the storage network, and the iSCSI mounting also uses the storage network, so as to maximize the use of the storage network resources. The specific implementation process of this method is as follows: S1: Overall network planning and network segmentation; S2. Configure the container's default network; S3. Configure virtual machine network; S4. Configure the storage network; S5, modified from kube-ovn, with external OVS; The virtual machine network configuration involves pre-configuring VLANs and planning network segments on the switch, adding the data access network to the VLAN, using the container's default network on the primary network interface card (NIC), and using the VLAN on the secondary NIC, implemented by kube-ovn and multus. The specific process is as follows: S3.

1. Create a ProviderNetwork resource and specify the network interface name for the data access network; S3.2 Create a VLAN resource, associate it with the ProviderNetwork resource in step S3.1, and specify an available vlanId; S3.3 Create a NetworkAttachmentDefinition resource for use with multiple network cards, and specify the provider according to the rules; S3.4 Create a Subnet resource, specifying the network segment to be used and the corresponding provider, and associate it with the provider of NetworkAttachmentDefinition in step S3.3; S3.5 When creating a virtual machine using kubevirt, you can directly specify the names of multiple network interfaces on the vm or vmi resource using multus.

2. The method for implementing network management of cloud-native hyperconverged integrated machines in a domestically developed information technology environment according to claim 1, characterized in that, The overall network planning and segmentation are divided into several parts: management network, control network, storage network, data access network, and network plug-ins. Management network: Used for IPMI connection to physical machines; network segments are configured according to the actual scenario. Control network: Used to manage Kubernetes nodes, network segment 100.64.0.0 / 24; Storage network: A network used for data storage, network segment 100.65.0.0 / 24; Data Access Network: Used for customer access to virtual machine services, utilizing three reserved private network segments, specifically allocated by the customer. 10.0.0.0 / 8，172.16.0.0 / 12，192.168.0.0 / 16； Docker network segment: The network segment of the Docker container is 100.102.0.0 / 16; Pod network segment: The network segment of the pod containers in the cluster, 100.103.0.0 / 16; service network segment: The network segment of service resources in the cluster, 100.105.0.0 / 16; The default network configuration for containers is as follows: the network of ordinary pod containers in the cluster is a single network card by default. You can create pods directly and use them normally. These container networks are automatically assigned IPs by kube-ovn's overlay mode, using the default ovn-default subnet.

3. The method for implementing network management of cloud-native hyperconverged integrated machines in a domestically developed information technology environment according to claim 1, characterized in that, The configuration storage network can be planned as a separate network for data storage, or the storage network can be merged with the virtual machine network; using kube-ovn and the multus plugin, the primary network interface card (NIC) uses the container's default network, and the secondary NIC uses the storage network; When deploying Longhorn, configure the following pods as having dual network interfaces: longhorn-manager, instance-manager-e, instance-manager-r; Modify the source code of Longhorn to change the network used by iSCSI to a configurable form. In the domestically developed hyperconverged infrastructure environment, business pods access iSCSI through the storage network.

4. The method for implementing network management of cloud-native hyperconverged integrated machines in a domestically developed information technology environment according to claim 3, characterized in that, The kube-ovn modification includes an external OVS connection: Change the mount path of the kube-ovn related pods to the installation path of the OVS already installed on the host machine, and modify the initialization command script to avoid overwriting the existing OVS externally. Detect existing resources on external OVS and convert them into CRD resources managed by kube-ovn.

5. A device for implementing network management of a cloud-native hyperconverged integrated machine in a domestically developed information technology environment, characterized in that, include: At least one memory and at least one processor; The at least one memory is used to store a machine-readable program; The at least one processor is configured to invoke the machine-readable program to implement the method according to any one of claims 1 to 4.

6. A computer-readable medium, characterized in that, The computer-readable medium stores computer instructions that, when executed by a processor, cause the processor to perform the method described in any one of claims 1 to 4.

Images