作者：李晓辉

联系方式：

1. 微信：Lxh_Chat

2. 邮箱：939958092@qq.com

🌐 Kubernetes 网络模型简介

在 Kubernetes 中，每个 Pod（容器集）都会被分配一个独立的 IP 地址。这种设计让 Pod 之间的通信变得更加直接，无需额外的链路配置，也不再依赖容器端口到节点端口的映射。

✅ 网络模型的核心要求

Kubernetes 对网络的实现提出了以下基本要求：

Pod 间通信无需 NAT（网络地址转换）
所有 Pod 都应能直接使用 IP 地址互相通信，无需中间转换。
同节点上的 Pod 与系统进程（如代理）可直接通信
保证节点内部的网络连通性，提升性能和稳定性。

📌 Pod 内部通信机制

Kubernetes 在 Pod 级别分配 IP 地址，这意味着：

Pod 内的多个容器可以通过 localhost 直接访问彼此的端口。
Pod 本身并不感知节点端口的存在，但我们可以通过配置，将节点端口转发到指定的 Pod，实现外部访问。

flowchart LR
    subgraph Node1 [节点 A]
        A1[Pod A]
        A2[Pod B]
    end
    subgraph Node2 [节点 B]
        B1[Pod C]
    end
    A1 -->|IP直连| A2
    A1 -->|IP直连| B1
    A2 -->|IP直连| B1

🧩 Kubernetes 网络模型的实现方式

在容器运行过程中，Kubernetes 网络模型可以通过多种方式落地，常见的包括：

使用自定义资源（CR）
借助容器网络接口（CNI）插件

其中，Multus CNI 插件是一种功能强大的网络扩展工具，它的工作方式类似“调度器”，可以调用其他 CNI 插件，从而实现更高级的网络功能，比如：在 OpenShift 集群中的 Pod 上绑定多个网络接口。

🔗 Multus CNI 在 OpenShift 中的应用

在 Red Hat OpenShift 中，Multus CNI 被用来“串联”多个 CNI 插件。使用 Multus 后，除了默认的 Pod 网络之外，我们还可以：

在集群安装期间配置额外网络
在集群运行过程中动态添加新网络

这种为虚拟机或 Pod 绑定多个网络接口的方式，称为 多宿主（multi-homing）。

flowchart TB
    VM[虚拟机 / Pod]
    Net1[默认网络 eth0]
    Net2[附加网络 net1]
    Net3[附加网络 net2]

    VM --> Net1
    VM --> Net2
    VM --> Net3

📌 注意事项：默认网络接口 eth0

虽然我们可以为 Pod 添加额外的网络接口，但每个 Pod 都必须保留一个连接到默认网络的 eth0 接口，以确保整个集群的网络连通性。

你可以在 Pod 内部使用如下命令查看当前绑定的网络接口：

1	oc exec -it pod_name -- ip address

🧵 多网络接口的命名规范（Multus CNI）

在使用 Multus CNI 插件为 Pod 添加多个网络接口时，这些附加接口需要遵循特定的命名规则：

所有非默认网络接口都采用 netN 的命名格式，其中 N 是一个从 1 开始的数字。

例如：

第一个附加接口命名为 net1
第二个为 net2
依此类推…

这种命名方式有助于统一管理和识别 Pod 中的多个网络接口，尤其在调试或配置网络策略时非常重要。

🎯 Multus CNI 的典型应用场景

在某些业务场景中，我们可能需要对网络进行隔离，以满足性能、安全或连接需求。此时，使用 Multus CNI 插件为 Pod 附加额外网络接口将非常有帮助。

以下是几个常见的用例：

🚀 提升性能：数据与控制面分离

对于网络密集型的工作负载，可以将数据面和控制面分别绑定到不同的节点接口，从而减少干扰、提升整体性能。

💡 示例：将数据库流量与管理指令分别走不同网卡，避免互相影响。

🔐 增强安全性：敏感流量隔离

将敏感数据流量隔离到专门管理的安全网络平面，确保这些信息不会在不同租户或客户之间被共享。

💡 示例：金融系统中的用户交易数据可通过专属网络传输，避免与其他业务混用。

🌍 连接外部网络：打通集群边界

Multus CNI 还可以帮助容器集或虚拟机连接到集群外部的网络，实现跨系统或跨环境的通信。

💡 示例：某业务 Pod 需要访问外部存储服务或第三方 API，可通过额外网络接口实现连接。

非常棒，Xiaohui！你这段内容信息量很大，涵盖了 Multus CNI 的实施原理、OpenShift 虚拟化的网络管理机制，以及多种 CNI 插件的用途。我已将其优化为更友好、结构清晰、适合教学展示的版本，便于学员理解和吸收：

🛠️ Multus CNI 的实施与应用

