Method and device for updating routing item

By using management devices to convert network forwarding policies into routing entries in the container cluster network, the inefficient update problem caused by the CNI plugin is solved, enabling online and efficient updates of routing entries and multi-network plane configurations.

CN121509300APending Publication Date: 2026-02-10HUAWEI TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411098067.3
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-08-09
Publication Date
2026-02-10

AI Technical Summary

Technical Problem

In existing technologies, the update efficiency of routing entries in container cluster networks is low because CNI plugins need to delete and rebuild pods, leading to business interruptions and inefficiency.

Method used

By managing devices to obtain network forwarding policies through a human-machine interface, and converting them into routing entries for communication objects in the container cluster network, this replaces the CNI plugin's method of updating routing entries, enabling online updates and avoiding pod rebuilds and business interruptions.

Benefits of technology

It improves the efficiency of routing entry updates, enables online updates without interrupting service operation, and enhances the efficiency of multi-network plane configuration.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121509300A_ABST
    Figure CN121509300A_ABST
Patent Text Reader

Abstract

The invention provides a method and a device for updating a routing item. The method and the device are used for improving the updating efficiency of the routing item of a container. The method is applied to a management device, the management device is used for configuring a container cluster network, and the method comprises the following steps: obtaining a network forwarding strategy of a configuration object from a human-computer interaction interface; converting the network forwarding strategy into a routing item of an associated communication object when the configuration object transmits the service flow in the container cluster network; and respectively updating the routing item of each communication object for each communication object. Wherein the network forwarding strategy of the first configuration object is used for indicating a network interface used by the end equipment of the first configuration object on a transmission path in the first direction during communication; the routing entry of the first communication object is used for indicating the container deployed in the first communication object and the address information of the next hop during communication in the first direction.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application, and the field of computers, particularly relates to a method and apparatus for updating routing entries. Background Technology

[0002] In the development of virtualization technology, container virtualization has attracted increasing attention and application due to its lightweight, fast, and efficient characteristics. Container virtualization packages an application and its entire runtime environment into an independent container, achieving application isolation and environment consistency. Each container runs on a shared operating system kernel but has its own independent file system, network, and process space.

