当前位置：首页 > news >正文

基于Kubernetes与GitOps构建生产级家庭实验室：从IaC到自动化运维

news 2026/5/15 11:14:46

1. 项目概述：从“玩具”到“生产力”的蜕变

如果你和我一样，是个对技术有执念的极客，家里肯定堆满了各种吃灰的树莓派、退役的旧笔记本，甚至还有几台二手服务器。我们总想用它们做点什么，搭建一个属于自己的“家庭实验室”（Homelab），但结果往往是：要么在复杂的配置中迷失方向，要么搭建完就束之高阁，成了一个纯粹的“玩具”。直到我遇到了khuedoan/homelab这个项目，它彻底改变了我对家庭实验室的认知。这不仅仅是一个简单的软件集合或配置清单，而是一套完整的、声明式的、生产就绪的现代化基础设施即代码（IaC）解决方案。它用工业级的工程实践，将你家里那堆零散的硬件，变成一个可以稳定运行、易于维护、甚至能承载核心业务逻辑的私有云平台。

简单来说，khuedoan/homelab 项目为我们提供了一个“开箱即用”的蓝图。它基于Kubernetes和GitOps理念，通过Ansible和Terraform等工具，自动化地完成了从裸机服务器到完整应用栈的部署。你不再需要手动去安装 Docker、配置网络存储、设置反向代理，或者为每个应用编写复杂的 YAML 文件。这个项目已经为你定义好了一切：高可用的 Kubernetes 集群、集中式的日志与监控系统（如 Loki, Prometheus, Grafana）、自动化的证书管理（Cert-Manager）、以及一系列精选的自托管应用（如 Nextcloud, Vaultwarden, Home Assistant 等）。它的核心价值在于标准化和自动化，让你能像管理一个云服务商那样管理自己的家庭实验室，将宝贵的时间从繁琐的运维中解放出来，专注于应用和创新本身。

这个项目非常适合那些已经具备一定 Linux 和容器化基础，希望将自己的 Homelab 提升到“准生产环境”级别的技术爱好者、DevOps 工程师或软件开发者。它不是一个面向纯新手的“一键脚本”，而是一个需要你理解其设计哲学并动手实践的优秀范例。通过学习和复现这个项目，你不仅能获得一个强大的私人云平台，更能深入掌握现代云原生基础设施的构建与管理精髓。

2. 架构深度解析：为什么是这套技术栈？

khuedoan/homelab 的架构设计充满了工程智慧，每一处技术选型都直指家庭实验室的典型痛点：资源有限、环境异构、追求稳定且希望运维成本最低。我们来逐一拆解其核心组件背后的设计逻辑。

2.1 基石：Kubernetes 作为统一抽象层

为什么是 Kubernetes (K8s)，而不是简单的 Docker Compose？这是项目最根本的决策。家庭实验室的设备往往五花八门，有 x86 服务器，也有 ARM 开发板。Docker Compose 虽然简单，但缺乏跨节点的调度、服务发现、自愈和滚动更新能力。K8s 提供了一个统一的抽象层，将你的所有硬件资源（CPU、内存、存储）池化。这意味着你可以轻松地将应用部署到最适合的节点上（比如将计算密集型的任务放在性能强的服务器上，将 IoT 应用放在树莓派上），并且当某个节点或容器故障时，K8s 会自动在其他健康节点上重新调度，保障服务的高可用性。

项目选择了K3s作为 K8s 发行版，这是一个关键且明智的优化。K3s 由 Rancher 开发，专为资源受限的边缘和物联网环境设计。它移除了很多传统 K8s 中非核心的、过时的组件，并用更轻量的实现替代（如用 sqlite3 替代 etcd 作为默认存储）。这使得 K3s 的安装包极小，内存占用极低（主节点仅需 512MB 左右），启动速度飞快，完美契合家庭环境。它保留了完整的 K8s API，确保所有生态工具（如 Helm, kubectl）都能无缝使用。

