CN121125478A - 一种在Kubernetes集群中进行网络通讯的方法 - Google Patents

Abstract

一种在Kubernetes集群中进行网络通讯的方法，集群中的第一节点部署有第一POD、第一网桥以及第一网卡，第一网卡属于第一物理网络；第一网桥与第一POD对应的第一POD网卡以及第一虚拟网卡相连接，第一虚拟网卡基于第一网卡生成，具有与第一网卡不同的MAC地址；第一POD网卡与第一网卡属于相同子网。所述方法包括：第一网桥接收由第一POD网卡发送的第一ARP应答，将第一ARP应答的发起方MAC修改为第一虚拟网卡的MAC地址；第一ARP应答对应于第一请求方发送的第一ARP请求。第一网桥通过第一虚拟网卡，接收由第一请求方向第一POD发送的第一请求。第一网桥将第一请求的接收方MAC修改为第一POD网卡的MAC地址。

Description

一种在Kubernetes集群中进行网络通讯的方法

技术领域

本说明书实施例涉及计算机容器网络技术领域，尤其涉及一种在Kubernetes集群中进行网络通讯的方法。

背景技术

当前互联网技术持续演进，服务架构模式历经多次变革，分布式微服务架构已逐步取代早期的单体应用架构。在此变革过程中，Kubernetes(常缩写为K8s)因其卓越的容器编排能力成为业界主流选择，广泛应用于生产环境。K8s开源平台为容器化集群提供自动化部署、弹性扩展及运维支撑，其核心优势在于通过声明式接口实现应用负载的智能调度与管理，现已成为云原生容器编排的事实标准。

然而，随着混合云、边缘计算及虚拟化融合场景的快速发展，容器网络也面临多维复杂的挑战。典型的需求包括例如：在多租户环境下构建严格隔离的虚拟私有网络(Virtual Private Cloud，VPC)；跨租户环境的网段重叠；金融、政务等敏感行业在共享基础设施中建立逻辑独立的网络边界；将容器直接接入经典网络，与既有硬件设备共享同一经典网络子网，等等。此外，单个容器常需同时接入虚拟网络和经典网络平面。以数据库服务为例，既需通过虚拟网络为容器服务隔离数据流量，又需将虚拟网络中的容器服务直连经典网络，访问其中的备份存储系统。面对日益复杂的K8S集群异构网络互联需求，相关技术方案普遍存在技术局限，难以支撑高度定制化的混合云异构网络通讯。

因此，希望能有一种技术方案，可以在K8S集群中实现多租户隔离、经典网络接入、IP动态管理等，提升云原生虚拟化网络的灵活性和可扩展性。

发明内容

本说明书第一方面提供了一种在Kubernetes集群中进行网络通讯的方法，所述集群中的第一节点部署有第一POD、第一网桥以及第一网卡，所述第一网卡属于第一物理网络；所述第一网桥与所述第一POD对应的第一POD网卡以及第一虚拟网卡相连接，所述第一虚拟网卡基于所述第一网卡生成，具有与所述第一网卡不同的MAC地址；所述第一POD网卡与所述第一网卡属于相同子网；所述方法包括：

所述第一网桥接收由所述第一POD网卡发送的第一ARP应答，将所述第一ARP应答的发起方MAC修改为所述第一虚拟网卡的MAC地址；所述第一ARP应答对应于第一请求方发送的第一ARP请求。

所述第一网桥通过所述第一虚拟网卡，接收由所述第一请求方向所述第一POD发送的第一请求，所述第一请求的接收方MAC为所述第一虚拟网卡的MAC地址、接收方IP为所述第一POD网卡的IP地址。

所述第一网桥将所述第一请求的接收方MAC修改为所述第一POD网卡的MAC地址。

本说明书第二方面提供了一种计算设备，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器执行所述计算机程序时，实现第一方面所述的方法。

根据本说明书实施例提供的方法，可以在仅具有单一网卡，无额外vLAN划分的宿主机节点之上，将POD网卡同时接入与宿主机节点网卡相同的经典网络，使得POD具备访问经典网络的能力，且不会劫持宿主机节点网卡的全部流量，保留宿主机网络的完整性与可运维性，无需对宿主机节点网卡上的监听或配置做任何改动。增加了K8s集群中通讯灵活性的同时，降低了运维复杂度。

附图说明

为了更清楚地说明本说明书实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为根据本说明书实施例提供的在K8s集群中进行网络通讯的实施框架示意图；

图2为根据本说明书实施例提供的网络组件交互框架示意图；

图3为根据本说明书实施例提供的网络拓扑示意图；

图4为根据本说明书实施例提供的一种在K8s集群中进行网络通讯的方法流程图；

图5为根据本说明书实施例提供的网络拓扑结构示意图；

图6为根据本说明书实施例提供的在多种组网方式下的K8s集群示意图。

具体实施方式

为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本说明书保护的范围。

目前在众多企业中，信息系统架构正逐步向云原生策略演进，从传统的单体应用到微服务架构，从单一实例的数据库到流式数据总线，越来越多的系统服务被分布式地部署在多地域、多可用区的云网络之中，形成跨云网络的混合部署形态。其中，系统服务可以是面向业务终端的微服务，也可以是依赖数据强一致性的分布式数据库服务，还可以是对数据同步延迟具有高要求的分布式消息队列服务等，本说明书实施例对此不做具体限定。

这些被部署在不同云网络中的系统服务，需要能够无缝、安全地跨越不同网络边界，进行高效通讯，以支持企业用户的异地双活、实时同步、弹性扩容等应用场景。