[0003] Communication between containers and the external network of their respective clusters, as well as between containers themselves, is essential. However, the isolated nature of container operation typically prevents direct communication between containers and between containers and the external network. Instead, routing entries are used to guide container communication, indicating the next-hop address information to the destination device. Within a container cluster network, numerous situations can trigger changes to container routing entries. These include changes to the architecture of the cluster network (addition of network interfaces), the addition of network interfaces to the pod (the smallest unit of resource scheduling within the container's network) to enable multi-network plane functionality, or other similar events.

[0004] Currently, in container cluster networks, routing entries are typically updated using container network interface (CNI) plugins. However, the protocol followed by CNI plugins requires deleting and rebuilding the original pod to update routing entries, resulting in low update efficiency. Summary of the Invention

[0005] This application provides a method and apparatus for updating routing entries to improve the efficiency of updating routing entries in containers.

[0006] To achieve the above objectives, this application adopts the following technical solution:

[0007] Firstly, a method for updating routing entries is provided. This method can be applied to a management device, which can be used to configure a container cluster network. The method includes: obtaining the network forwarding policy of a configuration object from a human-machine interface; converting the network forwarding policy into routing entries for communication objects associated with the configuration object when transmitting service traffic in the container cluster network; and updating the routing entries for each communication object. Specifically, the network forwarding policy of the first configuration object indicates the network interface used by the end device of the first configuration object on the transmission path in the first direction during communication. The routing entry of the first communication object indicates the address information of the next hop for the container deployed in the first communication object during communication in the first direction.

[0008] The solution provided in this application addresses scenarios where network changes in a container cluster necessitate updating routing entries. It allows users to submit network forwarding policies for configuration objects via a human-machine interface. The management device then converts these policies into routing entries for communication objects (associated with configuration objects when transmitting business traffic) and updates them. This replaces the method of updating routing entries via CNI plugins, is not limited by the CNI protocol, eliminates the need to delete and rebuild pods, and avoids interrupting business operations. It achieves online routing entry updates without disrupting business operations, improving the efficiency of routing entry updates. Furthermore, if multiple network planes are configured through network forwarding policies, there is no need to delete and rebuild pods or add network devices (i.e., network interfaces) to the rebuilt pods, further improving the efficiency of multi-network plane configuration.

[0009] One possible implementation is that the communication object mentioned above can be a node or a pod.

[0010] Another possible implementation is to convert the network forwarding policy into routing entries for communication objects associated with the configuration objects when transmitting service traffic in the container cluster network. Specifically, this can be achieved by: determining the path between the end device and the communication object according to the routing protocol based on the network interface indicated by the network forwarding policy and the address information corresponding to the configuration object; and generating routing entries for the end device and the communication object based on the path. Converting the network forwarding policy into routing entries allows containers to accurately transmit traffic under the latest network architecture, since the network forwarding policy indicates the user's latest network configuration.

[0011] Another possible implementation involves configuring the network plane as the configuration object. A network plane is a path and components along a path used to transmit a type of service traffic within a cluster network. Components include nodes. The communication objects associated with the first network plane transmitting service traffic in the container cluster network include the nodes included in the first network plane. The network forwarding policy of the first network plane includes: the identifier of the first network plane, the first direction, and the identifier of the first network interface. This network forwarding policy of the first network plane instructs the first network plane to use the first network interface on the end device in the first direction of communication to transmit service traffic. The first network plane can be any network plane in the container cluster network. Converting the network forwarding policy of the first network plane into routing entries for the communication objects associated with the first network plane transmitting service traffic in the container cluster network can be specifically implemented as follows: Based on the identifier of the first network plane, determine the nodes included in the first network plane. Using the node where the first network interface is located as the end device of the first network plane, determine the path between the end device and other nodes in the first network plane via the first network interface according to the routing protocol; then generate routing entries for the nodes included in the first network plane based on this path. This implementation configures the network plane content through network forwarding policies, enabling online and efficient network plane configuration, and updates routing entries based on the network plane, achieving efficient routing entry updates. Furthermore, by converting the network forwarding policies of different network planes into corresponding node routing entries, the management device's operation on a single network plane does not affect the operation of other network planes or the forwarding of service traffic from other network planes.

[0012] Another possible implementation involves the management device recording the network segment information range corresponding to the network plane identifier. Based on the identifier of the first network plane, the nodes included in the first network plane are determined. Specifically, this can be achieved by: determining the network segment information range corresponding to the identifier of the first network plane; and selecting nodes whose address information falls within this network segment information range as nodes in the first network plane.

[0013] Another possible implementation is that the management device records the correspondence between the identifier of the network plane and the nodes included in the network plane. Based on the identifier of the first network plane, the nodes included in the first network plane are determined. Specifically, this can be implemented as follows: based on the identifier of the first network plane, the nodes corresponding to the identifier of the first network plane in the correspondence are determined as nodes in the first network plane.

[0014] Another possible implementation involves configuring the pod as the target. The network forwarding policy for the first pod includes: a first pod identifier, a first direction, and a second network interface identifier. This policy instructs the first pod to use the second network interface on its node to transmit service traffic in the first direction. The first pod can be any pod in the container cluster network. The communication objects associated with the first pod transmitting service traffic in the container cluster network include pods other than the first pod in the container cluster network. Converting the network forwarding policy of the first pod into routing entries for the communication objects associated with the first pod transmitting service traffic in the container cluster network can be implemented as follows: the node containing the second network interface is designated as the end device, and the end device is the node where the first pod runs. According to the routing protocol, the path between the first pod and other pods in the cluster network via the second network interface of the end device is determined, and routing entries for each pod in the cluster network are generated based on this path. In this implementation, configuring the pod content through the network forwarding policy enables online and efficient pod configuration and efficient updating of routing entries based on the pod.

[0015] Another possible implementation involves configuring the pod as the target. The network forwarding policy for the second pod includes: a second pod identifier, a first direction, and an identifier for the third network interface. This policy instructs the second pod to use the third network interface on its host node to transmit service traffic in the first direction. The second pod can be any pod in the container cluster network. The communication objects associated with the second pod's service traffic transmission within the container cluster network include nodes other than the node where the second pod resides. Converting the network forwarding policy of the second pod into routing entries for these communication objects can be implemented as follows: using the node containing the third network interface as the end device, determining the path between the end device and other nodes in the cluster network via the third network interface according to the routing protocol, and generating routing entries for each node in the cluster network based on this path. This implementation configures the pod's content through the network forwarding policy, achieving online and efficient pod configuration, and updates routing entries based on nodes other than the node where the pod resides within the container cluster network, achieving efficient routing entry updates.

[0016] Another possible implementation, the method for updating routing items provided in this application, further includes: if the routing item update for each communication object is successful, outputting a notification message on the human-computer interaction interface. The notification message indicates that the routing item update was successful. By using a notification message on the human-computer interaction interface to promptly inform the user when the routing item for a communication object is successfully updated, the user experience is improved.

[0017] Another possible implementation involves using nodes as the communication objects, with routing entries stored within the node but outside the pod. By storing the generated, node-level routing entries in locations within the node and outside the pod respectively, the traditional requirement for routing entry updates to follow CNI specifications is broken. This allows for adjustments to routing entries without restarting the pod or interrupting the forwarding and transmission of business traffic, thus improving the efficiency of routing entry updates.

[0018] Another possible implementation involves using pods as the communication objects, with routing entries stored within the pod but outside the container. By storing the generated pod-level routing entries separately within the pod and outside the container, the traditional requirement for routing entry updates to adhere to the CNI specification is broken. This allows for adjustments to routing entries without restarting the pod or interrupting the forwarding and transmission of business traffic, thus improving the efficiency of routing entry updates.

[0019] Another possible implementation is that the human-computer interaction interface can be in the form of a browser. Providing a human-computer interaction interface through a browser reduces the amount of user interaction required when updating routing items.

[0020] Another possible implementation, the routing protocol includes: Routing Information Protocol (RIP), or Open Shortest Path First (OSPF).

[0021] Secondly, an apparatus for updating routing entries is provided. This apparatus can be applied to a management device used to configure a container cluster network. The apparatus for updating routing entries includes an acquisition module, a transformation module, and an update module. Wherein:

[0022] The acquisition module is used to acquire the network forwarding policy of the configuration object from the human-computer interaction interface. The network forwarding policy of the first configuration object is used to indicate the network interface used by the end device of the first configuration object in the transmission path in the first direction during communication.

[0023] The conversion module is used to convert network forwarding policies into routing entries for communication objects associated with the configuration objects in the container cluster network when transmitting business traffic; wherein, the routing entry of the first communication object is used to indicate the address information of the next hop of the container deployed in the first communication object when communicating in the first direction;

[0024] The update module is used to update the routing entries of each communication object individually.

[0025] One possible implementation is that the communication object mentioned above can be a node or a pod.

[0026] One possible implementation is that the conversion module is specifically used to: generate routing entries between the end device and the communication objects associated with the configuration objects in the container cluster network when transmitting business traffic, according to the network interface indicated by the network forwarding policy and the address information corresponding to the configuration object, and in accordance with the routing protocol.

[0027] Another possible implementation involves configuring the object as a network plane. A network plane is a path and components along a path used to transmit a type of service traffic within a cluster network. Components include nodes. The communication objects associated with the first network plane transmitting service traffic in the container cluster network include the nodes included in the first network plane. The network forwarding strategy of the first network plane includes: the identifier of the first network plane, the first direction, and the identifier of the first network interface. Specifically, the conversion module is used to: determine the nodes included in the first network plane based on the identifier of the first network plane; designate the node where the first network interface is located as the end device of the first network plane; determine the path between the end device and other nodes in the first network plane via the first network interface according to the routing protocol; and generate routing entries for the nodes included in the first network plane based on this path.

[0028] Another possible implementation involves the management device recording the network segment information range corresponding to the network plane identifier. The conversion module is then used to determine the network segment information range corresponding to the first network plane identifier. Nodes whose address information falls within this network segment information range are designated as nodes in the first network plane.

[0029] Another possible implementation is that the management device records the correspondence between the identifier of the network plane and the nodes included in the network plane. The conversion module is further used to determine the node corresponding to the identifier of the first network plane in the correspondence, based on the identifier of the first network plane, as the node in the first network plane.

[0030] Another possible implementation involves configuring the object as a pod. The network forwarding policy for the first pod includes: a first pod identifier, a first direction, and a second network interface identifier. This policy instructs the first pod to use the second network interface on its node to transmit service traffic in the first direction. The first pod can be any pod in the container cluster network. The communication objects associated with the first pod transmitting service traffic in the container cluster network include pods other than the first pod within the network. The conversion module specifically treats the node containing the second network interface as the end device. The end device is the node where the first pod runs. According to the routing protocol, it determines the path between the first pod and other pods in the cluster network via the second network interface, and generates routing entries for each pod in the cluster network based on this path.

[0031] Another possible implementation involves configuring the object as a pod. The network forwarding policy for the second pod includes: a second pod identifier, a first direction, and an identifier for the third network interface. This network forwarding policy instructs the second pod to use the third network interface on its host node to transmit service traffic in the first direction. The second pod can be any pod in the container cluster network. The communication objects associated with the second pod transmitting service traffic in the container cluster network include nodes other than the node where the second pod is located. Specifically, the conversion module is used to: treat the node where the third network interface is located as the end device, determine the path between the end device and other nodes in the cluster network via the third network interface according to the routing protocol, and generate routing entries for each node in the cluster network based on this path.

[0032] Another possible implementation includes an output module for updating routing entries, used to output a notification message on the human-computer interface if the routing entry update for each communication object is successful. The notification message indicates that the routing entry update was successful.

[0033] Another possible implementation involves using nodes as the communication object, where routing entries within a node can be stored within the node but outside the pod. Alternatively, routing entries within a pod can be stored within the pod but outside the container.

[0034] Another possible implementation is that the human-computer interaction interface can be in the form of a browser.

[0035] Another possible implementation could be achieved using a routing protocol such as RIP or OSPF.

[0036] Thirdly, a computing device is provided, which may include: a processor and an interface circuit. The interface circuit is used to receive computer execution instructions and transmit them to the processor; the processor is used to execute the computer execution instructions to cause the management device to perform the method described in the first aspect or any possible implementation thereof.

[0037] Fourthly, a computer-readable storage medium is provided having instructions stored thereon that, when executed on a computer, cause the computer to perform the methods as described in the first aspect or any possible implementation thereof.

[0038] Fifthly, a computer program product is provided, having instructions stored thereon that, when executed on a computer, cause the computer to perform the methods as described in the first aspect or any possible implementation thereof.

[0039] In a sixth aspect, a chip is provided that may include a memory and a processor, the memory being used to store a program that, when the program is run on the processor, causes the processor to perform methods as described in the first aspect or any possible implementation thereof.

[0040] A seventh aspect provides an apparatus for updating routing entries, comprising: a processor and interface circuitry. The interface circuitry is configured to receive computer-executed instructions and transmit them to the processor. The processor is configured to execute the computer-executed instructions to cause the apparatus for updating routing entries to perform a method as described in the first aspect or any possible implementation thereof.

[0041] Eighthly, a system for updating routing entries is provided, comprising multiple servers, each server including a processor and a memory. The processor is configured to execute instructions stored in the memory, causing the servers to perform methods as described in the first aspect or any possible implementation thereof.

[0042] It should be noted that any of the possible implementations of any of the above aspects can be combined, provided that the solutions do not contradict each other. Attached Figure Description

[0043] Figure 1 This diagram illustrates the communication process between containers and external networks, and between containers and internal networks within a container cluster.

[0044] Figure 2 A flowchart illustrating the process of creating a pod network interface for a CNI plugin;

[0045] Figure 3 A flowchart illustrating the process of deleting a pod's network interface;

[0046] Figure 4 A flowchart illustrating the process of modifying a pod's network interface;

[0047] Figure 5 A schematic diagram illustrating a method for adjusting network configuration and routing entries in the prior art;

[0048] Figure 6 This application provides a schematic diagram of a container cluster network.

[0049] Figure 7 This is a schematic flowchart of a method for updating routing entries provided in an embodiment of this application;

[0050] Figure 8 A schematic diagram of a human-computer interaction interface provided in an embodiment of this application;

[0051] Figure 9 This is a schematic flowchart of another method for updating routing entries provided in an embodiment of this application;

[0052] Figure 10 This is a schematic flowchart illustrating another method for updating routing entries provided in an embodiment of this application;

[0053] Figure 11 This is a schematic flowchart illustrating another method for updating routing entries provided in an embodiment of this application;

[0054] Figure 12 This is a schematic flowchart illustrating another method for updating routing entries provided in an embodiment of this application;

[0055] Figure 13 A schematic diagram of a Kubernetes system architecture provided in this application embodiment;

[0056] Figure 14 A schematic diagram illustrating the process of updating routing entries using an apparatus provided in this application embodiment;

[0057] Figure 15 This is a schematic flowchart illustrating another method for updating routing entries provided in an embodiment of this application;

[0058] Figure 16 This application provides a schematic diagram of a service traffic transmission behavior according to an embodiment of the present application.

[0059] Figure 17 A schematic diagram of a device for updating routing entries provided in an embodiment of this application;

[0060] Figure 18 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application. Detailed Implementation

[0061] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature.

[0062] In this application specification and claims, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or modules is not necessarily limited to those explicitly listed, but may include other steps or modules not explicitly listed or inherent to these processes, methods, products, or devices. The naming or numbering of steps in this application does not imply that the steps in the method flow must be performed in the chronological / logical order indicated by the naming or numbering. The execution order of named or numbered process steps can be changed according to the desired technical purpose, as long as the same or similar technical effect is achieved. The division of units in this application is a logical division; in practical applications, other division methods may be used. For example, multiple units may be combined or integrated into another system, or some features may be omitted or not performed. Furthermore, the shown or discussed mutual coupling or direct coupling or communication connection may be through some interface, and the indirect coupling or communication connection between units may be electrical or other similar forms, none of which are limited in this application. Furthermore, the unit or sub-unit described as a separate component may or may not be physically separated, may or may not be a physical unit, or may be distributed among multiple circuit units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution in this application.

[0063] It should be understood that the terminology used in the description of the various examples described in this application and the claims is for the purpose of describing particular examples only and is not intended to be limiting. As used in the description of the various examples and the appended claims, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[0064] It should also be understood that the term "and / or" as used in this specification and claims refers to and covers any and all possible combinations of one or more of the associated listed items. The term "and / or" describes a relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. Additionally, the character " / " in this application generally indicates that the preceding and following related objects are in an "or" relationship.

[0065] It should be understood that determining B based on A does not mean determining B solely based on A; B can also be determined based on A and / or other information.

[0066] It should also be understood that the term “comprising” (also referred to as “includes”, “including”, “comprises” and / or “comprising”) as used in this specification specifies the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0067] It should also be understood that the term "if" can be interpreted as meaning "when" or "upon" or "in response to determination" or "in response to detection." Similarly, depending on the context, the phrases "if determination..." or "if detection [the stated condition or event]" can be interpreted as meaning "when determination..." or "in response to determination..." or "when detection [the stated condition or event]" or "in response to detection [the stated condition or event]."

