Method for carrying out network communication in Kubernetes cluster

Abstract

According to the method for network communication in the Kubernetes cluster, a first POD, a first network bridge and a first network card are deployed in a first node in the cluster, and the first network card belongs to a first physical network; the first network bridge is connected with a first POD network card corresponding to the first POD and a first virtual network card, and the first virtual network card is generated based on the first network card and has an MAC address different from that of the first network card; the first POD network card and the first network card belong to the same subnet. The method comprises the following steps: a first network bridge receives a first ARP response sent by a first POD network card, and modifies an initiator MAC of the first ARP response into an MAC address of a first virtual network card; the first ARP response corresponds to a first ARP request sent by the first requester. And the first network bridge receives a first request sent by the first request direction to the first POD through the first virtual network card. And the first network bridge modifies the receiver MAC of the first request into the MAC address of the first POD network card.

Description

Technical Field

[0001] This specification relates to the field of computer container networking technology, and more particularly to a method for network communication in a Kubernetes cluster. Background Technology

[0002] As internet technology continues to evolve, service architecture patterns have undergone multiple transformations, with distributed microservice architectures gradually replacing earlier monolithic application architectures. During this transformation, Kubernetes (often abbreviated as K8s) has become the mainstream choice in the industry due to its superior container orchestration capabilities and is widely used in production environments. The K8s open-source platform provides automated deployment, elastic scaling, and operational support for containerized clusters. Its core advantage lies in achieving intelligent scheduling and management of application workloads through declarative interfaces, and it has now become the de facto standard for cloud-native container orchestration.

[0003] However, with the rapid development of hybrid cloud, edge computing, and virtualization convergence scenarios, container networks also face multi-dimensional and complex challenges. Typical requirements include, for example: building strictly isolated Virtual Private Clouds (VPCs) in multi-tenant environments; overlapping network segments across tenant environments; establishing logically independent network boundaries in shared infrastructure for sensitive industries such as finance and government; and directly connecting containers to classic networks, sharing the same classic network subnet with existing hardware devices, etc. Furthermore, a single container often needs to access both the virtual network and the classic network plane simultaneously. Taking database services as an example, it is necessary to isolate data traffic for container services through the virtual network, and also to directly connect container services in the virtual network to the classic network to access its backup storage system. Faced with the increasingly complex heterogeneous network interconnection requirements of Kubernetes clusters, related technical solutions generally have technical limitations and are unable to support highly customized hybrid cloud heterogeneous network communication.

[0004] Therefore, there is a need for a technical solution that can achieve multi-tenant isolation, classic network access, and dynamic IP management in a Kubernetes cluster, thereby improving the flexibility and scalability of cloud-native virtualized networks. Summary of the Invention

[0005] This specification provides a method for network communication in a Kubernetes cluster, wherein a first node in the cluster is deployed with a first POD, a first bridge, and a first network interface card (NIC), the first NIC belonging to a first physical network; the first bridge is connected to the first POD NIC and a first virtual NIC corresponding to the first POD, the first virtual NIC being generated based on the first NIC and having a different MAC address than the first NIC; the first POD NIC and the first NIC belong to the same subnet; the method includes:

[0006] The first bridge receives a first ARP response sent by the first POD network card and modifies the MAC address of the initiator of the first ARP response to the MAC address of the first virtual network card; the first ARP response corresponds to the first ARP request sent by the first requester.

[0007] The first bridge receives a first request sent by the first requesting party to the first POD through the first virtual network interface card (NIC). The recipient MAC address of the first request is the MAC address of the first virtual NIC, and the recipient IP address is the IP address of the first POD NIC.

[0008] The first bridge modifies the MAC address of the recipient of the first request to the MAC address of the first POD network card.

[0009] A second aspect of this specification provides a computing device including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method described in the first aspect.

[0010] The method provided in the embodiments of this specification allows a POD network interface card (NIC) to be simultaneously connected to the same classic network as the host node's NIC on a host node with only a single NIC and no additional VLAN partitioning. This enables the POD to access the classic network without hijacking all traffic from the host node's NIC, preserving the integrity and maintainability of the host network, and requiring no changes to the listening or configuration settings on the host node's NIC. This increases communication flexibility in the Kubernetes cluster while reducing operational complexity. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram illustrating the implementation framework for network communication in a K8s cluster according to the embodiments provided in this specification;

[0013] Figure 2 This is a schematic diagram of the network component interaction framework provided according to the embodiments of this specification;

[0014] Figure 3 This is a schematic diagram of the network topology provided according to the embodiments of this specification;

[0015] Figure 4This is a flowchart illustrating a method for network communication in a Kubernetes cluster according to an embodiment of this specification.

[0016] Figure 5 This is a schematic diagram of the network topology provided according to the embodiments of this specification;

[0017] Figure 6 This is a schematic diagram of a K8s cluster under various networking methods provided in the embodiments of this specification. Detailed Implementation

[0018] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0019] Currently, many enterprises are gradually evolving their information system architecture towards cloud-native strategies, moving from traditional monolithic applications to microservice architectures, and from single-instance databases to streaming data buses. More and more system services are being distributed across multi-region, multi-availability-zone cloud networks, forming a hybrid deployment model across cloud networks. These system services can be microservices oriented towards business terminals, distributed database services that rely on strong data consistency, or distributed message queue services with high requirements for data synchronization latency, etc. The embodiments in this specification do not specifically limit these categories.

[0020] These system services, deployed in different cloud networks, need to be able to communicate efficiently across different network boundaries to support enterprise users' application scenarios such as active-active deployment in different locations, real-time synchronization, and elastic scaling.