2.2 灵魂：GitOps 与声明式配置

项目的所有基础设施和应用配置，都以代码的形式存放在 Git 仓库中。这就是GitOps的核心：将 Git 作为系统期望状态的唯一事实来源。具体实现上，项目使用了FluxCD作为 GitOps 工具。FluxCD 运行在 K8s 集群内部，持续监控你的 Git 仓库。当你将新的配置（如一个 Helm chart 的版本更新）推送到 Git 后，FluxCD 会自动同步这些变更到集群中，并驱动 K8s 将实际状态调整到与 Git 中声明的期望状态一致。

这种模式带来了革命性的运维体验：

可追溯：集群的任何变更都有对应的 Git commit，谁、在什么时候、改了什么都一清二楚。
可回滚：如果一次更新导致问题，简单地git revert然后推送，FluxCD 就会自动将集群回滚到上一个稳定状态。
一致性：无论是重建整个集群，还是新增一个节点，只需拉取相同的 Git 配置，就能得到完全一致的环境。彻底解决了“雪花服务器”问题。

2.3 骨架：基础设施即代码（IaC）与配置管理

在 K8s 集群建立之前，我们需要准备底层的基础设施：操作系统的初始化、网络配置、用户创建、内核参数调优等。khuedoan/homelab 使用Ansible来完成这部分工作。Ansible 是一个无代理的配置管理工具，通过 SSH 连接到目标服务器执行预定义的“剧本”（Playbook）。项目的 Ansible 剧本定义了服务器的基线配置，确保每台机器在加入集群前都处于一个已知、可控的状态。

对于云资源或需要更复杂生命周期管理的资源，项目引入了Terraform。虽然家庭实验室核心是物理机，但你可能会有一些外围的云服务需求，比如动态 DNS 的 API 调用，或者管理云上的对象存储。Terraform 的声明式语法和资源依赖图，能很好地管理这部分“基础设施”。项目将 Ansible 和 Terraform 结合，实现了从底层系统到上层云资源的全栈 IaC。

2.4 核心应用栈：精选、集成与自动化

项目预置的应用栈是其“开箱即用”感的直接体现。这些应用不是随意堆砌，而是经过精心挑选和深度集成：

存储：使用Longhorn提供分布式块存储。它为 K8s 提供了易用的、云原生风格的持久化存储方案，支持快照、备份、甚至跨节点的数据复制，实现了存储的高可用。
网络：使用Traefik作为入口控制器（Ingress Controller）。它自动从 K8s Ingress 资源发现路由规则，并与Cert-Manager集成，自动从 Let‘s Encrypt 申请和续签 HTTPS 证书，实现“配置即生效，自动有 HTTPS”。
监控与日志：使用Prometheus收集指标，Grafana进行可视化，Loki收集日志。这套组合就是云原生领域的监控事实标准。项目预配了常用的 Dashboard 和告警规则，让你一眼就能掌握集群的健康状况。
实用工具：包括密码管理器Vaultwarden（Bitwarden 的 Rust 实现）、文件同步与协作平台Nextcloud、智能家居中枢Home Assistant、媒体服务器Jellyfin等。它们都通过 Helm Chart 部署，配置已经过优化。

所有这些应用的配置都通过 GitOps 管理。你想升级 Nextcloud？只需在 Git 仓库中修改其 Helm chart 的版本号，提交推送，剩下的就交给 FluxCD 了。

3. 从零开始：手把手部署实战

理解了架构，我们开始动手。部署过程就像搭乐高，步骤清晰，但需要耐心。以下是我在多次部署中总结的详细流程和避坑指南。

3.1 前期硬件与网络规划

在写第一行代码之前，规划至关重要。