在 OpenShift 虚拟化环境中，我们可以借助 自定义资源定义（CRD） 和 CNI 插件（如 Multus CNI），为虚拟机提供更灵活的高级网络功能。

🧩 网络管理组件

CNAO（Cluster Network Addons Operator）
负责管理虚拟机中基于 Multus 的网络配置。
Multus CNI 插件
由 Kubernetes 网络工作组开发，通过 NetworkAttachmentDefinition 资源实现多网络支持。
NetworkAttachmentDefinition（网络附加定义）
是一种命名空间级别的对象，用于将现有的二层网络设备（如网桥、交换机）暴露给 Pod 和虚拟机使用。

💡 如果集群尚未部署 OpenShift 虚拟化 Operator，红帽建议使用 CNO（Cluster Network Operator） 来集中管理 Pod 的附加网络。
对于虚拟机，不需要修改 CNO 即可创建网络附加定义。

📌 如何添加额外网络接口

要为 Pod 或虚拟机添加额外网络接口，需先创建一个 NetworkAttachmentDefinition，用于定义该接口所使用的 CNI 插件及其配置。

🔌 OpenShift 支持的 CNI 插件类型（可与 Multus 串联）

插件类型	功能说明	适用场景
bridge	基于 Linux 网桥，允许同一主机上的 Pod 和虚拟机互联互通	内部通信、连接物理网络
host-device	直接独占访问主机上的物理网卡	高吞吐、低延迟场景，如电信应用
ipvlan	每个容器/虚拟机拥有独立 IP，共享主机 MAC	简化网络管理，适合高密度部署
macvlan	每个容器/虚拟机拥有唯一 MAC 地址	适用于需要唯一 MAC 的系统，如 DHCP、网络监控
SR-IOV	绑定到 SR-IOV 兼容硬件的虚拟功能接口	极致性能需求，如裸金属级网络加速

graph TD
    Bridge[bridge: 网桥通信]
    HostDevice[host-device: 独占物理网卡]
    IPVLAN[ipvlan: 共享 MAC，独立 IP]
    MACVLAN[macvlan: 唯一 MAC，物理通信]
    SRIOV[SR-IOV: 虚拟功能接口]

    Bridge -->|适合| 内部通信
    HostDevice -->|适合| 高吞吐低延迟
    IPVLAN -->|适合| 高密度部署
    MACVLAN -->|适合| 运维/许可系统
    SRIOV -->|适合| 极致性能场景

📌 注意：每种插件都需通过 NetworkAttachmentDefinition 进行配置，且可能有额外的系统要求。
在为虚拟机配置 bridge 网络前，需先将相关配置清单应用到集群，并确保 Linux 网桥已连接到虚拟机节点。

🧱 创建网络附加定义的两种方式

在 OpenShift 中，我们可以通过以下两种方式为虚拟机创建网络附加定义（NetworkAttachmentDefinition）：

🖥️ 方法一：使用命令行（CLI）

你可以通过编写并应用 YAML 清单文件，在命令行中创建网络附加定义。这种方式适合熟悉配置文件的用户，便于批量部署和版本控制。

🌐 方法二：使用 OpenShift Web 控制台

如果你更偏好图形界面操作，也可以通过 Web 控制台完成配置：

打开控制台，进入菜单路径：
Networking > Network Attachment Definitions
点击创建按钮，选择以下方式之一：
- 使用表单填写网络参数
- 切换到 YAML 编辑器，自定义网络配置

💡 小贴士：使用 YAML 编辑器可以更灵活地定义网络类型、插件参数等高级配置。

sequenceDiagram
    participant 用户
    participant CLI
    participant 控制台
    participant 集群

    用户->>CLI: oc apply -f net.yaml
    用户->>控制台: 表单或 YAML 编辑器
    控制台->>集群: 创建 NetworkAttachmentDefinition
    CLI->>集群: 创建 NetworkAttachmentDefinition

🧾 示例：创建 Linux 网桥的 NetworkAttachmentDefinition

以下是一个用于配置 Linux 网桥的网络附加定义 YAML 清单，适用于 OpenShift 虚拟化环境：

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: bridge-dev
  annotations:
    k8s.v1.cni.cncf.io/resourceName: bridge.network.kubevirt.io/bridge-dev
spec:
  config: '{
    "cniVersion": "0.3.1",
    "name": "bridge-dev",
    "type": "cnv-bridge",
    "bridge": "dev-bridge",
    "macspoofchk": true,
    "vlan": 0
  }'

📌 参数说明

字段	说明
`name`	网络定义名称，用于标识该附加网络
`type`	使用的 CNI 插件类型，此处为 `cnv-bridge`
`bridge`	指定的 Linux 网桥名称
`macspoofchk`	是否启用 MAC 地址伪造检查
`vlan`	VLAN ID，设置为 `0` 表示不使用 VLAN 分隔