[0021] As mentioned earlier, Kubernetes (K8s), as the de facto standard for automated container scheduling and orchestration in cloud-native scenarios, provides basic orchestration capabilities for containerized workloads through declarative APIs and control plane mechanisms. However, when faced with increasingly complex enterprise networking needs, K8s has limitations in several aspects, such as multi-tenant network isolation, seamless access to classic networks, and orchestration of hybrid networking strategies, and cannot provide users with advanced network virtualization capabilities.

[0022] For example, in some related technologies, network solutions for Kubernetes clusters allow users to customize VPCs, vSwitch, and classic network topologies through the Kubernetes API-Server. They also leverage SDN technology to instantiate abstract models such as Logical Switches and Logical Routers, enabling rapid construction of virtual network topologies. The Open Virtual Switch (OVS) handles data plane forwarding, while the Open Virtual Network (OVN) handles control plane orchestration. The OVN / OVS bridge, acting as a local forwarding plane on the node, can bridge PODs, virtual machines, physical network interface cards (NICs), and tunnel ports, achieving traffic convergence between the virtual and classic networks.

[0023] However, the technical solutions proposed by the aforementioned technologies generally have the following limitations in actual deployment:

[0024] 1. Limited Classic Network Deployment: To directly connect a POD to the host machine's physical network segment, it's typically necessary to bridge the host machine's physical network interface card (NIC) entirely into the OVS bridge. In this case, the NIC becomes a port in OVS, and the original IP, routing, ARP, iptables, and other protocol stacks are bypassed. Management traffic also needs to be forwarded through OVS flow tables or additional devices, resulting in complex configuration and a high risk of interrupting node management network operations. For a host machine equipped with only a single physical NIC, simultaneously handling control and data plane management, it faces risks of inadequate network isolation and address conflicts, significantly increasing the deployment threshold.

[0025] 2. Limited Use Cases with Classic Networks: Pods using classic networks require their network interface cards (NICs) to be connected to that network, statically assigned a physical subnet IP address, and continuously occupied throughout the Pod's lifecycle. This allocation is neither released nor modified at runtime. In cloud-native virtualization scenarios, a large portion of the workload on a Pod is virtual machine (VM). The actual connection to the classic network should be via the VM's NIC, not the Pod's NIC. Users expect to manage IP addresses within the VM, but current technologies tightly couple IP addresses to the Pod, failing to provide advanced virtual network functionalities such as customizable VM NICs.

[0026] 3. Limited Network Segment Definition: On the one hand, related technologies typically pre-bind a fixed POD CIDR (POD IP address range) to each host machine. Network segments across nodes cannot overlap, making it impossible to create virtual private networks with the same address space but isolated from each other for different tenants. On the other hand, the strong correlation between POD IPs and host nodes means that when a POD is migrated to another node due to failure or other reasons, its address must be changed, making it difficult to meet the needs of scenarios requiring IP persistence, such as stateful services, long-lived connections, and security whitelists. Furthermore, the control plane in related technologies generally lacks centralized IP address management (IPAM), making it difficult to implement advanced network functions such as cross-node address conflict detection, overlapping network segment routing, and VPC-level firewalls, hindering flexible networking and elastic scaling in hybrid cloud and heterogeneous multi-tenant environments.

[0027] In view of this, the inventors propose a method for network communication in a Kubernetes cluster in the embodiments of this specification. This method can integrate OVN and OVS technology frameworks to provide high-level network virtualization capabilities for cloud-native workloads. In the K8s cluster, it supports the coexistence of virtualized networks and classic networks, and can realize multi-tenant isolation, classic network access, and dynamic IP management in the K8s cluster. This method can be applied to K8s clusters that do not have VLAN segmentation capabilities, further improving the flexibility and scalability of cloud-native virtualized networks.

[0028] To better understand and explain the solutions of the various embodiments of this application, some technical terms involved in the embodiments of this application will be briefly explained below.

[0029] In terms of cluster management, Kubernetes divides the machines in the cluster into a master node and several worker nodes. The master node runs a set of cluster management processes, implementing resource management, Pod scheduling, elastic scaling, and security control for the entire cluster. The worker nodes run the actual applications; the smallest unit of operation managed by Kubernetes on a node is a Pod. Running on a node are Kubernetes services such as kubelet and kube-proxy, which are responsible for creating, starting, detecting, restarting, and destroying Pods, as well as implementing a software-based load balancer.

[0030] Cloud-native: A software development and architecture design philosophy for cloud computing environments. It emphasizes leveraging the elasticity, high availability, and distributed computing capabilities of cloud platforms, and using technologies such as containerization and dynamic orchestration (e.g., Kubernetes) to build scalable, resilient, and easy-to-maintain applications. Cloud-native aims to fully utilize the advantages of the cloud environment, improve system agility and delivery efficiency, while supporting rapid evolution and multi-tenant deployment.

[0031] Software-Defined Networking (SDN): A network architecture that separates the data plane and control plane to achieve centralized control and flexible management of the network. Traditional network devices (such as switches and routers) tightly integrate data forwarding functions with control logic, while SDN decouples the control logic from hardware and transfers it to a programmable centralized controller. Key features of SDN include:

[0032] Centralized Control: The control plane in the network is centrally managed by one or more controllers, providing a global view, enabling intelligent decision-making, and dynamic resource scheduling. Programmability: Through open standard interfaces (such as OpenFlow), users or developers can programmatically define network behavior without relying on dedicated hardware. Flexibility and Automation: Dynamic configuration of network device behavior via software supports rapid adjustment of network resources to meet demands. Isolation of Data Plane and Control Plane: The data plane is responsible for forwarding traffic, while the control plane handles logical decisions such as path calculation, thus providing greater controllability.