硬件清单：至少需要两台物理机（或虚拟机）作为 K3s 服务器节点，以实现高可用。建议配置：x86架构，4核 CPU，8GB 内存，100GB SSD 起步。可以额外添加树莓派等 ARM 设备作为边缘节点。确保所有设备在同一局域网内，且能通过 SSH 互访。
网络规划：
- 固定IP：为所有服务器在路由器中设置 DHCP 保留，分配固定的局域网 IP 地址。这是集群稳定性的基础。
- 主机名：为每台机器设置一个有意义的主机名，如k3s-master-01,k3s-worker-01。
- 防火墙：确保 K3s 所需端口（如 6443, 8472/UDP 等）在节点间是开放的。一个简单的起步策略是先在内部网络暂时禁用防火墙，待集群部署成功后再细化规则。
准备跳板机：选择你日常使用的一台 Linux/Mac 笔记本作为“部署机”。所有 Ansible 和 Terraform 命令都将从这台机器发起。确保其上已安装 Git、Python3、pip。

3.2 部署机环境准备与仓库克隆

首先在部署机上搭建工作环境。

# 1. 克隆项目仓库 git clone https://github.com/khuedoan/homelab.git cd homelab # 2. 安装 Ansible 及相关依赖 python3 -m pip install --user ansible # 安装 Ansible 所需的社区集合和角色 ansible-galaxy collection install community.general ansible-galaxy install geerlingguy.pip # 3. 安装 Terraform # 以 macOS 为例，使用 Homebrew brew tap hashicorp/tap brew install hashicorp/tap/terraform # 对于 Linux，可从官网下载二进制包并放置到 PATH 中

注意：项目的requirements.txt可能包含特定版本的 Ansible 模块。建议在 Python 虚拟环境中操作，避免污染系统环境。使用python3 -m venv venv && source venv/bin/activate创建并激活虚拟环境后，再安装依赖。

3.3 配置清单与变量定制：项目的核心配置

这是最关键的一步，你需要告诉 Ansible 和 Terraform “你的实验室长什么样”。所有配置集中在inventory/目录下。

复制示例配置：
```
cp -r inventory/sample inventory/my-homelab cd inventory/my-homelab
```
现在你就在my-homelab目录下工作，这里将存放你所有的个性化配置。
编辑 Ansible 清单文件 (hosts)：这个文件定义了你的服务器。根据你的规划修改它。
```
[k3s_servers] k3s-master-01 ansible_host=192.168.1.101 ansible_user=root k3s-master-02 ansible_host=192.168.1.102 ansible_user=root [k3s_workers] k3s-worker-01 ansible_host=192.168.1.201 ansible_user=root # 可以添加更多worker节点 [k3s_cluster:children] k3s_servers k3s_workers
```
实操心得：ansible_user强烈建议使用一个具有 sudo 权限的非 root 用户（如ubuntu），并在group_vars/all.yml中设置ansible_become: true，让 Ansible 在需要时提权。这比直接使用 root 更安全。你需要提前在该用户下配置 SSH 密钥登录。

编辑组变量文件 (group_vars/all.yml)：这是主配置文件，定义了集群的全局参数。

# 集群配置 cluster_name: "my-homelab" cluster_domain: "home.example.com" # 你拥有的域名，用于生成证书和访问地址 # K3s 配置 k3s_version: "v1.28.5+k3s1" # 指定一个稳定版本 k3s_install_script_url: "https://get.k3s.io" # 网络配置 - 这是最容易出错的地方！ # 必须选择一个与你的家庭局域网（如192.168.1.0/24）不重叠的 Pod 和 Service 网段 pod_network_cidr: "10.42.0.0/16" service_network_cidr: "10.43.0.0/16" # 存储配置 - Longhorn 的数据路径 longhorn_data_path: "/var/lib/longhorn" # GitOps 配置 - 指向你 fork 并修改后的仓库 flux_github_owner: "your-github-username" flux_github_repository: "homelab" flux_github_branch: "main" flux_github_path: "./kubernetes/apps"