承前所述，作为云原生场景下，容器自动化调度及编排的事实标准，K8s通过声明式API和控制平面机制为容器化工作负载提供基础编排能力。然而，在面对日益复杂的企业组网需求时，K8s在多租户网络隔离、经典网络无缝接入、混合组网策略编排等多个方面存在局限，无法为用户提供高阶的网络虚拟化能力。

举例来说，在一些相关技术中，面向K8s集群的网络方案，允许用户通过K8s API-Server自定义VPC、vSwitch以及经典网络拓扑，并借助SDN技术将虚拟交换机(LogicalSwitch)、虚拟路由器(Logical Router)等抽象模型实例化，从而快速构建虚拟网络拓扑。其中，虚拟交换机(Open VirtualSwitch，OVS)负责数据面转发，虚拟网络(OpenVirtualNetwork，OVN)负责控制面编排。OVN/OVS网桥作为节点本地的转发平面，可以将POD、虚拟机、物理网卡以及隧道端口统一桥接，实现虚拟网络与经典网络的流量汇聚。

然而，上述相关技术所提出的技术方案，在实际部署中普遍存在以下几个方面的局限性：

1.经典网络部署受限：为了将POD直接接入宿主机所在物理网段，通常需要将宿主机的物理网卡整体桥接到OVS网桥内，此时，该物理网卡成为了OVS的一个端口，原有IP、路由、ARP、iptables等协议栈被旁路，管理流量也需要通过OVS流表或额外设备转发，配置复杂且容易中断节点管理网络。对于仅配备单块物理网卡的宿主机，同时承载控制面与数据面的管理，将面临网络隔离缺失、地址冲突风险，显著提高了部署门槛。

2.经典网络使用场景受限：使用经典网络的POD，其网卡需要接入该经典网络，被静态分配一个物理子网IP，并在Pod生命周期内持续占用，既不支持释放，也不支持在运行时修改。在云原生虚拟化场景中，大量的POD工作负载是虚拟机，接入经典网络的实质应该是虚拟机网卡，而非POD网卡。用户期望在虚拟机内部自行管理IP地址，而在相关技术中，将IP地址与POD强耦合，无法提供虚拟机网卡自定义等高阶虚拟网络功能。

3.网段定义受限：一方面，在相关技术中，通常为每个宿主机预先绑定一段固定的POD CIDR(POD IP地址段)，跨节点的网段不能重叠，因此无法为不同租户创建地址空间相同但彼此隔离的虚拟私有网络；另一方面，POD IP与宿主机节点强相关，使得POD因为发生故障等原因，被迁移到另一节点时必须更换地址，难以满足有状态服务、长连接、安全白名单等需要IP保持的场景需要。此外，相关技术中的控制面普遍缺乏集中式IP地址管理(IPAddress Management，IPAM)，导致跨节点地址冲突检测、网段重叠路由、VPC级别防火墙等高阶网络功能实现困难，阻碍了混合云、异构多租环境下的灵活组网与弹性扩容。

有鉴于此，发明人在本说明书实施例中提出了一种在Kubernetes集群中进行网络通讯的方法，可以集成OVN、OVS技术框架，为云原生工作负载提供高阶网络虚拟化能力，在K8s集群中，支持虚拟化网络与经典网络共存，并且可以在K8S集群中实现多租户隔离、经典网络接入、IP动态管理，本方法可以应用于不具备VLAN划分能力的K8s集群之中，进一步提升云原生虚拟化网络的灵活性和可扩展性。

为了更好的理解及说明本申请各实施例的方案，下面将首先对本申请实施例中所涉及到的一些技术用语进行简单说明。

在集群管理方面，K8s将集群中的机器划分为一个主节点(Master)和若干工作节点(Node)。其中，在Master节点运行着集群管理相关的一组进程，实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制等管理能力。Node作为集群中的工作节点，运行真正的应用程序，在Node上K8s管理的最小运行单元是Pod。Node上运行着K8s的kubelet、kube-proxy等服务进程，这些服务进程负责Pod的创建、启动、检测、重启、销毁以及实现软件模式的负载均衡器。

云原生：一种面向云计算环境的软件开发与架构设计理念，强调利用云平台的弹性、高可用性、分布式计算能力等特性，通过容器化、动态编排(如K8s)等技术，构建可扩展、复原能力强且易于维护的应用。云原生旨在充分发挥云环境的优势，提升系统的敏捷性和交付效率，同时支持快速演进和多租户部署。

软件定义网络(Software Defined Network，SDN)：一种网络架构方式，通过分离网络的数据平面和控制平面，实现网络的集中控制与灵活管理。传统网络设备(如交换机和路由器)将数据转发功能与控制逻辑紧密结合，而SDN则可以将控制逻辑从硬件中解耦，转移到可编程的集中式控制器。SDN的核心特点包括：

集中控制：网络中的控制平面由一个或多个控制器负责集中管理，能够提供全局视图、实现智能决策和动态资源调度。可编程性：通过开放的标准接口(如OpenFlow)，用户或开发者可以编程定义网络行为，无需依赖专用硬件。灵活性和自动化：通过软件对网络设备的行为进行动态配置，支持快速调整网络资源以满足需求。隔离数据平面和控制平面：数据平面负责转发流量，而控制平面负责路径计算等逻辑决策，从而提供更强的可控性。

虚拟私有网络VPC：一种逻辑隔离的虚拟网络架构，其核心是通过软件定义网络(SDN)技术在物理基础设施上构建用户专属的私有网络空间。

虚拟交换机(VirtualSwitch，vSwitch)：一种以软件形态运行的网络交换机，用于在虚拟化网络设备与经典网络之间转发和协调网络流量。vSwitch基于软件实现，可以模拟传统硬件交换机的功能。

