Harvester 是 SUSE/Rancher 生态中的开源超融合基础设施平台。它面向裸金属服务器，把虚拟机管理、分布式块存储、虚拟网络、监控和 Rancher 集成放在同一套 Kubernetes 底座上。对于习惯 VMware vSphere、Proxmox 或 OpenStack 的团队，Harvester 最需要先理解的一点是：它不是“给 Kubernetes 加一个虚拟机页面”，而是把虚拟机作为 Kubernetes 资源进行管理，再用 KubeVirt、Longhorn、Multus、Rancher 和监控组件补齐传统虚拟化平台需要的能力。

本文是 Harvester 实战系列的第一篇。目标不是罗列功能清单，而是建立后续安装、虚拟机、存储、网络和运维文章共用的心智模型：哪些组件负责控制面，哪些组件负责虚拟机运行，哪些组件负责数据持久化，哪些组件负责网络接入，哪些边界不能混淆。

Harvester 解决的真实问题

传统虚拟化环境通常由计算服务器、共享存储、网络交换机、集中管理平台和备份系统组成。这个架构稳定，但也带来几个现实问题：存储阵列成本高，节点扩容和存储扩容节奏不同，虚拟化平台和 Kubernetes 平台割裂，边缘站点难以维护完整三层架构，自动化接口与云原生生态脱节。

Harvester 的思路是把标准 x86 服务器组成一个超融合集群。每台节点同时贡献计算资源、本地磁盘和网络接口；Longhorn 把本地磁盘组织成分布式块存储；KubeVirt 使用 KVM/QEMU 运行虚拟机；Kubernetes API 成为统一控制面；Harvester UI/API 把这些底层对象包装成虚拟化管理员可以理解的 VM、Volume、Image、Network、Snapshot、Backup 和 Host。

这种架构适合希望降低专用存储依赖、在边缘或中小型数据中心运行虚拟机、同时保留 Kubernetes/Rancher 管理能力的团队。它不意味着所有场景都应该替换成熟 vSphere 环境。对极大规模虚拟化、复杂企业许可、深度生态插件、传统备份矩阵和长期稳定运维团队来说，Harvester 需要通过试点验证，而不是凭“开源 HCI”四个字直接迁移生产。

Harvester 的价值来自统一。虚拟机、卷、网络、备份和主机状态都可以通过 Kubernetes 风格的对象和 API 被管理。团队可以逐步把虚拟机交付、网络配置、备份策略和资源治理纳入 GitOps、Terraform、Rancher 或自研平台。但统一也带来复杂度：排障时不能只看虚拟机控制台，还要理解 Kubernetes 事件、KubeVirt VMI、Longhorn Volume、Multus 网络和节点状态。

当前版本背景

本文按 Harvester v1.8 官方文档核验。官方 v1.8 Overview 页面说明，Harvester 是基于 Kubernetes 的现代开源 HCI，运行在裸金属服务器上，提供集成虚拟化和分布式存储能力；架构组件包括 SUSE Linux Micro 6.2、Kubernetes、KubeVirt、Longhorn、Grafana 和 Prometheus。官方页面同时列出 v1.8 为 Latest，v1.9 为 Dev，因此本文以 v1.8 稳定文档为主。

版本背景很重要。早期 Harvester 文章常提到 openSUSE MicroOS、K3s、旧安装路径或旧网络对象名。当前文档已经强调 SUSE Linux Micro 6.2、Kubernetes 底座和更明确的安装/网络/存储配置页面。后续执行安装或写自动化时，不应照搬旧教程里的镜像地址、配置字段和组件名称。

本系列不假设你已经有生产 Harvester 集群。第一篇讲架构；第二篇讲安装部署；第三篇讲虚拟机管理；第四篇讲存储；第五篇讲网络。每篇都围绕“可验证、可恢复、可排障”展开，而不是只演示 UI 操作。

核心架构：五层心智模型

Harvester 可以分成五层理解。

第一层是硬件层。它包括 CPU、内存、本地系统盘、本地数据盘、管理网卡、业务网卡、存储网络、交换机和电源。Harvester 是裸金属 HCI，硬件质量直接影响稳定性。CPU 需要支持硬件虚拟化，内存决定 VM 密度，本地磁盘决定 Longhorn 副本性能，网卡和交换机决定管理、存储、迁移和业务流量的边界。