关键解析：pod_network_cidr和service_network_cidr必须是你家庭局域网未使用的私有 IP 段。例如，你家路由器是192.168.1.1/24，那么10.x.x.x或172.16.x.x都是安全的选择。冲突会导致网络不通。

配置 Git 仓库与 Secrets：项目要求你将应用配置部分（kubernetes/apps目录）fork 到自己的 GitHub 仓库，因为其中可能包含你的个性化配置（如密码）。同时，一些敏感信息（如 GitHub Token、域名 API 密钥）需要通过SOPS（Secrets OPerationS）加密后存储在 Git 中。
- 首先，Fork 原项目仓库到你自己的 GitHub 账号下。
- 然后，在inventory/my-homelab/下生成 SOPS 的加密密钥：
```
# 生成一个 age 密钥对（比 PGP 更现代） age-keygen -o sops.agekey # 将公钥（以 age1 开头的那行）复制到 `secrets.sops.yaml` 中
```
- 编辑secrets.sops.yaml，用 SOPS 加密你的敏感信息。这是一个需要仔细阅读项目文档来完成的步骤。

3.4 执行 Ansible 剧本：初始化服务器与部署 K3s

配置完成后，就可以运行 Ansible 剧本了。这个过程是全自动的，但建议分阶段执行，便于排查问题。

# 回到项目根目录 cd /path/to/homelab # 1. 首先测试 Ansible 连接 ansible -i inventory/my-homelab/hosts all -m ping # 2. 执行基础准备剧本（配置SSH、安装基础包、调优系统） ansible-playbook -i inventory/my-homelab/hosts playbooks/prepare.yml # 3. 部署 K3s 集群（这是核心步骤，耗时较长） ansible-playbook -i inventory/my-homelab/hosts playbooks/deploy-k3s.yml

执行deploy-k3s.yml时，请密切观察输出。剧本会依次在k3s_servers组的第一台机器上安装 K3s 主节点，将其余服务器加入作为主节点实现高可用，最后将 worker 节点加入集群。如果中途失败，剧本输出会明确指示在哪一步出了问题。常见问题包括网络连通性、端口被占用、或系统资源不足。

3.5 配置 GitOps 与部署应用栈

K3s 集群启动后，下一步是安装 GitOps 控制器（FluxCD），让它开始从你的 Git 仓库同步应用。

# 安装 FluxCD 及其所需组件（Helm Controller, Source Controller等） ansible-playbook -i inventory/my-homelab/hosts playbooks/deploy-flux.yml

这个剧本会在集群中安装 FluxCD，并根据你在group_vars/all.yml中配置的 GitHub 仓库信息，创建一个GitRepository资源。FluxCD 会开始监听你仓库中./kubernetes/apps目录下的变化。

此时，你可以通过kubectl命令查看集群状态：

# 从部署机复制 kubeconfig 文件（Ansible 剧本会将其取回本地） # 通常位于 inventory/my-homelab/artifacts/kubeconfig.yaml export KUBECONFIG=/path/to/homelab/inventory/my-homelab/artifacts/kubeconfig.yaml # 查看所有节点 kubectl get nodes -o wide # 查看所有 Pod kubectl get pods --all-namespaces # 查看 FluxCD 的同步状态 kubectl get gitrepositories,kustomizations -n flux-system

如果一切顺利，你会看到 FluxCD 正在“协调”状态，并开始自动创建longhorn-system、traefik、cert-manager等命名空间，并部署对应的 Pod。这个过程可能需要几分钟到十几分钟，取决于你的网络速度和硬件性能。

4. 核心应用配置与个性化调优

当基础组件就绪后，真正的乐趣开始了——定制属于你自己的应用。所有应用配置都位于你 fork 的仓库的kubernetes/apps/目录下，按命名空间组织。

4.1 存储基石：Longhorn 配置与数据持久化

