Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

8.2. 支持多网络插件 (Multus)

OpenShift Data Foundation 支持在裸机基础架构上使用多网络插件 Multus 来通过隔离不同类型的网络流量来提高安全性和性能。通过使用 Multus，主机上一个或多个网络接口可能会保留来独占使用 OpenShift Data Foundation。

要使用 Multus，首先运行 Multus 先决条件验证工具。有关使用该工具的说明，请参阅 OpenShift Data Foundation - Multus 先决条件验证工具。有关 Multus 网络的更多信息，请参阅 多个网络。

您可以将 Multus 网络配置为使用 IPv4。您还可以将网络配置为使用 IPv6 是一个技术预览。Multus 网络只能配置为使用 IPv4 或 IPv6。不支持混合模式。

重要

技术预览功能为用户提供了一个对最新的产品创新的试用机会，以便用户可以对其进行测试并提供反馈。但是，Red Hat 服务等级协议不支持这些功能，其功能可能并不完善，且不适用于生产环境。由于红帽会考虑在将来的产品中使用这些技术预览功能，我们将尝试解决客户在使用这些功能时遇到的问题。

如需更多信息，请参阅技术预览功能支持范围。

8.2.1. Multus 先决条件
复制链接

为了使 Ceph-CSI 与启用了 Multus 的 CephCluster 通信，Kubernetes 主机需要一些设置。

这些先决条件需要了解 Multus 网络的配置方式以及 Rook 如何使用它们。本节将有助于说明可能出现的问题。

必须满足两个基本要求：

  • OpenShift 主机必须能够成功路由到 Multus 公共网络。
  • Multus 公共网络上的 Pod 必须能够成功路由到 OpenShift 主机。

这两个要求可以进一步划分，如下所示：

  • 要将 Kubernetes 主机路由到 Multus 公共网络，每个主机都必须确保以下内容：

    • 主机必须具有连接到 Multus 公共网络的接口(public-network-interface)。
    • "public-network-interface"必须具有 IP 地址。
    • 必须存在一个路由，以通过"public-network-interface"来指示用于 Multus 公共网络上的 pod 的流量。

  • 对于 Multus 公共网络上的 pod 路由到 Kubernetes 主机，必须配置公共 NetworkAttachmentDefinition，以确保以下内容：

    • 该定义必须将其 IP 地址管理(IPAM)配置为路由通过网络用于节点的流量。
  • 为确保两个网络之间的路由正常工作，分配给节点的 IP 地址可以与 Multus 公共网络上分配给 pod 的任何 IP 地址重叠。
  • 通常，NetworkAttachmentDefinition 和节点配置必须使用相同的网络技术(Macvlan)来连接到 Multus 公共网络。

节点配置和 pod 配置是相互相关的且紧密耦合。必须同时计划这两者，而 OpenShift Data Foundation 不支持 Multus 公共网络，而无需两者。

对于这两者，"public-network-interface"必须相同。通常，连接技术(Macvlan)对于两者来说也应该相同。NetworkAttachmentDefinition 中的 IP 范围必须编码为节点上的路由，而 mirror 中，节点的 IP 范围必须在 NetworkAttachmentDefinition 中编码为路由。

有些安装可能不希望为 pod 和节点使用相同的公共网络 IP 地址范围。如果 pod 和节点有不同的范围，则必须执行额外的步骤来确保每个范围路由到另一个范围，以便它们充当一个连续的网络。这些要求需要仔细规划。请参阅 Multus 示例 来帮助理解并实现这些要求。

提示

每个存储节点通常会有十个或更多 OpenShift Data Foundation pod。pod 地址空间通常需要多次大于主机地址空间（或以上）。

OpenShift Container Platform 建议使用 NMState Operator 的 NodeNetworkConfigurationPolicies 作为配置主机要求的好方法。如果需要，也可以使用其他方法。

8.2.1.1. Multus 网络地址空间大小
复制链接

网络必须具有足够的地址来考虑附加到网络的存储 pod 数量，以及一些额外的空间以考虑故障转移事件。

强烈建议您提前计划将来的存储集群扩展，并估算以后 OpenShift Container Platform 和 OpenShift Data Foundation 集群可以如何增长。为将来的扩展保留地址意味着在扩展过程中意外删除 IP 地址池的风险较低。

分配 25% 比存储集群生命周期一次需要的最大地址总数（或以上）。这有助于降低在故障切换和维护过程中耗尽 IP 地址池的风险。

为了便于编写对应的网络 CIDR 配置，还建议将总计舍入到最接近的 2 指数。