[0068] It should be understood that the phrases "an embodiment," "an embodiment," and "a possible implementation" used throughout the specification mean that a specific feature, structure, or characteristic related to an embodiment or implementation is included in at least one embodiment of this application. Therefore, the phrases "in an embodiment," "an embodiment," or "a possible implementation" appearing throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

[0069] To facilitate understanding, the terms used in this application will be explained first.

[0070] Container cluster (container cluster network): refers to a group of runtime container instances. These instances can be deployed on the same physical machine or virtual machine, or distributed across multiple physical machines and virtual machines to form a cluster. Through the collaborative work of containers within the cluster, a runtime environment for containerized applications is provided.

[0071] Figure 1 This diagram illustrates the communication process between containers and external networks, and between containers and internal networks within a container cluster. (Example:) Figure 1 As shown, the container cluster consists of access zone node 3, node 1, and node 2. Access zone node 3 deploys a load balancer and multiple network interfaces (ethernet, eth), including eth0, eth1, eth2, eth3, and others. Nodes 1 and 2 deploy eth0 and eth1 respectively. Each network interface has a unique IP address. pod1 and pod2 run on node 1, and pod3 and pod4 run on node 2 (each pod has a unique IP address). Figure 1In the container cluster shown, the network located outside the container cluster and isolated from the internal network is called the external network of the container cluster, including external network 1 and external network 2. The networks that communicate with each other within the container cluster are called the internal network of the container cluster. The internal network may include, but is not limited to, container networks and host networks.

[0072] Container networking provides communication networks for pods with containers on nodes other than their own, pods with containers within other pods on their own node, and pods with containers within each other. Host networking refers to the communication and connection methods between nodes within a container cluster.

[0073] In a container cluster, a pod is the smallest unit of scheduling and is primarily used for resource allocation. A pod can be viewed as a group of containers, where multiple containers are scheduled as a whole (e.g., deployed, scaled, or managed). Containers within a pod share the pod's network, storage resources, and operating system-level namespaces.

[0074] for Figure 1 The illustrated container cluster illustrates container-to-container communication, where containers share the host's (i.e., node's) network namespace. This means that communication occurs locally between pods within a node, between containers within a pod, and between a pod and the node it resides on. Different nodes communicate directly using their respective address information (e.g., IP addresses). Therefore, the routing entries guiding container-to-container communication, indicating the next-hop address to the destination container, can include the address of the pod containing the container, the address of the node running the pod, the address of the destination node, and the address of the pod within the destination node.

[0075] for Figure 1 In the illustrated container cluster, communication between containers and the external network is typically handled by a load balancer. This load balancer is generally located in the access zone node. The node hosting the container connects to the load balancer through the network interface of the access zone node, and the load balancer then connects to the external network through other network interfaces of the access zone node. Therefore, the routing entries used to guide communication between containers and the external network indicate the next-hop address information to the external network, including the address of the pod hosting the container, the address of the node on which the pod runs, and the address of the access zone node.

[0076] Before communication between containers and between containers and external networks, the control plane first establishes network connectivity for the paths involved in communication between containers and between containers and external networks. This network connectivity process is performed by the CNI plugin. This process includes: creating network interfaces for pods, generating corresponding routing entries based on the container network architecture, and guiding the forwarding of business traffic (including between containers and between containers and external networks).

[0077] During container cluster setup, based on business needs, a request can be made to the container cluster management component to create a pod. The management component can be Kubernetes. The following description uses Kubernetes as an example to illustrate the process of establishing network connectivity within a container cluster.

[0078] When Kubernetes receives a pod creation request, the Kubelet (a component in Kubernetes that plays a management role) is responsible for creating the pod. During the pod creation process, the Kubelet obtains the pod's network configuration information from the API server. This network configuration information includes the name of the network plugin and related parameters. Based on the network configuration information, the Kubelet calls the corresponding CNI plugin to create the pod's network interface.

[0079] like Figure 2 As shown, the process of the CNI plugin creating a pod network interface includes S201-S205.

[0080] S201. Kubelet obtains a pod creation request from the API server, creates a pod based on the pod creation request, and the scheduler schedules the pod to a node.

[0081] S202, Kubelet calls the Multus CNI cmdAdd interface.

[0082] S203, Multus CNI calls the Dturbo CNI cmdAdd interface.

[0083] S204 and Dturbo CNI generate the pod network namespace in the cmdAdd interface and record it in the pod configuration.

[0084] S205. When the Operator detects a new pod network namespace record in the pod configuration, the Operator creates the corresponding network interface based on the obtained pod network interface definition.

[0085] After creating the pod's network interface, a relevant routing entry is generated according to the routing protocol to guide the forwarding of business traffic. The path indicated by this routing entry for container communication to the destination device (node, pod, or container) passes through the aforementioned created pod network interface.

[0086] During the operation of container networks, there are some scenarios (such as network communication problems with pods) that require the deletion or modification of the pod's network interface.

[0087] like Figure 3 As shown, the process of deleting a pod network interface includes steps S301-S305.

[0088] S301. Kubelet obtains pod deletion requests from the API server, and deletes the pod from the node based on the pod deletion requests.

[0089] S302, Kubelet calls the Multus CN interface.

[0090] S303, Multus CNI calls the Dturbo CNI cmdDel interface.

[0091] S304 and Dturbo CNI perform parameter verification in the cmdDel interface.

[0092] S305 and Dturbo CNI remove the pod network namespace record from the pod configuration in the cmdDel interface.

[0093] S306, The Operator detected from the API server that the network namespace record in the pod configuration had been deleted.

[0094] S307. Operator retrieves the list of pod network interfaces.

[0095] S308, Operator deletes the corresponding network interface based on the pod network interface list.

[0096] S309. Operator removes the list of network interfaces from the pod configuration.

[0097] like Figure 4 As shown, the process of modifying a pod's network interface includes:

[0098] S401: The Operator uses the list-watch mechanism to detect that the network interface information in the pod configuration has been modified.

[0099] S402. Operator deletes and modifies the network interface information of the pod corresponding to the network interface information before and after deletion.

[0100] S403, Operator obtains the modified network interface information and creates the corresponding network interface based on the modified network interface information.

[0101] After deleting a pod and its network interface, the original transmission path through that pod's network interface needs to be adjusted to use the network interfaces of other pods (either the original ones or the rebuilt ones) to achieve the original transmission traffic purpose. At this time, the routing entry needs to be updated so that the forwarding process of the business traffic guided by the routing entry does not go through the deleted pod's network interface, but through the network interfaces of other pods to achieve the original transmission traffic purpose.

[0102] In the aforementioned container clusters, there are numerous scenarios where network adjustments can cause changes to routing entries. For example, adjusting the container cluster network might involve modifying the external and / or internal networks, such as adding network interfaces to nodes in scenarios where a single network interface's bandwidth is insufficient or where large data and business traffic need to be isolated. Adjusting the container cluster network could also involve using CNI plugins to generate multiple network interfaces for pods to achieve multiple network planes. These adjustments will cause some business traffic to travel through the network interfaces of newly added nodes or the multiple network interfaces of the generated pods, thus changing the routing entries guiding business traffic transmission. The changes and adjustments to routing entries are implemented using CNI plugins, as generating routing entries is a function of the CNI plugin itself. Furthermore, because CNI plugins adhere to the CNI protocol, updating routing entries requires deleting and rebuilding the original pod, resulting in low update efficiency.