Longhorn 是你的“云硬盘”。部署完成后，第一件事是访问其 Web UI 并配置默认存储类。

访问 UI：通过kubectl port-forward或配置好的 Ingress 访问 Longhorn UI。
配置默认存储类：在 Longhorn UI 中，进入Setting -> General，将default-data-path设置为与group_vars/all.yml中一致的路径（如/var/lib/longhorn）。然后，在StorageClass页面，将longhorn存储类设为默认。
创建磁盘：在Node页面，确保所有节点都被识别，并且为每个节点添加磁盘（指向你准备好的数据目录）。Longhorn 会自动在所有节点间复制数据副本（默认2副本），实现高可用。

注意事项：Longhorn 对磁盘 I/O 比较敏感。如果使用机械硬盘（HDD），性能可能成为瓶颈，尤其是当运行数据库类应用时。建议至少为系统盘和 Longhorn 数据盘使用 SSD。此外，确保数据目录所在分区有充足的空间。

4.2 网络与安全：Traefik 与 Cert-Manager 集成

Traefik 和 Cert-Manager 的组合实现了自动化 HTTPS。

验证 Traefik IngressRoute：应用（如 Nextcloud）的 Helm chart 通常会创建 IngressRoute 资源。使用kubectl get ingressroute -A查看。
配置 DNS 与证书：你需要一个域名（例如home.example.com），并在你的 DNS 提供商处设置通配符 A 记录*.home.example.com指向你的家庭公网 IP 地址。由于家庭宽带通常没有固定公网 IP，你需要使用 DDNS 服务。
Cert-Manager 签发证书：项目预配置了 Let‘s Encrypt 的签发器（ClusterIssuer）。当 Traefik 接收到一个访问app.home.example.com的请求，且对应的 IngressRoute 指定了 TLS 时，它会触发 Cert-Manager 通过 HTTP-01 挑战（假设你配置了端口转发或拥有公网IP）或 DNS-01 挑战（更推荐，无需开放端口）来申请证书。

实操心得（DNS-01挑战）：使用 DNS-01 挑战是最优雅的方式，它不需要你将服务的 80/443 端口暴露到公网。你需要获取你的域名提供商（如 Cloudflare）的 API Token，并通过 SOPS 加密后配置到secrets.sops.yaml中，并在kubernetes/apps/infrastructure/cert-manager/下的配置里引用。这能极大提升安全性。

4.3 添加你自己的应用：以部署一个博客为例

假设你想部署一个 Ghost 博客。你不需要手动编写复杂的 K8s YAML。