必须规划三个范围：

  • 如果使用，公共网络附加定义地址空间必须包含足够的 IP 地址，用于 openshift-storage 命名空间中运行的 ODF pod 总数
  • 如果使用，集群网络附加定义地址空间必须包含足够的 IP 地址，用于 openshift-storage 命名空间中运行的 OSD pod 总数
  • 如果使用 Multus 公共网络，节点公共网络地址空间必须包含足够的 IP 地址，用于连接到 Multus 公共网络的 OpenShift 节点总数。
注意

如果集群为公共网络附加定义和节点公共网络附加使用统一地址空间，请将这两个要求添加到一起。这相关，例如，如果 DHCP 用于管理公共网络的 IP。

8.2.1.1.1. 建议
复制链接

对于大多数机构，以下建议要求：建议使用最后 6.25%(1/16)的保留专用地址空间(192.168.0.0/16)，假设范围的开头正在使用或需要。给出大约最大限制（代表 25% 的开销）。

Expand
表 8.1. Multus 建议
网络网络范围 CIDR大约最大值

公共网络附加定义

192.168.240.0/21

1,600 个 ODF pod

集群网络附加定义

192.168.248.0/22

800 OSD

节点公共网络附加

192.168.252.0/23

400 个节点

8.2.1.1.2. 计算
复制链接

可以确定更详细的地址空间大小，如下所示：

  1. 确定未来可能需要的最大 OSD 数量。添加 25%，然后添加 5。将结果向上舍入为最接近的 2 指数。这是集群地址空间大小。
  2. 从步骤 1 中计算的未舍入数开始。添加 64，然后增加 25%。将结果向上舍入为最接近的 2 指数。这是 pod 的公共地址空间大小。
  3. 确定未来可能需要的最大 OpenShift 节点（包括存储节点）总数。增加了 25%将结果向上舍入为最接近的 2 指数。这是节点的公共地址空间大小。

8.2.1.2. 验证要求是否已满足
复制链接

配置节点并创建 Multus 公共 NetworkAttachmentDefinition （请参阅 创建网络附加定义）检查节点配置和 NetworkAttachmentDefinition 配置是否兼容。为此，请验证每个节点是否可以通过公共网络 ping pod。

启动类似以下示例的 daemonset： 

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: multus-public-test
  namespace: openshift-storage
  labels:
    app: multus-public-test
spec:
 selector:
   matchLabels:
     app: multus-public-test
 template:
   metadata:
     labels:
       app: multus-public-test
     annotations:
       k8s.v1.cni.cncf.io/networks: openshift-storage/public-net #
   spec:
     containers:
       - name: test
         image: quay.io/ceph/ceph:v18 # image known to have ‘ping’ installed
         command:
           - sleep
           - infinity
         resources: {}
Copy to Clipboard Toggle word wrap

使用类似以下示例的命令，列出分配给测试 pod 的 Multus 公共网络 IP。此示例命令列出了分配给所有测试 pod 的所有 IP （每个 IP 将有 2 个 IP）。在输出中，手动提取与 Multus 公共网络关联的 IP 很容易。 

$ oc -n openshift-storage describe pod -l app=multus-public-test | grep -o -E 'Add .* from .*'
Add eth0 [10.128.2.86/23] from ovn-kubernetes
Add net1 [192.168.20.22/24] from default/public-net
Add eth0 [10.129.2.173/23] from ovn-kubernetes
Add net1 [192.168.20.29/24] from default/public-net
Add eth0 [10.131.0.108/23] from ovn-kubernetes
Add net1 [192.168.20.23/24] from default/public-net
Copy to Clipboard Toggle word wrap

在上例中，测试 Multus 公共网络上的 pod IP 是：

  • 192.168.20.22
  • 192.168.20.29
  • 192.168.20.23

检查每个节点(NODE)是否可以通过公共网络访问所有测试 pod IP： 

$ oc debug node/NODE
Starting pod/NODE-debug ...
To use host binaries, run `chroot /host`
Pod IP: ****
If you don't see a command prompt, try pressing enter.


sh-5.1# chroot /host


sh-5.1# ping 192.168.20.22
PING 192.168.20.22 (192.168.20.22) 56(84) bytes of data.
64 bytes from 192.168.20.22: icmp_seq=1 ttl=64 time=0.093 ms
64 bytes from 192.168.20.22: icmp_seq=2 ttl=64 time=0.056 ms
^C
--- 192.168.20.22 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1046ms
rtt min/avg/max/mdev = 0.056/0.074/0.093/0.018 ms