[0033] Virtual Private Network (VPC): A logically isolated virtual network architecture whose core is to build a user-exclusive private network space on physical infrastructure through software-defined networking (SDN) technology.

[0034] A virtual switch (vSwitch) is a software-based network switch used to forward and coordinate network traffic between virtualized network devices and classic networks. Because it is software-based, a vSwitch can simulate the functionality of a traditional hardware switch.

[0035] Classic Network: A network architecture where the POD directly connects to the underlying physical network. Traffic is handled by physical switches, and all network configurations depend on the physical infrastructure. Classic networks feature simple direct connections, but have limited network topology scalability and management capabilities.

[0036] Load balancing: A technology that distributes network or application traffic across multiple servers, offering advantages such as optimized resource utilization, improved performance, and avoidance of single points of failure. It can be implemented through hardware or software and is commonly used in high-concurrency, high-traffic scenarios.

[0037] NAT Gateway: A gateway service that implements Network Address Translation (NAT) for mapping IP addresses between a Virtual Private Network (VPN) and a Classic Network. It helps VPN devices access (or be accessed) the underlying physical network through a Classic Network IP address while hiding the internal network structure.

[0038] The above is a brief explanation of some technical terms used in the embodiments of this application. The methods proposed in the embodiments of this specification will now be described in detail with reference to the accompanying drawings.

[0039] Figure 1 This document describes an implementation framework for network communication in a Kubernetes cluster, based on an embodiment. It constructs a network topology based on "control plane-data plane separation," providing communication capabilities for both virtual and classic networks within the Kubernetes cluster. Overall, the network architecture proposed in this embodiment can be divided into three logical layers: a "northbound interface layer," a "control plane," and a "distributed data plane." The components of each layer and their interactions are as follows.

[0040] Northbound Interface Layer: Includes the Kubernetes API-Server component. This component serves as the unified entry point for cluster configuration and deployment, exposing network elements in the network model to users in the form of CRDs (Custom Resource Definitions). Users can configure and deploy network elements in the Kubernetes cluster by submitting configuration files (e.g., YAML files) to the API-Server component. The CRD models supported by the network architecture provided in this embodiment include, but are not limited to: Virtual Private Network (VPC), Virtual Switch (vSwitch), Classic Network / Underlay Description ProviderNetwork, Software Load Balancer (LoadBalancer), Classic Network IP Resources (EIP), Floating IP Resources (FIP) used to describe IP mapping relationships, SNAT Gateway (NATGateway), Firewall Rules (ACL), and the IP addresses (InstanceIP) occupied by each virtual network element (or instance).

[0041] Control Plane: Operates at the Kubernetes cluster level and includes the Global Controller, ovn-northd, ovnsb, and ovnnb components. The Global Controller, as the core control module of the Kubernetes cluster, continuously monitors events related to the lifecycle of CRDs and PODs within the cluster. For example, the Global Controller can convert CRD descriptions (deployment statements) into objects in the northbound database (ovnnb), such as virtual switches, virtual routers, and NATs. The Global Controller also manages IPAM for global IP addresses, preventing cross-node network element IP address conflicts and providing overlapping VPC networks to multi-tenants. Furthermore, the Global Controller can write the configuration results of each CRD back to the POD Annotation or CR status field for use by the data plane.

[0042] The ovn-northd component in the control plane acts as a translation component between the northbound database (ovnnb) and the southbound database (ovnsb). It can monitor data changes in ovnnb, parse northbound data, perform logical-to-physical mapping, generate southbound data, and write it to the southbound database. The mapped content can include, for example, converting virtual switches to bridges and ports, access control lists to flow table rules, and so on.

[0043] Distributed Data Plane: Operates at the distributed node level, including the node controller, CNI, ovn-controller, ovsdb, and ovs-vswitchd components. The node controller is deployed on each node as a daemon process. It can read ovnsb through ovn-controller and distribute information such as flow tables, tunnel encapsulation, and port bindings to the local OVS instance. Simultaneously, it writes the node's state data back to ovnsb, allowing the control plane to perform high-availability (HA) scheduling based on this state data.

[0044] The CNI component included in the data plane can forward CNI (binary) call events initiated by the Kubernetes kubelet component to the node controller for processing via the local node's Unix socket.

[0045] The data plane includes the ovs-vswitch component, which is responsible for operations such as flow table execution, tunnel encapsulation, and decapsulation; the ovsdb component stores configuration information such as local bridges, ports, and QoS for ovn-contoller to synchronize.

[0046] The network system architecture deployed based on the above structure can achieve the following interaction process: (See below) Figure 2In a Kubernetes cluster, users can submit standard Kubernetes resources (e.g., Pods) or extended custom resources (CRDs, such as VPCs, vSwitch, classic networks, etc.) through the Kubernetes command-line tool kubectl or the user interface to declare their required network topology and policies. The Kubernetes API-Server, as the single deployment entry point component for the cluster, is responsible for receiving, validating, and storing resource objects. See also... Figure 2 The specific interaction process between components is as follows.

[0047] 1. Create VPC, vSwitch, and Classic Network: Users submit custom resource (CRD) objects to the K8s API-Server, including, for example, VPC, vSwitch, and ProviderNetwork, to complete the declarative definition of the network topology.

[0048] 2. Monitor VPC, vSwitch, and Classic Network Creation / Update Events: The global controller deployed in the cluster continuously monitors the addition or deletion events of the above CRDs, converts user intent into the internal data model of the virtual network, and triggers the subsequent SDN topology configuration process.

