NSX 4.1 开始,您可以使用动态成员资格条件中的 Kubernetes 成员类型创建通用组,以匹配流入或流出 Antrea Kubernetes 集群的流量。

然后,可以在分布式防火墙规则或网关防火墙规则中使用这些通用组来保护 NSX 环境中的虚拟机与 Antrea Kubernetes 集群中的 Pod 之间的流量。

重要说明: 在多租户 NSX 环境中,Kubernetes 集群资源不会向项目清单公开。因此,在项目中,您无法使用动态成员资格条件中的 Kubernetes 成员类型创建通用组。您必须在 NSX默认视图(默认空间)中创建组,然后在默认空间下的分布式防火墙规则或网关防火墙规则中使用这些组。

保护从 Antrea Kubernetes 集群流向 NSX 中的虚拟机的流量

要匹配从 Antrea Kubernetes 集群流向 NSX 的流量,可以在防火墙规则中添加基于以下 Kubernetes 成员类型(资源)的通用组:
  • Kubernetes 节点
  • Antrea Egress
  • Antrea IP 池

下图显示了从 Antrea Kubernetes 集群流向 NSX 逻辑网络中的虚拟机的典型流量流。


在周围文本中对该图进行了说明。

正如此流量流图中所示,为了匹配流出 Antrea Kubernetes 集群的流量,可能会出现以下场景:

场景 1:通过 Egress(网关节点)的 SNAT

您可以在 Antrea Kubernetes 集群中部署 Egress 资源。在 Egress 资源的清单文件中,选择要将 Egress 资源应用到的 Pod 的分组条件。您可以在清单文件中手动指定 Egress IP,或者 Antrea CNI 可以从 ExternalIPPool 自定义资源分配 Egress IP。

重要说明: Egress IP 地址必须在物理网络上可路由,并且必须可从 K8s 集群中的所有节点访问。

Antrea CNI 会将来自选定 Pod 的出站流量发送到网关节点。网关节点执行源地址转换 (SNAT),以将源 IP (Pod IP) 转换为 Egress IP。

例如,在上述流量流图中,来自节点 1 上运行的 Pod1 和 Pod2 的出站流量将被发送到网关节点。网关节点将 Pod IP 地址转换为 Egress1 IP。

要了解有关 Egress 资源的更多信息,请参见 Antrea 文档门户中的《Egress 指南》

可用作网关节点的集群节点取决于节点网络拓扑,该拓扑由物理网络管理员或 IaaS 网络管理员控制。网关节点具有以下两个特性:
  • 物理网络允许节点将可路由 IP 作为用于访问外部网络的源 IP。
  • (可选)将物理网关上的物理防火墙配置为筛选来自网关节点的出站流量。
请考虑以下示例:
  • 示例 1:假设您的 Antrea Kubernetes 集群具有三个节点:node1、node2 和 node3。集群中的 node1 和 node2 是特殊节点,因为它们分配有两个网络接口:一个接口用于 K8s 集群通信,另一个接口用于连接到外部网络。node3 只分配有一个网络接口,用于集群通信。在此场景中,只能将 node1 和 node2 用作网关节点。
  • 示例 2:假设 K8s 集群中的所有三个节点都只分配有一个网络接口,并且网络管理员已将物理防火墙配置为仅允许 node1 和 node2 MAC 地址访问 Internet。在此场景中,可以将 node1 和 node2 用作网关节点。
  • 示例 3:假设所有三个节点均可访问 Internet。网络管理员已在物理网关上配置了物理防火墙,并且防火墙要筛选来自特定 Egress IP 的流量。在此场景中,所有三个节点均可用作网关节点。

以下段落介绍了特定于实施的限制:

Antrea Kubernetes 集群外部的任何物理主机或虚拟机都不能用作通过隧道传输 Pod 出站流量的网关节点。其原因是,Antrea 代理 会维护 Egress IP 地址,并且此代理在 K8s 集群的每个节点上作为 Pod 运行。因此,要用作网关节点的物理主机或虚拟机必须是 K8s 集群的一部分。

场景 2:通过节点的 SNAT

在此场景中,并没有在任何 Egress 资源的清单文件中明确选择 Pod。

Pod 的出站流量会伪装到节点 IP,然后将流量发送到 IaaS 网络。例如,在上述流量流图中,SNAT 规则会将源 IP(Pod3 IP、Pod4 IP)转换为节点 2 IP,然后将 Pod 的出站流量发送到 IaaS 网络。

