用三台小主机构建轻量集群，兼顾可维护性、功耗和学习价值。
核心思路
控制平面使用固定地址，工作节点按角色打标签；系统盘与持久化数据盘分离。先解决时间同步、DNS 和主机名，再安装 K3s，能减少大量隐蔽故障。
落地步骤
家庭环境不必照搬大型生产集群。优先做好备份、断电恢复和可观测性，再逐步引入 Ingress、证书与 GitOps。
验证清单
实施后不要只确认“能运行”，还应检查错误率、延迟、资源占用和异常路径。把验证命令、预期结果和回滚方式写进变更记录，后续维护会轻松很多。
小结
好的工程实践不是堆叠工具，而是用清晰边界、可观察结果和可逆变更降低长期成本。先解决最重要的问题，再逐步自动化。
可执行实践
先为三台机器设置固定地址、唯一主机名和时间同步。控制节点备份 /var/lib/rancher/k3s/server/db 与 token，工作节点只保存可重建负载；用节点标签区分存储和计算角色。
验证与退出条件
演练控制节点重启、工作节点离线和断电恢复。确认系统启动后 K3s 自动拉起、Service 可达、持久卷未损坏，再考虑安装更多平台组件。
实践场景
以“在三台局域网主机搭建可重建的轻量集群”为例。实施前先保存当前版本、配置和关键指标基线，写明成功条件与停止条件；涉及生产数据或外部写入时，先在隔离环境验证。
分步实施
固定节点地址和主机名，记录 token 的安全保存方式；先建服务端再逐台加入代理，最后安装存储和入口组件。每完成一步都记录可观察结果，不把命令返回零等同于业务正确。
故障演练
关闭一个工作节点、重启服务端并模拟磁盘不足，确认工作负载重调度且控制面数据有备份。演练应使用可清理的测试数据，并验证告警、日志和恢复路径，而不只是确认系统最终又能访问。
观测与回滚
观察节点 Ready、证书有效期和磁盘水位；恢复失败时按备份重建而不是手工修补未知状态。变更单中应写清负责人、观察窗口、阈值和回滚触发器，避免故障发生后再临时争论。
完成后把使用的版本、关键命令、观测窗口和结果写入变更记录。没有验证证据的“已完成”不能作为上线结论。
第二轮实践复核
可复用交付物： 节点清单、备份策略和重建记录。复用时先固定软件版本、依赖锁文件、测试数据规模和运行环境；文章中的命令包含占位符，必须替换成自己的非生产目标后再执行。
最低验证： kubectl get nodes -o wide && kubectl get --raw=/readyz?verbose
执行记录要保存命令、退出码、关键输出、观察窗口和回滚结果。若验证会产生写入，先使用隔离环境或 dry-run；任何失败都不能通过扩大权限、关闭校验或跳过测试来“解决”。
完整实战：三节点家庭实验室
目标是学习部署与恢复，不追求把家庭网络伪装成生产集群。先记录硬件、功耗、网段、存储和故障域：三台节点若共用一个插排、路由器和磁盘阵列，并不具备真正高可用。
1 | router / DNS |
为节点预留地址与主机名，固定时间同步，关闭公网直接暴露的管理端口。安装 token 使用文件或短时安全通道分发，不进入 shell 历史、Git 和博客截图。实验服务对公网开放前增加反向代理、TLS、认证、限速和路由器侧最小端口。
存储与备份先于业务
本地路径卷会把 Pod 绑定在节点上；节点损坏时 Deployment 重建不等于数据恢复。为每个有状态服务写清数据位置、备份频率、RPO/RTO 和恢复步骤。K3s 数据存储快照与应用数据备份是两件事，都要恢复演练。
| 演练 | 通过条件 |
|---|---|
| 关闭一个 agent | 无状态服务迁移，容量仍足够 |
| 关闭一个 server | API 仍可用或明确进入预期降级 |
| DNS/路由器重启 | 集群内服务行为与恢复时间可解释 |
| 恢复应用数据 | 在隔离 namespace 完成校验 |
| 证书续期 | 外部入口返回新证书且无中断 |
升级与日常预算
固定 K3s 小版本和系统包窗口，先备份、再升级一台非关键节点，观察后逐台继续。监控节点温度、磁盘寿命、可用空间、内存压力、证书期限、备份最后成功时间和 UPS 状态。为日志、镜像和快照设置容量上限，避免小磁盘被慢慢填满。
回滚前确认数据格式是否仍兼容旧版本；不能只重新安装旧二进制。保留安装参数、systemd 配置、网络策略和应用声明的版本记录，使“重装一台空机器”成为可重复流程，而不是依赖记忆。
一手资料
资料与版本边界复核日期：2026-08-22。工具行为可能演进，实施前以锁定版本对应的官方文档为准。
评论