05-Harvester 网络配置

1. 从“虚拟机能通”走向“网络可运营”

前四篇已经完成 Harvester 的架构、安装、虚拟机和存储管理。第五篇进入最容易出现跨团队故障的部分：网络配置。虚拟机创建成功却拿不到地址、同 VLAN 互通但访问不了网关、迁移后连接中断、某些节点上的虚拟机正常而另一些节点异常，这些现象通常不是单一组件故障，而是来宾系统、KubeVirt、Multus、Harvester 网络对象、主机 bond/bridge、物理交换机和上游路由共同作用的结果。

本文不把“在 UI 中新增一个 VLAN”当作终点，而是建立一套生产网络交付方法。读完后，你应该能够完成以下工作：

1. 解释 Management Network、Cluster Network、Network Config 和 VM Network 的职责边界。
2. 设计管理、业务、存储复制和虚拟机迁移流量的隔离方案。
3. 从交换机 trunk、主机接口、Harvester 对象到虚拟机操作系统逐层完成配置和验证。
4. 识别双网卡默认路由、MTU、节点覆盖、VLAN 放行和回程路径等高频问题。
5. 在网络变更前保存证据、设置回滚点，并在故障时按确定的顺序定位责任域。

本文于 2026-06-12 核对 Harvester v1.8 官方文档与 v1.8.0 发布信息。Harvester v1.8 提供 Management、VLAN 和 Untagged 三类虚拟机网络；VPC/Kube-OVN 相关能力仍属于实验特性，不应未经验证直接承担关键生产流量。命令示例用于展示检查方法，实际资源名称、接口名、地址和 VLAN 必须替换为现场值。

2. 先建立正确的网络对象模型

Harvester 的网络配置不是“一个网桥对应一个 VLAN”这么简单。生产排障时必须区分四个层次。

2.1 Management Network

mgmt 是集群部署时自动创建的 Cluster Network，始终覆盖所有主机。它承担集群内通信和平台管理任务，也为虚拟机提供默认的 management network。默认情况下，虚拟机的第一块网卡通常连接该网络，虚拟机可以在集群节点范围内通过它通信。

不要因为名称里有“management”就假设它天然等于企业管理网。它的实际可达范围取决于安装时绑定的物理接口、交换机 VLAN、网关和防火墙。小型实验环境可以让平台管理和虚拟机测试流量共用 mgmt，但生产环境如果把所有业务也压在这一平面，会造成三个问题：平台故障与业务故障互相放大、容量难以解释、变更无法按业务域隔离。

2.2 Cluster Network

Cluster Network 是一组网络配置和虚拟机网络的逻辑边界。它回答的是“哪些主机、通过哪一组物理网络能力，能够承载这一类网络”。除系统创建的 mgmt 外，可以创建业务专用、存储专用或迁移专用的 Cluster Network。

Cluster Network 本身不等于 VLAN，也不直接决定每台主机使用哪个接口。它更像一个可治理的网络域：网络管理员可以给一批硬件规格相同的节点配置同一套 Network Config，也可以对接口命名不同的节点使用另一套配置，但让它们归入同一个 Cluster Network。

2.3 Network Config

Network Config 定义节点如何接入某个 Cluster Network。它通过节点选择器确定覆盖范围，并配置物理接口、bond 模式和 MTU 等主机侧细节。只有被某个有效 Network Config 覆盖的节点，才能承载关联的 VM Network。

这也是“部分节点正常、部分节点异常”的常见根因。创建 VM Network 后，如果调度器把虚拟机放到未被 Network Config 覆盖的节点，网络附件就无法按预期工作。排障时不能只看 VM Network 是否 Ready，还要核对运行节点是否在 Network Config 的选择范围内、接口名是否存在、链路是否 Up、bond 成员是否一致。

2.4 VM Network

VM Network 是最终提供给虚拟机选择的网络。Harvester v1.8 文档列出三种类型：

VLAN Network 最适合企业生产网络，因为它可以让一组物理接口承载多个隔离的二层广播域。Untagged Network 更适合专用接口只承载单一网络的场景，但要特别小心交换机 native VLAN、PVID 和不同厂商术语的差异。

这张图的阅读顺序是从 Cluster Network 到 Network Config，再到 VM Network 和虚拟机。任何 VM 网络问题都可以沿这条链反向检查，避免在 UI、主机和交换机之间无序跳转。

3. 生产网络应该先分平面，再分 VLAN

网络设计的第一步不是确定 VLAN ID，而是明确流量性质。Harvester 集群至少存在四类流量：

“物理隔离”不是唯一正确答案。三节点中小型集群可以使用冗余的两口或四口 bond，再通过 VLAN 做逻辑隔离；大规模或高 I/O 集群可以为存储、迁移配置独立接口和交换机。选择时要同时考虑故障域、带宽、端口成本、布线复杂度和运维能力。

3.1 一个可落地的示例

假设三台 Harvester 节点各有 4 个 25GbE 接口：