sh-5.1# ping 192.168.20.29
PING 192.168.20.29 (192.168.20.29) 56(84) bytes of data.
64 bytes from 192.168.20.29: icmp_seq=1 ttl=64 time=0.403 ms
64 bytes from 192.168.20.29: icmp_seq=2 ttl=64 time=0.181 ms
^C
--- 192.168.20.29 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1007ms
rtt min/avg/max/mdev = 0.181/0.292/0.403/0.111 ms


sh-5.1# ping 192.168.20.23
PING 192.168.20.23 (192.168.20.23) 56(84) bytes of data.
64 bytes from 192.168.20.23: icmp_seq=1 ttl=64 time=0.329 ms
64 bytes from 192.168.20.23: icmp_seq=2 ttl=64 time=0.227 ms
^C
--- 192.168.20.23 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1047ms
rtt min/avg/max/mdev = 0.227/0.278/0.329/0.051 ms
Copy to Clipboard Toggle word wrap

如果有任何节点没有成功 ping 正在运行的 pod，则无法安全地继续。诊断并修复问题，然后重复此测试。您可能会遇到问题的一些原因包括：

  • 主机可能无法正确附加到 Multus 公共网络（通过 Macvlan）
  • 主机可能无法正确配置为路由到 pod IP 范围
  • 公共 NetworkAttachmentDefinition 可能没有正确配置为路由回主机 IP 范围
  • 主机可能具有防火墙规则阻止任一方向的连接
  • 网络交换机可能具有防火墙或安全规则阻止连接

推荐的调试步骤：

  • 确保节点可以相互 ping 使用公共网络"shim"IP
  • 确保 ip 地址的输出

8.2.2. Multus 示例
复制链接

此集群的相关网络计划如下：

  • 专用 NIC 为 Multus 公共网络提供 eth0
  • macvlan 将 OpenShift Pod 附加到 eth0
  • IP 范围 192.168.0.0/16 在示例集群中可用 - pod，节点将在 Multus 公共网络中共享这个 IP 范围
  • 节点将获取 IP 范围 192.168.252.0/22 （这最多允许 1024 个 Kubernetes 主机，超过示例组织需要）
  • Pod 将把范围的其余部分(192.168.0.1 到 192.168.251.255)）
  • 示例机构不想使用 DHCP，除非有必要，节点将在 Multus 网络中具有 IP （通过 eth0），使用 NMState operator's NodeNetworkConfigurationPolicy 资源静态分配
  • 在 DHCP 不可用的情况下，W Whereabouts 将用来为 Multus 公共网络分配 IP，因为它可以轻松地开箱即用。
  • OpenShift 集群中有 3 个计算节点，其上运行的 OpenShift Data Foundation 也运行：compute-0、compute-1 和 compute-2

节点的网络策略必须配置为路由到 Multus 公共网络上的 pod。

由于 Pod 将通过 Macvlan 连接，因此 Macvlan 不允许主机和 pod 互相路由，因此还必须通过 Macvlan 连接主机。通常，主机必须使用与 pod 相同的技术连接到 Multus 公共网络。Pod 连接在 Network Attachment 定义中配置。

由于主机 IP 范围是整个范围的子集，因此主机无法仅通过 IP 分配路由到 pod。必须向主机添加路由，以允许它们路由到整个 192.168.0.0/16 范围。

NodeNetworkConfigurationPolicy desiredState specs 将类似如下： 

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: ceph-public-net-shim-compute-0
  namespace: openshift-storage
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ""
    kubernetes.io/hostname: compute-0
 desiredState:
   interfaces:
     - name: odf-pub-shim
       description: Shim interface used to connect host to OpenShift Data Foundation public Multus network
       type: mac-vlan
       state: up
       mac-vlan:
         base-iface: eth0
         mode: bridge
         promiscuous: true
       ipv4:
         enabled: true
         dhcp: false
         address:
           - ip: 192.168.252.1 # STATIC IP FOR compute-0
             prefix-length: 22
   routes:
     config:
       - destination: 192.168.0.0/16
         next-hop-interface: odf-pub-shim
---
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: ceph-public-net-shim-compute-1
  namespace: openshift-storage
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ""
    kubernetes.io/hostname: compute-1
 desiredState:
   interfaces:
     - name: odf-pub-shim
       description: Shim interface used to connect host to OpenShift Data Foundation public Multus network
       type: mac-vlan
       state: up
       mac-vlan:
         base-iface: eth0
         mode: bridge
         promiscuous: true
       ipv4:
         enabled: true
         dhcp: false
         address:
           - ip: 192.168.252.1 # STATIC IP FOR compute-1
             prefix-length: 22
   routes:
     config:
       - destination: 192.168.0.0/16
         next-hop-interface: odf-pub-shim