经典网络：POD直接连接底层物理网络的网络架构。流量由物理交换机处理，一切网络配置依赖于物理基础设施。经典网络具有简单直连的特点，但网络拓扑扩展性和管理能力有限。

负载均衡：一种将网络或应用流量分发到多台服务器上的技术，优势是优化资源利用、提升性能、避免单点故障等。它可以通过硬件或软件实现，常用于高并发、大流量场景。

NAT网关：实现网络地址转换(NAT)的网关服务，用于虚拟私有网络和经典网络之间的IP地址映射，帮助虚拟私有网络设备通过一个经典网络IP访问底层物理网络(或被访问)，同时隐藏内部网络结构。

以上是对本申请实施例中所涉及到的一些技术用语进行的简要说明。下面将结合附图对本说明书实施例提出的方法进行详细介绍。

图1为根据一个实施例，示出的在Kubernetes集群中进行网络通讯的方法实施框架，基于“控制面-数据面分离”的网络拓扑构建，在K8s集群中同时提供虚拟网络与经典网络的通讯能力。整体来看，该实施例提出的网络架构可以划分为“北向接口层”、“控制面”、“分布式数据面”，三个逻辑层面。各层的组件及其之间的交互关系如下。

北向接口层：包括K8s组件API-Server。该组件作为集群配置、部署的统一入口，以CRD(Custom Resource Definition，自定义资源)方式向用户暴露网络模型中的网元。用户可以通过向API-Server组件提交配置文件(例如，YAML文件)，实现对K8s集群中网元的配置部署。本实施例提供的网络架构所能够支持的CRD模型，包括但不限于：虚拟私有网络VPC、虚拟交换机vSwitch、经典网络/Underlay描述ProviderNetwork、软件负载均衡LoadBalancer、经典网络IP资源EIP、用于描述IP映射关系的浮动IP资源FIP、SNAT网关NATGateway、防火墙规则ACL、各虚拟网元(或实例)所占有的IP地址InstanceIP。

控制面：工作于K8s集群层级，包括全局控制器、ovn-northd、ovnsb、ovnnb组件。其中，全局控制器作为K8s集群的核心控制模块，可以持续监听K8s集群中与CRD以及POD生命周期相关的事件。举例来说，全局控制器可以将CRD描述(部署语句)转换为北向数据库(ovnnb)中的对象，例如，虚拟交换机、虚拟路由器、NAT等。全局控制器还可以负责全局IP地址管理IPAM，避免跨节点网元IP地址冲突，并可以向多租户提供网段重叠的VPC网络。全局控制器还可以将各CRD配置结果写回POD Annotation或CR状态字段，供数据面使用。

控制面中包含的ovn-northd组件作为北向数据库(ovnnb)与南向数据库(ovnsb)之间的翻译组件，其可以监听ovnnb中的数据变更、解析北向数据，进行逻辑到物理的映射，生成南向数据并写入南向数据库。映射的内容可以例如：虚拟交换机转换为网桥和端口，访问控制列表转换为流表规则，等等。

分布式数据面：工作于分布式节点层级，包括节点控制器、CNI、ovn-controller、ovsdb、ovs-vswitchd组件。其中，节点控制器部署于各个节点，作为节点的守护进程，可以通过ovn-controller读取ovnsb，将流表、隧道封装、端口绑定等信息下发至本地OVS实例；同时将节点的状态数据回写至ovnsb，供控制面基于此状态数据执行高可用(HighAvailability，HA)调度。

数据面中包含的CNI组件可以将K8s的kubelet组件发起的CNI(二进制)调用事件，通过本地节点的unix socket转发至节点控制器进行处理。

数据面中包含的ovs-vswitch组件，可以负责流表的执行、隧道封装、解封等操作；ovsdb组件则保存有本地网桥、端口、QoS等配置信息，供ovn-contoller同步。

基于上述结构部署的网络系统架构可以实现如下的交互流程：参阅图2，在K8s集群中，用户可通过K8s命令行工具kubectl或UI界面，提交标准的K8s资源(例如，Pod)或扩展的自定义资源(CRD，例如VPC、vSwitch、经典网络等)，以声明其所需的网络拓扑和策略。K8sAPI-Server作为集群的单一部署入口组件，负责接收、验证并存储资源对象。参阅图2，具体的组件之间交互过程如下。

1.创建VPC、vSwitch、经典网络：用户向K8s API-Server提交自定义资源(CRD)对象，包括例如，VPC、vSwitch、ProviderNetwork等，完成网络拓扑的声明式定义。

2.监听VPC、vSwitch、经典网络创建/更新事件：部署在集群的全局控制器持续监听上述CRD的新增或删除事件，将用户意图转换为虚拟网络内部数据模型，并触发后续的SDN拓扑配置流程。

3.配置SDN拓扑：根据用户描述，全局控制器向ovnnb数据库中写入虚拟路由器、虚拟交换机、NAT规则、负载均衡器、ACL等对象，形成完整的虚拟网络拓扑。

4.SDN控制面配置下发至数据面：ovn-northd守护进程监听ovnnb中的数据变更，将逻辑对象翻译成流表匹配规则、隧道封装参数及端口绑定信息，写入ovnsb数据库，供节点侧控制器消费。

5.创建Pod用户向K8s API-Server提交标准的K8s资源(例如，Pod)部署配置，在其中指定所需的虚拟网络或经典网络。API-Server首先将该部署配置写入集群的后端数据库(etcd)，完成配置文件持久化；而后，API-Server将该部署事件广播给集群中各个控制器，其中kube-scheduler监听到有新Pod需要调度时，将会为其分配一个最合适的目标节点，并把目标节点的分配结果写回后端数据库(例如，更新Pod的spec.nodeName字段)。最后，目标节点上的kubelet组件监听到POD分配事件，即可执行POD创建相关动作，例如，下载镜像、创建容器、调用CNI等。

6.监听POD创建/更新事件、7.为POD网卡配置IP(分配、保持)、8.存储POD网卡IP配置结果：全局控制器监听到POD事件后，可以根据所选网络类型调用集中式IP地址管理IPAM，为POD网卡配置IP(支持新分配、保持等IP配置策略)，并将POD网卡配置结果写回API-Server。

9.监听本地节点POD创建事件：如前所述，运行在各节点的kubelet组件监听到POD分配事件、发现需要启动的新实例时，可以进入网卡实例化流程。

10.二进制调用：kubelet调用CNI组件，通过unix socket将CNI请求转发给同节点的节点控制器。

11.通过unix socket转发CNI请求：节点控制器收到CNI请求后，提取POD相关信息(例如，POD名称、网络类型、Annotation字段等)，准备执行POD网卡创建与数据面接入。

12.等待POD IP确认：节点控制器通过API-Server检查POD所对应的Annotation中的IP分配记录，确保全局IPAM已完成对POD的IP配置。

13.为POD配置网卡并接入数据面：为POD创建两个虚拟网卡(例如，veth pair)，主机端虚拟网卡加入网桥(可以为虚拟网络网桥br-int，或经典网络网桥br-pn)，对端虚拟网卡移入POD的网络命名空间(namespace)，从而POD可以对二层网络数据帧进行收发。为了可以将POD在接入虚拟网络的同时也接入经典网络，可以同步创建MacVLAN子接口并挂入经典网络网桥，配置流表规则，以实现单网卡同网段互通。该实施步骤将在下文给出详细阐述，此处不过多描述。此外，ovn-controller还可以将ovnsb中存储的规则推送至ovs-vswitchd，流表生效，完成控制面到数据面的端到端打通。

上文从网络组件角度给出了一个实施例中在Kubernetes集群进行网络通讯的方法实施框架，下面将从网络拓扑角度，阐述用于支持上述实施框架的网络架构。图3提供了一个实施例中的网络拓扑示意图，以K8s集群中的两个节点为例，节点1与节点2各自具有一张物理网卡eth0，分别连接至经典网络。

参阅图3，节点中的各个POD分别拥有独立的网络栈(图中以POD NS/Namespace示出)。任意节点均可为POD提供虚拟网络对应的网卡(图中以o-nic示出)、和/或经典网络对应的网卡(图中以u-nic示出)。OVN控制面能够在每个节点上部署一个网桥(OVS Bridge，图中以br-int示出)，网桥会将桥接于其上的网卡的流量交由内核流表(例如，OpenFlow流表)处理，实现精细化的流量控制与策略执行，其能力可以覆盖数据帧的二层转发、三层路由以及四层协议处理。如前所述，各个节点上的内核流表可以由控制面基于用户定义的网络拓扑结构进行配置，并下发至节点数据面，实现网络策略的集中式管理与分布式执行。

继续参阅图3，以虚线示出的数据链路为例，o-nic网卡接入br-int，纳入OVN管理。涉及跨POD的虚拟网络流量，可以通过geneve协议进行隧道封装、解包，实现不同节点或同节点内POD之间的虚拟网络数据交换。同时，可以基于POD所连接的虚拟交换机的相关信息构造隧道ID，在不同节点之间实现多租户虚拟网络的逻辑隔离，在同节点内实现虚拟交换机端口间的流量隔离。

继续参阅图3，以实线示出的数据链路为例，u-nic网卡接入br-int，纳入OVN管理。通过OVN的localnet port机制，流量从u-nic进入br-int后，被定向至专设的经典网络网桥br-pn。br-pn网桥负责为流量添加或剥离vLAN标签，并将其转发至对应的vLAN子接口(例如，图中示出的VLAN NIC)，最终通过节点的物理网卡eth0与经典网络进行数据交换。

根据上文描述可以知晓，为了在K8s集群内实现虚拟网络与经典网络共存的网络通讯，通常需要借助vLAN技术对网络流量进行逻辑隔离，从而在共享物理基础设施的前提下确保网络通讯的安全性与可控性。换言之，为了实现K8s集群内的虚拟网络与经典网络之间的互通，需要为POD额外规划一条二层网络通道，最简洁的做法是划分独立的vLAN。POD流量携带专属vLAN Tag进入交换机，而宿主机流量则继续沿用原先vLAN，从而在同一个经典网络链路上实现虚拟网络与经典网络的流量分离。

然而在生产实践中，由于成本限制或硬件支持不足，大多数K8s节点并不具备vLAN划分能力。当用户无法为节点划分出额外的vLAN，而POD网卡又需要与宿主机节点网卡处于同一物理子网时，依据前文介绍的相关技术所提供的方案，不得不将宿主机节点网卡直接桥接到该节点的OVS网桥(br-pn)，以借助OVN的localnet port让POD网卡MAC直接出现在节点所连接的网络中。此方式虽然能够使得POD网卡获得与宿主机节点网卡相同网段的IP地址，实现POD与经典网络之间的互通，但对于仅具备单一网卡的节点来说，流经节点网卡的所有流量均会被OVS网桥旁路，导致原先在节点网卡上配置的IP地址、路由规则、安全策略等网络设置失效，需在OVS网桥层面重新配置，增加了运维复杂度。

有鉴于此，发明人基于上述网络拓扑架构，在本说明书实施例中提出了一种网络通讯方法，可以在单网卡节点上，无需vLAN划分即可实现POD网卡与宿主机节点网卡在同一子网中通讯，可以使得POD具备访问经典网络的能力，同时保留宿主机网络的完整性与可运维性，从而解决前文所提及的相关技术中“经典网络部署受限”问题。

图4示出了根据一个实施例提供的一种在Kubernetes集群中进行网络通讯的方法流程图。可以理解，该方法可以通过任何具有计算、处理能力的装置、设备、平台、设备集群来执行。

参阅图4，所述集群中的第一节点部署有第一POD、第一网桥以及第一网卡，所述第一网卡属于第一物理网络。第一网桥可以由OVS网桥br-int、br-pn组成，参照前文的介绍可知，所述第一网桥可以通过虚拟交换机、虚拟路由，或二者组合实现；经由第一网桥的所有转发动作可以基于自定义的流表规则完成，无需经过操作系统协议栈。

在云原生领域，经典网络通常指的是云计算环境中一种传统的、多租户共享的扁平化网络模型，其核心特征在于通过统一的网络地址空间为工作负载提供自动化、免配置的网络接入能力。在下文中将以物理网络作为经典网络的一种选型，对各个实施例做简要介绍，然而需知晓，物理网络仅是经典网络在底层硬件直连场景中的一种具体实现形态，并不代表是对本发明方法应用场景的一种限定。在具体实践中，凡是具备经典网络与虚拟网络的K8s集群，均可应用本说明书实施例所提供的方法，在Kubernetes集群中安全、高效地实现虚拟网络与经典网络的互通。

所述第一网桥与所述第一POD对应的第一POD网卡以及第一虚拟网卡相连接，所述第一虚拟网卡基于所述第一网卡生成，具有与所述第一网卡不同的MAC地址；所述第一POD网卡与所述第一网卡属于相同子网。在一个优选的实现方式中，第一虚拟网卡可以是基于第一网卡生成的macVLAN子设备。

macVLAN是一种网卡虚拟化技术，由操作系统内核实现。其可以在一个物理网卡上虚拟出多个虚拟网卡，每个虚拟网卡具有独立的MAC地址，并能够与物理网卡所连接的其他网络设备进行通讯。需要知晓的是，macVLAN不同于vLAN，vLAN是一种在交换机层面实现的二层网络隔离技术，用于将一个物理局域网划分为多个逻辑广播域，各vLAN之间在二层网络上无法直接通讯，需要借助路由器或交换机实现互通；而macVLAN则是在节点内部实现的网卡虚拟化，不依赖于交换机的vLAN功能。

在该实施例中，可以将基于第一网卡创建的第一虚拟网卡接入第一网桥中的br-pn，实现物理网络与虚拟网络中POD的连通。由于第一虚拟网卡可以直接承载物理网络流量，并通过第一网桥的流表规则动态修改数据帧的头信息，从而可以在不依赖额外vLAN划分、且无需将第一网卡桥接至第一网桥的情况下，通过二层ARP欺骗与数据帧修改机制，实现虚拟网络中POD与物理网络中其他网络设备的通讯。下面将结合图4，对一个实施例中提出的该方法各个步骤进行详细阐述。

步骤S401，所述第一网桥接收由所述第一POD网卡发送的第一ARP应答，将所述第一ARP应答的发起方MAC修改为所述第一虚拟网卡的MAC地址；所述第一ARP应答对应于第一请求方发送的第一ARP请求。

在网络通讯过程中，当请求方需要向接收方发送数据包时，需要获知接收方的MAC地址。通常，请求方会通过广播方式在本地二层网络中发送ARP请求报文，查询接收方IP地址所对应的MAC地址。在该步骤中，当第一请求方尚未知晓第一POD网卡的MAC地址时，可以广播发送第一ARP请求。由于ARP请求是广播帧，同一广播域内的所有设备(包括第一POD网卡)均会收到该ARP请求。所述第一POD网卡在收到第一ARP请求后，识别其中的接收方IP地址与自身相符，因此可以构造并发送第一ARP应答。在该应答报文中，发起方(Sender)MAC地址字段被填充为所述第一POD网卡自身的MAC地址。

第一网桥作为网络流量的拦截和代理组件，捕获到所述第一ARP应答后，可以将其发起方MAC修改为所述第一虚拟网卡的MAC地址。在具体的实践中，上述修改动作可以通过流表匹配来实现。修改后的第一ARP应答通过第一网桥中的br-int送至br-pn，进而通过第一网卡发往所述第一请求方。如此，所述第一请求方能够在其ARP缓存中对第一ARP应答进行记录，将所述第一POD网卡的IP地址所对应的MAC地址，记录为所述第一虚拟网卡的MAC地址。也就是说，此后当所述第一请求方需要与第一POD进行通讯时，可以根据ARP缓存表，构造数据帧，其中的接收方(Destination)MAC为所述第一虚拟网卡的MAC地址，而接收方IP仍为所述第一POD网卡的IP地址。

通过上述处理之后，后续由所述第一请求方向第一POD发出的单播报文不再会因为MAC地址查找失败而被丢弃，从而在二层网络中实现了ARP欺骗。

接下来，在步骤S403，所述第一网桥通过所述第一虚拟网卡，接收由所述第一请求方向所述第一POD发送的第一请求，所述第一请求的接收方MAC为所述第一虚拟网卡的MAC地址、接收方IP为所述第一POD网卡的IP地址。

在该步骤中，所述第一请求方基于之前记录的IP-MAC映射关系，构造并发出了发往第一POD的第一请求。所述第一请求在传输过程中，因其接收方MAC指向所述第一虚拟网卡，最终会被第一网桥通过对应的虚拟网卡(所述第一虚拟网卡)接收(基于二层MAC地址匹配)。