场景 3:可路由 Pod 直接桥接到 IaaS 网络

可路由 Pod 表示在底层网络上为 Pod 分配了可路由 IP 地址。通常,可以从节点上配置的 PodCIDR 属性为 Pod 分配专用 IP 地址。当 Pod 想要访问 K8s 集群外部的网络时,流量需要执行 SNAT 操作以将源 IP (Pod IP) 转换为可路由 IP。

如果您的 Antrea Kubernetes 集群部署在具有 Tanzu Kubernetes Grid Service (TKGS) 的 NSX 覆盖网络上,则会有一种机制可供 Tanzu Kubernetes 集群 (TKC) 节点从 NSX 请求可路由子网,并将此可路由子网用作节点的 PodCIDR 属性。然后,Pod 将能够获取可路由的 IP 地址。要了解有关为 TKC 配置可路由 Pod 网络的更多信息,请参见 VMware vSphere with Tanzu 文档。

如果您的 Antrea Kubernetes 集群未部署在 NSX 覆盖网络上,Kubernetes 管理员可以确保在底层网络中预留可路由子网或可路由 IP 范围。管理员可以在 IPPool 自定义资源的清单文件中配置子网或 IP 范围。然后,Antrea CNI 可以将可路由 IP 地址分配给 Pod。

例如,在上述流量流图中,在节点 5 上运行的 Pod5 会从 IPPool 自定义资源获取可路由 IP。

要了解有关 IPPool 自定义资源的更多信息,请参见 Antrea 文档门户中的《Antrea IPAM 指南》

保护从 NSX 中的虚拟机流向 Antrea Kubernetes 集群的流量

要匹配从 NSX 流向 Antrea Kubernetes 集群的流量,可以在防火墙规则中添加基于以下 Kubernetes 成员类型(资源)的通用组:
  • Kubernetes 服务
  • Kubernetes Ingress
  • Kubernetes Gateway
  • Antrea IP 池

下图显示了从 NSX 逻辑网络中的虚拟机流向 Antrea Kubernetes 集群的典型流量流。


在周围文本中对该图进行了说明。

正如此流量流图中所示,为了匹配流入 Antrea Kubernetes 集群的流量,可能会出现以下场景:

场景 1:通过虚拟 IP 和端口向外部流量公开 Pod
您可以使用以下本机 Kubernetes 资源实施第三方负载均衡器解决方案,从而向外部流量公开 Pod:
  • Ingress:用作 L7 负载均衡器。Ingress 资源将提供虚拟 IP 地址 (VIP),并公开某些端口 (TCP/UDP)。
  • 网关:用作 L4 和 L7 负载均衡器。网关资源将提供 VIP,并公开某些端口 (TCP/UDP)。
  • LoadBalancer 类型的服务:用作 L4 负载均衡器。该服务将提供 VIP,并公开某些端口 (TCP/UDP)。
注: 尽管 Ingress 和网关资源可以用作 L7 负载均衡器,但对于 NSX 中的分布式防火墙规则和网关防火墙规则,它们通过使用 IP 地址和端口与入站流量匹配,从而显示为 L3 或 L4 负载均衡器。
场景 2:通过节点 IP 和端口向外部流量公开 Pod
  • 类型为 NodePort 的 Kubernetes 服务:该服务会触发 K8s 集群中的所有节点,以在节点上为每个服务端口打开一个端口。该服务可以通过节点 IP 和端口进行访问。节点会对流量执行 SNAT 和 DNAT。
  • 类型为 ClusterIP 且启用了 NodePortLocal 功能的 Kubernetes 服务:该服务要求您在 Antrea 代理 上启用 NodePortLocal 功能,并在 Kubernetes 服务的清单文件中添加注释。Antrea CNI 可以识别注释,并为运行 Pod 的节点上的每个 Pod 打开一个端口。NodePortLocal 会避免在 K8s 集群的所有节点上打开端口,从而节省可用的端口范围。它还会避免执行 SNAT 操作,并保留原始客户端 IP。

    要了解有关 NodePortLocal 功能的更多信息,请参见 Antrea 文档门户中的《NodePortLocal 指南》

场景 3:通过可路由 Pod IP 地址向外部流量公开 Pod

Antrea 支持在 Antrea Kubernetes 集群中部署 IPPool 自定义资源,从而将可路由 IP 地址分配给 Pod。Pod 从此池中分配 IP 地址,并直接桥接到 IaaS 网络。