[0049] 3. Configure SDN topology: Based on the user's description, the global controller writes virtual routers, virtual switches, NAT rules, load balancers, ACLs, and other objects into the ovnnb database to form a complete virtual network topology.

[0050] 4. SDN control plane configuration is distributed to the data plane: The ovn-northd daemon listens for data changes in ovnnb, translates logical objects into flow table matching rules, tunnel encapsulation parameters and port binding information, and writes them into the ovnsb database for consumption by the node-side controller.

[0051] 5. The Pod creation user submits a standard Kubernetes resource (e.g., Pod) deployment configuration to the Kubernetes API-Server, specifying the required virtual or classic network. The API-Server first writes this deployment configuration to the cluster's backend database (etcd), completing the configuration file persistence. Then, the API-Server broadcasts this deployment event to each controller in the cluster. When the kube-scheduler detects a new Pod that needs scheduling, it allocates the most suitable target node for it and writes the target node allocation result back to the backend database (e.g., updating the Pod's spec.nodeName field). Finally, the kubelet component on the target node detects the POD allocation event and can then perform POD creation-related actions, such as downloading the image, creating the container, and calling CNI.

[0052] 6. Listen for POD creation / update events; 7. Configure IP for POD network cards (assignment, retention); 8. Store POD network card IP configuration results: After the global controller listens for POD events, it can call the centralized IP address management system (IPAM) according to the selected network type to configure IP for the POD network card (supporting new allocation, retention, and other IP configuration policies), and write the POD network card configuration results back to the API-Server.

[0053] 9. Listen for local node POD creation events: As mentioned earlier, when the kubelet component running on each node listens for the POD allocation event and discovers a new instance that needs to be started, it can enter the network interface instantiation process.

[0054] 10. Binary call: The kubelet calls the CNI component and forwards the CNI request to the node controller on the same node via a Unix socket.

[0055] 11. Forwarding CNI requests via Unix sockets: After receiving a CNI request, the node controller extracts relevant POD information (e.g., POD name, network type, annotation fields, etc.) and prepares to execute POD network card creation and data plane access.

[0056] 12. Waiting for POD IP confirmation: The node controller checks the IP allocation record in the annotation corresponding to the POD through the API-Server to ensure that the global IPAM has completed the IP configuration for the POD.

[0057] 13. Configure the network interface card (NIC) for the POD and connect it to the data plane: Create two virtual NICs (e.g., veth pair) for the POD. Add the host-side virtual NIC to the bridge (either a virtual network bridge br-int or a classic network bridge br-pn). Move the peer-side virtual NIC into the POD's network namespace, allowing the POD to send and receive Layer 2 network data frames. To enable the POD to connect to both the virtual and classic networks simultaneously, a MacVLAN sub-interface can be created and attached to the classic network bridge, configuring flow table rules to achieve single-NIC communication within the same network segment. This implementation step will be described in detail below and will not be elaborated on here. Furthermore, ovn-controller can push the rules stored in ovnsb to ovs-vswitchd, making the flow tables effective and completing end-to-end connectivity from the control plane to the data plane.

[0058] The above section presented an implementation framework for network communication in a Kubernetes cluster from the perspective of network components. The following section will describe the network architecture used to support the above implementation framework from the perspective of network topology. Figure 3A network topology diagram is provided in one embodiment. Taking two nodes in a K8s cluster as an example, node 1 and node 2 each have a physical network card eth0, which are connected to the classic network respectively.

[0059] See Figure 3 Each POD within a node has its own independent network stack (shown as POD NS / Namespace in the diagram). Any node can provide a network interface card (NIC) for a virtual network (shown as o-nic in the diagram) and / or a NIC for a classic network (shown as u-nic in the diagram) for a POD. The OVN control plane can deploy a bridge (OVS Bridge, shown as br-int in the diagram) on each node. The bridge will pass the traffic of the NICs bridged to it to the kernel flow table (e.g., OpenFlow flow table) for processing, realizing fine-grained traffic control and policy enforcement. Its capabilities can cover Layer 2 forwarding, Layer 3 routing, and Layer 4 protocol processing of data frames. As mentioned earlier, the kernel flow table on each node can be configured by the control plane based on the user-defined network topology and distributed to the node data plane, realizing centralized management and distributed execution of network policies.

[0060] Continue reading Figure 3 Taking the data link shown by the dashed line as an example, the o-nic network card is connected to br-int and included in OVN management. Virtual network traffic involving cross-PODs can be tunneled and depacked using the generate protocol, enabling virtual network data exchange between different nodes or PODs within the same node. Simultaneously, tunnel IDs can be constructed based on the information of the virtual switches connected to the PODs, achieving logical isolation of multi-tenant virtual networks between different nodes and traffic isolation between virtual switch ports within the same node.

[0061] Continue reading Figure 3 Taking the data link shown by the solid line as an example, the u-nic network card is connected to br-int and included in OVN management. Through OVN's localnet port mechanism, traffic entering br-int from u-nic is directed to the dedicated classic network bridge br-pn. The br-pn bridge is responsible for adding or removing VLAN tags from the traffic and forwarding it to the corresponding VLAN sub-interface (e.g., the VLAN NIC shown in the figure), and finally exchanging data with the classic network through the node's physical network card eth0.

[0062] As described above, to achieve network communication where virtual networks and classic networks coexist within a Kubernetes cluster, VLAN technology is typically used to logically isolate network traffic, thereby ensuring the security and controllability of network communication while sharing physical infrastructure. In other words, to enable interoperability between virtual and classic networks within a Kubernetes cluster, an additional Layer 2 network channel needs to be planned for the POD (Personal Device). The simplest approach is to create a separate VLAN. POD traffic carries a dedicated VLAN tag when entering the switch, while host traffic continues to use the original VLAN, thus achieving traffic separation between the virtual and classic networks on the same classic network link.