查找 Helm Chart：在 Artifact Hub (https://artifacthub.io) 上搜索ghost。
创建应用目录：在你的 Git 仓库的kubernetes/apps/下，创建一个新目录，例如ghost-blog。

创建 Kustomization：在ghost-blog/目录下创建kustomization.yaml文件，通过 HelmRepository 和 HelmRelease 资源来声明式地部署。

# kubernetes/apps/ghost-blog/kustomization.yaml apiVersion: kustomize.toolkit.fluxcd.io/v1 kind: Kustomization metadata: name: ghost-blog namespace: default # 或新建一个 blog 命名空间 spec: interval: 10m path: "./" prune: true sourceRef: kind: GitRepository name: flux-system validation: client --- apiVersion: source.toolkit.fluxcd.io/v1beta2 kind: HelmRepository metadata: name: bitnami namespace: flux-system spec: interval: 1h url: https://charts.bitnami.com/bitnami --- apiVersion: helm.toolkit.fluxcd.io/v2beta1 kind: HelmRelease metadata: name: ghost namespace: default spec: interval: 5m chart: spec: chart: ghost version: "19.x.x" # 指定版本 sourceRef: kind: HelmRepository name: bitnami namespace: flux-system values: ghostHost: blog.home.example.com mariadb: enabled: true ingress: enabled: true hostname: blog.home.example.com tls: true annotations: cert-manager.io/cluster-issuer: "letsencrypt-prod" # 使用预配置的签发器

提交与同步：将更改推送到你的 GitHub 仓库。几分钟内，FluxCD 就会检测到变化，自动在集群中创建HelmRepository和HelmRelease资源，并开始部署 Ghost。你可以通过kubectl get helmrelease查看部署状态。

5. 运维、监控与故障排查实录

系统跑起来只是开始，稳定运行才是 Homelab 的价值所在。项目集成的监控栈是你的“千里眼”和“顺风耳”。

5.1 利用 Grafana 监控一切

访问预配置的 Grafana（通常通过grafana.home.example.com），默认用户名/密码在kubernetes/apps/monitoring/grafana/的配置中。你会发现已经导入了许多有用的 Dashboard：

Kubernetes / Compute Resources / Cluster：查看整个集群的 CPU、内存使用情况。
Kubernetes / Networking / Cluster：查看网络 I/O。
Longhorn：专属面板，监控卷状态、IOPS、吞吐量。
Node Exporter：监控单个节点的详细系统指标（磁盘空间、负载、温度等）。

配置告警：Prometheus 的 Alertmanager 也已就绪。你可以编辑kubernetes/apps/monitoring/prometheus/下的告警规则文件，定义诸如“节点宕机”、“磁盘空间不足80%”、“Pod 持续重启”等告警规则，并通过电子邮件、Slack 或钉钉接收通知。

5.2 常见问题与排查命令速查

即使自动化程度很高，遇到问题也在所难免。以下是我踩过坑后整理的排查清单：

问题现象	可能原因	排查命令与步骤
FluxCD Kustomization 状态为`False`	Git 仓库配置错误、YAML 语法错误、镜像拉取失败	`kubectl describe kustomization -n flux-system <name>` `kubectl logs -n flux-system -l app=helm-controller`
Pod 处于`Pending`状态	资源不足、节点选择器不匹配、PVC 无法绑定	`kubectl describe pod <pod-name> -n <namespace>`（看 Events） `kubectl get pvc -n <namespace>`
Pod 处于`CrashLoopBackOff`	应用启动失败、配置错误、依赖服务未就绪	`kubectl logs -n <namespace> <pod-name> --previous`（查看上次崩溃日志） `kubectl describe pod`检查探针配置
无法通过域名访问服务	Ingress/IngressRoute 未正确配置、DNS 未生效、Traefik 未运行	`kubectl get ingress,ingressroute -A` `kubectl logs -n traefik <traefik-pod-name>` 本地`nslookup your.domain.com`
Longhorn 卷状态异常	节点磁盘满、网络问题、副本数不足	访问 Longhorn UI 查看卷详情和事件 `kubectl logs -n longhorn-system -l app=longhorn-manager`
证书申请失败（`Certificate`状态为`False`）	Let‘s Encrypt 挑战失败（DNS/HTTP 配置错误）、速率限制	`kubectl describe certificate -n <namespace> <cert-name>` `kubectl describe challenge -n cert-manager`（如果用了 cert-manager）

一个典型排错流程：当服务无法访问时，我习惯从外到内排查：1) 检查本地 DNS 解析是否正确；2) 检查路由器端口转发（如使用）；3) 检查 Traefik 的 IngressRoute 是否存在且配置正确 (kubectl get ingressroute)；4) 检查对应的 Service 和 Endpoints (kubectl get svc,ep -n <ns>)；5) 检查 Pod 是否就绪 (kubectl get pods -n <ns>)；6) 查看 Pod 日志 (kubectl logs)。

5.3 备份与灾难恢复策略

Homelab 再稳定，备份也不能少。项目虽然没有直接提供备份方案，但基于其架构，我们可以轻松实现。