• eno1、eno2 组成 mgmt bond，承载 VLAN 10 管理网。
• eno3、eno4 组成 workload bond，作为自定义 Cluster Network 的上联。
• VLAN 110 为生产应用，VLAN 120 为数据库，VLAN 130 为 DMZ。
• VLAN 210 用于 Longhorn Storage Network。
• VLAN 220 用于 VM Migration Network。

如果交换机和服务器端口有限，也可以让 VLAN 110、120、130、210、220 共用 workload bond，但要通过 QoS、监控和容量水位避免 Replica 重建与 VM 迁移同时抢占业务带宽。更重要的是，必须明确“链路冗余”和“交换机冗余”不是同一件事。两个接口如果都接在同一台交换机，bond 只能保护网卡和端口，不能保护交换机故障；跨两台交换机的聚合则要求交换机支持 MLAG、vPC、IRF、堆叠或等价机制，并由网络团队确认配置模型。

图中四种流量平面使用不同颜色。设计评审时应逐一回答：它走哪组物理接口、允许哪些 VLAN、由谁分配地址、谁负责监控、拥塞时优先级如何、故障后是否会影响平台控制。

4. 配置前必须完成的联合检查

Harvester 网络变更通常跨越虚拟化、网络、安全和应用团队。最危险的做法是由平台管理员先在 UI 中创建资源，再临时找网络团队放 VLAN。正确顺序是先形成一张可验证的网络交付单。

4.1 网络参数表

至少记录以下字段：

不要只记录“VLAN 110 已开”。还要确认该 VLAN 在所有目标交换机、上联链路、MLAG peer-link 和防火墙子接口上都存在。虚拟机可能在任意被覆盖节点上运行或迁移，如果只有两台节点的交换机端口放行 VLAN，故障会表现为随机性。

4.2 主机基线采集

变更前保存节点接口、地址、路由、bond 和 bridge 状态：

kubectl get nodes -o wide
kubectl get clusternetworks.network.harvesterhci.io
kubectl get networkconfigs.network.harvesterhci.io -A
kubectl get network-attachment-definitions.k8s.cni.cncf.io -A

在目标节点上检查：

ip -br link
ip -br address
ip route
nmcli connection show
nmcli device status
bridge link
bridge vlan show

命令输出应该作为变更记录的一部分。它不是为了制造大量日志，而是为了在异常时回答“变更前接口叫什么、哪个 bond 是 Up、原路由是什么、VLAN 表是否发生变化”。

4.3 交换机侧检查

不同厂商命令不同，但检查目标一致：

1. 两端接口速率、双工、FEC 和 MTU 一致。
2. 聚合组成员正确，LACP 状态正常。
3. trunk 允许目标 VLAN，native/PVID 没有冲突。
4. MAC 地址表能在预期端口学习到虚拟机 MAC。
5. 网关 SVI、VRRP/HSRP 或防火墙子接口状态正常。
6. DHCP relay、ACL、微隔离和防火墙策略已纳入目标网段。

5. 创建自定义 Cluster Network 与 Network Config

下面以 workload 网络为例。具体 UI 名称可能随小版本变化，实施时应以目标版本官方文档为准。

5.1 给节点建立可审计的选择范围

如果所有节点接口名称和布线一致，可以覆盖全部节点；如果节点硬件异构，应先使用标签分组：

kubectl label node harv-01 network.harvesterhci.io/workload=true
kubectl label node harv-02 network.harvesterhci.io/workload=true
kubectl label node harv-03 network.harvesterhci.io/workload=true

kubectl get nodes -l network.harvesterhci.io/workload=true

标签的价值在于把“哪些节点可以承载业务网络”从口头约定变成可查询状态。新增节点时，如果没有完成交换机和接口配置，就不要立即打上该标签。

5.2 创建 Cluster Network

在 Harvester UI 的 Networks 区域创建名为 workload 的 Cluster Network。创建后先不要急着建 VM Network，先确认对象 Ready：

kubectl get clusternetworks.network.harvesterhci.io workload -o yaml

重点查看状态条件、关联配置和错误信息。若对象未 Ready，应先解决它，不要继续叠加 VM Network。

5.3 创建 Network Config

为 workload 创建 Network Config，使用前面定义的节点选择器，绑定 eno3、eno4，并选择与交换机一致的 bond 模式。

Bond 模式选择不能只看“哪个性能高”：

创建后逐节点检查：

kubectl get networkconfigs.network.harvesterhci.io -A -o wide
kubectl describe networkconfigs.network.harvesterhci.io <network-config-name> -n <namespace>

再登录节点确认新增的 bond、bridge 和成员接口：

nmcli connection show
ip -br link
cat /proc/net/bonding/<bond-name>
bridge link

如果使用 LACP，还应在交换机侧检查聚合成员是否都进入 Collecting/Distributing 状态。Harvester UI 显示 Ready 不代表交换机聚合一定正确。

6. 创建 VLAN VM Network

当 Cluster Network 和 Network Config 都稳定后，再创建 VLAN VM Network，例如：