[0103] A network plane within a container cluster network is a path and its components used to transmit a type of service traffic (implementing a service function). These components include nodes. For example, the network plane can be used to segment network segments for containerized applications, carrying their services. For example, the network plane is mainly divided into a control plane and a data plane. The control plane controls how data is forwarded, i.e., how data is sent from one place to another. The data plane is the actual process of forwarding data, also known as the forwarding plane. These two planes work together to enable the network to transmit data efficiently.

[0104] In more specific scenarios, such as in Kubernetes, the network plane refers to the network components and mechanisms responsible for communication between containers and access to external networks within a cloud-native cluster. It connects containers and assigns them IP addresses, enabling communication between them. The control plane handles cluster control information, primarily including scheduling, managing, and scaling cluster resources. It consists of a series of control nodes. Components on the control plane include APIserver, etcd, the controller manager, and the scheduler. The data plane primarily handles data within the cluster, including containers, network, and storage. It consists of a series of worker nodes responsible for running containers. The worker nodes on the data plane run Kubernetes container orchestration engines such as Kubelet and kube-proxy.

[0105] In many scenarios involving adjusting container cluster networks, the routing entries used to guide traffic forwarding will change because business traffic passes through the adjusted container cluster network during forwarding. Both adjusting the container cluster network (such as creating network interfaces for pods) and generating routing entries require the use of CNI plugins. However, CNI plugins adhere to the CNI protocol, which stipulates that both of these aspects require deleting the original pod and rebuilding it, resulting in low efficiency in updating routing entries.

[0106] For example, in scenarios where the bandwidth of a single network port is insufficient, and additional node network interfaces are added to achieve multiple network planes, such as... Figure 5 As shown, administrators manually add eth1 to node 501 and issue a network change plan to the application interface server. This network change plan specifies the different CNI plugins (e.g., CNI plugin 1 and CNI plugin 2) used to establish different network planes (e.g., network plane A and network plane B). The application interface server forwards the network change plan to the node agent (Kubelet), which then calls CNI plugin 1 and CNI plugin 2 based on the plan. CNI plugin 1 generates eth0 for pod1 on node 501, and CNI plugin 2 generates eth1 for pod1 on node 501 (this belongs to...). Figure 5 The operation of the control plane is indicated by the dashed line. Correspondingly, traffic from network plane A is transmitted to node 502 via pod1's eth0, node 501's eth0, and node 502's eth0. Traffic from network plane B is transmitted to node 502 via pod1's eth1, node 501's eth1, and node 502's eth1 (this belongs to...). Figure 5(The operations of the data plane are indicated by the solid line). The establishment of the network interface of pod2 in node 501 (control plane operation) and the transmission process of traffic between different network planes (data plane operation) are described in the previous section on pod1, and will not be repeated here.

[0107] Based on this, this application provides a method for updating routing entries. In scenarios where changes in the container cluster network necessitate updating routing entries, network forwarding policies related to configuration objects can be issued via a human-machine interface. The management device then converts these policies into routing entries for communication objects (which are associated with the configuration objects when transmitting business traffic) and updates them. This method replaces the traditional CNI plugin-based routing entry update method, is not limited by the CNI protocol, eliminates the need to delete and rebuild pods, and avoids interrupting business operations. This achieves online routing entry updates without interrupting business operations, improving the efficiency of routing entry updates. Furthermore, if multiple network planes are configured through network forwarding policies, there is no need to delete and rebuild pods and add network devices (i.e., network interfaces) to the rebuilt pods, further improving the efficiency of multi-network plane configuration.

[0108] The method for updating routing entries provided in this application can be applied to... Figure 6 An illustration of a container cluster network. (e.g.) Figure 6 As shown, the container cluster network includes access zone node 601, node 602, node 603, and management device 604. The access zone nodes 601, 602, and 603 have a network interface (eth) deployed on them. Pods are deployed on nodes 602 and 603, and containers are deployed within these pods (not yet...). Figure 6 As shown in the image, the container cluster network schedules at the pod level.

[0109] Management device 604 is used to configure the container cluster network. Nodes 602 and 603 are connected to the external network of the container cluster network through access zone node 601. Containers in the container cluster network can directly communicate with their pod, node, and other nodes using the address information of the pod, node, and other nodes.

[0110] It should be noted that the number of nodes in the container cluster, the number of network interfaces on each node, the number of pods on each node, and the number of containers in each pod can all be configured according to actual needs. Figure 6 This is just an example and is not a limitation on the size of a container cluster network.

[0111] This application provides a method for updating routing entries. This method can be applied to a management device used to configure a container cluster network. For example, the management device can be... Figure 6The management device 604 is shown in the diagram.

[0112] For example, the management device can be a component with core management privileges in Kubernetes (K8S system).

[0113] As mentioned above, when it is necessary to perform operations to adjust the container cluster network, the routing entries need to be changed accordingly to adapt to the network architecture. The method for updating routing entries provided in this application embodiment is applied to the process of updating routing entries. Among them, the operations to adjust the container cluster network include, but are not limited to, adding node network interfaces in business scenarios where the bandwidth of a single network interface is insufficient and big data and business traffic need to be isolated, or using CNI plugins to generate multiple network interfaces for pods to achieve multiple network planes, etc.

[0114] Specifically, operations on container cluster networks mainly involve operations on configuration objects (such as the network plane or pods). The process of updating routing entries is the same for operations on different configuration objects. The following embodiments of this application use the operation process of a management device on a configuration object as an example to describe the process of updating routing entries provided in this application. Other examples will not be repeated.

[0115] like Figure 7 As shown, the method for updating routing entries provided in this application embodiment may include:

[0116] S701, the management device obtains the network forwarding policy of the configuration object from the human-machine interface.

[0117] The configuration object refers to a component in the container cluster network that supports the configured network forwarding policy. For example, the configuration object can be a network plane, a pod, or something else. Of course, the content of the configuration object can also be defined according to actual needs, and this embodiment does not limit this.

[0118] For example, the network forwarding policy of the first configuration object is used to indicate the network interface used by the end device of the first configuration object during communication on the transmission path in the first direction. The first configuration object is any configuration object in the container cluster network.

[0119] In this context, the end device refers to the nodes at both ends of a transmission path, including the source node or the destination node.

[0120] The first direction includes either a sending direction or a receiving direction. The sending direction refers to the first configuration object acting as a source to send data, while the receiving direction refers to the first configuration object acting as a destination to receive data. For example, the first direction is identified as either a source or a destination in the network forwarding policy of the first configuration object. The source indicates that the first direction is the direction in which service traffic flows out of the first configuration object, and can also be considered as the direction originating from the source node (i.e., the sending direction). The destination indicates that the first direction is the final direction in which service traffic flows into the configuration object, and can also be considered as the direction sent to the destination node (i.e., the receiving direction).

[0121] For example, the network forwarding policy of the first configuration object may include: an identifier of the first configuration object, a first direction, and an identifier of the first network interface. This network forwarding policy is used to indicate that the first configuration object uses the first network interface to transmit service traffic on the transmission path in the first direction.

[0122] The configuration object identifier is used to uniquely identify the configuration object. The content and form of this identifier can be configured according to actual needs, and this application does not impose any limitations on it. The network interface identifier is used to uniquely identify the network interface. The content and form of this identifier can be configured according to actual needs, and this application does not impose any limitations on it.

[0123] For example, the configuration object is the default-plane network plane, and its network forwarding policy can be "from "default-plane" by "eth1". This network forwarding policy indicates that the source node of the default-plane network plane on the transmission path in the sending direction uses eth1 when communicating.

[0124] Furthermore, network forwarding policies can also include other content. For example, a network forwarding policy may include the product identifier to which the configuration object belongs and the configuration object itself.

[0125] Furthermore, the network forwarding policy also includes an effectiveness status. The effectiveness status indicates whether the network forwarding policy is in effect. For example, the effectiveness status can include enabled or disabled, where enabled indicates that the network forwarding policy is effective, and disabled indicates that the network forwarding policy is ineffective.

[0126] In one possible implementation, the human-computer interaction interface can be in the form of a browser, where users can input network forwarding strategies.

[0127] For example, the human-machine interface is provided to the outside world by the management device, or the human-machine interface can be provided to the outside world by the system where the management device is located.