[0063] However, in production practice, due to cost constraints or insufficient hardware support, most Kubernetes nodes lack VLAN partitioning capabilities. When users cannot partition additional VLANs for a node, and the POD network interface card (NIC) needs to be on the same physical subnet as the host node's NIC, the solutions provided by the technologies described above necessitate directly bridging the host node's NIC to the node's OVS bridge (br-pn) to allow the POD NIC's MAC address to appear directly in the network the node is connected to, utilizing the OVN's localnet port. While this method allows the POD NIC to obtain an IP address in the same network segment as the host node's NIC, enabling communication between the POD and the classic network, for nodes with only a single NIC, all traffic flowing through the node's NIC is bypassed by the OVS bridge. This renders the previously configured IP addresses, routing rules, security policies, and other network settings on the node's NIC invalid, requiring reconfiguration at the OVS bridge level, increasing operational complexity.

[0064] In view of this, based on the above network topology, the inventors propose a network communication method in the embodiments of this specification, which enables communication between the POD network card and the host node network card in the same subnet on a single network card node without the need for VLAN partitioning. This allows the POD to access classic networks while preserving the integrity and maintainability of the host network, thereby solving the problem of "limited deployment of classic networks" in the related technologies mentioned above.

[0065] Figure 4 A flowchart illustrating a method for network communication in a Kubernetes cluster according to one embodiment is shown. It will be understood that this method can be executed by any device, equipment, platform, or cluster of devices with computing and processing capabilities.

[0066] See Figure 4The first node in the cluster is deployed with a first POD, a first bridge, and a first network interface card (NIC). The first NIC belongs to the first physical network. The first bridge can be composed of OVS bridges br-int and br-pn. As mentioned above, the first bridge can be implemented through a virtual switch, a virtual router, or a combination of both. All forwarding actions through the first bridge can be completed based on custom flow table rules without going through the operating system protocol stack.

[0067] In the cloud-native field, classic networking typically refers to a traditional, multi-tenant, shared, flat network model in a cloud computing environment. Its core feature is providing automated, configuration-free network access capabilities for workloads through a unified network address space. The following section will briefly introduce various embodiments using physical networks as an example of classic networking. However, it should be understood that physical networks are merely a specific implementation of classic networks in scenarios with direct hardware connections at the underlying level, and do not represent a limitation on the application scenarios of the method of this invention. In practice, any Kubernetes cluster with both classic and virtual networks can apply the methods provided in the embodiments of this specification to securely and efficiently achieve interoperability between virtual and classic networks within the Kubernetes cluster.

[0068] The first bridge is connected to the first POD network card and the first virtual network card corresponding to the first POD. The first virtual network card is generated based on the first network card and has a different MAC address than the first network card. The first POD network card and the first network card belong to the same subnet. In a preferred implementation, the first virtual network card can be a macVLAN sub-device generated based on the first network card.

[0069] macVLAN is a network interface card (NIC) virtualization technology implemented by the operating system kernel. It can virtualize multiple NICs on a single physical NIC, each with its own independent MAC address and capable of communicating with other network devices connected to the physical NIC. It's important to understand that macVLAN differs from VLAN. VLAN is a Layer 2 network isolation technology implemented at the switch level, used to divide a physical LAN into multiple logical broadcast domains. VLANs cannot communicate directly on the Layer 2 network and require a router or switch for interoperability. macVLAN, on the other hand, virtualizes NICs within a node and does not rely on the switch's VLAN functionality.

[0070] In this embodiment, a first virtual network interface card (NIC) created based on the first NIC can be connected to the br-pn in the first bridge, enabling connectivity between the physical network and the PODs in the virtual network. Since the first virtual NIC can directly carry physical network traffic and dynamically modify the header information of data frames through the flow table rules of the first bridge, communication between the PODs in the virtual network and other network devices in the physical network can be achieved without relying on additional VLAN partitioning or bridging the first NIC to the first bridge, through Layer 2 ARP spoofing and data frame modification mechanisms. The following will combine... Figure 4 The method proposed in one embodiment is described in detail.

[0071] Step S401: The first bridge receives a first ARP response sent by the first POD network card and modifies the MAC address of the initiator of the first ARP response to the MAC address of the first virtual network card; the first ARP response corresponds to the first ARP request sent by the first requester.

[0072] During network communication, when a requesting party needs to send a data packet to a receiving party, it needs to know the receiving party's MAC address. Typically, the requesting party will broadcast an ARP request message within its local Layer 2 network to query the MAC address corresponding to the receiving party's IP address. In this step, if the first requesting party does not yet know the MAC address of the first POD network card, it can broadcast the first ARP request. Since an ARP request is a broadcast frame, all devices within the same broadcast domain (including the first POD network card) will receive the ARP request. After receiving the first ARP request, the first POD network card identifies that the receiving party's IP address matches its own, and therefore can construct and send a first ARP reply. In this reply message, the sender's MAC address field is filled with the first POD network card's own MAC address.

[0073] As a network traffic interception and proxy component, the first bridge, upon capturing the first ARP reply, can modify the initiator's MAC address to the MAC address of the first virtual network interface card (NIC). In practice, this modification can be achieved through flow table matching. The modified first ARP reply is sent to the br-pn via the br-int in the first bridge, and then forwarded to the first requester via the first NIC. Thus, the first requester can record the first ARP reply in its ARP cache, recording the MAC address corresponding to the IP address of the first POD NIC as the MAC address of the first virtual NIC. In other words, when the first requester needs to communicate with the first POD, it can construct a data frame based on the ARP cache table, where the destination MAC address is the MAC address of the first virtual NIC, while the recipient IP address remains the IP address of the first POD NIC.