第二层是操作系统层。官方 v1.8 文档说明，Harvester 使用 SUSE Linux Micro 6.2，并强调不可变 Linux 发行版用于减少 Kubernetes 集群中的 OS 维护。不要把 Harvester 节点当普通 Linux 服务器随意安装包、改系统文件或运行额外服务。节点越“干净”，升级和恢复越可控。

第三层是 Kubernetes 层。Harvester 的控制面、调度、对象存储、控制器和事件机制都依赖 Kubernetes。VM 在 Harvester 中不是孤立进程，而是由 Kubernetes 资源和控制器协调的工作负载。节点 NotReady、Pod 调度失败、CRD 异常、Webhook 失败，都会影响虚拟机生命周期。

第四层是虚拟化、存储和网络能力层。KubeVirt 负责把虚拟机带入 Kubernetes，Longhorn 负责分布式块存储，Multus 负责多网络附件，Harvester 的控制器负责把这些能力整合成易用对象。理解这一层，是后续排障的关键。

第五层是管理和集成层。Harvester UI 提供 Web 管理入口，API 支持自动化，Rancher 集成让 Harvester 可以承载 Rancher 管理的 Kubernetes 集群，Prometheus/Grafana 提供监控观测。生产落地时，Harvester 不应成为孤立平台，而应进入现有 CMDB、监控、备份、工单和权限体系。

KubeVirt：虚拟机运行模型

KubeVirt 是 Harvester 虚拟机能力的核心。它让 Kubernetes 能管理虚拟机对象，并通过 KVM/QEMU 在节点上运行虚拟机。对传统虚拟化管理员来说，可以把 KubeVirt 理解为“把 VM 生命周期纳入 Kubernetes 控制面”的组件；对 Kubernetes 管理员来说，可以把它理解为“用 CRD 和控制器管理非容器工作负载”的扩展。

虚拟机的静态定义和运行实例要区分。VirtualMachine 表示期望状态，VirtualMachineInstance 表示正在运行的实例。VM 能否启动，不只取决于 VM 自身配置，还取决于镜像、PVC、StorageClass、节点资源、网络附件、调度规则和 KubeVirt 组件状态。

Harvester UI 会隐藏很多底层复杂度，但排障时要知道背后对象。VM 卡在 Starting，可能是镜像卷没准备好；VM 启动后没有网络，可能是 NetworkAttachmentDefinition 或交换机 VLAN 问题；VM 迁移失败，可能是目标节点网络不覆盖、存储不健康、CPU model 不兼容或资源不足。

KubeVirt 模型的好处是 API 化和声明式。你可以通过 UI 创建 VM，也可以通过 Terraform、API 或 GitOps 交付标准 VM。代价是团队要学会从 Kubernetes 事件和对象状态中取证，而不能只依赖传统虚拟化平台的任务列表。

Harvester 核心组件关系

Longhorn：分布式块存储模型

Longhorn 是 Harvester 默认集成的分布式块存储。它把节点本地磁盘组织成可供 VM 使用的卷，并通过多副本提供节点级容错能力。Harvester 的很多“虚拟机问题”最终会落到 Longhorn：卷是否 attached，副本是否健康，节点磁盘是否满，Replica 是否在重建，备份目标是否可用。

理解 Longhorn 时，不要只看“有三副本就安全”。三副本意味着写入路径、网络复制、容量放大和恢复时间都会增加。一个 500GiB 数据卷使用 3 副本，实际需要约 1.5TiB 原始容量，还要考虑快照、备份、重建临时空间和未来增长。存储网络如果和业务网络争用，Replica 同步和 VM I/O 都可能受影响。

Longhorn 的优势是让中小规模环境不再依赖外部 SAN，也让边缘站点可以用本地磁盘构建可恢复的虚拟化平台。但它不是“无成本共享存储”。生产环境必须规划磁盘介质、节点数量、StorageClass、副本数、快照保留、备份目标、容量水位和恢复演练。