---
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: ceph-public-net-shim-compute-2 # [1]
  namespace: openshift-storage
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ""
    kubernetes.io/hostname: compute-2 # [2]
 desiredState:
   interfaces: [3]
     - name: odf-pub-shim
       description: Shim interface used to connect host to OpenShift Data Foundation public Multus network
       type: mac-vlan # [4]
       state: up
       mac-vlan:
         base-iface: eth0 # [5]
         mode: bridge
         promiscuous: true
       ipv4: # [6]
         enabled: true
         dhcp: false
         address:
           - ip: 192.168.252.2 # STATIC IP FOR compute-2 # [7]
             prefix-length: 22
   routes: # [8]
     config:
       - destination: 192.168.0.0/16 # [9]
         next-hop-interface: odf-pub-shim
Copy to Clipboard Toggle word wrap
  1. 对于静态 IP 管理，每个节点都必须有一个不同的 NodeNetworkConfigurationPolicy。
  2. 为每个策略选择单独的节点来配置静态网络。
  3. "shim"接口用于通过与网络附加定义相同的技术将主机连接到 Multus 公共网络。
  4. 主机的"shim"类型必须与 Pod 的计划相同，本例中是 macvlan。
  5. 接口必须与 规划中选择的 Multus 公共网络接口匹配，在本例中是 eth0。
  6. ipv4 （或 ipv6'）部分在 Multus 公共网络上配置节点 IP 地址。
  7. 分配给此节点的 shim 的 IP 必须与计划匹配。本例使用 192.168.252.0/22 用于 Multus 公共网络上的节点 IP。
  8. 对于静态 IP 管理，请不要忘记更改每个节点的 IP。
  9. routes 部分指示节点如何访问 Multus 公共网络上的 pod。
  10. 路由目的地必须与为 pod 计划的 CIDR 范围匹配。在这种情况下，使用整个 192.168.0.0/16 范围是安全的，因为它不会影响通过其"shim"接口访问其他节点的能力。通常，这与 Multus 公共 NetworkAttachmentDefinition 中使用的 CIDR 匹配。

公共网络的 NetworkAttachmentDefinition 类似，使用 Whereabouts 的 exclude 选项来简化 范围 请求。Whereabouts routes[].dst 选项确保 pod 通过 Multus 公共网络路由到主机。 

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: public-net
  namespace: openshift-storage
spec:
  config: '{
     "cniVersion": "0.3.1",
     "type": "macvlan", # [1]
     "master": "eth0", # [2]
     "mode": "bridge",
     "ipam": {
       "type": "whereabouts", # [3]
       "range": "192.168.0.0/16", # [4]
       "exclude": [
          "192.168.252.0/22" # [5]
       ],
       "routes": [              # [6]
         {"dst": "192.168.252.0/22"} # [7]
       ]
     }
   }'
Copy to Clipboard Toggle word wrap
  1. 这必须与如何将 pod 附加到 Multus 公共网络的计划匹配。节点必须使用相同的技术 Macvlan 附加。
  2. 接口必须与 规划中选择的 Multus 公共网络接口匹配，在本例中是 eth0。
  3. 本例计划使用 whereabouts 而不是 DHCP 将 IP 分配给 pod。
  4. 在本例中，决定 pod 可以在 192.168.0.0/16 范围中分配任何 IP，但分配给节点的范围除外（请参阅 5）。
  5. Whereabouts 提供了一个 exclude 指令，它允许从池中轻松排除为节点分配的范围。这样可使 范围 指令保持简单（请参阅 4）。
  6. routes 部分指示 pod 如何访问 Multus 公共网络中的节点。
  7. 路由目的地(dst)必须与为节点计划的 CIDR 范围匹配。

8.2.3. holder pod 弃用
复制链接

由于升级过程中对拥有者 pod 的重复维护影响（当启用 Multus 时存在拥有者 pod），因此拥有者 pod 在 ODF v4.16 版本中已弃用，并在 ODF v4.17 发行版本中删除。此弃用需要在删除拥有者 pod 前完成额外的网络配置操作。在 ODF v4.15 中，启用了 Multus 的集群会根据标准升级步骤升级到 v4.16。当 ODF 集群（启用 Multus）成功升级到 v4.16 后，管理员必须完成文章 Disabling Multus holder pod 中记录的步骤来禁用和删除拥有者 pod。请注意，这个禁用过程会消耗大量时间，但在升级到 v4.16 后，无法立即完成整个进程。在将 ODF 升级到 v4.17 前，务必要完成这个过程。