[0074] After the above processing, subsequent unicast messages sent by the first requesting party to the first POD will no longer be discarded due to MAC address lookup failure, thus realizing ARP spoofing in the Layer 2 network.

[0075] Next, in step S403, the first bridge receives a first request sent by the first requesting party to the first POD through the first virtual network card. The receiving MAC address of the first request is the MAC address of the first virtual network card, and the receiving IP address is the IP address of the first POD network card.

[0076] In this step, the first requester constructs and sends a first request to the first POD based on the previously recorded IP-MAC mapping relationship. During transmission, because the receiving MAC of the first request points to the first virtual network interface card (NIC), it will eventually be received by the first bridge through the corresponding virtual NIC (the first virtual NIC) (based on Layer 2 MAC address matching).

[0077] Subsequently, step S405 is executed, in which the first bridge modifies the MAC address of the recipient of the first request to the MAC address of the first POD network card.

[0078] The first bridge can identify that the recipient's IP address in the first request corresponds to the first POD network interface card connected to another port of the bridge. Therefore, to ensure that the first request is correctly delivered to the recipient, the first bridge can modify the header information of the first request, changing the recipient MAC field value from the MAC address of the first virtual network interface card to the MAC address of the first POD network interface card. After modification, the first bridge can forward the modified first request to the first POD network interface card through the corresponding port.

[0079] Thus, the first POD can receive a normal data packet from the first physical network that conforms to the standard Ethernet protocol and whose receiver MAC is its own MAC, thereby realizing the interconnection between the physical network and the virtual network.

[0080] In addition to the two types of data packets processed in the above embodiments, the first bridge can also process other types of data packets.

[0081] According to one implementation, the first bridge receives a second ARP request sent by the first POD network card and can modify the initiator MAC address and SHA field value of the second ARP request to the MAC address of the first virtual network card.

[0082] The second ARP request can be an ARP request sent by the first POD to actively probe the MAC addresses of other network devices in the same subnet. The first bridge can parse the second ARP request packet and modify the values ​​of the initiator MAC address and SHA field to the MAC address of the first virtual network interface card (NIC). Subsequently, the first bridge can send the modified second ARP request packet via the first NIC. In this way, the network element receiving the second ARP request obtains the sender MAC address as the MAC address of the first virtual NIC, ensuring that subsequent ARP replies can be unicast to the first virtual NIC.

[0083] According to one implementation, the first bridge receives a second ARP response sent by the second requesting party to the first POD through the first virtual network card, and can modify the recipient MAC address and the tha field value of the second ARP response to the MAC address of the first POD network card.

[0084] The first bridge can parse the ARP reply packet and modify the values ​​of the receiver MAC address and the tha field to the MAC address of the first POD network card that originally initiated the corresponding ARP request. The modified second ARP reply packet can be sent to the first POD network card through the first bridge, achieving correct Layer 2 network forwarding and avoiding packet drop due to receiver MAC mismatch.

[0085] In summary, the flow table rules executed by the first bridge can be summarized as follows:

[0086] For data traffic sent out by the first POD, its initiator MAC address can be modified to the MAC address of the first virtual network interface card (NIC), and sent through the first NIC of the host node. This ensures that subsequent response data traffic can use the MAC address of the first virtual NIC as the receiver MAC address, thereby enabling correct Layer 2 forwarding.

[0087] For data traffic sent from the first requesting party to the first POD, the receiving MAC address can be modified to the MAC address of the first POD network card. This ensures that the data traffic can be routed to the first POD network card after being processed by the first virtual network card and the first bridge.

[0088] Therefore, even on a host node with only a single network interface card (NIC) and no additional VLAN partitioning, the POD NIC can simultaneously connect to the same physical network as the host node's NIC without hijacking all traffic from the host node's NIC. Thus, no changes are needed to the host node's NIC's listening or configuration. This increases communication flexibility within the Kubernetes cluster while reducing operational complexity.

[0089] The preceding text details the methods for achieving interoperability between virtual networks and classic networks in a Kubernetes cluster. Recalling the limitations of the technologies analyzed earlier, other embodiments in this specification, based on the aforementioned network topology, also present methods to address the "limited use cases of classic networks" issue mentioned earlier. These methods decouple the strong binding relationship between IP addresses and POD lifecycles and achieve autonomous network management of virtual machine workloads through network interface card (NIC) model abstraction.

[0090] Revisiting the previously mentioned issue of "limited use cases for classic networks": related technologies bind classic network IP addresses to the lifecycle of a Point-of-Demand (POD). Each POD network interface card connected to the classic network is statically assigned a classic network subnet IP address, which cannot be released or modified at runtime. This strong binding between POD and IP severely restricts the flexibility of cloud-native virtualization scenarios. For example, when the workload is a virtual machine, users actually need to manage the virtual machine's network interface card, not the POD's, and expect to have independent control over IP configuration within the virtual machine. However, related technologies strongly bind IPs to PODs, depriving the virtual machine of network autonomy.

[0091] To solve this technical problem, based on the network topology architecture given above, when the workload running on the first POD is a virtual machine (first virtual machine), a first virtual machine network card can be created in the first virtual machine as the network card of the first POD; the IP address of the first virtual machine network card is configured through the first virtual machine.

