为 Red Hat OpenShift 虚拟化设计网络 IBM Cloud VPC
设计适用于 Red Hat OpenShift 虚拟化环境的网络架构（基于 IBM Cloud VPC ），涵盖 VPC 网络、OpenShift 软件定义网络（SDN）以及 Open Virtual Networking（OVN）用户定义网络。
Red Hat OpenShift Virtualization on IBM Cloud VPC 中的网络设计有以下不同层次。
- VPC 网络
- Red Hat OpenShift 社交
- OVN 网络
主要网络架构要素如下图所示。
IBM Cloud VPC 社交
您使用 IBM Cloud VPC 网络来部署和管理云资源。 它为工作负载（包括虚拟服务器、容器和裸机部署）提供了基础，有助于确保网络分段、安全性和可扩展性。
您需要创建一个 VPC 才能部署一个 Red Hat® OpenShift® Kubernetes Service 集群。
带子网的默认专用网络
您需要在至少一个可用性区域内创建一个 VPC 子网，以配置 Red Hat OpenShift Kubernetes Service 集群。 更多信息，请参阅“使用子网的默认专用网络”。
负载均衡器
Red Hat OpenShift 入口控制器部署在 Red Hat OpenShift Kubernetes Service 集群上，作为外部网络流量的入口端点。 在 Red Hat OpenShift Kubernetes Service 集群中，每个集群都会自动创建一个 VPC 应用程序负载平衡器，以暴露入口控制器。 更多信息，请参阅 负载平衡器。
Red Hat OpenShift Kubernetes Service 具有以下功能
- DNS 服务会将路由子域解析为 VPC 负载平衡器主机名。
- VPC 负载均衡器会将 VPC 主机名解析为可用的入口控制器服务外部 IP 地址，该地址已被报告为运行正常。
- VPC 负载均衡器将请求发送到入口控制器服务。
- 入口控制器通过私有网络将请求转发到应用 Pod 的私有 IP 地址。
虚拟专用端点
Red Hat OpenShift Kubernetes Service 环境中的虚拟专用端点 (VPE) 主要用于实现 Red Hat OpenShift 集群与 IBM Cloud 平台服务之间的专用连接，而无需穿越公共互联网的网络流量。
下表列出了 IBM Cloud 为基本群集操作自动提供的所有虚拟专用端点。
| 虚拟专用端点 | 管理者 | 描述 |
|---|---|---|
| iks-api | Kubernetes Service 应用程序接口 |
|
| iks-riaas | VPC 基础设施服务 |
|
| iks-registry | Container Registry |
|
| iks-<集群ID> | 特定群组实例 |
|
| iks-cos-config | Cloud Object Storage (配置) |
|
| iks-cos | Cloud Object Storage (数据) |
|
Red Hat OpenShift 虚拟化网络
Red Hat OpenShift 虚拟化利用 Red Hat OpenShift 网络功能，为与容器化工作负载同时运行的虚拟服务器提供灵活的软件定义网络。 了解虚拟服务器网络和 pod 网络的区别非常重要。 每个虚拟服务器都在 virt-launcher pod 中运行，该 pod 始终连接到默认 pod 网络。
┌────────────────────────────────┐
│ Worker Node │
│ ┌──────────────────────────┐ │
│ │ virt-launcher │ │ ← Kubernetes Pod Security Context
│ │ pod │ │
│ │ ┌────────────────────┐ │ │
│ │ │ virtual server │ │ │ ← KVM/QEMU Hypervisor Isolation
│ │ │ (QEMU) │ │ │
│ │ └────────────────────┘ │ │
│ └──────────────────────────┘ │
└────────────────────────────────┘
根据配置和设置虚拟服务器的方式，它可以共享一个 pod 网络（也可以通过 multus 连接到不同的网络）。
下面的示例描述了 Red Hat OpenShift 中的默认 pod 网络连接，您可以使用 OVN- Kubernetes 网络连接进行修改。
Pod 网络（集群网络）
- 每个 pod 都会从集群网络的无类域间路由（CIDR）中获取一个私有 IP 地址
- 提供跨节点的 pod-to-pod 通信
- Pod 在集群内使用各自的私有 IP 直接通信
- 网络策略在第 3/4 层控制 pod 之间的流量
- 扁平网络模式--默认情况下所有 pod 都能通信
- pod 之间无 NAT（pod 与 pod 之间直接通信）
- 网络策略提供分段和安全
- 集群内基于 DNS 的服务发现
- 当虚拟服务器在 virt-launcher Pod 内运行时，其 IP 地址会通过 virt-launcher Pod 的 IP 地址进行网络地址转换（NAT）
IP 伪装（源 NAT（SNAT））
- 当 pod 向外部网络发起出站连接时，源 IP 会被伪装
- 请求数据包的源 IP 地址被更改为运行该 Pod 的工作节点 IP 地址
- IP 伪装是必要的，因为 pod IP 在群集外是不可路由的
- 返回流量会被分解回原始 pod IP
- 外部服务会看到来自工作节点 IP 而非 pod IP 的请求
ClusterIP 服务
服务为 pod 提供稳定的端点和负载平衡。 它们抽象了 pod IP，为应用程序提供一致的接入点。 ClusterIP 服务提供以下功能。
- 创建一个只能在群集内访问的虚拟 IP ( ClusterIP )
- ClusterIP 是默认服务类型（如果未指定
- 在后端 pod 之间提供内部负载平衡
- 使用 kube-proxy 或 OVN- Kubernetes 进行流量分配
以下是 ClusterIP 的使用实例。
- 内部微服务通信
- 无需外部访问的后台服务
- 仅由集群工作负载访问的数据库服务
- 节点间服务发现
NodePort 服务
服务为 pod 提供稳定的端点和负载平衡。 它们抽象了 pod IP，为应用程序提供一致的接入点。 NodePort 服务提供以下功能。
- 在每个工作节点的静态端口（30000-32767 范围）上提供服务
- 通过以下方式提供服务
<NodeIP>:<NodePort> - 自动创建 ClusterIP 服务
- NodePort 的流量转发到服务
下面的示例显示了 NodePort 流量。
- 外部客户端连接到
<WorkerNodeIP>:<NodePort> - 节点将流量转发至 ClusterIP 服务
- 服务会平衡后端 pod 的负载
- 响应将通过反向路径返回，并使用 SNAT（源网络地址转换）
以下用例说明了 NodePorts 的用途。
- 开发和测试环境
- 无需负载平衡器即可快速进行外部访问
- 与外部负载平衡器集成
- 定制负载平衡解决方案
LoadBalancer 服务
在 IBM Cloud Red Hat OpenShift Kubernetes Service 上，负载平衡器服务会自动配置 VPC 网络负载平衡器或应用程序负载平衡器。 负载平衡器服务提供以下功能。
- 自动配置外部负载平衡器
- 为服务分配外部 IP 或主机名
- 自动创建 NodePort 和 ClusterIP 服务
- 为服务后端提供第 4 层负载平衡
下面的示例显示了 VPC 中的流量。
- 外部客户端连接到 VPC 负载均衡器 IP 或主机名
- VPC 负载均衡器分发到工作节点 NodePorts
- Node 转入服务 ClusterIP
- 服务会平衡后端 pod 的负载
以下用例说明了负载平衡器的用途。
- 需要专用外部访问权限的生产应用程序
- 非 HTTP 协议（ TCP 或 UDP 服务）
- 需要稳定外部 IP 的应用
- 绕过入口层或路由层的服务
Red Hat OpenShift 路线
Red Hat OpenShift 路由通过将完全限定域名（FQDN）映射到后端服务，将服务暴露给外部网络流量，从而使应用程序可在集群外部访问。 以下列表显示了 Red Hat OpenShift 路由的主要功能。
- 第 7 层路由 - HTTP / HTTPS 基于主机名的路由流量
- 自动 DNS - 路由使用群集子域：
<route-name>-<namespace>.apps。<cluster-domain> - 无担保路线 ( HTTP )
- TLS 终止
- 边缘终结路由（路由器 TLS ）
- 直通路线 ( TLS at Pod)
- 重新加密路由（在路由器和 Pod 上 TLS ）
- HAProxy-由 Red Hat OpenShift 入口控制器（路由器）执行
- 流量管理 - 基于路径的路由选择、流量分割和会话亲和性
开放虚拟网络（OVN）
OVN- Kubernetes 容器网络接口（CNI）插件是 Red Hat OpenShift 虚拟化推荐的网络选项，它支持与传统Pod网络并行运行的虚拟服务器网络用例。 OVN- Kubernetes 基于 Open Virtual Networking（OVN），并在每个工作节点上使用 Open vSwitch （OVS）。 它支持多租户、NetworkPolicies,、混合虚拟服务器和 pod 网络。 Red Hat OpenShift on IBM Cloud VPC 支持 OVN- Kubernetes 作为默认联网插件。
对于熟悉 VMware vSphere 和NSX-T的管理员，请参阅 《 OpenShift 中的OVN网络（面向 vSphere 管理员） 》，其中列出了OVN概念与其在 vSphere 中的对应关系。
在 Red Hat OpenShift 和 OVN 中，以下三种网络拓扑结构可为 pod 和虚拟服务器提供辅助网络连接。
- 第 2 层 ( L2 )- 使用 Geneve 封装软件定义 L2 广播域
- 第 3 层 ( L3 )- 具有自定义 IP 子网的路由网段。 L3 网络中，每个节点都有一个独立的CIDR（无类域间路由）。
- 本地网 - 直接访问底层物理网络 VLAN
在 Red Hat OpenShift Virtualization on IBM Cloud 中，OVN 第 2 层和 OVN localnet 是与用户定义网络（UDN）一起使用的两种主要拓扑结构。
- OVN 第 2 层通过使用 Geneve 封装在整个集群中创建软件定义的 L2 广播域，提供与 NSX 重叠网段类似的重叠网络。 这些网络与 VPC 子网隔离。 它们需要连接到 OVN Localnet 的网关 pod 或虚拟服务器，以提供 VPC 子网的入口和出口以及 VPC 路由。
- OVN Localnet 提供对底层 VPC 网络的 VLAN 访问，类似于 NSX VLAN 支持的网段。 在 IBM Cloud VPC 中，这种直接连接可使虚拟服务器和 pod 通过使用虚拟网络接口（VNI）和 VLAN 附件直接连接到 VPC 子网。
下图是使用 OVN 和 multus 进行虚拟服务器联网的概览。 默认情况下，Kubernetes （和 Red Hat OpenShift ）通过使用主 CNI 插件（如 OVN- Kubernetes ）为每个 pod 分配一个网络接口。 Red Hat OpenShift 中的 Multus 是一个 CNI 插件，可为 pod 和虚拟服务器提供多个网络接口。
最初，只有 OVN 第 2 层网络可用。
OVN 用户定义网络
Red Hat OpenShift 虚拟化
Red Hat OpenShift 中的用户定义网络（UDN）是由 OVN- Kubernetes 提供的自定义网络。 UDN 取代默认群集网络（也称为默认 pod 网络） UDN 用于创建具有自己的 IP 子网、网关和路由域的网络。 UDN 独立于主 pod 网络，通常在工作负载需要以下功能时使用。
- 与群集中其他应用程序的网络隔离
- 自定义 IP 地址范围或重叠子网
- 直接控制选定命名空间或工作负载之间的东西向流量
- 与需要多个网络接口的虚拟服务器（ Red Hat OpenShift virtualization）集成
- 满足安全或合规要求的专用网段
与默认 pod 网络不同，UDN 是明确附加到命名空间的。 每个 UDN 都会在 OVN 中创建一个额外的逻辑交换机。 当 UDN 被标记为命名空间的主用户定义网络时，该命名空间中的所有 pod 和虚拟服务器都会将其用作主网络，而不是群集默认网络。
集群用户定义网络（CUDN）通过提供不属于任何特定命名空间的集群范围资源，扩展了 UDN 概念。 创建的 CUDN 与一个或多个命名空间相关联。 与命名空间范围 NetworkAttachmentDefinition (NAD) 资源（每个命名空间需要一个）不同，当命名空间被添加到 CUDN 定义中时，CUDN 会自动在命名空间中创建 NAD。
UDN 可根据范围、连接方法和拓扑结构提供灵活的联网选项：
网络范围
- 命名空间范围的 UDN - 仅限于单一命名空间的网络定义，每个命名空间需要单独的 NetworkAttachmentDefinitions
- 群集范围内的 CUDN - 网络定义在整个群集范围内可用，在选定的命名空间中自动创建 NetworkAttachmentDefinitions
附着方法
- 主网络 - 作为命名空间中所有 pod/虚拟服务器的默认网络，取代群集默认网络
- 辅助网络 - 通过 Multus CNI 连接，为 pod/虚拟服务器和主网络提供额外的网络接口
网络拓扑
- 第 2 层——通过 Geneve 封装实现软件定义的 L2 广播域，从而支持基于地址解析协议（ARP）的发现以及 MAC 到 MAC 的通信
- 第 3 层 - 带有自定义 IP 子网和网关的路由网段
- 本地网 - 通过使用虚拟网络接口 (VNI) 附件，直接将 VLAN 接入底层 VPC 子网
您可以将这些特性结合起来，创建定制的网络解决方案。 例如，使用本地网拓扑的群集范围 CUDN 可以提供多个命名空间，作为主网络或辅助网络直接访问 VPC 子网。
OVN 第 2 层网络
OVN 第 2 层网络是软件定义的第 2 层广播域，类似于 NSX 覆盖网段或传统 VLAN。 第 2 层完全是在 OVN 中通过在集群现有网络基础设施上使用 Geneve 封装实现的。 第 2 层网络允许 pod 和虚拟服务器像在同一以太网段上一样进行通信，支持 ARP 发现、广播、组播和直接 MAC 对 MAC 通信。
Red Hat OpenShift 群集有一个主群集网络，其中 pod 和虚拟服务器从通过 OVN 路由的默认群集 CIDR 接收 IP。 您可以通过 ClusterUserDefinedNetwork (CUDN) 或命名空间范围 UDN 定义辅助二层网络。 辅助第 2 层网络是在默认 pod 网络之外创建的任何额外网络。
以下项目是第 2 层网络的主要特征。
- 为 OVN 创建的第 2 层广播域提供 IPAM、MAC 分配和连接功能
- 没有内置的 DNS 解析功能，无法解析二级网络上的 pod 名称
- 当流量从虚拟服务器流出时，来自主第 2 层网络的流量会进行源网络地址转换（NAT），同时还会被路由至第 2 层网络；该网络的访问路径可通过
FRR-K8s和 VPC 路由进行配置 - 二级第 2 层网络默认是隔离的，除非明确配置，否则不能直接访问互联网
- 适用于集群内虚拟服务器之间的通信以及依赖组播的应用程序
OVN 本地网网络
OVN Localnet 网络可让虚拟服务器和 pod 以 VLAN 方式直接访问底层 VPC 网络基础设施。 OVN Localnet 可让虚拟服务器和 pod 通过使用虚拟网络接口 (VNI) 和 VLAN 附件连接到 VPC 子网。
利用 VLAN 附件，可以将 Red Hat OpenShift Virtualization 上运行的虚拟服务器直接附加到 VPC 子网。 您可以使用这种方法，通过在工作负载之间提供一致的网络，将现有的 VPC 子网设计用于新的或迁移的虚拟服务器。
本地网联网要求连接到 VPC 子网的每个虚拟服务器网卡都需要满足以下要求：
- 虚拟网络接口 (VNI) 资源定义了一个从 VPC 子网中保留的 IP 地址，以及一个或多个控制 VNI 入站和出站流量的安全组。
- 裸机服务器 VLAN 附件。 必须启用此 VLAN 连接的浮动功能（该功能决定了该连接能否在工作节点之间迁移），虚拟服务器才能向另一个工作节点进行实时迁移。
- 一个 VLAN ID。 VLAN 标记与工作节点上的 PCI 接口相关联。 通常，这种关联是 VLAN ID 和 VPC 子网之间一对一的映射。
在为本地网网络设计安全组规则时，要考虑到有些网络交换是在工作节点上的 OVS 内进行的，永远不会到达 VPC 基础架构。 安全组规则只适用于穿越 VPC 网络结构的流量。 同一工作节点上虚拟服务器之间的流量可绕过 VPC 安全控制。
以下示例是本地网的使用案例。
- 需要现有 VPC 子网 IP 地址的已迁移虚拟服务器
- 与现有 VPC 安全组和网络策略集成
- 与其他 VPC 资源的直接连接
- 使用 VPC 子网进行网络分段的合规要求
- 需要跨 VPC 和 Red Hat OpenShift 虚拟化实现一致 IP 寻址的混合架构
后续步骤
现在，您已了解 Red Hat OpenShift 虚拟化的网络设计，请探索这些相关主题：