后续存储篇会详细讲 StorageClass、Volume、Snapshot、Backup、Storage Network 和外部 CSI。这里先建立一个原则：Harvester 存储不是 VM 的附属功能，而是整个平台可用性的核心。如果 Longhorn 不健康，VM 管理再顺也没有意义。

Multus 和网络模型

Harvester 的网络比单一桥接网络复杂。官方 v1.8 文档在 Overview 中说明，Harvester 支持 VIP 和多网卡；VM 需要连接外部网络时，可以创建 VLAN 或 untagged network。背后依赖的是 Kubernetes 网络、Multus、NetworkAttachmentDefinition、节点接口、交换机 trunk 和来宾系统路由。

生产环境至少要区分四类流量：管理流量、业务 VM 流量、Longhorn 存储流量和 VM 迁移流量。它们可以物理隔离，也可以 VLAN 隔离，但不能在文档和监控中混成一团。管理网络用于 UI/API、节点管理和控制面；业务网络承载 VM 对外访问；存储网络承载 Longhorn 副本；迁移网络承载 Live Migration。

网络排障不能只在 VM 内 ping 网关。要从 VM 网卡、Harvester VM Network、Cluster Network、Network Config、节点接口、Linux bridge 或 bond、交换机端口和上游网关逐层取证。多网卡 VM 还要检查默认路由、源地址选择和安全策略。

第五篇网络配置会深入讨论这些对象。第一篇只强调一点：Harvester 网络是平台设计的一部分，不是安装完成后再临时加几个 VLAN。网络规划越晚，后续存储、迁移和业务隔离越容易返工。

Rancher 集成的意义

Harvester 与 Rancher 的集成让它不只是一个虚拟机平台。官方 Overview 提到，Harvester 可以通过 Rancher 的 Virtualization Management 页面访问和管理 VM 工作负载，并且支持容器化环境。这一点对平台团队很有价值：同一个 Rancher 生态可以管理 Kubernetes 集群，也可以把 Harvester 作为承载 Kubernetes 节点或传统 VM 的基础设施。

常见模式是：Harvester 运行在裸金属上，提供虚拟机能力；Rancher 管理下游 Kubernetes 集群；部分 Kubernetes 节点可以运行在 Harvester VM 上；传统应用继续以 VM 方式运行。这样团队可以渐进式迁移，而不是一次性把所有传统应用容器化。

但 Rancher 集成也需要边界。Harvester 管的是虚拟化基础设施，Rancher 管的是 Kubernetes 集群生命周期。不要把 Harvester 当作普通 Kubernetes 工作负载集群来部署业务 Pod，也不要让 Rancher 自动化绕过 Harvester 的存储和网络治理。边界清楚，集成才会降低复杂度；边界混乱，会让故障跨越 VM、Kubernetes、存储和网络多层同时爆炸。

适用场景和不适用场景

Harvester 适合中小规模私有云、边缘站点、工厂现场、实验室、开发测试平台、希望统一 VM 和 Kubernetes 管理的组织，以及正在评估从传统虚拟化向云原生基础设施过渡的团队。它的开源生态、Rancher 集成和标准服务器硬件路线，对成本敏感或多站点部署场景尤其有吸引力。

Harvester 不适合一开始就承载所有关键生产负载。若环境高度依赖成熟商业虚拟化生态、复杂备份软件矩阵、存储阵列高级能力、特定厂商硬件兼容认证或大量第三方插件，迁移前需要做充分验证。Harvester 能提供 HCI 能力，但不自动替代已有平台多年积累的运维流程。

单节点 Harvester 可以用于学习和边缘小站，但不要把单节点当生产高可用。Longhorn 多副本、Kubernetes 控制面和管理 VIP 的价值都需要多节点才能体现。生产最小形态通常应从三节点开始，并明确硬件、网络、存储和备份边界。

对工厂、园区和边缘站点，Harvester 的优势是节点级一体化和远程管理。但边缘站点也更容易遇到网络不稳定、备份窗口短、硬件规格不统一和现场人员能力不足的问题。部署前要准备离线安装、远程控制、备份恢复、告警转发和硬件更换流程。

与传统虚拟化的差异

传统虚拟化平台通常把 VM 作为中心对象，数据存储、网络、主机和集群围绕 VM 展开。Harvester 则更接近 Kubernetes 世界：VM 是一种工作负载，底层由控制器、CRD、PVC、StorageClass、NetworkAttachmentDefinition 和节点调度共同决定。

在 vSphere 中，管理员习惯看 vCenter task、ESXi host、datastore、port group 和 vMotion。在 Harvester 中，除了 UI 任务，还要看 Kubernetes event、VMI、Pod、PVC、Longhorn Volume、Node、Network Config 和 Harvester Setting。这不是优劣差异，而是运维证据入口不同。

传统虚拟化中，共享存储通常是外部阵列或 vSAN；Harvester 默认用 Longhorn 基于本地磁盘提供分布式块存储。传统虚拟交换机由 ESXi 标准交换机或分布式交换机提供；Harvester 依赖 Kubernetes 网络、Multus 和节点/交换机配置。传统平台中的 VM 模板，对应到 Harvester 时要结合 image、cloud-init、SSH Key、StorageClass 和 Terraform 模块。

理解这些差异，可以避免把旧平台操作习惯硬套到 Harvester 上。Harvester 的正确落地方式不是“复制一套 vSphere 名词”，而是把虚拟化需求映射到 Kubernetes 原生对象和 Harvester 提供的上层抽象。

部署前的架构规划

部署 Harvester 前，至少要完成五类规划。

第一，节点规划。确定节点数量、CPU、内存、系统盘、数据盘、网卡数量和硬件一致性。生产集群建议至少三节点，节点规格尽量一致，避免调度和副本分布出现隐性差异。

第二，网络规划。确定管理 VIP、节点管理 IP、DNS、NTP、网关、业务 VLAN、存储网络、迁移网络、交换机 trunk 和 MTU。VIP 不是随便找一个空 IP，它会成为 UI/API 管理入口，必须纳入地址管理和高可用设计。

第三，存储规划。确定系统盘和数据盘边界、Longhorn 数据盘、StorageClass、默认副本数、快照策略、备份目标和容量水位。不要等 VM 创建后才发现默认 StorageClass 不符合生产要求。

第四，权限和身份规划。确定本地管理员、Rancher 集成、认证方式、审计要求和运维分工。虚拟化平台通常涉及多个团队，权限边界越早定义，后续越少返工。

第五，恢复规划。确定节点故障、磁盘故障、VM 误删、备份恢复、集群升级失败和管理 VIP 异常时的处置流程。HCI 平台的价值不只在创建 VM，而在故障后能恢复服务。

Harvester 部署架构规划

运维证据链

Harvester 的排障证据链要从对象关系出发。VM 问题先看 VirtualMachine 和 VMI，再看 Pod、Event、PVC、Volume 和网络附件；存储问题先看 Longhorn Volume、Replica、Node、Disk 和 StorageClass；网络问题先看 VM Network、Cluster Network、Network Config、节点接口和交换机；控制面问题先看节点 Ready、Harvester 系统组件和 Kubernetes API。

初学者最常见的错误是只看 UI 状态。UI 显示 VM Starting，只能说明期望状态没有完成；真正原因可能藏在 Kubernetes event、Longhorn volume attach、镜像下载、网络附件或节点调度中。生产排障应先取证，再修改。随意重启节点或删除对象，可能会掩盖根因。

监控也要覆盖多层。只监控 VM ping 不够，还要监控节点资源、Longhorn Volume health、Replica rebuild、磁盘容量、网络错误、KubeVirt 组件、Harvester 系统组件和备份任务。Prometheus/Grafana 提供基础观测能力，但告警规则需要按业务重要性调优。

Harvester 架构排障矩阵

生产落地路线

建议用四阶段落地。

第一阶段是实验环境。使用一到三台测试服务器验证安装、UI、基础 VM、镜像导入、StorageClass、VLAN 网络、快照、备份和恢复。这个阶段重点是理解对象，不要急着承载生产。

第二阶段是试点业务。选择非核心但真实的内部系统，建立标准镜像、cloud-init、备份策略、监控告警和恢复演练。试点必须覆盖一次节点维护、一次 VM 迁移、一次卷扩容和一次备份恢复。

第三阶段是平台化交付。把常用 VM 规格、网络、StorageClass、标签、备份等级和负责人字段固化为模板或 Terraform 模块。接入 CMDB、监控、工单和权限系统，减少人工 UI 操作。

第四阶段是规模化治理。建立容量预测、升级演练、硬件更换流程、灾难恢复计划和跨集群备份。此时 Harvester 才能从“能用的平台”变成“可运营的平台”。

关键数据路径

理解 Harvester 不能只看组件名称，还要看数据路径。第一条路径是 VM 启动路径。管理员在 UI 或 API 中创建 VM 后，Harvester 生成或更新 Kubernetes 资源；KubeVirt 控制器根据 VM 规格创建 VMI；Kubernetes 调度器选择节点；节点上的 virt-handler 和 kubelet 协调启动 QEMU/KVM；磁盘通过 PVC 和 Longhorn Volume 挂载；网络通过默认 Pod 网络或 Multus 附加网络接入。任何一个环节失败，VM 都可能无法 Running。

第二条路径是存储 I/O 路径。来宾系统写入虚拟磁盘，I/O 进入 QEMU/KVM，再到节点上的 Longhorn engine，随后写入多个 Replica。Replica 可能分布在不同节点的数据盘上。这个路径说明为什么存储网络、节点磁盘、Longhorn 副本状态和容量水位会直接影响 VM 性能。它也说明，单看 VM 内部磁盘利用率是不够的，平台侧还要看 Longhorn Volume、Replica、Engine、Disk 和 Node。

第三条路径是业务网络路径。VM 的网卡连接到 Harvester 中的网络对象，再映射到节点上的 Linux bridge、bond、VLAN 或其他数据面，最后进入物理交换机和上游网关。若业务网络不通，问题可能在来宾 IP、默认路由、VM Network、Cluster Network、Network Config、节点接口、交换机 trunk、VLAN 放行或安全策略。排障必须沿路径逐层排除。

第四条路径是控制面访问路径。管理员通过管理 VIP 访问 Harvester UI/API，Harvester 后端再调用 Kubernetes API 和相关控制器。VIP、DNS、证书、管理网关、控制面 Pod、API Server 和 etcd 都在这条路径上。管理入口不可用时，不代表 VM 一定停止运行；但如果控制面长期异常，后续调度、变更、备份和恢复都会受影响。

第五条路径是备份恢复路径。VM Backup 需要读取 VM、Volume、Snapshot、Backup Target、网络和对象存储状态。恢复时还要重新创建卷和 VM，并验证来宾系统启动、IP、DNS、业务端口和监控。备份成功只是路径的一半，恢复可用才是闭环。

容量估算方式

Harvester 容量规划不能直接把所有节点 CPU、内存和磁盘相加。CPU 需要考虑超分比例、VM 峰值、系统组件开销和迁移余量。内存更敏感，过度超分容易导致 VM 性能不稳定。生产环境应给 Harvester 系统组件、Longhorn、KubeVirt 和监控组件预留资源，不能把节点资源全部分配给 VM。

存储容量要按副本数放大。假设计划给 VM 提供 10TiB 可用数据盘，默认 3 副本就需要约 30TiB 原始数据盘容量，还要加上快照、备份暂存、Replica 重建和增长预留。若节点磁盘水位接近上限，Longhorn 重建副本时可能找不到合适位置，故障恢复能力反而下降。

网络容量也要单独估算。业务流量、存储副本、镜像导入、备份、恢复和 Live Migration 都会消耗网络。三节点小集群如果所有流量共用 1Gbps 管理口，测试可能能跑，生产一旦发生副本重建或备份窗口，就会影响业务 VM。至少应评估是否需要独立存储网络、迁移网络和业务 VLAN。

容量规划还要考虑故障余量。三节点集群要能承受一个节点维护或故障，就不能把所有节点长期跑到 80% 以上。节点故障后，剩余节点要承接 VM、Longhorn 副本重建和控制面负载。没有故障余量的集群，平时看起来资源充足，故障时会因为调度和副本无法重建而进入危险状态。

与 vSphere、Proxmox 和 OpenStack 的对照

和 vSphere 相比，Harvester 的管理模型更接近云原生，API 和 Rancher 集成更自然，存储更依赖本地盘和 Longhorn。vSphere 的优势在于成熟企业生态、硬件认证、备份软件支持和长期运维经验。Harvester 的优势在于开源、轻量、标准服务器、Kubernetes 生态和边缘部署便利。

和 Proxmox 相比，Harvester 更强调 Kubernetes 原生对象和 Rancher 集成；Proxmox 更接近传统虚拟化和集群管理工具，学习门槛对 Linux 虚拟化管理员可能更低。Harvester 在 VM 与云原生平台结合方面更自然，但底层对象链也更长，排障需要 Kubernetes 能力。

和 OpenStack 相比，Harvester 部署和日常运维通常更轻。OpenStack 能覆盖更复杂的 IaaS 多租户、网络和云平台能力，但组件数量、运维复杂度和团队要求更高。Harvester 更适合希望快速获得 HCI 虚拟化平台、并接受 Kubernetes 作为控制面的场景。

因此选型时不要只问“哪个功能更多”。更好的问题是：团队是否具备 Kubernetes 运维能力；是否接受 Longhorn 作为主存储；是否需要 Rancher 集成；业务规模是否适合 HCI；备份、监控、CMDB、工单和安全体系能否接入；出现故障时团队是否能沿 Kubernetes/KubeVirt/Longhorn/网络链路排查。

组织分工

Harvester 落地后，传统“虚拟化管理员一个人负责全部”的模式很难长期维持。平台团队需要负责集群、节点、升级、存储类、网络对象和监控；网络团队负责 VLAN、交换机 trunk、MTU、网关和安全域；应用团队负责 VM 内系统、应用一致性、业务端口和恢复验证；安全团队负责认证、权限、镜像基线和审计。

如果组织分工不清，最常见的问题是互相等待。VM 启动慢，应用团队认为平台有问题，平台团队认为来宾系统有问题；网络不通，平台团队看到 Network 对象 Ready，网络团队认为交换机已放行，最后发现是来宾默认路由错误。明确证据边界和责任边界，比单纯写操作手册更重要。

建议为 Harvester 建立四类运行手册：安装和扩容手册、虚拟机交付手册、存储和备份手册、网络和排障手册。每类手册都要包含前置条件、操作步骤、验证方法、失败回滚和责任人。系列后续文章可以作为这些手册的初稿。

安全边界

Harvester 是基础设施平台，安全边界要早设计。管理 UI/API 只应暴露给运维网络或跳板机，不应直接暴露到普通办公网。管理员账号要接入组织认证和最小权限，API Token 要有归属和过期策略。SSH 访问节点只用于运维和排障，不应成为日常配置入口。

镜像安全同样关键。公共云镜像、内部模板和迁移镜像都可能携带默认账号、旧 SSH host key、过期软件包或未清理的 cloud-init 状态。镜像导入后应有基线检查，模板化前要清理 machine-id、临时账号、日志和敏感文件。

网络安全不能只靠 VM 内防火墙。平台应从 VM Network、VLAN、安全域、上游防火墙和路由策略上做隔离。管理网络、存储网络、迁移网络和业务网络之间不应随意互通。尤其是存储网络，通常不应被业务 VM 访问。

备份安全也不能忽略。备份目标包含 VM 数据和系统状态，应有访问控制、加密、保留策略和恢复审计。勒索软件和误操作场景下，Longhorn 副本不能替代离线或异地备份。

升级和生命周期

Harvester 的生命周期管理包括节点、操作系统、Kubernetes、Harvester 组件、KubeVirt、Longhorn、Rancher 集成和 VM 工作负载。升级不是点击按钮后等待完成这么简单。升级前要确认版本路径、已知问题、备份、节点健康、Longhorn 状态、可用容量和维护窗口。

升级前应做预检查：所有节点 Ready，Longhorn Volume 没有 Degraded，备份任务可用，管理 VIP 正常，关键 VM 有恢复点，监控告警可用。升级中要观察节点轮转、系统 Pod、Longhorn 和 KubeVirt 组件。升级后要验证 UI/API、VM 启停、迁移、备份、恢复、网络和存储。

生命周期还包括硬件更换。HCI 平台中节点既是计算，也是存储。换盘、换网卡、换节点都可能影响 Longhorn Replica、节点标签、网络配置和调度能力。硬件操作必须和 Harvester 对象状态联动，不能按传统物理服务器维护习惯直接拔盘换机。

验收清单

第一，架构验收。能说清楚 Harvester 中 Kubernetes、KubeVirt、Longhorn、Multus、Harvester UI/API 和 Rancher 的职责；能解释 VM 启动、存储 I/O、业务网络和备份恢复路径；能识别每条路径上的关键证据。

第二，硬件验收。节点支持硬件虚拟化，系统盘和数据盘分离，数据盘介质符合预期，节点规格尽量一致，网络接口数量满足管理、业务、存储和迁移规划，电源和带外管理可用。

第三，网络验收。管理 VIP、节点 IP、DNS、NTP、网关、业务 VLAN、存储网络、迁移网络、交换机 trunk 和 MTU 都有文档；每个网络有用途和责任人；测试 VM 能覆盖目标节点和 VLAN。

第四，存储验收。默认 StorageClass、生产 StorageClass、副本数、磁盘标签、容量水位、快照保留、备份目标和恢复演练都明确。不能只验证能创建 VM，还要验证能恢复 VM。

第五，运维验收。监控、告警、日志、工单、CMDB、权限、备份、恢复和升级流程都有入口。至少完成一次 VM 创建、一次迁移、一次卷扩容、一次快照回滚和一次备份恢复演练。

从现有虚拟化平台迁移前要问的问题

很多团队关注 Harvester，是因为传统虚拟化平台成本、许可或扩容压力越来越大。但迁移不是把 VM 文件搬过去。迁移前至少要回答六个问题。

第一，当前 VM 的依赖是什么。每台 VM 关联哪些网络、IP、DNS、负载均衡、防火墙、备份策略、监控项、CMDB 记录和运维脚本。没有依赖清单，迁移后很容易出现“虚拟机启动了，业务不可用”的情况。

第二，存储语义能否接受。传统平台可能使用外部 SAN、阵列快照、存储复制或备份软件 CBT 能力。迁移到 Harvester 后，默认存储路径是 Longhorn 卷、快照和备份，能力边界不同。数据库、文件服务和高 I/O 工作负载需要单独验证。

第三，网络模型能否映射。vSphere port group、分布式交换机、VLAN、NSX、安全组和物理交换机配置，迁移到 Harvester 时要映射到 VM Network、Cluster Network、Network Config、节点接口和上游交换机。网络不是迁移后再补的事项。

第四，备份和恢复是否闭环。原备份软件是否支持 Harvester，是否改用 Harvester/Longhorn 备份，恢复到测试环境是否可用，RPO/RTO 是否满足业务要求。不能只验证迁移当天能开机。

第五，团队能力是否匹配。Harvester 需要 Kubernetes、KubeVirt、Longhorn、Linux 网络和存储排障能力。若团队完全没有这些能力，先做培训和试点，比直接迁移生产更稳。

第六，回退路径是什么。迁移失败时，是回退到旧平台，还是保留双运行窗口，还是只迁移可重建业务。每类业务要有不同策略。无状态测试 VM 可以快速迁移，核心数据库和域控类系统必须谨慎。

常见故障模式

Harvester 的故障模式通常不是单点的。一个 VM 启动失败，可能同时涉及镜像下载、PVC 绑定、Longhorn Volume attach、节点资源不足和网络附件。架构层面要把故障模式归类，后续排障才有顺序。

第一类是控制面故障。表现为 UI/API 不可用、节点 NotReady、系统组件异常、事件大量堆积。此时先确认管理 VIP、DNS、证书、节点状态和 Harvester/Kubernetes 系统 Pod，不要急着重启业务 VM。

第二类是存储故障。表现为 VM 启动慢、Volume Degraded、Replica 重建、PVC Pending、快照或备份失败。先看 Longhorn，再看节点磁盘、storage network、容量水位和最近变更。存储故障时盲目迁移 VM 可能加重副本重建压力。