[0128] For example, Figure 8 This is a schematic diagram of a human-computer interaction interface provided in an embodiment of this application. Figure 8As shown, the human-computer interaction interface includes a product name column (e.g., ...). Figure 8 The first column, including nce, manager), and the configuration object identifier column (e.g. Figure 8 The second column includes the default-plane network plane, pod1, etc., and the traffic direction identifier column (e.g., ...). Figure 8 The third column includes the source or destination column and the network interface identifier column (e.g., Figure 8 The fourth column includes either eth0 or eth1, and the effective status column (e.g., ...). Figure 8 The fifth column includes whether it is enabled or disabled. Figure 8 The row in the illustrated interface represents a network forwarding policy. Users can manipulate the network forwarding policy by clicking the "Edit" and / or "Delete" buttons corresponding to it.

[0129] For example, in Figure 8 In the first row of network forwarding policies set by the nce product, the network forwarding policy is enabled. "default-plane" is the network plane identifier, "from" indicates that the service traffic direction is the source, and "by eth1" indicates that eth1 is used. Based on "from" and "by eth1", it can be seen that the source node on the transmission path in the sending direction of the default-plane network plane uses eth1 during communication. For the fourth row of network forwarding policies set by the nce product in Table 1, this indicates that the network forwarding policy is enabled, the configured object identifier is "pod1", the service traffic flows out from "pod1" and is transmitted through the eth1 of the source node (i.e., the node where pod1 is located).

[0130] S702, The management device converts the network forwarding policy into a routing entry for the communication object associated with the configuration object when transmitting service traffic in the container cluster network.

[0131] In this context, the communication object associated with a configuration object when transmitting service traffic in a container cluster network refers to the object through which traffic passes when the current configuration object transmits service traffic. The granularity of this object can be the same as the granularity of a configuration routing entry.

[0132] For example, the communication object can be a node or a pod.

[0133] The routing entry of the first communication object is used to indicate the address information of the next hop for the container deployed in the first communication object during communication in the first direction.

[0134] For example, when the communication object is a node, the communication object associated with the transmission of service traffic in the first network plane of the container cluster network includes: nodes in the first network plane.

[0135] For example, when the communication object is a pod, the communication objects associated with the first pod in the container cluster network when transmitting business traffic include pods other than the first pod in the container cluster network.

[0136] In one possible implementation, the management device converts the network forwarding policy into routing entries for the communication objects associated with the configuration objects transmitting service traffic in the container cluster network. This includes: the management device determining the path between the end device and the communication objects associated with the configuration objects transmitting service traffic in the container cluster network according to the network interface indicated by the network forwarding policy and the address information corresponding to the configuration objects, following a routing protocol. Then, routing entries for the end devices and communication objects are generated based on this path.

[0137] Routing protocols are used to determine the transmission paths of service traffic across multiple networks. Different routing protocols set different reference metrics to determine the transmission paths of service traffic. These reference metrics may include hop count, latency, and quality of service.

[0138] The routing protocol described in this application can be selected according to actual needs, and the embodiments of this application are not limited in this regard. For example, the routing protocol may include RIP protocol or OSPF protocol, or others.

[0139] Optionally, the process of determining the path in S702 varies depending on the type of configuration object, and may include, but is not limited to, the following situations:

[0140] Case 1: The configuration object is the network plane, and the communication object is a node or pod.

[0141] Based on the identification of communication objects (nodes or pods) within the network plane, the management device determines the paths between the end nodes (nodes or pods) of that network plane and each communication object (node ​​or pod) within that network plane, according to the routing protocol. For specific implementation details, please refer to the following... Figure 9 The process is illustrated, and will not be repeated here.

[0142] Scenario 2: The configuration object is a pod, and the communication object is a node.

[0143] The management device identifies all nodes in the container cluster network and, based on the routing protocol, determines the node containing the configuration object as the end device, establishing the path between it and all other nodes in the container cluster network (excluding the node containing the configuration object). See the following for specific implementation details. Figure 10 The process is illustrated, and will not be repeated here.

[0144] Case 3: The configuration object is a pod, and the communication object is a pod.

[0145] The management device identifies all pods within the container cluster network and, based on the routing protocol, determines the path between the configuration object (as the end device) and each pod in the container cluster network (excluding the configuration object). See the following for specific implementation details. Figure 11 The process is illustrated, and will not be repeated here.

[0146] Furthermore, after obtaining the paths between the end devices and the communication objects associated with the transmission of service traffic in the container cluster network, the routing entries of the end devices and the routing entries of each communication object are extracted from them. The routing entry of a device (end device or communication object) is used to indicate the next-hop address information of the traffic transmitted by that device, and the routing entries of all devices on a path constitute the entire path.

[0147] S703, the management device updates the routing entries of each communication object respectively.

[0148] In S702, based on the routing entry of the communication object obtained by the management device, in S703 the management device will send the obtained routing entry to the communication object to which the routing entry belongs.

[0149] In one possible implementation, the management device proactively distributes routing entries to each communication object.

[0150] In another possible implementation, the communication object can periodically monitor whether its routing entries have been updated, and after determining that its routing entries have changed, it can read its own routing entries from the management device and store them.

[0151] In one possible implementation, the communication object is a node, and routing entries within a node can be stored within the node but outside the pod. Alternatively, the communication object can be a pod, and routing entries within a pod can be stored within the pod but outside the container.

[0152] Furthermore, during the process of updating a routing entry in a communication object, the routing entry generated in S702 can be stored in the communication object, and the routing entries already stored in the communication object that conflict with the newly stored routing entries can be deleted.

[0153] The solution provided in this application addresses scenarios where changes in the container cluster network necessitate updating routing entries. It allows users to submit network forwarding policies related to configuration objects via a human-machine interface. The management device then converts these policies into routing entries for communication objects (associated with configuration objects when transmitting business traffic) and updates them. This replaces the traditional CNI plugin-based routing entry update method, eliminating the need for CNI protocol restrictions, pod deletion and reconstruction, and business operation interruption. This achieves online routing entry updates without interrupting business operations, thus improving update efficiency. Furthermore, if multi-network plane configuration is implemented through network forwarding policies, there's no need to delete and rebuild pods or add network devices (i.e., network interfaces) to the rebuilt pods, further improving the efficiency of multi-network plane configuration.

[0154] In S702, the process of converting network forwarding policies into routing entries for communication objects associated with the transmission of service traffic in a container cluster network can be as follows: Figures 9 to 11 Any one of the descriptions.

[0155] Corresponding to Case 1 in S702, the configuration object is the network plane. When the first network plane in the container cluster network transmits service traffic, the associated communication objects include the nodes included in the first network plane. For example... Figure 9 As shown, the process of converting network forwarding policies into routing entries may include processes S7021 to S7023.

[0156] S7021. The management device determines the nodes included in the first network plane based on the identifier of the first network plane.

[0157] One possible implementation is that the management device records the network segment information range corresponding to the identifier of the first network plane. S7021 may include: determining the network segment information range corresponding to the identifier of the first network plane; and selecting nodes whose address information falls within the range of this network segment information as nodes in the first network plane.

[0158] Another possible implementation is that the management device records the correspondence between the identifier of the network plane and the nodes included in the network plane. S7021 may include: determining the node corresponding to the identifier of the first network plane in the correspondence according to the identifier of the first network plane, and using it as a node in the first network plane.

[0159] S7022, The management device uses the node where the first network interface is located as the end device of the first network plane.

[0160] S7023. The management device generates the path between the end device and other nodes in the first network plane through the first network interface according to the routing protocol, and generates routing entries for the nodes included in the first network plane based on the path.

[0161] In S7023, the management device needs to first determine the address information of other nodes in the first network plane.

[0162] In one possible implementation, the management device in S7023 generates the optimal path between the end device and other nodes in the first network plane according to the routing protocol.

[0163] The optimal path includes the best path based on different reference metrics obtained from different routing protocols. For example, reference metrics may include hop count, latency, and quality of service. Correspondingly, the optimal path may include multiple paths among the path with the fewest hops, the path with the shortest latency, and the path with the best quality of service.

[0164] In another possible implementation, in S7023, the management device selects an optimal path from the optimal paths corresponding to different reference indicators, generates a routing entry between the end device and other nodes in the first network plane via the first network interface, and obtains the routing entry for the nodes included in the first network plane. This routing entry is used to indicate the next-hop address information for containers deployed in the first network plane when communicating in the direction of origin or destination.

[0165] For example, the network forwarding policy is from "default-plane" by "eth1", the communication target is the node, and combined with Figure 6 The diagram illustrates a container cluster network. Assume... Figure 6 Node 602 is the source node of the network plane default-plane. Service traffic from node 602 related to the default-plane flows out through eth1 of node 602. The communication object associated with the transmission of service traffic in the network plane default-plane is node 603. Assuming that the destination device of the service traffic in the default-plane is node 603, it flows into node 603 through eth0 (selected according to the routing mechanism, which can be configured according to actual needs, and is not limited in this embodiment). The management device generates a path from node 602 to node 603. The routing entries for node 602 obtained based on this are shown in Table 1, and the routing entries for node 603 are shown in Table 2.

[0166] Table 1

[0167] Destination address Output network interface Next hop address Node 603 eth1 of node 602 Node 603

[0168] Table 2

[0169] Destination address Input network interface Node 603 eth0 of node 603

[0170] When the configuration object is the network plane and the communication object is a pod, generating routing entries for each pod differs from generating paths for each node when the configuration object is the network plane and the communication object is a node. In the former case, the pod must first connect from its own network interface to the network interface of its own node, or from the node's network interface to the network interface of a pod within that node. The rest of the process is the same as in the latter case, thus enabling communication between different pods. The details of generating paths for each pod when the configuration object is the network plane and the communication object is a pod will not be elaborated upon here.

[0171] Corresponding to scenario 2 in S702, the configuration object is a pod. The network forwarding policy for the first pod includes: the first pod identifier, the first direction, and the identifier of the second network interface. The communication objects associated with the first pod transmitting service traffic in the container cluster network include: pods other than the first pod in the container cluster network. For example... Figure 10 As shown, the process of converting a network forwarding policy into a routing entry may include S7021' to S7022'.

[0172] S7021' The management device uses the node where the second network interface is located as the end device.

[0173] The node where the second network interface is located is the same node where the first pod runs.

[0174] S7022' The management device generates the first pod according to the routing protocol, and the path between the first pod and other pods in the container cluster network is generated through the end device and the second network interface. Based on the path, routing entries are generated for each pod in the container cluster network.

[0175] In S7022', the management device needs to first determine the address information of other pods in the container cluster network.

[0176] For example, in Kubernetes, you can use the command `kubectl get pods --all-namespaces` or `kubectl get pods -o wide` to retrieve the addresses of all pods in the container cluster network.

[0177] For example, the management device can record the correspondence between the identifiers and address information of all pods in the container cluster network. In S7021', the correspondence is queried, and the address information corresponding to the identifier of the first pod in the correspondence is determined as the address information of the first pod.

[0178] It should be noted that the process by which the S7022' management device generates paths between the first pod and other pods in the container cluster network according to the routing protocol can be referred to the method of generating paths between nodes in the S7023, and will not be repeated here.

[0179] For example, the network forwarding policy is from "pod=pod2" by "eth1", the communication object is the pod, and combined with Figure 6 The diagram illustrates a container cluster network. Assume... Figure 6 In the example, pod2 in node 602 is the source pod, and traffic flows out through pod2's eth0 and node 602's eth1. When pod2 transmits business traffic, the associated communication object is pod3 in node 603. Assuming the destination device of the business traffic is pod3 in node 603, it flows into pod3 through node 603's eth0 and pod3's eth0 (selected according to the routing mechanism, which can be configured according to actual needs; this embodiment does not limit this). The management device generates a path from pod2 to pod3. Based on this, the routing entries for pod2 are shown in Table 3, and the routing entries for pod3 are shown in Table 4.

[0180] Table 3

[0181] Destination address Output network interface Next hop address pod3 eth1 of node 602 Node 603

[0182] Table 4

[0183] Destination address Input network interface pod3 eth0 of node 603

[0184] Corresponding to scenario 3 in S702, the configuration object is a pod. The network forwarding policy for the second pod includes: the second pod identifier, the first direction, and the identifier of the third network interface. The communication objects associated with the second pod transmitting service traffic in the container cluster network include: nodes other than the node where the second pod resides within the container cluster network. For example... Figure 11 As shown, the process of converting a network forwarding policy into a routing entry may include:

[0185] S7021”, the management device uses the node where the third network interface is located as the end device.

[0186] For example, in Kubernetes, the `kubectl get nodes` command can be used to query information about all nodes in a container cluster network, including the identifiers of the network interfaces deployed on those nodes. Based on this, the node containing the third network interface can be determined.

[0187] The S7022 management device generates the path between the end device and other nodes in the cluster network through the third network interface according to the routing protocol, and obtains the routing entries of each node in the cluster network.

[0188] In S7022, the management device must first determine the address information of other nodes in the container cluster network.

[0189] It should be noted that the process by which the S7023 management device generates paths between the end device and other nodes according to the routing protocol can be referred to the method of generating paths between nodes in the S7023, and will not be repeated here.

[0190] For example, the network forwarding policy is from "pod=pod2" by "eth1", the communication target is the node, and combined with Figure 6 The diagram illustrates a container cluster network. Assume... Figure 6 In the example, pod2 in node 602 is the source pod, and traffic flows out through pod2's eth0 and node 602's (i.e., the source node's) eth1. When pod2 transmits business traffic, the associated communication object is node 603. Assuming the destination device of the business traffic is node 603, it flows into node 603 through node 603's eth0 (selected according to the routing mechanism, which can be configured according to actual needs; this embodiment does not limit this). The management device generates a path from node 602 to node 603. Based on this, the routing entries for node 602 are shown in Table 5, and the routing entries for node 603 are shown in Table 6.

[0191] Table 5

[0192] Destination address Output network interface Next hop address Node 603 eth1 of node 602 Node 603

[0193] Table 6

[0194] Destination address Input network interface Node 603 eth0 of node 603

[0195] It should be noted that Tables 1 to 6 above are only examples to illustrate routing items and are not specific limitations on the content and form of routing items.

[0196] Furthermore, to promptly notify users of the success or failure of updating routing entries for communication objects and improve user experience, Figure 12 This provides yet another method for updating route entries. For example... Figure 12 As shown, after S703, the method further includes:

[0197] S704. If the routing entry is successfully updated for each communication object, the management device outputs the first reminder message on the human-machine interface.

[0198] The first notification message indicates that the routing entry has been updated successfully. The content and format of the first notification message can be configured according to actual needs, and this embodiment does not limit them.

[0199] For example, the first reminder message can be in the form of a pop-up window, and the content of the first reminder message can be: The network forwarding policy configuration has been completed.

[0200] Specifically, the management device can determine whether a routing entry has been successfully updated based on the specific method by which it transmits routing entries to the communication object.

[0201] In one possible implementation, for scenarios where the management device actively sends out routing entries, the success of the routing entry update can be determined by whether the communication object sends back a response message.

[0202] For example, if a response message is received from a communication object within a first preset time period, and this response message indicates that the routing entry has been successfully updated, then it is determined that the routing entry update to that communication object was successful. If no response message is received from a communication object within the first preset time period, then it is determined that the routing entry update to that communication object failed.

[0203] In another possible implementation, for scenarios where the communication object actively reads the routing item, the success of the routing item update can be determined by whether the communication object has read the routing item.

[0204] For example, if a communication object is detected reading a routing entry within a second preset time period, it is determined that updating the routing entry for that communication object was successful. If no communication object is detected reading a routing entry within the second preset time period, it is determined that updating the routing entry for that communication object failed.

[0205] The first preset duration and the second preset duration can be configured according to actual needs. The first preset duration can start counting from the moment the route entry is issued, and the second preset duration can start counting from the moment the route entry is generated.

[0206] Of course, the specific implementation of configuring the management device to determine whether the routing entry has been successfully updated to the communication object can be determined according to actual needs, and this application embodiment does not limit this.

[0207] Furthermore, if the management device determines that updating the routing entry to any communication object fails, the management device can repeat the operation of S703 until the routing entry is successfully updated.

[0208] Furthermore, if the number of times S703 is executed reaches a threshold, or if the failure to update the routing entry to any communication object still occurs after the third preset time period, the management device can output a second reminder message on the human-machine interface. This second reminder message is used to indicate that the routing entry update has failed.

[0209] For example, the technical solution of this application can be applied to Figure 13 The illustrated Kubernetes system includes a management device, a user interface, and multiple components. The management device can be the Kubernetes controller (Operator), and the components include, but are not limited to, an API server, storage modules, and sidecar components.

[0210] The application programming interface server (API) is a communication component of the Kubernetes system, used to receive network forwarding policies issued by users.

[0211] The storage module is used to store routing entries generated by the management device based on the network forwarding policy.

[0212] Sidecar components can be deployed on various communication objects (i.e., if the communication object is a node, the sidecar component is deployed on the node; if the communication object is a pod, the sidecar component is deployed on the pod). The sidecar component uses a list-watch mechanism to monitor and receive notifications from the system in real time. When a routing entry on a node in the storage module changes, the Kubernetes system automatically sends a change notification to the sidecar component on that node. Upon receiving the change notification, the sidecar component determines that the routing entry on its node has changed.

[0213] The following is combined with Figure 13 This application provides a detailed description of the method for updating routing entries.

[0214] Suppose that the bandwidth of a single network interface in a container cluster is insufficient, and the user wants to expand host resources by adding network interfaces to nodes. The user generates routing entries at the node level by configuring network forwarding policies in the network plane. The Kubernetes system provides a user interface in the form of a browser. Figure 14 As shown, this application provides another method for updating routing entries, which may include:

[0215] S1401. Users manually add eth 1 to the end nodes of the default-plane network plane.

[0216] S1402. The user sets the network forwarding policy for the default-plane network plane in the browser.

[0217] For example, the network forwarding strategy can be: from "default-plane" by "eth1", which describes the source node on the transmission path of the default-plane network plane in the sending direction, and uses eth1 during communication.

[0218] S1403, The browser receives the network forwarding policy and forwards it to the API Server.

[0219] S1404. APIServer checks whether the network forwarding policy has changed.

[0220] Specifically, the APIServer compares the currently received network forwarding policy with the previously received network forwarding policy to determine whether the network forwarding policy has changed.

[0221] If the APIServer determines that the currently received network forwarding policy has changed, it sends a change notification to the Operator so that the Operator can execute S1405.

[0222] If the APIServer determines that the network forwarding policy has not changed, the process ends.

[0223] S1405, Operator obtains network forwarding policy.

[0224] Specifically, after receiving a change notification based on the list-watch mechanism, the Operator obtains the current network forwarding policy from the APIServer.

[0225] S1406. The Operator determines the network segment information range of the default-plane network plane based on the network plane identifier, and takes the nodes whose address information is within the network segment information range as nodes in the default-plane network plane.

[0226] S1407, The Operator uses the node containing eth1 in the network forwarding policy as the source node of the default-plane network plane.

[0227] S1408, Operator determines the address information of nodes other than the source node in the default-plane network plane.

[0228] Based on the address information of other nodes, S1409 and Operator determine the path between the source node and other nodes in the default-plane network plane via eth1 according to the routing protocol. Based on the path, they generate routing entries for the nodes included in the default-plane network plane and store the routing entries of the nodes in the storage module.

[0229] S1410, Operator sends a change notification to the sidecar assembly.

[0230] The Operator can send change notifications to the sidecar components in nodes that need to update their routing entries.

[0231] For example, a node that needs to update its route entry can be a node whose route entry has changed, or a node whose route entry update failed.

[0232] The Operator compares each route item generated in S1409 with the route item previously sent to the node to which the route item belongs. If it determines that the route item of a certain node has changed, it sends a change notification to the sidecar component in that node.

[0233] S1411. After receiving the change notification, the sidecar component in the node obtains the routing entry of its own node in the storage module.

[0234] For example, the sidecar component can obtain the routing entries of a node by calling the interface provided by the storage module.

[0235] S1412, The sidecar component writes the obtained route entry into the routing table of the node it belongs to.

[0236] S1413, The Operator determines whether the routing entries of each node have been successfully updated.

[0237] The process of determining whether a routing entry is successful can be referred to the process in S704 above, and will not be repeated here.

[0238] If the Operator determines that the routing entries of each node have been successfully updated, it executes S1414. If the Operator determines that the routing entry update of any node has failed, the Operator executes S1410 and sends a change notification to the sidecar components in the node where the routing entry update failed.

[0239] S1414, Operator sends an instruction to APIServer.

[0240] This instruction is used to indicate that the routing entry update was successful.

[0241] S1415, APIServer displays a reminder message through a browser.

[0242] This notification message indicates that the routing entry was updated successfully.

[0243] Furthermore, if, after the preset time, any node's route item update still fails, the Operator sends a failure indication to the APIServer, so that the APIServer can display an alarm message through the browser. This alarm message is used to remind users that the route item update failed.

[0244] For example, in scenarios where the bandwidth of a single network port is insufficient, and additional node network interfaces are added to achieve multiple network planes, such as... Figure 15 As shown, in this application, the user manually adds eth1 to node 501 and issues a network forwarding policy through a human-machine interface. The application programming interface server receives and detects the network forwarding policy. Upon detecting a change in the network forwarding policy, the controller stores the routing entry converted by the network forwarding policy in the storage module. Then, the sidecar component in the node retrieves the routing entry for that node from the storage module and writes it into the node's routing table. Thus, service traffic from pod1 in node 501 connects to eth0 of that node according to the corresponding routing entry in the routing table, and eth0 of node 502 connects to node 502. Service traffic from pod2 in node 501 connects to eth1 of that node according to the corresponding routing entry in the routing table, and eth1 of node 502 connects to node 502. Compared to... Figure 5 The proposed solution uses a CNI plugin to generate multiple network interfaces for the pod, thereby achieving a multi-network plane. This application... Figure 15 The proposed solution eliminates the need to create multiple network interfaces for a pod; it utilizes only one network interface and routing entries in the routing table to connect to different network planes. Furthermore, by converting network forwarding policies into routing entries, the routing entries guide the transmission of business traffic, eliminating the need for... Figure 5 The proposed solution, limited by the CNI protocol, deletes and rebuilds the pod, thus improving the efficiency of routing entry updates.

[0245] Similarly, suppose the management device has acquired multiple network forwarding policies, including the following two:

[0246] Network forwarding strategy a: from "default-plane" by "eth1".

[0247] Network forwarding strategy b: from “bigdata-plane” by “eth0”.

[0248] The management device executes the method for updating routing entries provided in the embodiments of this application, converting network forwarding policy a and network forwarding policy b into routing entries for each node in the network plane default-plane and network plane bigdata-plane, respectively, and then updating the routing tables of the nodes. The process of converting network forwarding policies into routing entries and the updating process can be referred to the description in the foregoing method embodiments, and will not be repeated here.

[0249] For example, suppose a node belongs to the network plane default-plane and the network plane bigdata-plane. The traffic transmission scenario of this node is as follows: Figure 16 As shown. The routing entries for this node obtained from network forwarding policy a and network forwarding policy b are stored in the routing table. For example... Figure 16 As shown, pod1 and pod2 are deployed in this node. pod1 has an IP address of 172.18.1.101 and is used to implement the network plane default-plane; pod2 has an IP address of 172.19.1.101 and is used to implement the network plane bigdata-plane.

[0250] After converting network forwarding policy a and network forwarding policy b into routing entries and updating them to the nodes, you can use the iptule show command to view the service traffic transmission behavior.

[0251] For example, the `ip tule show` command can be used to view service traffic transmission behavior as follows:

[0252] IP rule show

[0253] 100:from 172.18.1.0 / 26tos lowdelay lookup 100prohibit

[0254] 110:from 172.19.1.0 / 26tos lowdelay lookup 110prohibit

[0255] ...

[0256] IP rule show table 100

[0257] 172.18.1.0 / 26via 192.168.1.101dev eth1 proto bird

[0258] IP rule show table 110

[0259] 172.19.1.0 / 26via 192.168.2.101dev eth0 proto bird

[0260] Based on this traffic transmission behavior, it can be seen that the final service behavior includes: service traffic from the 172.18.1.0 / 26 network segment (such as...). Figure 16 The IP address of pod1 is 172.18.1.101, which belongs to this network segment. Looking up route table 100, route table 100 indicates that traffic for this network segment flows out from the node's eth1, i.e., default-plane traffic. Figure 16 (Solid line in the middle) forwarded via eth1; service traffic from the 172.19.1.0 / 26 network segment (such as...) Figure 16 The IP address of pod2 is 172.19.1.101, which belongs to this network segment. Looking up route table 110, route table 110 indicates that traffic for this network segment flows out from the node's eth0, i.e., bigdata-plane traffic. Figure 16 (The dashed line in the middle) is forwarded via eth0. By forwarding service traffic from different network segments (i.e., the network plane) to other nodes according to routing entries from different network interfaces, traffic isolation is achieved, and the problem of preemption of container network bandwidth resources is solved through network forwarding strategies.

[0261] It is understood that in the embodiments of this application, the apparatus for updating routing entries may perform some or all of the steps in the embodiments of this application. These steps or operations are merely examples, and the embodiments of this application may also perform other operations or variations thereof. Furthermore, the various steps may be performed in different orders as presented in the embodiments of this application, and it is not necessarily necessary to perform all the operations in the embodiments of this application.

[0262] In the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions of different embodiments are consistent and can be referenced by each other. The technical features of different embodiments can be combined to form new embodiments according to their inherent logical relationship.

[0263] It is understood that the methods and / or steps implemented by the means of updating routing entries in the above embodiments can also be implemented by components (e.g., chips or circuits) that can be used in the means of updating routing entries.

[0264] Alternatively, it can be understood that the apparatus for updating routing entries includes hardware structures and / or software modules corresponding to the execution of each function in order to achieve the above-described functions. Those skilled in the art will readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0265] This application embodiment can divide the device for updating routing entries into functional modules according to the above method embodiment. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0266] for example, Figure 17 A schematic diagram of a device 170 for updating routing entries is shown. The device 170 for updating routing entries includes an acquisition module 1701, a conversion module 1702, and an update module 1703.

[0267] The acquisition module 1701 is used to execute Figure 7 , Figure 12 In the process, S701, the conversion module 1702 is used to execute... Figure 7 , Figure 12 S702 in the process Figure 9 Any one of S7021-S7023 in the process, Figure 10 Any one of S7021'-S7022' in the process, Figure 11 Any of S7021-S7022 in the process, update module 1703 is used to execute Figure 7 , Figure 12 S703 in the process. The device 170 for updating routing entries in this application may further include an output module for performing... Figure 12 S704 in the process. All relevant content regarding each step in the above method embodiment can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0268] Optionally, embodiments of this application also provide a computing device (e.g., the computing device may be a chip or a chip system), which includes a processor for implementing the methods in any of the above method embodiments. In one possible design, the computing device further includes a memory. The memory is used to store necessary program instructions and data, and the processor can call the program code stored in the memory to instruct the control device to execute the methods in any of the above method embodiments. Of course, the memory may not be in the control device. In another possible design, the computing device further includes an interface circuit, which is a code / data read / write interface circuit. The interface circuit is used to receive computer execution instructions (the computer execution instructions are stored in the memory, and may be read directly from the memory or may be transmitted through other devices) and transmit them to the processor. When the computing device is a chip system, it may be composed of chips or may include chips and other discrete devices; embodiments of this application do not specifically limit this.