• 名称：prod-app-v110
• Cluster Network：workload
• VLAN ID：110
• 描述：生产应用区

创建后检查相关对象：

kubectl get network-attachment-definitions.k8s.cni.cncf.io -A
kubectl get vlanconfigs.network.harvesterhci.io -A 2>/dev/null || true
kubectl get virtualmachinenetworks.network.harvesterhci.io -A 2>/dev/null || true

CRD 名称可能因版本和资源实现变化而不同，优先通过 kubectl api-resources | grep -Ei 'network|vlan' 确认目标版本暴露的资源。不要把旧版本教程中的 CRD 名称当作永久接口。

6.1 先用最小测试虚拟机验证

生产接入前创建一台最小 Linux 测试 VM，只连接 prod-app-v110。建议验证：

ip -br link
ip -br address
ip route
cat /etc/resolv.conf
ping -c 3 10.110.0.1
ping -c 3 <same-vlan-test-host>
tracepath <upstream-service>

如果使用 DHCP，再检查租约和客户端日志：

journalctl -u NetworkManager --since "-15 min"
journalctl -u systemd-networkd --since "-15 min"

不要只用 ping 8.8.8.8 判断成功。至少分层验证同网段、网关、DNS、跨网段应用和回程路径。安全策略可能禁止 ICMP，但 TCP 服务正常；反之，能 ping 网关也不代表 DNS、NTP 和业务端口已放行。

6.2 调度到每个节点验证

网络必须在所有目标节点验证。可以通过节点选择器或亲和性依次让测试 VM 在不同节点启动，或者在维护窗口执行迁移。每次记录：

• VM 所在节点。
• 获取的 IP、MAC 和默认路由。
• 同 VLAN 与跨 VLAN 连通性。
• 交换机 MAC 地址学习端口。
• 丢包、延迟和 MTU 结果。

如果只在一台节点测试，无法发现接口名不一致、某条 trunk 漏放 VLAN、某个 bond 成员异常等节点局部问题。

这条流程把网络交付拆成可中止的阶段。任何阶段未通过都应停止扩展范围，而不是继续把更多虚拟机接入一个尚未验证的网络。

7. 双网卡虚拟机最容易踩中的默认路由问题

很多团队希望虚拟机同时连接 management network 和业务 VLAN：管理网用于平台访问，业务网用于正式流量。这个模型可行，但必须明确默认路由只能由一条路径承担。

假设：

• eth0 连接 management network，地址 192.168.10.50/24，网关 192.168.10.1。
• eth1 连接业务 VLAN 110，地址 10.110.0.50/24，网关 10.110.0.1。

如果两块网卡都通过 DHCP 下发默认网关，来宾系统可能根据 metric 选择业务网作为默认路由。平台管理员从 management 网 SSH 到 VM 时，请求从 eth0 进入，响应却从 eth1 返回，状态防火墙、反向路径过滤或上游路由会丢弃该流量，最终表现为“management IP 偶尔能通、重启后又不通”。

7.1 推荐做法

1. 明确主默认路由，一般由业务网承担。
2. 管理网不下发默认网关，或设置更高 route metric。
3. 需要从多个管理网段访问时，为管理网添加明确静态路由。
4. 检查 Linux rp_filter，不要在未理解安全影响时全局关闭。
5. 使用 cloud-init 或模板固化路由，而不是每台 VM 手工修改。

NetworkManager 示例：

nmcli connection modify "mgmt" ipv4.never-default yes
nmcli connection modify "business" ipv4.never-default no
nmcli connection modify "business" ipv4.route-metric 100
nmcli connection modify "mgmt" +ipv4.routes "192.168.20.0/24 192.168.10.1"
nmcli connection up "mgmt"
nmcli connection up "business"
ip route

Ubuntu Netplan 示例：

network:
  version: 2
  ethernets:
    enp1s0:
      addresses: [192.168.10.50/24]
      routes:
        - to: 192.168.20.0/24
          via: 192.168.10.1
          metric: 200
    enp2s0:
      addresses: [10.110.0.50/24]
      routes:
        - to: default
          via: 10.110.0.1
          metric: 100
      nameservers:
        addresses: [10.110.0.10, 10.110.0.11]

修改后使用 ip route get <client-ip> 检查响应将从哪块网卡发出。这个命令比只看路由表更直接。

8. Untagged Network 的适用边界

Untagged Network 让虚拟机流量以未打标签形式进入物理网络。它适用于专用接口连接 access 端口、边缘站点单一业务网、某些无法处理 VLAN tag 的旧设备集成场景。

使用前必须对齐三个概念：

• Harvester 侧认为该网络是 untagged。
• 交换机端口的 PVID/native VLAN 是目标业务 VLAN。
• 该链路上不能同时出现与设计冲突的 tagged/untagged 流量。

最常见故障是交换机一端把 VLAN 110 配成 tagged，Harvester 一端按 untagged 发送；或者 trunk 的 native VLAN 与目标 VLAN 不一致。此时抓包会看到 ARP 请求发出但没有正确响应。除非确实需要，生产中优先使用语义更清晰的 VLAN Network。

9. MTU：必须端到端一致

Jumbo Frame 可以降低高吞吐场景的包处理开销，但“主机接口设置 9000”并不等于端到端支持 9000。路径上的物理网卡、bond、bridge、交换机端口、peer-link、路由接口、防火墙、虚拟网卡和来宾系统都必须一致。

验证时使用禁止分片的探测：

# IPv4，1500 MTU 常用测试
ping -M do -s 1472 -c 3 <peer-ip>

# 9000 MTU 常用测试，实际可用载荷需考虑头部
ping -M do -s 8972 -c 3 <peer-ip>

tracepath <peer-ip>

如果小包正常、大包失败，重点检查 MTU。不要立即归因于防火墙。对于 Storage Network 和 Migration Network，MTU 不一致可能表现为迁移卡住、Replica 重建慢或特定负载超时，而普通 ping 仍然正常。

生产建议先统一使用 1500，只有在明确的性能目标、完整链路控制和监控条件下再启用 9000。混合 MTU 环境可以运行，但排障成本显著增加。

10. Storage Network 与 VM Migration Network

Harvester v1.8 提供专用 Storage Network 和 VM Migration Network 配置，用于隔离 Longhorn 存储流量和虚拟机迁移流量。

10.1 Storage Network

Storage Network 不是普通 VM Network 的别名。启用设置后，Harvester 会创建或更新相关 NetworkAttachmentDefinition，并重启 Longhorn 的 instance-manager、backing-image-manager 等组件。官方文档明确提示，变更会影响 Longhorn、Prometheus、Grafana、Alertmanager 和 VM Import Controller 等相关 Pod，而且配置完成后 Harvester 不会自动启动虚拟机。

因此它必须作为维护变更执行：

1. 完成 Cluster Network、Network Config、VLAN 和地址池准备。
2. 停止虚拟机及挂载 Longhorn 卷的相关工作负载。
3. 保存卷健康状态和备份。
4. 启用 storage-network，等待状态为 configured。
5. 检查 Longhorn 相关 Pod 是否获得附加网络。
6. 验证卷、监控、镜像和虚拟机后再恢复业务。

检查示例：

kubectl get settings.harvesterhci.io storage-network -o yaml
kubectl get pods -n longhorn-system -o wide
kubectl get network-attachment-definitions.k8s.cni.cncf.io -A

Harvester 文档还提示 Storage Network 的支持边界与 Longhorn Data Engine 版本有关。启用前必须核对目标 Harvester 版本和 Longhorn 引擎，不要直接照搬其他版本配置。

10.2 VM Migration Network

vm-migration-network 用于把 live migration 流量从默认 mgmt 网络隔离出去。启用时需要指定 VLAN、Cluster Network、IP Range 和排除地址。它适合迁移频繁、虚拟机内存较大或管理网络容量有限的集群。

变更后至少验证：

kubectl get settings.harvesterhci.io vm-migration-network -o yaml
kubectl get virtualmachineinstances.kubevirt.io -A -o wide
kubectl get virtualmachineinstancemigrations.kubevirt.io -A

随后选择一台非关键 VM 做迁移，观察迁移耗时、网络使用、VM 连通性和目标节点。只有对象状态成功还不够，还要确认迁移流量确实走预期接口。

11. 一套从虚拟机到交换机的排障顺序

网络故障最忌讳多人同时修改。建议固定按“虚拟机内部 → 虚拟机附件 → Harvester 对象 → 节点数据面 → 交换机 → 网关与安全策略”的顺序收集证据。

11.1 第一层：来宾系统

ip -br link
ip -br address
ip route
ip rule
ip neigh
ethtool <interface>
resolvectl status 2>/dev/null || cat /etc/resolv.conf

确认网卡是否 Up、MAC 是否与 Harvester UI 一致、地址来源是否正确、默认路由是否唯一、ARP/邻居表是否能解析网关。若没有 IP，区分 DHCP 未响应和静态配置未生效。

11.2 第二层：虚拟机和网络附件

kubectl get vm,vmi -A -o wide
kubectl describe vmi <vm-name> -n <namespace>
kubectl get network-attachment-definitions.k8s.cni.cncf.io -A

检查 VM 选择的网络、接口模型、Multus 附件和事件。若创建后立即失败，事件通常比应用日志更接近根因。

11.3 第三层：Cluster Network 与 Network Config

kubectl get clusternetworks.network.harvesterhci.io -o wide
kubectl get networkconfigs.network.harvesterhci.io -A -o wide
kubectl describe networkconfigs.network.harvesterhci.io <name> -n <namespace>
kubectl get nodes --show-labels

确认 VM 所在节点被配置覆盖。若故障只发生在某些节点，优先比较节点标签、接口名、bond 状态和交换机端口，而不是反复重建 VM。

11.4 第四层：节点 bridge、bond 和抓包

ip -br link
cat /proc/net/bonding/<bond-name>
bridge link
bridge vlan show
ip -s link show <interface>

需要抓包时，先从来宾系统和节点对应 bridge/bond 两侧观察 ARP、DHCP 和业务端口：

tcpdump -eni <interface> vlan 110 and arp
tcpdump -eni <interface> port 67 or port 68
tcpdump -eni <interface> host <vm-ip>

抓包的目标是判断包在哪一层消失，而不是无差别保存全部流量。生产环境应遵守数据安全要求，避免采集不必要的业务载荷。

11.5 第五层：交换机、网关和安全策略

网络团队应检查聚合状态、VLAN 允许列表、MAC 学习、ARP 表、网关接口、ACL 和防火墙会话。一个很有效的证据链是：

1. VM 发出 ARP 请求。
2. 节点上联可见带 VLAN 110 的 ARP。
3. 交换机在预期端口学习到 VM MAC。
4. 网关收到请求并返回响应。
5. 响应经过同一路径回到 VM。

证据在哪一步中断，责任域就大致明确。

这张决策图适合放进值班 runbook。先确定故障层级，再执行修复，可以减少平台、网络和操作系统团队互相等待。

12. 高频故障场景

12.1 VM Network Ready，但虚拟机无网络

可能原因：

• VM 所在节点未被 Network Config 覆盖。
• 交换机 trunk 未放行 VLAN。
• 来宾系统没有启用新网卡。
• DHCP relay 或地址池异常。
• bond 成员或 LACP 状态异常。

先确认 VM 节点和 Network Config 覆盖，再抓 ARP/DHCP。不要先删除网络对象。

12.2 同节点 VM 互通，跨节点不通

这通常说明虚拟网络内部附件正常，但物理上联存在问题。重点检查：

• 两个节点上联端口 VLAN 是否一致。
• MLAG/堆叠 peer-link 是否允许目标 VLAN。
• MAC 地址是否在错误端口漂移。
• 某个节点 bond 只有单成员工作。
• MTU 是否在跨交换机路径不一致。

12.3 迁移后业务中断

检查目标节点是否有相同 Network Config 覆盖，目标交换机是否放行 VLAN，以及上游设备是否及时更新 MAC 表。若业务依赖静态绑定、端口安全或 NAC，迁移后的 MAC 学习可能被限制。

12.4 双网卡 VM 管理地址不可达

先执行：

ip route
ip route get <management-client-ip>
sysctl net.ipv4.conf.all.rp_filter

如果响应走业务网，修复路由 metric 或添加管理网静态路由。不要用永久关闭防火墙来掩盖非对称路由。

12.5 小包正常，大文件或迁移失败

检查 MTU、丢包、接口错误计数和拥塞：

ip -s link
ethtool -S <interface>
ping -M do -s 8972 <peer-ip>

同时查看交换机 CRC、discard、pause frame 和队列丢弃。大流量问题经常被误判为存储或应用性能问题。

13. 网络变更的回滚设计

网络变更必须在执行前定义回滚，而不是失败后临时讨论。建议设置以下停止条件：

• 任一 Harvester 节点进入 NotReady。
• 管理 VIP 或 API 出现持续不可达。
• 目标节点 bond/bridge 未 Ready。
• 测试 VM 在任一目标节点无法访问网关。
• 丢包、错误包或延迟超过现场基线。
• Storage Network 或 Migration Network 状态未配置成功。

回滚动作按影响面从小到大：

1. 停止新 VM 接入，恢复测试 VM 到原网络。
2. 删除或禁用新 VM Network，不动已验证的 Cluster Network。
3. 恢复 Network Config 的节点选择或接口配置。
4. 恢复交换机 trunk、聚合或 MTU。
5. 对 Storage/Migration Network 按官方步骤禁用并确认组件恢复。

不要在同一个变更窗口同时修改 bond 模式、VLAN、MTU、网关和防火墙策略。变量越多，回滚越难。推荐分阶段交付：先建立物理链路和 Cluster Network，再创建 VLAN 网络，再迁移少量 VM，最后扩大范围。

14. DHCP、静态地址与 IPAM 的协同设计

虚拟机成功连接 VM Network 只代表二层接入完成，地址如何分配仍由来宾系统和外部网络服务决定。Harvester 不会替企业自动完成 DHCP 地址池、网关、DNS、地址保留和资产登记。生产中经常出现“网络已经通了，但地址治理失控”的情况：测试 VM 使用 DHCP 获得临时地址，后来被直接转成生产；克隆 VM 保留旧静态地址；恢复操作生成相同 MAC；CMDB 中记录的 IP 与实际租约不一致。最终故障看起来像网络不稳定，实质是地址生命周期没有被管理。

14.1 三种地址分配模式

对于多数企业虚拟机，DHCP Reservation 是较好的折中：网络团队在 IPAM 中分配地址并绑定虚拟机 MAC，系统团队通过 cloud-init 配置主机名、DNS 搜索域和必要路由。对于 DNS、NTP、目录服务、监控和网关类基础设施，可以使用静态地址，但必须由 IPAM 统一分配，禁止运维人员从网段中“挑一个看起来空闲的地址”。

14.2 cloud-init 与网络配置

创建 Linux VM 时，可以使用 cloud-init 注入网络配置。这样做的价值不只是减少手工操作，而是让地址、路由和 DNS 与虚拟机模板、自动化流水线和审计记录绑定。一个典型流程是：

1. 自动化平台向 IPAM 请求地址。
2. IPAM 返回 IP、掩码、网关、DNS 和地址记录编号。
3. 平台生成 cloud-init network data。
4. Harvester 创建 VM，并连接指定 VM Network。
5. VM 首次启动后回传主机名、IP 和 Agent 状态。
6. 自动化执行连通性检查，成功后写入 CMDB。

Netplan 静态配置示例：

network:
  version: 2
  ethernets:
    enp1s0:
      addresses:
        - 10.110.0.51/24
      routes:
        - to: default
          via: 10.110.0.1
      nameservers:
        search:
          - prod.example.internal
        addresses:
          - 10.10.10.10
          - 10.10.10.11

模板不能假设接口永远叫 eth0。不同镜像、固件和网卡模型可能呈现 ens3、enp1s0 等名称。应在目标镜像上验证 predictable network interface names，或使用 MAC 匹配和 set-name 明确接口。Windows VM 则要通过镜像初始化、Sysprep、PowerShell DSC 或配置管理工具完成同类治理。

14.3 DHCP 排障证据链

当 VM 获取不到地址时，按以下顺序确认：

1. 来宾系统是否发出 DHCP Discover。
2. 节点 bridge/bond 是否看到带正确 VLAN 的 Discover。
3. 交换机是否把广播转发到 DHCP Server 或 Relay。
4. DHCP Server 是否收到请求、是否有可用租约、是否返回 Offer。
5. Offer 是否沿相同 VLAN 回到 VM。
6. 来宾系统是否拒绝租约，或因旧租约、重复客户端 ID 导致异常。

Linux 中可使用：

sudo tcpdump -eni <vm-interface> port 67 or port 68
journalctl -u NetworkManager --since "-10 min"
cat /var/lib/NetworkManager/*.lease 2>/dev/null

克隆虚拟机后如果多个实例携带相同 machine-id、DHCP client-id 或 cloud-init 状态，DHCP 服务器可能把它们视为同一客户端。模板发布前应清理 /etc/machine-id、cloud-init 状态和持久化租约，并在克隆后确认每台 VM 获得唯一身份。

14.4 DNS 与反向解析

生产验收不能止于 IP 可达。应用、中间件、证书、Kerberos、监控和备份系统经常依赖正反向 DNS。每个生产 VM 至少验证：

getent hosts <service-fqdn>
dig +short <service-fqdn>
dig +short -x <vm-ip>
resolvectl query <service-fqdn> 2>/dev/null

如果使用 DHCP 动态更新 DNS，要确认租约释放、VM 删除和恢复后旧记录会被清理。恢复到隔离测试环境时，不应让测试 VM 抢占生产 DNS 名称。建议在恢复流程中自动修改主机名、禁用动态 DNS 更新，或使用独立测试 DNS 域。

15. 网络安全不应只依赖 VLAN

VLAN 提供二层广播域隔离，但不是完整的安全边界。攻击者一旦进入同一 VLAN，仍可能扫描、横向移动或利用错误开放的管理端口。Harvester 网络交付必须与防火墙、身份认证、主机加固和日志审计结合。

15.1 安全域设计

一个常见的最小分区可以包括：

• 平台管理区：Harvester UI、API、SSH 和运维工具，仅允许跳板机和受管终端访问。
• 基础服务区：DNS、NTP、目录、监控、备份和自动化控制器。
• 生产应用区：按业务系统或敏感等级进一步划分。
• 数据库区：只允许应用服务器和受控运维入口访问。
• DMZ：面向外部或合作方的服务，由防火墙双向控制。
• 测试区：与生产凭据、数据和管理平面隔离。
• 备份恢复区：限制写入入口，防止勒索攻击同时破坏生产和备份。

不要给每个小应用都创建独立 VLAN，导致网络策略和运维成本失控；也不要把所有生产服务放进一个大二层。合适的粒度应由数据敏感性、东西向通信、故障域和管理团队共同决定。

15.2 管理入口保护

Harvester 管理 VIP 和节点管理地址应满足：

1. 不直接暴露到互联网。
2. 通过跳板机、VPN 或零信任访问代理进入。
3. 使用最小权限账户和多因素认证能力。
4. API 调用使用独立服务账户并限制凭据范围。
5. 防火墙记录管理访问，异常扫描和失败登录触发告警。
6. 节点 SSH 只用于受控排障，日常操作优先通过平台和 Kubernetes 审计路径。

如果平台管理与 VM 业务流量共用物理链路，也应通过 VLAN 和上游策略隔离。业务 VM 不应因为“同在一套虚拟化平台”就能访问 Harvester API、节点 SSH 或 Longhorn 管理接口。

15.3 东西向访问控制

传统防火墙通常擅长南北向流量，但同 VLAN VM 之间可能不经过防火墙。若业务要求细粒度隔离，可以考虑：

• 按安全域拆分 VM Network，让跨域流量经过防火墙。
• 在来宾操作系统启用主机防火墙。
• 使用应用身份、服务网关或代理控制关键访问。
• 对实验性的 Kube-OVN/VPC 能力先验证功能标签、升级兼容和支持边界。

安全策略必须可测试。为每个网络维护一张“允许”和“拒绝”用例表，例如应用服务器允许访问数据库 5432，但禁止访问数据库管理 SSH；监控允许采集 Agent 端口，但不能访问业务管理后台。验收时同时验证应通和不应通，避免只检查开放路径。

16. 容量、性能与故障域验证

网络上线初期能通，不代表在 Replica 重建、批量备份、镜像导入和 VM 迁移同时发生时仍能稳定。生产验收应覆盖正常负载和受控压力。

16.1 建立基线

建议记录以下指标：

• 每个物理接口和 bond 的吞吐、丢包、错误包、队列丢弃。
• VM 到同网段、网关和关键服务的延迟与抖动。
• 大包和小包下的有效吞吐。
• Storage Network 的 Replica 重建带宽。
• Migration Network 的迁移耗时和业务中断时间。
• 交换机端口利用率、buffer discard、CRC 和 LACP 状态。

可以在隔离测试 VM 之间使用 iperf3 建立基线，但不要把单次结果当作平台承诺：

# 服务端
iperf3 -s

# 客户端，单流
iperf3 -c <server-ip> -t 30

# 多并发流，观察聚合链路利用
iperf3 -c <server-ip> -P 4 -t 30

# 反向测试
iperf3 -c <server-ip> -R -t 30

测试应记录 VM 所在节点、CPU 限制、网卡模型、MTU、并发数和网络路径。不要伪造或移植其他环境的吞吐数字。真正有价值的是同一环境在变更前后、不同节点和故障切换时的可比结果。

16.2 验证链路故障

在批准的维护窗口内，可以对非关键测试环境执行：

1. 关闭一个 bond 成员端口。
2. 观察节点、bond、交换机和监控告警。
3. 持续运行 ping、TCP 会话和 iperf3。
4. 记录切换时间、丢包数量和会话影响。
5. 恢复端口，确认链路重新加入但没有 MAC 抖动。

如果使用 LACP，再分别验证单成员故障和一台交换机故障。很多方案在单端口故障时正常，但 MLAG peer-link、LACP system-id 或上游路由设计错误会在整机故障时暴露。

16.3 验证节点维护与 VM 迁移

选择一台具有业务 VLAN 的测试 VM，持续执行：

ping <gateway>
curl --connect-timeout 2 http://<test-service>/health

触发迁移后记录源节点、目标节点、迁移对象状态、连接中断和交换机 MAC 更新。若迁移网络独立，还要确认流量走预期接口。迁移成功后重复 DNS、路由、MTU 和业务端口测试，避免只看 VM 状态为 Running。

16.4 避免流量风暴

Replica 重建、镜像下载、备份、批量开机和迁移都可能产生突发流量。治理措施包括：

• 把高带宽维护任务错峰。
• 为存储和迁移流量配置独立网络或 QoS。
• 限制同时迁移的 VM 数量。
• 监控接口水位，在达到阈值前暂停非关键任务。
• 新增节点后先验证所有 VLAN 和 MTU，再允许调度生产 VM。

17. 一个跨团队交付案例

某制造企业准备把 MES 接口服务、报表服务和运维跳板机迁入三节点 Harvester。最初方案只提出“新增 VLAN 310 并让 VM 上线”，评审后发现需求实际包含三种安全域：MES 应用区、数据库访问区和运维管理区。如果把三类 VM 放进同一 VLAN，跳板机和报表服务将拥有不必要的横向访问能力。

项目组最终采用以下步骤。

第一阶段，资产与流量盘点。应用团队列出每台 VM 的源、目的、端口、DNS、NTP 和外部依赖；网络团队把它们转换成安全域和防火墙策略；平台团队确认节点接口和容量。最终确定 VLAN 310 为 MES 应用区、VLAN 320 为报表区、VLAN 390 为运维区。

第二阶段，底层网络交付。两台冗余交换机建立 MLAG，三台 Harvester 节点的业务接口组成 LACP bond，trunk 放行 310、320、390。网络团队逐端口验证 LACP、VLAN 和 MTU，并把配置版本归档。

第三阶段，Harvester 对象创建。平台团队创建 workload Cluster Network 和覆盖三台节点的 Network Config，再分别创建 prod-mes-v310、prod-report-v320、ops-v390。每创建一个网络都先用测试 VM 在三台节点轮流验证，不同时上线多个网络。

第四阶段，地址和安全策略。IPAM 分配地址，DHCP Reservation 绑定 VM MAC；防火墙只允许 MES 接口服务访问指定数据库和上游 ERP，报表服务只能读取报表库，运维区可通过受控端口管理两类服务。验收同时执行允许与拒绝测试。

第五阶段，迁移与观察。先迁移非关键报表服务，观察一天后再迁移 MES 接口服务。迁移期间监控 bond 利用率、交换机丢弃、VM 延迟和防火墙会话。最后执行一次节点维护迁移，确认 VM 到目标节点后 VLAN 和 MAC 学习正常。

这个案例说明，Harvester 网络交付的价值不在于“比传统虚拟化多几个对象”，而在于把节点覆盖、物理接口、业务网络和虚拟机附件显式化。只要联合网络、IPAM、安全和应用依赖进行设计，就能把随机故障转化为可审计的交付流程。

18. 生产运维基线

18.1 配置治理

• 每个 Cluster Network 有明确用途、负责人和节点覆盖范围。
• Network Config 使用节点标签，不依赖口头约定。
• VM Network 名称包含环境、业务域和 VLAN，例如 prod-app-v110。
• VLAN、网段、网关、DHCP、DNS 和安全策略同步登记到 IPAM/CMDB。
• 新增节点只有在交换机、接口和验证完成后才加入业务网络标签。

18.2 可观测性

• 监控节点接口、bond 成员、错误包、丢包和带宽。
• 监控交换机聚合、端口错误、MAC 漂移和 VLAN 状态。
• 记录 VM 到节点、MAC、IP、Network 和 VLAN 的关系。
• 对 Storage Network、Migration Network 和关键 VM 网络建立可用性测试。
• 保存网络对象状态和变更前后快照，便于复盘。

18.3 安全

• 平台管理网络只允许跳板机、运维终端和必要系统访问。
• 生产、测试、DMZ 和基础服务使用独立安全域。
• 不因为虚拟化平台内部互通就跳过防火墙和最小权限设计。
• 抓包、日志和配置导出按数据分类要求保存。
• 实验性的 VPC/Kube-OVN 功能先在隔离环境验证支持边界、升级路径和回滚。

19. 一个完整的验收清单

对象与节点

• [ ] Cluster Network 状态 Ready。
• [ ] Network Config 覆盖所有预期节点。
• [ ] 每个节点接口名、bond 成员和 MTU 一致。
• [ ] VM Network 与 VLAN、Cluster Network 的映射正确。
• [ ] 测试 VM 能在每个目标节点启动。

二层与三层

• [ ] 交换机 trunk 在所有路径放行目标 VLAN。
• [ ] MAC 地址在预期端口学习，无异常漂移。
• [ ] VM 可访问同网段、网关和必要跨网段服务。
• [ ] DHCP、DNS、NTP 和业务端口正常。
• [ ] 双网卡 VM 默认路由和回程路径符合设计。

性能与韧性

• [ ] MTU 端到端验证通过。
• [ ] 单链路故障时 bond 按预期切换。
• [ ] VM 迁移到其他节点后网络保持可用。
• [ ] 大流量时业务、存储和迁移平面无不可接受的争用。
• [ ] 监控可以发现接口错误、丢包和带宽水位。

变更与恢复

• [ ] 变更前状态、交换机配置和地址规划已归档。
• [ ] 停止条件和回滚负责人明确。
• [ ] 试点 VM 验证后再扩大范围。
• [ ] Storage/Migration Network 变更按维护窗口执行。
• [ ] 验收结果写入运行手册和 CMDB。

20. 总结

Harvester 网络配置的核心不是创建 VLAN，而是把虚拟机网络变成可解释、可验证、可迁移和可排障的服务。Cluster Network 定义逻辑网络域，Network Config 决定哪些节点通过哪些物理接口接入，VM Network 把 management、VLAN 或 untagged 网络交付给虚拟机；物理交换机、来宾系统路由和安全策略则决定这条链路最终能否工作。

生产环境应先划分管理、业务、存储和迁移流量，再选择物理隔离或 VLAN 隔离。配置时从交换机和节点基线开始，逐步创建对象，用测试 VM 覆盖每个节点，并验证二层、三层、DNS、业务端口、MTU和回程路径。故障时坚持从来宾系统到网络附件、Harvester 对象、节点数据面、交换机和网关逐层收集证据，避免无序修改。

下一篇将进入 镜像管理，重点讨论镜像来源、导入、缓存、版本治理、校验、模板化和故障排查。

参考资料

• Harvester v1.8 - Cluster Network
• Harvester v1.8 - VM Network
• Harvester v1.8 - Network Best Practice
• Harvester v1.8 - Network Deep Dive
• Harvester v1.8 - Storage Network
• Harvester v1.8 - VM Migration Network
• Harvester v1.8 - Virtual Private Cloud
• Harvester GitHub Releases