支持的 IaaS 网络

可以在以下 IaaS 平台上部署 Antrea Kubernetes 集群:
  • 基于 vSphere 的内部部署数据中心:作为 Tanzu Kubernetes 集群,它们是使用 Tanzu Kubernetes Grid Service 创建的。集群由 Tanzu Kubernetes Grid (TKG) 2.0 和 vSphere 管理。
  • VMware Cloud:作为 Tanzu Kubernetes 集群,由 TKG 2.0 和 VMC SDDC 管理。
  • 公有云:作为公有云平台上的受管 Kubernetes 集群。
  • 物理服务器:作为裸机服务器上的 Kubernetes 集群。
  • OpenShift:
    • Antrea CNI 部署在 OpenShift 集群中,而 OpenShift 则在安装程序置备的基础架构 (Installer Provisioned Infrastruture, IPI) 模式或用户置备的基础架构 (User Provisioned Infrastructure, UPI) 模式下部署。
    • 基础架构提供程序可以是以下任何一种:vSphere、Amazon Web Services (AWS)、Azure、OpenStack、Google Cloud Platform (GCP)、裸机。
重要说明: IaaS 网络负责 Antrea Kubernetes 集群和虚拟机之间的流量。不同站点(例如内部部署数据中心、VMC 和公有云)之间的流量可能涉及特定于 IaaS 的 VPN。在所有情况下,IaaS 网络都可能应用 SNAT 操作。 NSX 管理员必须确保源或目标 IP 地址可路由,以便可以在防火墙规则中使用这些地址来保护虚拟机和 Kubernetes 集群之间的流量。

应用防火墙策略的建议方法

分布式防火墙和网关防火墙都允许您在防火墙规则的源和目标中指定使用 Kubernetes 成员类型的通用组。因此,您可以灵活地决定是引用分布式防火墙中的组,还是网关防火墙中的组。

VMware 提供以下建议:
  • 使用 NSX 网关防火墙可允许或阻止从 Antrea Kubernetes 集群流向 NSX 网络中的虚拟机的流量。

    此方法可帮助您在流量流入 NSX 覆盖网络时尽早筛选流量。

  • 使用 NSX 分布式防火墙可允许或阻止从 NSX 网络中的虚拟机流向 Antrea Kubernetes 集群的流量。

    此方法可帮助您在流量流出 NSX 覆盖网络中的虚拟机时尽早筛选流量。

在防火墙策略中使用 Kubernetes 成员类型的摘要

下表汇总了可以在 NSX 通用组中用于匹配防火墙规则中流量的 Kubernetes 成员类型。

成员类型 范围 在防火墙策略中的使用情况

Kubernetes 集群

集群

在动态组成员资格条件中显示为 AND 条件,以匹配特定集群中的资源。

Kubernetes 命名空间

命名空间

在动态组成员资格条件中显示为 AND 条件,以匹配特定命名空间中的资源。

Antrea Egress

集群

匹配来自 Antrea Kubernetes 集群的出站流量,其中源 IP = Egress IP

Antrea IP 池

集群

匹配来自 Antrea Kubernetes 集群的出站流量,其中源 IP 在 IP 范围内。

匹配流入 Antrea Kubernetes 集群的流量,其中目标 IP 在 IP 范围内。

Kubernetes 节点

集群

匹配来自 Antrea Kubernetes 集群的出站流量,其中源 IP 位于集群节点 IP 地址中。

Kubernetes Ingress

命名空间

匹配流入 Antrea Kubernetes 集群的流量,其中目标 IP 位于 Ingress IP 地址中。

Kubernetes Gateway

命名空间

匹配流入 Antrea Kubernetes 集群的流量,其中目标 IP 位于网关 IP 地址中。

Kubernetes 服务(类型=LoadBalancer)

命名空间

匹配流入 Antrea Kubernetes 集群的流量,其中目标 IP 位于 LoadBalancer IP 地址中。

Kubernetes 服务(类型=NodePort)

命名空间

匹配流入 Antrea Kubernetes 集群的流量,其中目标 IP + 端口位于节点 IP 地址 + NodePort 范围内。

Kubernetes 服务(类型=ClusterIP)

命名空间

Kubernetes 服务(类型=ClusterIP)且启用了 NodePortLocal 功能

命名空间

匹配流入 Antrea Kubernetes 集群的流量,其中目标 IP + 端口位于节点 IP 地址 + NodePortLocal 范围内。