8.2.4. 使用 Multus 隔离存储流量
复制链接

默认情况下，Red Hat OpenShift Data Foundation 被配置为使用 Red Hat OpenShift Software Defined Network(SDN)。默认 SDN 执行以下类型流量：

  • Pod 到 pod 的流量
  • 当存储是 OpenShift Data Foundation 时，pod 到存储的流量称为公共网络流量
  • OpenShift Data Foundation 内部复制和重新平衡流量，称为集群网络流量

通过三种方法将 OpenShift Data Foundation 与 OpenShift 默认网络隔离：

  1. 在主机上为 OpenShift Data Foundation 的公共网络保留网络接口

    • pod 到存储和内部存储复制流量在与 pod 到 pod 网络流量隔离的网络上共存。
    • 当 OpenShift Data Foundation 集群正常运行时，应用程序 pod 可以访问最大公共网络存储带宽。
    • 当 OpenShift Data Foundation 集群从失败时恢复时，应用容器集会因为持续复制和重新平衡流量而降低带宽。

  2. 在主机上为 OpenShift Data Foundation 的集群网络保留网络接口

    • pod 到 pod 和 pod-to-storage 流量都继续使用 OpenShift 的默认网络。
    • Pod 到存储带宽会受到 OpenShift Data Foundation 集群的健康状态的影响较低。
    • pod 到 pod 和 pod-to-storage OpenShift Data Foundation 流量可能会在忙碌的 OpenShift 集群中进行网络带宽。
    • 存储内部网络通常具有不使用的带宽超负状态，预留给在故障期间使用。

  3. 在主机上为 OpenShift Data Foundation 保留两个网络接口：一个用于公共网络，一个用于集群网络

    • pod 到 pod、pod-to-storage 和存储内部流量都是隔离的，资源都没有流量类型。
    • 所有流量类型的服务级别协议可以确保。
    • 在健康运行时，保留更多网络带宽，但跨所有三个网络使用。

双网络接口隔离配置模式示例：

Dual network interface segregated configuration schematic

三网络接口完整隔离的配置模式示例：

Triple network interface full segregated configuration schematic

8.2.5. 何时使用 Multus
复制链接

当您需要以下内容时，使用 Multus for OpenShift Data Foundation：

改进了带有 ODF 的延迟 - Multus 始终提高了延迟。在近主机网络速度中使用主机接口，并绕过 OpenShift 软件定义的 Pod 网络。您还可以为每个接口执行每个接口级别的 Linux。

改进了 OpenShift Data Foundation 客户端数据流量和内部数据流量的带宽 Dedicated 接口。这些专用接口保留完整的带宽。

改进了 security - Multus 将存储网络流量与应用程序网络流量隔离，以提高安全性。但是，当网络共享一个接口时，带宽或性能可能无法隔离，但您可以使用 QoS 或流量整形来优先选择共享接口的带宽。

8.2.6. Multus 配置
复制链接

要使用 Multus，您必须在部署 OpenShift Data Foundation 集群前创建网络附加定义(NAD)，该集群稍后附加到集群。如需更多信息，请参阅 创建网络附加定义。

要将额外网络接口附加到 pod，您必须创建配置来定义接口的附加方式。您可以使用 NetworkAttachmentDefinition 自定义资源（CR）来指定各个接口。每个 CR 中的 Container Network Interface (CNI)配置定义如何创建该接口。

OpenShift Data Foundation 支持 macvlan 驱动程序，其中包括以下功能：

  • 每个连接都会获得具有其自身 MAC 地址的父接口的子接口，并与主机网络隔离。
  • 使用 CPU 比 Linux 网桥或 ipvlan 提供更好的吞吐量。
  • 网桥模式几乎总是最佳选择。
  • 当网卡(NIC)支持硬件中的虚拟端口/虚拟局域网(VLAN)时，接近主机性能。

OpenShift Data Foundation 支持以下两种类型的 IP 地址管理：

Expand

Whereabouts

DHCP

使用 OpenShift/Kubernetes 租期 来选择每个 Pod 的唯一 IP 地址。

不需要 range 字段。

不需要 DHCP 服务器为 Pod 提供 IP。

网络 DHCP 服务器可以为 Multus Pod 以及同一网络上的任何其他主机提供相同的范围。

Important

如果存在 DHCP 服务器，请确保 Multus 配置的 IPAM 没有给出相同的范围，以便网络上的多个 MAC 地址不能具有相同的 IP。

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat