上一篇建立了 Harvester 的架构心智模型：裸金属节点提供计算、磁盘和网络，Kubernetes 是控制面，KubeVirt 运行虚拟机，Longhorn 提供分布式块存储，Multus 承载多网络，Harvester UI/API 把这些能力包装成虚拟化平台。本篇进入安装部署。重点不是“把 ISO 写进 U 盘然后下一步”，而是把安装前规划、配置文件、首节点创建、节点加入、管理 VIP、首次健康检查和回滚条件做成可复验流程。

本文按 Harvester v1.8 官方安装、硬件网络要求和配置文档核验。官方文档显示 v1.8 是 Latest，v1.9 为 Dev；Harvester Configuration 文档明确区分 CREATE 和 JOIN 模式，创建集群时 server_url 应为空或省略，加入集群时必须配置指向集群 VIP 或域名的 server_url。旧教程中基于早期版本的 ISO 地址、配置字段和 RKE2 端口假设不能直接照搬。

安装目标和环境边界

本篇以三节点裸金属集群为主要目标。单节点安装可以用于学习和功能验证，但不用于生产高可用。三节点集群可以验证控制面、管理 VIP、Longhorn 多副本、节点维护和基础迁移路径，是进入生产试点前的最低有效形态。

安装前要先确定四个边界。第一，硬件边界：每台节点的 CPU、内存、系统盘、数据盘、网卡数量和带外管理能力。第二，网络边界：管理网络、业务网络、存储网络、迁移网络、DNS、NTP、网关、MTU 和交换机 VLAN。第三，存储边界：系统盘和 Longhorn 数据盘是否分离，默认 StorageClass 是否适合生产，是否需要专用 storage network。第四，运维边界：谁负责安装，谁维护交换机，谁维护备份目标，谁批准 VM 上线。

不要把安装向导当规划工具。安装向导只能接受输入，不能替你判断管理 VIP 是否冲突、交换机 trunk 是否放行、NTP 是否可达、数据盘是否会被误格式化、Token 是否会泄露。真正的安装工作从规划表开始，而不是从开机启动 ISO 开始。

硬件和网络前置检查

硬件检查至少包含 CPU 虚拟化、内存容量、系统盘、数据盘和网卡。CPU 必须开启硬件虚拟化；内存要给系统组件、Longhorn、KubeVirt 和 VM 预留；系统盘不应和业务数据盘混用；数据盘应使用稳定 SSD/NVMe；网卡要能满足管理、业务、存储和迁移流量的隔离需求。

磁盘检查不能只看容量。要确认安装目标盘、数据盘、磁盘序列号和控制器。安装会写入系统盘，数据盘会被 Harvester/Longhorn 使用。生产部署前应把磁盘用途贴到服务器资产表和安装记录中，避免装错盘。若节点已有旧系统或旧 Longhorn 数据，必须在维护窗口中确认是否清空。

网络检查要覆盖 IP、交换机和时间同步。管理 IP、VIP、节点主机名、DNS 记录、NTP 服务器、默认网关、业务 VLAN、存储 VLAN 和迁移 VLAN 都要提前确定。管理 VIP 必须在管理网段中未被占用，并且能从运维终端访问。交换机端口要提前配置 trunk 或 access，不能等安装失败后再猜。

对三节点集群，建议先准备这样的表格：

项目 节点 1 节点 2 节点 3
主机名 hv-01 hv-02 hv-03
管理 IP 10.10.10.11/24 10.10.10.12/24 10.10.10.13/24
管理 VIP 10.10.10.20 10.10.10.20 10.10.10.20
存储 IP 10.10.20.11/24 10.10.20.12/24 10.10.20.13/24
系统盘 /dev/nvme0n1 /dev/nvme0n1 /dev/nvme0n1
数据盘 /dev/nvme1n1 /dev/nvme1n1 /dev/nvme1n1
管理接口 bond0 或 eno1 bond0 或 eno1 bond0 或 eno1
存储接口 bond1 或 eno2 bond1 或 eno2 bond1 或 eno2

表格中的设备名只是示例，实际环境必须以现场 ip link、BMC 资产信息和安装介质识别结果为准。不要把示例中的 IP、网卡名和磁盘名复制到生产。

安装方式选择

Harvester 支持 ISO、USB、PXE/iPXE 和配置文件驱动的自动安装。实验环境可以用 ISO 交互安装；多节点生产建议至少准备配置文件，保证主机名、接口、磁盘、VIP、Token、DNS 和 NTP 可复验；批量边缘站点或多机房交付则更适合 PXE/iPXE。

交互式 ISO 安装的优点是直观，适合首次学习。缺点是容易出现人工输入不一致，例如主机名格式、DNS、网卡选择和数据盘选择不同。自动安装的优点是可重复，缺点是配置文件包含 Token、密码或 SSH Key，必须安全保存。官方 Harvester Configuration 文档也提醒配置文件包含凭据，不应公开暴露。

如果团队刚开始使用 Harvester，建议先用交互式方式完成一套测试环境，再把实际输入整理成配置文件。直接从网上复制一份自动安装 YAML 风险很高，因为字段含义、版本行为和本地网络都可能不同。

配置文件的关键字段

Harvester Configuration 文档给出了完整示例和字段说明。安装相关核心字段包括 scheme_version、server_url、token、os 和 install。其中 server_url 最容易被误用：创建新集群时必须省略或为空；加入已有集群时才配置为集群 VIP 或域名，例如 https://cluster-VIP:443。官方文档强调，为了高可用，应指定 Harvester 集群 VIP 或域名。

token 是集群 secret 或 node token，用于节点加入。它属于敏感信息。配置文件、截图、日志和工单中都不应明文公开 Token。若配置文件放在 HTTP 服务器上供自动安装读取，必须保证网络隔离、访问控制和生命周期管理，安装结束后及时撤下。

os 字段用于主机名、SSH authorized keys、DNS、NTP、代理、标签和必要的系统级设置。不要通过 after_install_chroot_commands 随意安装大量软件。Harvester 节点不是通用 Linux 服务器，节点上越多自定义内容，升级和排障越不可控。确实需要持久化系统修改时，要确认官方文档中的持久化机制和升级影响。

install 字段用于安装模式、管理接口、安装目标盘、数据盘、VIP、Pod/Service CIDR 和插件开关等。生产配置应明确写入安装目标盘和数据盘，避免安装器自动选择导致误格式化。Pod CIDR 和 Service CIDR 要避免与现有网络、VM 网络和业务网段冲突。

下面是简化的配置片段，仅表达字段关系，不作为可直接执行的生产配置：

yaml
scheme_version: 1
server_url: ""
token: "REPLACE_WITH_CLUSTER_SECRET"
os:
  hostname: hv-01
  ssh_authorized_keys:
    - "ssh-rsa REPLACE_WITH_PUBLIC_KEY ops@example"
  dns_nameservers:
    - 10.10.10.53
  ntp_servers:
    - 10.10.10.123
install:
  mode: create
  management_interface:
    interfaces:
      - name: eno1
    method: static
    ip: 10.10.10.11/24
    gateway: 10.10.10.1
  device: /dev/nvme0n1
  data_disk: /dev/nvme1n1
  vip: 10.10.10.20

加入节点时，mode 改为 join，server_url 指向管理 VIP 或域名，主机名、管理 IP 和数据盘按节点变化。不要让多个节点使用同一主机名或同一管理 IP。

首节点创建

首节点安装前，先完成 ISO 校验。下载地址应来自官方发布页面或组织内部镜像仓库，校验值要和官方发布信息匹配。不要使用来历不明的 ISO。制作 USB 启动盘时，必须确认目标设备路径，避免误写本机磁盘。生产环境更建议通过带外管理挂载 ISO，减少现场 U 盘不可控因素。

首节点安装选择 create 模式。关键输入包括安装目标盘、数据盘、管理接口、IP/DNS/网关、主机名、管理 VIP、Token 或密码、SSH Key。输入完成后不要急着确认，先与安装计划表逐项核对。尤其要确认磁盘和接口名称，因为它们在不同服务器型号上可能不同。

安装完成后，首节点会启动 Harvester 控制面和基础组件。此时不要立即开始创建 VM。先确认节点状态、管理 VIP、UI/API、系统 Pod、Longhorn、KubeVirt 和监控组件是否健康。若首节点本身不健康，继续加入其他节点只会扩大问题范围。

首节点健康检查建议包括：

bash
kubectl get nodes -o wide
kubectl get pods -A | grep -v Running
kubectl -n harvester-system get pods
kubectl -n longhorn-system get pods
kubectl -n kubevirt get pods

这些命令需要在具备访问权限的节点或管理终端执行。文章不提供固定“预期输出”，因为不同版本和插件会改变 Pod 名称和数量。验收重点是节点 Ready、关键命名空间无异常、管理 VIP 可访问、UI 登录正常、Longhorn 和 KubeVirt 组件状态稳定。

加入第二、第三个节点

新增节点使用 join 模式。加入前要确保首节点健康，管理 VIP 或域名可达，Token 正确，新增节点的管理网络和 DNS/NTP 可用。官方配置文档说明，join 模式必须设置 server_url，并且高可用场景应使用 VIP 或域名，而不是临时指向某个节点的普通 IP。

加入节点时，不要只看安装器完成。节点加入后要确认 Kubernetes Node Ready、Longhorn 识别数据盘、KubeVirt 节点组件运行、Harvester UI 中 Host 状态正常。若某个节点 Ready 但 Longhorn 磁盘不可用，VM 调度可能能成功，存储副本却无法按预期分布。

三节点全部加入后，先不要直接导入生产 VM。应做基础故障域验证：关闭或维护一个非关键节点，观察管理 VIP 是否仍可访问；创建测试 VM，验证能运行；检查 Longhorn Volume 副本分布；把测试 VM 迁移到其他节点；恢复节点后确认副本重建正常。只有这些基础能力正常，集群才具备继续配置的前提。

管理 VIP 和访问入口

管理 VIP 是 Harvester UI/API 的稳定入口。它必须在管理网络中唯一、可路由、可被运维终端访问，并纳入 DNS 和 CMDB。不要把某个节点 IP 当长期管理入口。节点维护或故障时，节点 IP 可能不可用，而 VIP 才是集群入口。

VIP 也涉及安全。UI/API 不应暴露到普通业务网或公网。访问应通过运维网、跳板机、VPN 或零信任入口。证书也要规划。测试环境可以接受自签证书，生产环境应评估组织 CA、证书续期和浏览器/API 客户端信任链。

如果 VIP 不可用，先判断是 VIP 未漂移、网络 ARP/路由问题、kube-vip 组件异常，还是控制面服务异常。不要直接重装节点。VIP 只是访问入口，背后依赖节点网络、Harvester 设置、系统组件和交换机行为。

安装后的第一批配置

安装完成后的配置不能拖到业务上线后再做。至少要完成认证、时间、存储、网络、备份、监控和日志边界。

认证方面，先更改默认密码或导入组织认证方案，明确管理员账号和审计要求。SSH Key 要统一管理，不要让多人共用个人临时 Key。

时间方面，所有节点必须同步 NTP。虚拟化平台时间漂移会影响证书、日志、备份、Kubernetes 控制面和来宾系统。NTP 不稳定时，很多问题会表现得像随机故障。

存储方面，确认默认 StorageClass、副本数、数据盘、Longhorn 节点和容量水位。不要在默认设置未评审的情况下创建大量 VM。若生产计划使用独立 storage network，应先按官方文档完成配置并验证，再承载关键工作负载。

网络方面，先创建和验证基础 VM Network，而不是一次性创建所有 VLAN。用测试 VM 覆盖每个节点，验证 DHCP、静态 IP、默认路由、DNS、业务端口、MTU 和迁移后的连通性。

备份方面，尽早配置备份目标并做一次恢复演练。没有恢复演练的备份，只能证明任务可能运行过，不能证明业务可恢复。

Harvester 安装后的关键配置边界

存储专项配置

安装完成后，先不要急着导入镜像和创建 VM。要先确认 Longhorn 的节点和磁盘状态。每台节点的数据盘是否被识别，是否标记为可调度，剩余容量是否符合规划，默认副本数是否适合当前节点数量，这些都要在创建业务 VM 前确认。

默认 StorageClass 适合快速开始，但不一定适合生产。生产环境通常需要至少区分通用三副本、低成本二副本、测试单副本、高性能 NVMe、保留策略不同的 StorageClass。StorageClass 是策略入口，后期大量 VM 建成后再改会非常困难。

若计划启用 storage network，应尽早配置。storage network 影响 Longhorn 组件和副本流量，官方文档也要求按照明确步骤配置和验证。这个操作不应在大量生产 VM 运行后临时执行。启用前要确认所有节点的存储接口、IP、MTU、交换机 VLAN、路由和防火墙策略；启用后要验证 Longhorn Pod、Volume attach、Replica rebuild 和 VM I/O。

存储验收还要覆盖容量水位。三节点集群即使每台有 2TiB 数据盘，也不等于可以放心提供 6TiB VM 容量。默认三副本、快照、备份缓存、Replica 重建和故障余量都会消耗空间。安装阶段至少要确定告警水位、扩容方式和磁盘更换流程。

网络专项配置

Harvester 网络配置分为管理网络和 VM 网络。管理网络承载 UI/API、节点通信和控制面访问，必须稳定、可达、受保护。VM 网络承载业务虚拟机访问，通常需要 VLAN 或 untagged network。安装完成后，第一件事是确认管理 VIP 稳定，第二件事是创建最小业务网络并用测试 VM 验证。

业务网络不要一次性全量创建。建议先选择一个测试 VLAN，创建对应的 Cluster Network、Network Config 和 VM Network，然后在每个目标节点启动测试 VM，验证 DHCP、静态 IP、默认路由、DNS、网关和业务端口。确认模型可用后，再按业务域扩展。

如果节点使用 bond，安装前就要确认 bond 模式和交换机配置匹配。LACP、active-backup、MTU、VLAN trunk、native VLAN 和端口安全策略都可能影响 VM 网络。Harvester UI 中网络对象 Ready，不代表物理交换机路径正确。真正验收必须从 VM 内访问网关和跨网段服务。

管理网络、存储网络和业务网络共用物理链路时，至少要在 VLAN、监控和变更记录中区分。故障时需要知道丢包发生在管理面、存储面还是业务面。所有流量混在一个无标签网络里，短期省事，长期排障成本会很高。

认证、证书和审计

安装后的默认管理员账号只能用于初始化。生产环境要尽早接入组织认证体系，至少要明确管理员、只读审计、虚拟机管理员、存储管理员和网络管理员的权限边界。多人共用 admin 账号会让审计失效。

证书也要纳入计划。测试环境可以使用默认自签证书，生产环境最好使用组织 CA 或受信任证书，并记录证书到期时间和续期流程。Harvester UI、API、Rancher 集成和自动化脚本都会受到证书影响。证书问题常被误判为网络或权限问题。

审计方面，要记录谁创建 VM，谁删除卷，谁修改网络，谁触发备份和恢复。Harvester 背后是 Kubernetes，很多对象变更可以通过事件、日志和 API 记录追踪。安装阶段就要决定日志保留位置和安全要求，否则上线后再追溯会很困难。

镜像和模板准备

安装完成后，下一步通常是导入镜像。镜像不是随便上传一个 ISO 或 qcow2 文件。每个镜像都应有来源、版本、校验、用途、维护人和废弃时间。官方 cloud image、内部标准镜像和从旧虚拟化平台迁移的镜像，应分别治理。

Linux cloud image 要验证 cloud-init、SSH Key、默认用户、qemu-guest-agent、磁盘扩容和网络配置。Windows 镜像要验证驱动、激活、远程访问、时间同步和 guest agent。模板 VM 要清理 machine-id、SSH host key、临时账号和 cloud-init 状态，避免克隆后身份冲突。

不要在安装完成当天就让业务团队自由上传镜像。先建立一组标准镜像和命名规范，再开放给项目使用。镜像治理做不好，后续 VM 管理会变成一堆不可追踪的系统盘。

备份目标和恢复演练

Harvester 集群安装好但没有备份目标，只能算半成品。生产平台至少要配置 VM Backup 目标，并完成一次从备份恢复测试 VM 的演练。备份目标可以是 S3 兼容对象存储、NFS 或其他官方支持方式，具体选择要结合网络、安全和保留策略。

恢复演练要验证的不只是任务状态。恢复出的 VM 要能启动，网络要正常，磁盘数据要可读，应用要能启动，监控要能发现。若恢复后 IP 冲突、machine-id 重复、DNS 未更新或业务端口不通，说明备份流程仍不完整。

备份策略要和业务分级绑定。测试 VM 可以低频备份或不备份，生产 VM 需要明确 RPO/RTO，数据库类业务还要结合应用一致性备份。平台快照不能替代跨故障域备份，Longhorn 副本也不能替代备份。

自动安装治理

自动安装的核心不是省几分钟人工输入，而是保证多节点、多站点、多批次交付的一致性。配置文件应进入受控仓库，但敏感值不能明文提交。可以把无敏感的模板版本化，把 Token、密码和 SSH Key 通过安全渠道注入。

自动安装配置要和资产系统对齐。主机名、管理 IP、BMC 地址、机柜位置、序列号、系统盘、数据盘、网卡 MAC 和交换机端口应能互相对应。否则安装失败时，很难判断是哪台机器、哪块盘、哪个交换机端口出了问题。

批量安装前应先对一台节点做 dry-run 式人工复核。确认配置文件字段、安装介质、网络访问、HTTP 配置文件地址和 Token 权限都正确，再扩大到整批节点。批量部署失败后，排查成本远高于单节点失败。

自动安装结束后，应自动或人工收集验收结果：节点状态、系统组件、Longhorn、KubeVirt、管理 VIP、网络连通性、时间同步和日志。没有验收的自动安装，只是自动把风险推进到了下一步。

试运行计划

安装通过后，应进入试运行，而不是直接承载生产。试运行至少持续一个完整业务周期，覆盖工作日、高峰时段、备份窗口、监控告警、节点维护和一次模拟故障。

试运行工作负载应包含不同类型：一台 Linux VM、一台 Windows VM、一台有数据盘的 VM、一台双网卡 VM、一台需要备份恢复的 VM。这样可以同时验证镜像、cloud-init、驱动、网络、存储和保护策略。

试运行期间要记录所有问题：VM 创建失败、网络不通、备份慢、恢复后 IP 变化、节点重启时间、Longhorn 副本重建耗时、告警噪声、权限不足和文档缺口。试运行结束后形成整改清单，整改完成后再上线生产。

运维交接

安装项目结束时，不能只交付一个可登录的 UI。应交付完整运维交接清单：安装配置、版本、ISO 校验、节点清单、网络规划、存储规划、VIP 和 DNS、管理员账号交接、备份目标、监控入口、告警联系人、常见故障处理和回滚流程。

运维交接还要明确日常节奏。每日看哪些告警，每周检查哪些容量和备份，每月做哪些恢复演练，升级前谁评审，节点硬件故障谁处理。没有这些节奏，平台会在上线初期看起来正常，几个月后因为容量、快照、备份和无主 VM 积累而变得不可控。

对于边缘站点，还要记录远程带外管理方式、现场联系人、备件型号、网络拓扑和断网场景处理方式。Harvester 很适合边缘，但边缘站点也更依赖文档和远程恢复能力。

离线和受限网络安装

很多 Harvester 场景在工厂、园区、边缘机房或安全区，无法直接访问公网。离线安装不能只准备 ISO，还要准备镜像、文档、校验值、备份目标、NTP、DNS、内部证书和必要的升级文件。若安装过程中需要临时访问外部仓库，说明离线准备不完整。

受限网络中，DNS 和 NTP 往往比镜像更容易被忽略。DNS 不通会影响证书、域名访问、备份目标和外部集成；NTP 不通会影响证书校验、日志顺序、Kubernetes 控制面和故障定位。安装前应从每个节点测试 DNS 和 NTP，而不是只从管理终端测试。

如果使用 HTTP 服务器提供配置文件或 ISO，服务器本身也要纳入安装计划。它的 IP、端口、防火墙、访问控制、文件校验和关闭时间都要明确。配置文件包含敏感字段时，不应长期留在无认证的 HTTP 目录中。安装完成后应撤下或替换敏感文件。

离线环境还要提前准备排障手段。没有公网时，不能依赖在线搜索、远程下载工具或临时拉取镜像。应提前准备 Harvester 文档、常用命令、日志收集方法、BMC 访问、交换机配置备份和内部知识库链接。边缘站点尤其要考虑断网时如何通过本地人员和带外管理恢复。

节点扩容流程

安装三节点只是起点。后续扩容时，新增节点应按和初始节点相同的标准执行：硬件检查、网络检查、数据盘确认、join 配置、Token 管理、节点加入、Longhorn 磁盘识别、网络覆盖和测试 VM 验证。不要因为集群已经运行，就降低新增节点的验收标准。

新增节点前，要先评估集群容量和调度策略。若新增节点硬件规格明显不同，VM 迁移和调度可能出现不均衡；若新增节点没有接入某些业务 VLAN，相关 VM 迁移到该节点后会断网；若新增节点数据盘性能较低，Longhorn 副本分布可能拉低整体性能。

新增节点后，不应马上把生产 VM 迁移过去。先创建测试 VM，验证管理网络、业务网络、存储卷、备份、迁移和监控。确认节点满足所有预期后，再允许调度生产 VM。必要时可以先通过标签或调度策略限制工作负载，再逐步开放。

节点扩容记录要和 CMDB 同步。新增节点的序列号、机柜位置、BMC 地址、管理 IP、存储 IP、网卡 MAC、磁盘序列号、Harvester 版本和加入时间都应有记录。没有资产记录的节点，后续故障更换和容量核算都会困难。

升级前安装基线

安装部署阶段还要为未来升级留下基线。Harvester 升级会影响操作系统、Kubernetes、Harvester 组件、KubeVirt、Longhorn 和相关 CRD。若安装时没有记录版本、配置和验证结果，升级前就很难判断当前状态是否健康。

升级前基线至少包括：节点列表、Harvester 版本、系统组件状态、Longhorn 状态、KubeVirt 状态、StorageClass、Network、备份目标、认证方式、证书到期时间和已知问题。安装完成后就开始记录这些信息，可以让未来升级少很多不确定性。

还要保留安装配置文件的脱敏版本。脱敏版本用于复盘字段、网络和磁盘选择；敏感版本则按密钥管理要求保存或销毁。没有配置记录，重建同一站点时只能依赖个人记忆。

故障恢复演练

安装验收不能只验证“正常路径”。至少要做三个小演练。第一，管理入口演练：重启当前持有 VIP 的节点，观察 VIP 是否恢复、UI/API 是否可访问。第二，VM 恢复演练：创建测试 VM，做备份，删除或停止测试 VM，再从备份恢复并验证网络。第三，节点维护演练：选择非关键时间重启一台节点，观察节点 Ready、Longhorn 副本和测试 VM 状态。

这些演练不需要制造破坏性事故，但要让团队知道证据入口在哪里。管理入口异常看 VIP 和系统组件；VM 恢复异常看 Backup、Volume、PVC、VM 和来宾系统；节点维护异常看 Node、Longhorn、KubeVirt 和事件。演练结论要写入运行手册。

如果演练失败，不应把失败当成安装任务的小问题跳过。安装阶段发现失败，是最便宜的修复机会。等业务上线后再发现备份无法恢复、VIP 不漂移、节点维护导致 VM 断网，代价会高得多。

安装验收

安装验收要分层执行。第一层是节点和控制面：所有节点 Ready，系统组件稳定，管理 VIP 可访问，UI/API 可登录，NTP 正常，DNS 正常。第二层是存储：Longhorn 节点和磁盘可用，默认 StorageClass 符合预期，测试 VM 卷健康，副本按节点分布。第三层是网络：管理网络稳定，测试 VM 能访问网关、DNS 和必要服务，业务 VLAN 在所有目标节点可用。第四层是虚拟机：能创建、启动、停止、迁移、快照、备份和恢复测试 VM。

验收记录要保留时间、版本、节点、配置文件、ISO 校验、关键截图或命令摘要、问题和处理人。安装验收不是为了写漂亮报告，而是为了后续升级、扩容和故障复盘有依据。

下面是一份可执行的验收清单：

  • ISO 来源和校验记录已保存。
  • 三台节点主机名、管理 IP、数据盘和网卡与规划一致。
  • 管理 VIP 可从运维网访问，并已写入 DNS/CMDB。
  • 所有节点 Ready，系统组件无持续异常重启。
  • Longhorn 节点、磁盘、Volume 和副本状态正常。
  • KubeVirt 组件正常，测试 VM 可创建和启动。
  • 测试 VM 网络覆盖所有目标节点。
  • 测试 VM 可执行快照、备份和恢复。
  • 节点维护或重启流程已演练。
  • 安装配置文件、Token 处理方式和权限边界已归档。
Harvester 安装验证与故障排查

上线准入标准

安装验收通过后，还要设置上线准入。第一，平台必须有负责人和值班入口；第二，管理入口、BMC、交换机和备份目标都能被运维团队访问；第三，至少有一套标准镜像和一套标准 VM 规格；第四，监控告警已经覆盖节点、Longhorn、KubeVirt、容量和备份；第五，至少完成一次恢复演练。

上线准入还要明确哪些业务可以先上。建议从内部工具、测试系统、低风险应用开始，不要第一批就迁移核心数据库、身份认证、生产控制系统或跨部门关键服务。低风险业务能帮助团队发现镜像、网络、备份和权限问题，同时不会把平台初期问题放大成重大事故。

准入结果应写入工单或评审记录。记录中包含通过项、遗留风险、临时限制、下一次复盘时间和扩大范围条件。例如“只允许创建测试环境 VM”“暂不承载数据库”“业务 VLAN 只开放 110/120”“备份恢复每周抽测一次”。这些限制能防止平台刚装好就被无限制使用。

安装前检查表

为了避免安装中反复中断，可以在维护窗口前一天完成预检查。硬件侧确认节点通电、BMC 可用、固件版本已记录、CPU 虚拟化开启、系统盘和数据盘识别正确。网络侧确认交换机端口配置、管理 IP 未冲突、VIP 未占用、DNS/NTP 可达、VLAN 和 MTU 与规划一致。

软件侧确认 ISO 已下载并校验，配置文件已脱敏评审，Token 和密码按安全渠道传递，安装介质可启动，运维终端可以访问管理网段。人员侧确认操作人、网络配合人、现场联系人、回滚决策人和变更窗口。资料侧确认规划表、拓扑、IP 地址表、交换机端口表和故障记录模板准备好。

预检查完成后，再进入正式安装。若预检查发现关键项缺失，例如 VIP 未确认、数据盘不明确、交换机端口未配置、Token 管理方式不清楚，应推迟安装。HCI 平台的安装失败往往不是安装器问题，而是前置条件没有完成。

安装窗口内还应冻结无关变更。不要一边安装 Harvester，一边调整交换机 trunk、改 DNS、替换磁盘或修改上游防火墙。并行变更会让故障边界变得模糊。确实必须调整时，要记录时间点、操作人和验证结果，便于安装失败后复盘。

验收未完成前，不开放业务创建权限。

试点业务也要走准入流程。

所有例外都要记录。

风险要复盘。

持续改进。

稳。

常见安装故障

第一类是硬件虚拟化未开启。表现为 VM 无法正常启动或 KubeVirt 能力异常。处理方式是进入 BIOS/UEFI 开启 Intel VT-x/AMD-V，并确认服务器固件没有禁用相关能力。

第二类是磁盘选择错误。表现为安装失败、Longhorn 找不到数据盘，或误格式化了不该使用的磁盘。处理前先停止继续安装，核对磁盘序列号和安装记录。生产环境不要靠 /dev/sdX 这种不稳定命名做唯一依据。

第三类是管理 VIP 冲突或不可达。表现为 UI 访问不稳定、VIP 漂移异常、节点间访问正常但运维终端访问失败。要检查 IP 是否冲突、交换机 ARP、VLAN、网关、安全策略和 VIP 设置。

第四类是 Token 或 server_url 配置错误。join 节点无法加入时，先确认 server_url 是否指向 VIP 或域名，Token 是否正确，节点能否解析和访问该地址。创建新集群时不应配置非空 server_url。

第五类是 DNS/NTP 问题。表现为证书、日志时间、组件通信或镜像拉取异常。安装前就应验证 DNS 和 NTP，而不是等集群异常后再补。

第六类是网络接口不一致。不同节点使用不同接口名、bond 成员或 VLAN 配置，会导致某些节点上的 VM 网络不可用。解决方式不是在 UI 中反复改 VM，而是回到节点和交换机配置。

回滚和重装策略

安装阶段失败时，不要把半成功节点继续加入集群。若首节点创建失败，先收集安装日志、网络和磁盘信息，再决定重装。若节点加入失败，先确认首节点健康、Token、server_url、网络和时间同步，再重试。反复重装前要清理旧数据，否则旧配置可能干扰新安装。

重装节点前必须确认数据盘是否保留。实验环境可以清空；生产环境要先判断该节点上是否有 Longhorn 副本、是否会影响 Volume 健康、是否需要先驱逐或迁移。HCI 节点不是普通无状态计算节点，重装可能影响存储副本。

如果集群已经承载业务，任何重装、换盘、换网卡、改管理 IP 或改 VIP 都应走变更流程。安装阶段形成的配置记录和验收记录，会直接决定后续回滚是否可执行。

小结

Harvester 安装部署的核心是“先规划，再安装，再验收”。ISO 或配置文件只是执行手段，真正决定集群质量的是硬件、网络、存储、VIP、Token、DNS、NTP、认证、备份和验收流程。按当前 v1.8 官方文档，create 和 join 模式的 server_url、Token、管理接口、安装盘、数据盘和 VIP 都要严格区分。

完成本篇后，你应该能设计一个三节点 Harvester 集群安装方案，知道首节点创建和后续节点加入的差异，知道安装后必须检查哪些对象，也知道哪些故障不能靠“重装一次”解决。下一篇将进入虚拟机管理，把安装好的平台转化为可交付、可迁移、可保护的 VM 服务。

参考资料