[0092] Specifically, to decouple the binding relationship between IP addresses and PODs, a network interface card (NIC) model independent of the first POD can be created within the first virtual machine (i.e., the first virtual machine NIC). This NIC model is associated with the POD (and can be used as the first POD's NIC in the Kubernetes cluster), but the mandatory IP binding attribute is removed. In other words, users can explicitly define the first virtual machine NIC through a declarative API and skip IP address allocation (for example, setting its IP allocation policy to null, causing the IP address management service to automatically skip IP address allocation for this NIC). From the control plane perspective, Kubernetes components no longer forcibly inject IP configuration into the first virtual machine NIC, but only establish link-layer (Layer 2 network) connections. From the data plane perspective, users can configure the IP address, subnet mask, and routing rules of the first virtual machine NIC as needed within the first virtual machine using standard network commands (e.g., ip, ipconfig, route).

[0093] Applying the above method, when a user creates a virtual machine (POD) connected to a Kubernetes cluster, the cluster can provide only a network interface card (NIC) channel for it without automatically assigning an IP address. After the virtual machine starts, the user can freely configure the NIC's IP address according to specific needs (through methods such as automatic DHCP acquisition or static assignment), and modify network parameters at any time during virtual machine operation without rebuilding the POD. This preserves the POD's connectivity to both virtual and classic networks while granting the virtual machine the same network autonomy as the host node, providing greater flexibility for cloud-native virtualization scenarios.

[0094] Continuing to review the relevant technical limitations analyzed above, other embodiments in this specification also provide a method to solve the "limited network segment definition" problem mentioned above, based on the above network topology. This method can provide overlapping IP address spaces for different tenants to allocate while maintaining the network isolation of the K8s cluster, and ensure that PODs have the ability to hold the same IP for a long time in scenarios such as cross-node fault migration, elastic scaling, and hot migration, thereby meeting high-level network requirements such as stateful services, long connections, and security whitelists.

[0095] Revisiting the previously mentioned issue of "restricted network segment definition": Related technologies commonly employ a node-based subnetting strategy, where each host node is pre-bound with a fixed POD CIDR (the IP address of the POD on a node is strongly correlated with the node). Cross-node network segments are not allowed to overlap, preventing different tenants from having VPCs with the same address range. Furthermore, due to the strong coupling between the POD IP and the host node, once a POD is relocated to another host node, its IP address must be changed, leading to a series of problems such as stateful application interruptions, firewall rule failures, and license binding failures. In addition, Kubernetes clusters lack centralized IP address management (IPAM), making cross-node conflict detection, overlapping network segment routing, and VPC-level distributed firewall capabilities difficult to implement, directly hindering flexible networking and elastic scaling in hybrid cloud and heterogeneous multi-tenant environments.

[0096] To address this technical challenge, based on the network topology described above, a virtual route can be created for each VPC in the control plane for management. Several virtual switches can be connected to each virtual route, and each virtual switch corresponds to a Layer 2 broadcast domain (subnet). The virtual route can select routes between internal virtual switches and execute user-defined static or policy-based routing rules. Virtual switches can respond to ARP requests for the network devices they bridge and maintain the mapping between MAC addresses and switch ports. The network interface cards (NICs) of each POD belonging to the VPC network can be bridged to virtual switches. For example, a POD using a classic network can be bridged to an underlay virtual switch; a POD using a virtual network can be bridged to an overlay virtual switch. Furthermore, the virtual routes corresponding to each VPC can also connect to several virtual gateway routes. These virtual gateway routes can serve as the default exit routes for the virtual routes, maintaining NAT rules, CT states, etc. A diagram of the above network topology can be found in the appendix. Figure 5 The following section will continue to use the example of the first node and its first POD in the Kubernetes cluster, as described earlier, to elaborate on the application of this network topology in Kubernetes clusters using multiple implementation methods. (See also...) Figure 6 The diagram illustrates K8s clusters under various networking methods.

[0097] According to one implementation, the first node also deploys a second POD; the first POD network interface card belongs to a first subnet and is connected to a first virtual switch; the second POD's corresponding second POD network interface card belongs to a second subnet and is connected to a second virtual switch. According to this implementation, PODs belonging to different subnets can be deployed simultaneously in the first node, using virtual switches to achieve network isolation. In one practice, the identifiers of the first / second virtual switches connected to the first / second POD network interface cards can be obtained as their respective tunnel IDs, used to perform data exchange based on a first transmission protocol on the first / second POD network interface cards. For example, the identification information (e.g., UUID) of each virtual switch can be extracted as the tunnel ID and encapsulated in the VNI (header information) of the data packet based on the first transmission protocol. In this case, even if two PODs are located on the same node, their traffic can be strictly isolated due to their different tunnel IDs, thereby achieving logical isolation communication between PODs in different subnets within the same node. Typically, the aforementioned first transmission protocol can be one of the following: VxLAN protocol or Geneve protocol.

[0098] According to one implementation, the cluster further includes a second node, which deploys a third POD; the third POD's network interface card (NIC) belongs to the same subnet as the first POD's NIC; the third POD NIC and the first POD NIC can be connected to the same virtual switch. This implementation corresponds to cross-node networking scenarios. When the third POD deployed on the second node needs to communicate with the first POD within the same subnet, the system can connect the third POD NIC and the first POD NIC to the same virtual switch. This method allows PODs in different nodes to form a unified broadcast domain, enabling direct Layer 2 communication through the virtual switch and avoiding performance loss caused by cross-Layer 3 forwarding.

[0099] According to one implementation, the cluster further includes a fourth POD, whose network interface card (NIC) belongs to a different subnet than the first POD NIC but to the same virtual cloud network. The first POD NIC can be connected to a third virtual switch, and the fourth POD NIC can be connected to a fourth virtual switch. The third and fourth virtual switches are then connected to a first virtual router. In other words, if the fourth POD and the first POD belong to different subnets but to the same virtual cloud network (e.g., a tenant's VPC), their NICs can be connected to independent third and fourth virtual switches respectively, and these two virtual switches can be connected to the same virtual router. This virtual router can automatically learn inter-subnet routing policies, enabling cross-subnet traffic communication, and can also implement tenant-level security isolation and NAT translation.

[0100] Furthermore, to achieve unified management and global coordination of IP addresses within the cluster, a centralized IP resource pool can be deployed in the Kubernetes cluster to uniformly allocate, track, and reclaim all IP resources in the cluster. This IP resource pool maintains the global address state at the cluster level, effectively avoiding IP address conflicts and supporting multi-tenant isolation in overlapping network segment scenarios.

[0101] According to one implementation, when the first POD is created, an IP address can be dynamically allocated to the network interface card of the first POD based on the IP resource pool and according to the IP address allocation policy. When the first POD migrates to a new node due to node failure or resource scheduling, its original IP address can be retained through the IP resource pool, and its original IP address can be restored after the migration is completed. This allows the first POD to maintain its IP address during cross-node migration, thereby effectively supporting scenarios that require fixed IP addresses, such as stateful services, long-connection sessions, and IP-based whitelist access, thus ensuring the continuity of system service operation. When the first POD is deleted, its IP address can be released and automatically recycled to the IP resource pool, realizing the recycling of IP address resources and improving the overall utilization rate of IP addresses and the scalability of the cluster.

[0102] In this specification, the terms "first" in the first node, first POD, etc., and the corresponding terms "second" and "third" (if they exist) in the text, are merely for the convenience of distinction and description, and do not have any limiting meaning.

[0103] The foregoing description describes specific embodiments of this specification; other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than those shown in the embodiments, and the desired result may still be achieved. Furthermore, the processes depicted in the drawings do not necessarily need to follow the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0104] This specification also provides a computing device in its embodiments, including a memory and a processor. The memory stores computer programs / instructions, and when the processor executes the computer programs / instructions, it implements the methods in the foregoing embodiments.

[0105] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0106] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0107] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0108] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0109] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0110] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0111] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0112] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0113] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0114] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0115] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0116] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0117] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0118] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0119] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of these embodiments. Various modifications and variations can be made to these embodiments by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A method for network communication in a Kubernetes cluster, wherein a first node in the cluster is deployed with a first POD, a first bridge, and a first network interface card (NIC), the first NIC belonging to a first physical network; The first bridge is connected to the first POD network card and the first virtual network card corresponding to the first POD. The first virtual network card is generated based on the first network card and has a different MAC address than the first network card. The first POD network card and the first network card belong to the same subnet; The method includes: The first bridge receives a first ARP response sent by the first POD network card and modifies the MAC address of the initiator of the first ARP response to the MAC address of the first virtual network card; the first ARP response corresponds to the first ARP request sent by the first requester. The first bridge receives a first request sent by the first requesting party to the first POD through the first virtual network interface card (NIC). The MAC address of the recipient of the first request is the MAC address of the first virtual NIC, and the IP address of the recipient is the IP address of the first POD NIC. The first bridge modifies the MAC address of the recipient of the first request to the MAC address of the first POD network card.