随后，执行步骤S405，所述第一网桥将所述第一请求的接收方MAC修改为所述第一POD网卡的MAC地址。

第一网桥可以识别出所述第一请求的接收方IP地址对应于连接在该网桥另一个端口上的第一POD网卡。因此，为了确保所述第一请求能够被正确送至接收方，所述第一网桥可以修改所述第一请求的头信息，将接收方MAC字段值从第一虚拟网卡的MAC地址，修改为所述第一POD网卡的MAC地址。修改完成后，第一网桥能够通过相应的端口，将修改后的第一请求转发给所述第一POD网卡。

如此，对于第一POD而言，其可接收到一个来自第一物理网络的符合标准以太网协议、接收方MAC为自身MAC的正常数据包，从而实现了物理网络与虚拟网络之间的互通。

除了上述实施例中进行处理的两类数据包之外，所述第一网桥还可对其他类型的数据包进行处理。

根据一种实现方式，所述第一网桥接收由所述第一POD网卡发送的第二ARP请求，可以将所述第二ARP请求的发起方MAC以及sha字段值，修改为所述第一虚拟网卡的MAC地址。

所述第二ARP请求可以是第一POD主动探测同子网其他网络设备的MAC地址，而发出的ARP请求。所述第一网桥可以解析所述第二ARP请求报文，并将其中的发起方MAC地址和sha字段的值，修改为所述第一虚拟网卡的MAC地址。随后，所述第一网桥可以经由第一网卡发出修改后的第二ARP请求报文。如此，接收第二ARP请求的网元得到的发送方MAC地址为所述第一虚拟网卡的MAC地址，可以确保后续回复的ARP应答可被单播送至所述第一虚拟网卡。

根据一种实现方式，所述第一网桥通过所述第一虚拟网卡，接收由第二请求方向所述第一POD发送的第二ARP应答，可以将所述第二ARP应答的接收方MAC以及tha字段值，修改为所述第一POD网卡的MAC地址。

所述第一网桥可以解析该ARP应答报文，并将其中的接收方MAC地址和tha字段的值，修改为最初发起对应ARP请求的所述第一POD网卡的MAC地址。修改后的第二ARP应答报文可通过第一网桥发送至所述第一POD网卡，实现正确的二层网络转发，避免因接收方MAC不匹配而丢弃报文。

综上所述，第一网桥所执行的流表规则可以归纳如下：

针对由第一POD向外发出的数据流量，可以将其发起方MAC修改为第一虚拟网卡的MAC地址，经由宿主机节点的第一网卡发出，这样可以保证后续的应答数据流量能够以所述第一虚拟网卡的MAC作为接收方MAC，从而进行正确的二层转发处理。

针对由第一请求方向第一POD发送的数据流量，可以将其接收方MAC修改为第一POD网卡的MAC地址，这样可以保证该数据流量经由第一虚拟网卡、第一网桥处理之后，能够被路由到第一POD网卡。

由此，在仅具有单一网卡，无额外vLAN划分的宿主机节点之上，也可以将POD网卡同时接入与宿主机节点网卡相同的物理网络，且不会劫持宿主机节点网卡的全部流量，因此无需对宿主机节点网卡上的监听或配置做任何改动。增加了K8s集群中通讯灵活性的同时，降低了运维复杂度。

上文详细阐述了在K8s集群中，实现虚拟网络与经典网络互通的方法。回顾前文分析的相关技术局限性，在本说明书其他实施例中，还基于上述网络拓扑架构，给出了能够解决前文所提及的“经典网络使用场景受限”问题的方法，可以解耦IP地址与POD生命周期的强绑定关系，并通过网卡模型抽象实现虚拟机工作负载的自主网络管理。

回顾前文所提及的“经典网络使用场景受限”问题：相关技术中，会将经典网络IP地址与POD生命周期绑定，每个接入经典网络的POD网卡被静态分配经典网络子网IP，且无法在运行时进行释放或修改。这种POD与IP强绑定的设计严重制约了云原生虚拟化场景的灵活性。例如，当工作负载为虚拟机时，用户实际需要管理的是虚拟机网卡而非POD网卡，期望在虚拟机内自主控制IP配置，然而相关技术将IP与POD强绑定，剥夺了虚拟机层面的网络自治权。

为解决这一技术问题，基于前文所给出的网络拓扑架构，当所述第一POD上运行的工作负载为虚拟机(第一虚拟机)时，可以在所述第一虚拟机中创建第一虚拟机网卡，作为所述第一POD网卡；所述第一虚拟机网卡的IP地址通过所述第一虚拟机进行配置。

具体来说，为了解耦IP地址与POD的绑定关系，可以在第一虚拟机中创建独立于第一POD的网卡模型(即第一虚拟机网卡)，该网卡模型与POD形成关联关系(可以作为第一POD的网卡在K8s集群中使用)，但剥离IP强制绑定属性。换言之，用户可通过声明式API显式定义第一虚拟机网卡，并跳过IP地址分配(例如，设置其IP分配策略为null，使得IP地址管理服务自动跳过该网卡的IP地址分配)。从控制面来说，K8s组件不再强制为第一虚拟机网卡注入IP配置，而是仅建立链路层(二层网络)连接。从数据面来说，用户可在第一虚拟机内部，通过标准网络命令(例如，ip、ipconfig、route)按需配置第一虚拟机网卡的IP地址、子网掩码及路由规则。

应用上述方法，当用户创建接入K8s集群的虚拟机POD时，集群可以仅为其提供网卡设备通道，而不自动分配IP地址。用户可在虚拟机启动后，根据具体需求自由配置该网卡设备的IP地址(可以通过诸如DHCP自动获取或静态指定)，并在虚拟机运行过程中随时修改网络参数而无需重建POD，既保留了POD对虚拟网络及经典网络的连通性，又赋予了虚拟机与宿主节点同等的网络自治能力，可以为云原生虚拟化场景提供更高的灵活性。