Git 仓库备份：你的所有配置都在 Git 中，这本身就是一份代码备份。确保你的 GitHub 仓库是私有的，或者使用自托管的 Gitea。
Longhorn 卷备份：Longhorn 支持定时快照和备份到 NFS 或 S3 兼容存储。在 Longhorn UI 中为重要卷（如 Nextcloud 数据库）创建定期快照和备份计划。这是恢复数据的最后防线。
集群状态备份：使用Velero工具，它可以备份整个 K8s 集群的资源和持久卷数据到对象存储。你可以将其部署在集群内，并设置定期备份。
恢复演练：定期（如每季度）在虚拟机上演练一次从零恢复：用 Ansible 剧本重建 K3s 集群，用 FluxCD 拉取 Git 配置，最后从 Longhorn 或 Velero 恢复数据。这能确保你的备份是有效的。

6. 进阶玩法与扩展思路

当基础平台稳定运行后，你可以基于此探索更多可能性，这才是 Homelab 的终极乐趣。

6.1 集成外部设备与服务

边缘计算：将树莓派作为 K3s 边缘节点加入集群。你可以将 Home Assistant 部署在树莓派上，直接控制本地 Zigbee/USB 设备，同时享受集群的统一管理。
硬件直通：通过 K8s 的 Device Plugin 机制，将 GPU 资源暴露给集群内的 AI 应用（如 Stable Diffusion WebUI）或媒体转码服务（如 Jellyfin）。
对接云服务：使用 Terraform 管理你在云服务商上的少量资源，比如一个用于备份的 S3 存储桶，或者一个 Cloudflare 的 DNS 记录。让你的 Homelab 成为混合云架构的起点。

6.2 安全加固实践

默认配置为了方便部署，安全性并非最强。生产化使用时需要考虑加固：

Pod 安全策略/PSA：启用 K8s 的 Pod 安全准入控制，限制 Pod 以特权模式运行或访问主机资源。
网络策略：使用 Calico 或 Cilium 等 CNI 替换默认的 Flannel，并定义严格的网络策略，实现 Pod 之间的微隔离。例如，禁止监控命名空间的 Pod 直接访问数据库命名空间的 Pod。
秘密管理：虽然用了 SOPS，但对于更复杂的场景，可以考虑集成HashiCorp Vault作为外部的秘密管理服务。
审计日志：启用 K8s 审计日志，并发送到 Loki 或 Elasticsearch 进行集中分析，记录所有对集群的 API 访问。

6.3 成本与能效优化

家庭实验室7x24小时运行，电费不容忽视。

节点自动伸缩：对于非关键的服务，可以尝试使用K3s 的自动伸缩或社区方案，在夜间低负载时自动关闭部分 Worker 节点，早上再启动。这需要对服务进行合理的容忍度和亲和性设置。
应用调度策略：利用 K8s 的亲和性/反亲和性规则，将计算密集型应用集中到少数高性能节点，让低功耗节点（如树莓派）运行轻量级、常驻的服务。这样高性能节点可以在空闲时进入低功耗状态。
监控与告警：在 Grafana 中创建电费消耗看板（基于功率计数据或智能插座 API），设置月度预算告警，培养节能意识。

khuedoan/homelab 项目为我打开了一扇门，它证明家庭实验室完全可以摆脱“玩具”的标签，成为一个严肃的、可运维的、充满乐趣的技术平台。这个过程最大的收获不是最终搭建的那个平台，而是在实践中对 GitOps、IaC、云原生理念的深刻理解。每一次调试、每一次优化、每一次成功部署新应用，都是对自身技能的锤炼。现在，我的 Homelab 已经稳定运行了一年多，它承载着我的代码仓库、家庭媒体库、自动化脚本甚至一些小型开发测试环境。它不再是一个负担，而是一个值得信赖的伙伴。如果你也厌倦了零散的手工运维，渴望一个整洁、自动化的私人云环境，那么从这个项目开始，绝对是一个不会后悔的选择。

查看全文

http://www.jsqmd.com/news/821316/