第三类是网络故障。表现为 VM 能启动但业务不可达、迁移后网络异常、某些节点上的 VM 不通、特定 VLAN 不通。先判断是单 VM、单节点、单 VLAN 还是全局故障，再沿 VM、Network、节点接口、交换机和网关取证。

第四类是来宾系统故障。表现为平台层显示 Running，但应用不可用、guest agent 不通、cloud-init 未完成、文件系统未扩容、默认路由错误。此时平台侧只能证明 VM 在运行，仍需要进入来宾系统或应用监控定位。

第五类是流程故障。表现为资源无主、快照长期保留、备份从未恢复验证、网络变更无人确认、节点维护没有排空计划。这类问题短期不一定导致宕机，但会在真正故障时放大影响。架构治理的目标之一，就是提前发现流程故障。

常见误区

第一，把 Harvester 当普通 Kubernetes 集群运行容器业务。Harvester 底层是 Kubernetes，但定位是 HCI 和虚拟化平台，不应随意把业务 Pod 部署到控制集群中。

第二，把 Longhorn 三副本等同于备份。副本解决节点或磁盘级可用性，不解决误删、逻辑损坏、勒索软件或跨集群灾难。生产 VM 仍需要备份和恢复演练。

第三，把单节点实验结果外推到生产。单节点无法验证控制面高可用、Longhorn 副本、节点故障、迁移和管理 VIP 漂移。

第四，把网络配置留到最后。Harvester 的 VM 网络、存储网络和迁移网络都依赖节点和交换机规划，后补网络往往意味着停机和返工。

第五，只看 UI 不看底层对象。Harvester 的 UI 是入口，不是全部事实来源。Kubernetes、KubeVirt 和 Longhorn 对象状态才是排障证据。

学完本篇后的自测

读完这一篇，可以用几组问题检查自己是否真正理解架构。第一，创建一台 VM 时，哪些组件参与了调度、启动、磁盘挂载和网络接入？如果回答只有“Harvester UI”，说明还没有理解底层路径。第二，Longhorn 三副本能解决哪些故障，不能解决哪些故障？如果把副本当备份，后续存储设计会出问题。

第三，管理网络、业务网络、存储网络和迁移网络分别承载什么流量？哪些可以 VLAN 隔离，哪些应该考虑物理隔离？第四，Harvester 与 Rancher 的职责边界是什么？第五，VM Running 但业务不可用时，应从哪些对象收集证据？这些问题都能回答，才适合进入下一篇安装部署。

后续学习顺序建议是：先搭建一个可丢弃的测试集群，验证安装和基础 VM；再用三节点环境验证存储副本、网络 VLAN、Live Migration 和备份恢复；最后再讨论生产接入、权限、监控和迁移。不要跳过测试环境直接把 Harvester 当生产平台。HCI 平台的稳定性来自设计、验证和流程，而不是某个安装向导。

正式立项前，建议输出一份简短的架构评审文档，包含节点规格、网络划分、存储策略、备份目标、权限边界、监控范围和首批试点业务。文档不需要很厚，但必须让运维、网络、应用和安全团队对边界达成一致。

评审完成后，再进入安装部署阶段。

没有评审结论的集群，不应承载生产虚拟机。

先验证，再迁移。

先小范围试点，再扩大生产范围。

每一步都要留下验收记录。

责任人必须明确。

持续复盘。

小结

Harvester 是基于 Kubernetes 的开源 HCI 平台，核心架构由 SUSE Linux Micro、Kubernetes、KubeVirt、Longhorn、Multus、Harvester UI/API、Prometheus/Grafana 和 Rancher 集成组成。它适合希望用标准服务器构建虚拟化平台、降低外部存储依赖、统一 VM 与 Kubernetes 管理的团队，但需要建立新的运维心智模型。

后续文章会从安装部署开始，把这些架构概念落到具体操作：如何规划硬件和网络，如何创建集群，如何管理 VM、存储和网络，如何做排障和恢复。读完本篇后，至少应记住三点：VM 是 Kubernetes 资源，存储健康决定 VM 可用性，网络规划必须在安装前完成。

参考资料