继续回顾前文分析的相关技术局限性，在本说明书其他实施例中，还基于上述网络拓扑架构，给出了能够解决前文所提及的“网段定义受限”问题的方法，可以在保持K8s集群网络隔离性的前提下，为不同租户提供可用于分配的重叠的IP地址空间，并确保POD在跨节点故障迁移、弹性伸缩、热迁移等场景下，具有长期持有同一IP的能力，从而满足有状态服务、长连接、安全白名单等高阶网络需求。

回顾前文所提及的“网段定义受限”问题：相关技术中普遍采用基于节点划分子网的组网策略，即为每台宿主机节点预先绑定固定的POD CIDR(节点上POD的IP地址与节点强相关)，跨节点网段不允许重叠，导致不同租户无法拥有相同地址段的VPC。同时，由于PODIP与宿主机节点强耦合，POD一旦被调度到其他宿主机节点，就必须更换IP地址，从而造成有状态应用中断、防火墙规则失效、许可证绑定失效等一系列问题。此外，K8s集群缺乏集中式IP地址管理(IPAM)，使得跨节点冲突检测、重叠网段路由、VPC级分布式防火墙等能力难以实现，直接阻碍了混合云、异构多租环境下的灵活组网与弹性扩容。

为解决这一技术问题，基于前文所给出的网络拓扑架构，在控制面，可以为各个VPC均对应创建一个虚拟路由进行管理，在虚拟路由上可以连接若干虚拟交换机，各个虚拟交换机均对应于一个二层广播域(子网)。虚拟路由可以对内部各虚拟交换机之间的路由做出选择，并执行用户自定义的静态或策略路由规则。虚拟交换机可以响应针对其上所桥接的网络设备的ARP请求，并维护MAC地址与交换机端口的映射关系。属于该VPC网络的各个POD所对应的POD网卡可以桥接到虚拟交换机上，例如：使用经典网络的POD网卡，可以桥接到underlay虚拟交换机之上；使用虚拟网络的POD网卡可以桥接到overlay虚拟交换机之上。此外，各个VPC所对应的虚拟路由还可以连接到若干虚拟网关路由，虚拟网关路由可以作为虚拟路由的默认路由出口，维护NAT规则、CT状态等。上述网络拓扑结构示意可以参阅附图5，下面将仍然以前文所例举的K8s集群中第一节点及其上第一POD为例，结合多个实施方式对应用该网络拓扑的K8s集群进行详细阐述。参阅图6，示出了多种组网方式下的K8s集群示意图。

根据一种实现方式，所述第一节点还部署有第二POD；所述第一POD网卡属于第一子网，连接至第一虚拟交换机；所述第二POD对应的第二POD网卡属于第二子网，连接至第二虚拟交换机。根据该实现方式，可以在第一节点中同时部署分属于不同子网的POD，使用虚拟交换机实现网络隔离。在一种实践中，可以获取所述第一/第二POD网卡各自连接的第一/第二虚拟交换机的标识，作为各自对应的隧道ID，分别用于对所述第一/第二POD网卡执行基于第一传输协议的数据交换。举例来说，可以提取各虚拟交换机的标识信息(例如，UUID)，作为隧道ID，基于第一传输协议封装在数据报文的VNI(头信息)，此时即使两个POD位于同一节点，其流量也能够因不同的隧道ID而被严格隔离，从而实现同节点内不同子网POD间的逻辑隔离通信。典型的，上述第一传输协议可以为以下中的一种：VxLan协议、Geneve协议。

根据一种实现方式，所述集群还包括第二节点，所述第二节点部署有第三POD；所述第三POD对应的第三POD网卡与所述第一POD网卡属于相同子网；可以将所述第三POD网卡与所述第一POD网卡连接至同一虚拟交换机。该实现方式对应于跨节点组网场景，当第二节点部署的第三POD需与第一POD同子网通信时，系统可以将第三POD网卡与第一POD网卡接入同一虚拟交换机。该方法可以使不同节点中的POD形成统一的广播域，通过虚拟交换机直接进行二层通信，避免跨三层转发而带来的性能损耗。

根据一种实现方式，所述集群还包括第四POD，所述第四POD对应的第四POD网卡与所述第一POD网卡属于不同子网，且属于相同虚拟云网络；可以将所述第一POD网卡连接至第三虚拟交换机，将所述第四POD网卡连接至第四虚拟交换机；将所述第三虚拟交换机与所述第四虚拟交换机连接至第一虚拟路由。也就是说，若第四POD与第一POD属于不同子网但同属一个虚拟云网络(例如，租户的VPC)，可以将二者网卡分别连接至独立的第三、第四虚拟交换机，并将这两台虚拟交换机接入同一虚拟路由器。该虚拟路由器可以自动学习子网间路由策略，实现跨子网流量互通，同时还可以通过虚拟路由器实施租户级安全隔离与NAT转换。

此外，为了实现集群内IP地址的统一管理与全局协调，可以在K8s集群中部署中枢化的IP资源池，对集群中的所有IP资源进行统一分配、跟踪与回收。所述IP资源池在集群层面维护全局地址状态，可以有效避免IP地址冲突并支持重叠网段场景下的多租户隔离。