2. The method according to claim 1, further comprising: The first bridge receives a second ARP request sent by the first POD network card and modifies the MAC address of the initiator of the second ARP request and the SHA field value to the MAC address of the first virtual network card. or, The first bridge receives a second ARP response sent by the second requesting party to the first POD through the first virtual network card, and modifies the receiver MAC address and the tha field value of the second ARP response to the MAC address of the first POD network card.

3. The method according to claim 1, wherein, The first bridge is implemented through a virtual switch and / or a virtual router.

4. The method according to claim 1, wherein, The first POD runs a first virtual machine; the method further includes: A first virtual machine network interface card (NIC) is created in the first virtual machine as the first POD NIC; the IP address of the first virtual machine NIC is configured through the first virtual machine.

5. The method according to claim 1, wherein, The first node also has a second POD deployed; the first POD network card belongs to the first subnet and is connected to the first virtual switch; the second POD network card corresponding to the second POD belongs to the second subnet and is connected to the second virtual switch.

6. The method according to claim 5, further comprising: Obtain the identifiers of the first / second virtual switches to which the first / second POD network cards are connected, and use them as their respective tunnel IDs. These IDs are then used to perform data exchange based on a first transmission protocol on the first / second POD network cards. The first transmission protocol is one of the following: VxLAN protocol or Geneve protocol.

7. The method according to claim 1, wherein, The cluster also includes a second node, on which a third POD is deployed; The third POD network card corresponding to the third POD belongs to the same subnet as the first POD network card; the method further includes: Connect the third POD network card to the first POD network card in the same virtual switch.

8. The method according to claim 1, wherein, The cluster also includes a fourth POD, the fourth POD network card corresponding to the fourth POD belongs to a different subnet than the first POD network card, but belongs to the same virtual cloud network; The method further includes: Connect the first POD network card to the third virtual switch, and connect the fourth POD network card to the fourth virtual switch; Connect the third virtual switch and the fourth virtual switch to the first virtual route.

9. The method according to claim 1, wherein, The cluster also includes an IP resource pool; the method further includes: When the first POD is created, an IP address is allocated to the network card of the first POD through the IP resource pool; During the migration of the first POD, an IP address is reserved for the network card of the first POD through the IP resource pool; When the first POD is deleted, the IP address of the first POD network card is reclaimed through the IP resource pool.

10. A computing device comprising a memory and a processor, wherein the memory stores a computer program, and the processor, when executing the computer program, implements the method of any one of claims 1-9.

Images