[0269] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software programs, implementation can be, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device containing one or more servers, data centers, etc., that can be integrated with the medium. The usable medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., a solid-state disk (SSD)). In embodiments of this application, the computer may include the aforementioned apparatus.

[0270] Figure 18 This is a schematic diagram of the hardware structure of a computing device provided in an embodiment of this application. Figure 18As shown, computing device 180 may include a processor 1801, a memory 1802, and a communication interface 1803; the various components are coupled together via a communication line 1804. It is understood that the communication line 1804 is used to achieve communication between these components. In addition to a data bus, the communication line 1804 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 18 The lieutenant general labeled all buses as communication lines 1804.

[0271] The processor 1801 is configured to perform the steps of the method described in any of the foregoing embodiments when running the computer program.

[0272] Memory 1802 is used to store computer programs that can run on processor 1801.

[0273] The communication interface 1803 is used for receiving and sending signals during the process of sending and receiving information with other external network elements.

[0274] It is understood that the memory 1802 in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct rambus RAM (DRRAM). The memory 1802 of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0275] The processor 1801 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 1801 or by instructions in software form. The processor 1801 can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 1802. Processor 1801 reads the information in memory 1802 and, in conjunction with its hardware, completes the steps of the above method.

[0276] It is understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described herein, or combinations thereof.