根据一种实现方式，在第一POD创建时，可以基于所述IP资源池，根据IP地址分配策略，为第一POD网卡动态分配IP地址；当第一POD因节点故障或资源调度而迁移至新节点时，通过所述IP资源池，可以将其原IP地址保留，并在第一POD迁移完毕后，恢复其原IP地址，使得第一POD可以在跨节点迁移过程中保持IP地址不变，从而有效支持有状态服务、长连接会话及基于IP的白名单访问等需要固定IP地址的场景，从而保障系统服务的运行连续性；当第一POD删除时，其IP地址可以被释放并自动回收至所述IP资源池，实现IP地址资源的循环利用，提高IP地址的整体利用率和集群的可扩展性。

本说明书中，第一节点、第一POD等词语中的“第一”，以及文中相应的“第二”、“第三”(如果存在)等，仅仅是为了区分和描述方便，并不具有任何限定意义。

上述内容对本说明书的特定实施例进行了描述，其他实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行，并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要按照示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的，或者可能是有利的。

本说明书实施例中还提供了一种计算设备，包括存储器和处理器，所述存储器中存储有计算机程序/指令，所述处理器执行所述计算机程序/指令时，实现前述各个实施例中的方法。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(CornellUniversity Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为服务器系统。当然，本申请不排除随着未来计算机技术的发展，实现上述实施例功能的计算机例如可以为个人计算机、膝上型计算机、车载人机交互设备、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

虽然本说明书一个或多个实施例提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或终端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境，甚至为分布式数据处理环境)。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下，并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。例如若使用到第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书一个或多个时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

本发明是参照根据本发明实施例的方法、装置(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储、石墨烯存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

本领域技术人员应明白，本说明书一个或多个实施例可提供为方法、系统或计算机程序产品。因此，本说明书一个或多个实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书一个或多个实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本说明书一个或多个实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书一个或多个实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

以上所述仅为本说明书一个或多个实施例的实施例而已，并不用于限制本说明书一个或多个实施例。对于本领域技术人员来说，本说明书一个或多个实施例可以有各种更改和变化。凡在本说明书的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在权利要求范围之内。

Claims (10)

1.一种在Kubernetes集群中进行网络通讯的方法，所述集群中的第一节点部署有第一POD、第一网桥以及第一网卡，所述第一网卡属于第一物理网络；所述第一网桥与所述第一POD对应的第一POD网卡以及第一虚拟网卡相连接，所述第一虚拟网卡基于所述第一网卡生成，具有与所述第一网卡不同的MAC地址；所述第一POD网卡与所述第一网卡属于相同子网；所述方法包括：

所述第一网桥接收由所述第一POD网卡发送的第一ARP应答，将所述第一ARP应答的发起方MAC修改为所述第一虚拟网卡的MAC地址；所述第一ARP应答对应于第一请求方发送的第一ARP请求；

所述第一网桥通过所述第一虚拟网卡，接收由所述第一请求方向所述第一POD发送的第一请求，所述第一请求的接收方MAC为所述第一虚拟网卡的MAC地址、接收方IP为所述第一POD网卡的IP地址；

所述第一网桥将所述第一请求的接收方MAC修改为所述第一POD网卡的MAC地址。

2.根据权利要求1所述的方法，还包括：

所述第一网桥接收由所述第一POD网卡发送的第二ARP请求，将所述第二ARP请求的发起方MAC以及sha字段值，修改为所述第一虚拟网卡的MAC地址；或者，

所述第一网桥通过所述第一虚拟网卡，接收由第二请求方向所述第一POD发送的第二ARP应答，将所述第二ARP应答的接收方MAC以及tha字段值，修改为所述第一POD网卡的MAC地址。

3.根据权利要求1所述的方法，其中，所述第一网桥通过虚拟交换机，和/或虚拟路由实现。

4.根据权利要求1所述的方法，其中，所述第一POD上运行有第一虚拟机；所述方法还包括：

在所述第一虚拟机中创建第一虚拟机网卡，作为所述第一POD网卡；所述第一虚拟机网卡的IP地址通过所述第一虚拟机进行配置。

5.根据权利要求1所述的方法，其中，所述第一节点还部署有第二POD；所述第一POD网卡属于第一子网，连接至第一虚拟交换机；所述第二POD对应的第二POD网卡属于第二子网，连接至第二虚拟交换机。

6.根据权利要求5所述的方法，还包括：

获取所述第一/第二POD网卡各自连接的第一/第二虚拟交换机的标识，作为各自对应的隧道ID，分别用于对所述第一/第二POD网卡执行基于第一传输协议的数据交换；所述第一传输协议为以下中的一种：VxLan协议、Geneve协议。

7.根据权利要求1所述的方法，其中，所述集群还包括第二节点，所述第二节点部署有第三POD；所述第三POD对应的第三POD网卡与所述第一POD网卡属于相同子网；所述方法还包括：

将所述第三POD网卡与所述第一POD网卡连接至同一虚拟交换机。

8.根据权利要求1所述的方法，其中，所述集群还包括第四POD，所述第四POD对应的第四POD网卡与所述第一POD网卡属于不同子网，且属于相同虚拟云网络；所述方法还包括：

将所述第一POD网卡连接至第三虚拟交换机，将所述第四POD网卡连接至第四虚拟交换机；

将所述第三虚拟交换机与所述第四虚拟交换机连接至第一虚拟路由。

9.根据权利要求1所述的方法，其中，所述集群还包括IP资源池；所述方法还包括：

在所述第一POD创建时，通过所述IP资源池向所述第一POD网卡分配IP地址；

在所述第一POD迁移时，通过所述IP资源池为所述第一POD网卡保留IP地址；

在所述第一POD删除时，通过所述IP资源池回收所述第一POD网卡的IP地址。

10.一种计算设备，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器执行所述计算机程序时，实现权利要求1-9中任一项所述的方法。