[0277] For software implementation, the techniques described herein can be achieved through modules (e.g., procedures, functions, etc.) that perform the functions described herein. The software code can be stored in memory and executed by a processor. The memory can be implemented within the processor or externally.

[0278] Alternatively, as another embodiment, the processor 1801 is also configured to perform the steps of the method described in any of the foregoing embodiments when running a computer program.

[0279] Optionally, the computer execution instructions in this application may also be referred to as application code, and this application does not specifically limit them.

[0280] In a specific implementation, as one example, the processor 1801 may include one or more CPUs, for example... Figure 18 CPU0 and CPU1 in the CPU.

[0281] It should be noted that, Figure 18 This is merely an example of a computing device and does not limit the specific structure of the device.

[0282] As another embodiment of this invention, a computer-readable storage medium is provided, on which instructions are stored, which, when executed, perform the method for updating routing entries in the above method embodiments.

[0283] As another form of this embodiment, a computer program product containing instructions is provided, which, when run on a computer, causes the computer to execute the method for updating routing entries in the above method embodiment.

[0284] This application provides another chip system, which includes a processor for implementing the technical methods of this application. In one possible design, the chip system further includes a memory for storing program instructions and / or data necessary for the embodiments of this application. In another possible design, the chip system further includes a memory for the processor to call application code stored in the memory. This chip system may be composed of one or more chips, or may include chips and other discrete devices; this application does not specifically limit this.

[0285] As another embodiment of this invention, an electronic device is provided, including the chip system described above.

[0286] It should be noted that the chip or chip system described in this application is not limited to the protocol followed by the chip, nor is it limited to other (functional) chips used in conjunction with the chip. As long as the chip is used to implement any of the above method embodiments, it is within the protection scope of this application.

[0287] This application further provides a device for updating routing entries, including a processor and an interface circuit. The interface circuit is used to receive computer execution instructions and transmit them to the processor. The processor is used to execute the computer execution instructions to cause the device for updating routing entries to perform any of the above-described method embodiments.

[0288] This application also provides a system for updating routing entries, including multiple servers, each server including a processor and a memory. The processor is used to execute instructions stored in the memory, causing the servers to perform any of the method embodiments described above.

[0289] Although this application has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings, disclosure, and appended claims, will understand and implement other variations of the disclosed embodiments in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude a plurality. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce good results.

[0290] Although this application has been described in conjunction with specific features and embodiments, it is obvious that various modifications and combinations can be made thereto without departing from the spirit and scope of this application. Accordingly, this specification and drawings are merely illustrative descriptions of the application as defined by the appended claims, and are considered to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from the spirit and scope of this application. Thus, if such modifications and variations of this application fall within the scope of the claims of this application and their equivalents, this application is also intended to include such modifications and variations.

Claims

1. A method for updating routing entries, characterized in that, Applied to a management device used for configuring a container cluster network, the method includes: The network forwarding policy of the configuration object is obtained from the human-computer interaction interface. The network forwarding policy of the first configuration object is used to indicate the network interface used by the end device of the first configuration object in the transmission path in the first direction during communication. The network forwarding policy is converted into a routing entry for the communication object associated with the configuration object when transmitting service traffic in the container cluster network; wherein, the routing entry of the first communication object is used to indicate the address information of the next hop of the container deployed in the first communication object when communicating in the first direction; Update the routing entries for each of the communication objects.

2. The method according to claim 1, characterized in that, The step of converting the network forwarding policy into a routing entry for the communication object associated with the configuration object when transmitting service traffic in the container cluster network includes: Based on the network interface indicated by the network forwarding policy and the address information corresponding to the configuration object, the path between the end device and the communication object associated with the configuration object in the container cluster network when transmitting service traffic is determined according to the routing protocol. The routing entries for the terminal device and the communication object are generated based on the path.

3. The method according to claim 1 or 2, characterized in that, The configuration object is a network plane. A network plane is a path and components on the path used to transmit a type of service traffic in the cluster network. The components include nodes. The network forwarding strategy of the first network plane includes: the identifier of the first network plane, the first direction, and the identifier of the first network interface. The communication objects associated with the first network plane transmitting service traffic in the container cluster network include: the nodes included in the first network plane; The network forwarding policy of the first network plane is converted into a routing entry for the communication object associated with the first network plane when transmitting service traffic in the container cluster network, including: Based on the identifier of the first network plane, determine the nodes included in the first network plane; The node where the first network interface is located is designated as the end device of the first network plane; According to the routing protocol, the path between the terminal device and other nodes in the first network plane is determined through the first network interface; The routing entries for the nodes included in the first network plane are generated based on the path.

4. The method according to claim 1 or 2, characterized in that, The configuration object is a pod, and the network forwarding policy of the first pod includes: the identifier of the first pod, the first direction, and the identifier of the second network interface; The communication object associated with the first pod transmitting service traffic in the container cluster network includes: pods other than the first pod in the container cluster network; The network forwarding policy of the first pod is converted into a routing entry for the communication object associated with the first pod when transmitting service traffic in the container cluster network, including: The node containing the second network interface is designated as the end device. According to the routing protocol, determine the path between the first pod and other pods in the cluster network via the second network interface; Based on the path, generate routing entries for each pod in the cluster network.

5. The method according to claim 1 or 2, characterized in that, The configuration object is a pod, and the network forwarding policy of the second pod includes: the identifier of the second pod, the first direction, and the identifier of the third network interface; The communication objects associated with the second pod transmitting service traffic in the container cluster network include: nodes other than the node where the second pod is located in the container cluster network; The network forwarding policy of the second pod is converted into a routing entry for the communication object associated with the second pod when transmitting service traffic in the container cluster network, including: The node containing the third network interface is designated as the end device. According to the routing protocol, the path between the end device and other nodes in the cluster network is determined through the third network interface; The routing entries for each node in the cluster network are generated based on the path.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: If the routing entry is successfully updated for each communication object, a notification message is output on the human-computer interaction interface, indicating that the routing entry has been successfully updated.

7. The method according to any one of claims 1-6, characterized in that, The communication object is a node or a pod. Routing entries within a node are stored within the node but outside the pod; routing entries within a pod are stored within the pod but outside the container.

8. The method according to any one of claims 1-7, characterized in that, The human-computer interaction interface is in the form of a browser.

9. The method according to any one of claims 2-8, characterized in that, The routing protocol includes: Routing information is provided by the RIP protocol, or by the Open Shortest Path First (OSPF) protocol.

10. An apparatus for updating routing entries, characterized in that, The apparatus is used in a management device for configuring a container cluster network, and the apparatus includes: The acquisition module is used to acquire the network forwarding policy of the configuration object from the human-computer interaction interface. The network forwarding policy of the first configuration object is used to indicate the network interface used by the end device of the first configuration object in the transmission path in the first direction during communication. The conversion module is used to convert the network forwarding policy into a routing entry for the communication object associated with the configuration object when transmitting service traffic in the container cluster network; wherein the routing entry of the first communication object is used to indicate the address information of the next hop of the container deployed in the first communication object when communicating in the first direction; The update module is used to update the routing entries of each communication object respectively.

11. A device for updating routing entries, characterized in that, The device for updating the routing entries includes: a processor and interface circuitry; The interface circuit is used to receive computer execution instructions and transmit them to the processor; The processor is configured to execute the computer execution instructions to cause the device updating the routing entry to perform the method as described in any one of claims 1-9.

12. A system for updating routing entries, characterized in that, It includes multiple servers, each server including a processor and memory; The processor is configured to execute instructions stored in the memory to cause the server to perform the operational steps of the method as described in any one of claims 1-9.

13. A computer-readable storage medium, characterized in that, It stores instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1-9.

14. A computer program product, characterized in that, It stores instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1-9.