bL34cHig0/rke2-homelab-blueprint

# RKE2 家庭实验室 Kubernetes 蓝图 [](LICENSE) [](https://github.com/bL34cHig0/rke2-homelab-blueprint/stargazers) [](https://github.com/bL34cHig0/rke2-homelab-blueprint/issues)         这是一个用于在 Ubuntu 主机上构建基于 RKE2 的 Kubernetes 集群的可复现蓝图。它涵盖了操作系统准备、集群安装、CIS 加固、网络（MetalLB、NAT egress）、使用 Traefik + cert-manager 的 ingress（Let's Encrypt 通配符证书），以及 Rancher、WordPress 和 Prometheus/Grafana 监控技术栈的参考部署。它旨在为希望深入学习安全、云或平台工程的工程师提供一种动手实践的工具，并且能够适应生产环境。 本仓库是一个起点——在应用任何 manifest 之前，您必须替换每一个以占位符形式出现的域名、电子邮箱、namespace 和组织标识符。 ## 核心亮点 - **默认安全第一** — CIS Benchmark 加固、受限的 Pod 安全、丢弃 Linux capabilities、只读根文件系统，以及禁用 token 自动挂载的专用 ServiceAccount。 - **生产级 ingress** — Traefik v3 + cert-manager 通过 Let's Encrypt DNS-01 (Cloudflare) 实现通配符 TLS，包含默认安全头和速率限制。 - **NetworkPolicy 微隔离** — 针对每个工作负载的网络隔离，外加用于主机层的 NAT-egress 和 CrowdSec/防火墙 posture。 - **开箱即用** — Rancher（集群管理）、Longhorn（加密块存储）、MetalLB（裸金属负载均衡），以及带有 Alertmanager → Discord 告警的 Prometheus/Grafana。 - **真实可用的 manifest** — 绝非骨架。提供了一个经过加固的 WordPress + MariaDB 参考工作负载，可作为新应用的模板。 - **循序渐进的文档** — 操作系统准备、RKE2 安装、CIS 加固、网络、节点维护——解释了每一个决策。 - **运行成本低廉** — 在 3 节点的 Hetzner 集群上每月约 15 欧元；适用于任何 KVM VPS 或裸金属。 ## 目录 - [核心亮点](#highlights) - [架构](#architecture) - [背景](#background) - [占位符约定](#placeholder-convention) - [目录结构](#layout) - [建议的操作顺序](#suggested-order-of-operations) - [Pod 安全基线](#pod-security-baseline) - [适用的托管环境](#suitable-hosting-environments) - [范围与限制](#scope-and-limits) - [致谢](#acknowledgments) - [贡献](#contributing) ## 架构 外部流量在 **Traefik** 处终止 TLS（由 **cert-manager** 签发通配符证书），并路由到 RKE2 集群上的工作负载。**MetalLB** 提供裸金属 `LoadBalancer` IP，**Longhorn** 通过静态加密支持持久化存储，**Prometheus/Alertmanager** 负责可观测性，并将告警发送至 Discord。 ``` flowchart TB users(["Internet / Users"]) cf["Cloudflare
DNS + Edge"] users --> cf --> mlb subgraph cluster["RKE2 Cluster · 1 control-plane + N workers"] mlb["MetalLB
L2 LoadBalancer"] --> traefik["Traefik v3
ingress + TLS termination"] certm["cert-manager
Let's Encrypt DNS-01"] -. wildcard cert .-> traefik traefik --> rancher["Rancher
cluster management"] traefik --> wp["WordPress + MariaDB
reference workload"] subgraph obs["Observability"] prom["Prometheus"] --> am["Alertmanager"] graf["Grafana"] end am -->|webhook| discord[("Discord alerts")] lh[("Longhorn
encrypted PVs")] rancher --> lh wp --> lh prom --> lh graf --> lh end ``` ## 背景 这份蓝图是我花了大约 7 个月时间、将安全作为首要考量因素从零开始构建和重建 Kubernetes 集群的成果——包括主机加固、CIS Benchmark 合规性、网络微隔离、镜像及 Pod 安全策略，以及围绕这些的运维习惯。本仓库将这些迭代过程提炼成一个连贯的起点，其他人可以直接采用，而无需重走我经历过的每一次试错。 这里的决策反映了特定的权衡和学习时刻。并非每一个选择对所有环境都是最优的，但每一个决策在文档中都有明确的理由——未来的方向是在开放中完善它们，而不是隐藏它们。 如果您正在实践安全、云或平台工程——想要构建一个反映真实生产模式的家庭实验室，或者想要一个可以自行调整的起点而不是从零开始构建——那么这正是为您准备的。该蓝图是可以适应生产环境的：安全选择可以完美迁移到更大的集群中（请参阅 [范围与限制](#scope-and-limits) 了解哪些可以直接扩展，哪些需要替换），manifest 是真实可用的配置而不是骨架示例，并且其结构设计允许您将部分内容直接移植到要求更高的设置中，而无需丢弃已完成的工作。 ## 占位符约定 | 占位符 | 替换为 | |---|---| | `` | 您控制的基础域名（例如 `example.com`） | | `` | 用于 Let's Encrypt 注册和管理员联系人的电子邮箱 | | `` | 您的容器镜像仓库组织 / GitHub 组织（例如 `acme-corp`） | | `` | 正在应用的工作负载所使用的 Kubernetes namespace | | `default-cert-production` / `default-cert-staging` | cert-manager `Certificate` 资源及其 TLS secret 的名称 | 本蓝图默认采用 **三级主机名布局**（`.`，例如 `rancher.example.com`）。这是最简单的途径：Cloudflare 的默认边缘证书涵盖它，并且通过 DNS-01 签发的 `*.` 的单个 Let's Encrypt 通配符可以覆盖每一个集群服务。 如果您更喜欢**将集群服务归类在专门的子域下**（`..`，例如 `rancher.k8s.example.com`），这是第四级主机名。这是一个合理的选择——它将集群流量与根域上的其他任何内容隔离开来——但它触发了 Cloudflare 边缘证书的限制，我们在 [cluster-apps/traefik/README.md](cluster-apps/traefik/README.md) 中为它提供了一个专门的附录。在选择此方案之前，请先阅读该部分。 ## 目录结构 ``` . ├── infrastructure/ Cluster build & operations docs │ ├── rke2-ubuntu-prerequisites.md │ ├── ubuntu-setup-and-user-provisioning.md │ ├── ssh-access-to-worker-srv-via-ctrl-plane.md │ ├── rke2-installation.md │ ├── rke2-cis-self-assessment-benchmark-config.md │ ├── metallb-load-balancer-config.md │ ├── nat-gateway-config.md │ ├── srv-security-and-firewall-config.md │ ├── node-maintenance.md │ ├── uninstalling-or-deactivating-auto-configuration-package.md │ └── security/ │ └── k8s-deployment-security-policy.md ├── images/ Screenshots referenced by infrastructure guides └── cluster-apps/ Helm values + Kubernetes manifests ├── traefik/ Ingress + cert-manager (Let's Encrypt DNS-01) ├── rancher/ Cluster management UI ├── longhorn/ Distributed block storage (encrypted StorageClass) ├── prometheus-grafana/ kube-prometheus-stack values, alert rules └── wordpress/ Reference workload (WP + MariaDB) ``` ## 建议的操作顺序 1. **主机准备** — `infrastructure/rke2-ubuntu-prerequisites.md`, `infrastructure/ubuntu-setup-and-user-provisioning.md`, `infrastructure/ssh-access-to-worker-srv-via-ctrl-plane.md` 2. **网络** — `infrastructure/nat-gateway-config.md`, `infrastructure/srv-security-and-firewall-config.md` 3. **集群安装** — `infrastructure/rke2-installation.md` 4. **CIS 加固（可选）** — `infrastructure/rke2-cis-self-assessment-benchmark-config.md`（启用 RKE2 的 `profile: cis` 模式；适用于新集群或现有集群） 5. **负载均衡器** — `infrastructure/metallb-load-balancer-config.md` 6. **Ingress + TLS** — `cluster-apps/traefik/`（先 cert-manager，然后 Traefik，最后是 dashboard） 7. **集群管理** — `cluster-apps/rancher/` 8. **存储** — `cluster-apps/longhorn/`（通过 Rancher UI 安装；为后续应用的 PVC 提供绑定所需的 StorageClass） 9. **可观测性** — `cluster-apps/prometheus-grafana/` 10. **应用工作负载** — `cluster-apps/wordpress/`（新应用的参考模式） 11. **运维操作** — `infrastructure/node-maintenance.md`, `infrastructure/uninstalling-or-deactivating-auto-configuration-package.md` ## Pod 安全基线 [`infrastructure/security/k8s-deployment-security-policy.md`](infrastructure/security/k8s-deployment-security-policy.md) 收集了本蓝图默认遵循的工作负载加固实践——非根 UID、只读根文件系统、丢弃 Linux capabilities、使用 `automountServiceAccountToken: false` 的专用 ServiceAccount、NetworkPolicy 微隔离、镜像仓库允许列表，以及针对 Cloudflare 前置流量的速率限制 / `X-Forwarded-For` posture。 请将这些视为推荐的基线，而不是硬性要求。文档中说明了每个控制项存在的具体原因，因此您可以明智地决定哪些适合您的威胁模型、哪些需要调整、哪些可以放宽。默认配置旨在实现“开箱即用的生产就绪”，但私有网络上的家庭实验室理应比面向互联网的生产集群需要更少的控制项。 ## 适用的托管环境 本蓝图专为小型 RKE2 集群设计——通常是 1 个控制平面 + 2 个工作节点，或者是用于测试的单节点集群。它可以运行在任何能为您提供具有 root shell 的 Ubuntu LTS 虚拟机（或裸金属）、公共 IPv4 以及加载内核模块能力的平台上。它非常适合作为以下任何一家廉价/平价服务商上的家庭实验室或自建预发布环境： - **[Hetzner Cloud](https://www.hetzner.com/cloud)** — 同类产品中性价比最高。由 3 台 CX22 实例（2 vCPU, 4 GB RAM）组成的集群每月总计约 15 欧元。主要位于欧洲，也提供美国节点。 - **[Hostinger VPS](https://www.hostinger.com/vps-hosting)** — KVM VPS 计划起价在每节点每月 5 美元以下。如果您已经在使用 Hostinger 的 DNS 或托管域名，这会非常方便。 - **[Contabo](https://contabo.com/)** — 低价提供大容量 RAM/CPU，位于欧洲和美国。请注意较低级别套餐的网络流出限制。 - **[OVHcloud](https://www.ovhcloud.com/)** — 用于小型集群的 VPS 系列；对于较重的工作负载，可使用 Eco / SoYouStart 裸金属。 - **[Scaleway](https://www.scaleway.com/)** — 法国云服务商，与 Hetzner 相当。他们的 `Stardust` nano 实例非常适合作为低成本的开发节点。 - **[Vultr](https://www.vultr.com/)** / **[DigitalOcean](https://www.digitalocean.com/)** / **[Linode (Akamai)](https://www.linode.com/)** — 价格略高于欧洲的选项，但如果您已经使用了这些云平台，它们的入门门槛很低。 - **[Oracle Cloud — Always Free](https://www.oracle.com/cloud/free/)** — 容量允许的情况下，永久免费提供多达 4 个 Arm Ampere 核心 + 24 GB RAM（但经常受到容量限制）。在调度新 VM 可能不可靠的警告下，构建一个完整的免费套餐集群是完全可行的。 - **裸金属 / 家庭实验室** — 任何闲置的 Intel NUC、Mini PC 或重新利用的运行 Ubuntu LTS 的台式机都可以。RKE2 的基准开销适中（每个节点的 kube-system 约需 1 GB RAM）；请为每个节点规划至少 3 GB RAM，以便为工作负载留出空间。 关于资源规划，一个最小可行性集群总共需要约 6 GB RAM（每个节点 1 GB 基准 + 为 Traefik、cert-manager、Rancher、Prometheus 和您的应用预留的余量）。一个 3 节点的 Hetzner CX22 集群可以轻松运行本蓝图中的所有内容，外加像 WordPress 示例这样的小型参考工作负载。 ## 范围与限制 本蓝图主要针对**中小型 Kubernetes 集群**——包括家庭实验室、学习、自建预发布环境，以及 1-5 个节点即可满足需求的小型生产部署。就其本身而言，它不是一个企业级或大规模集群的蓝图。虽然界限比较模糊，但下文如实地设定了预期。 **可以直接迁移到任何规模集群的内容：** 这些加固模式是工作负载层面的决策，因此能够完美地适应向更大集群的跨越： - Pod 安全上下文、capability 丢弃、只读根文件系统、使用 `automountServiceAccountToken: false` 的专用 ServiceAccount - 针对每个工作负载的 NetworkPolicy 微隔离 - 针对 Cloudflare 前置流量的速率限制和 `X-Forwarded-For` posture - cert-manager + DNS-01 通配符模型 - Traefik 及 `externalTrafficPolicy: Local` - 按应用划分的文件夹仓库结构 **在大规模环境下需要替换的内容：** | 组件 | 当前选择 | 大规模替代方案 | |---|---|---| | 控制平面 | 单节点 | 3 个或更多节点以实现 etcd quorum 和 HA | | 负载均衡 | MetalLB L2 模式 | MetalLB BGP，或硬件负载均衡器——L2 会将所有 ingress 流量集中在单个节点上 | | 存储 | Longhorn（2 副本，加密） | Rook/Ceph、OpenEBS Mayastor，或用于高 IOPS 或大卷数的外部存储 | | 数据库（参考工作负载） | 单副本 MariaDB | Galera Cluster 或主从复制 | | 指标 | 单实例 Prometheus | Thanos、Cortex 或 VictoriaMetrics，用于长期存储和水平扩展 | | Manifest 应用方式 | 命令式 `kubectl apply` | GitOps (Argo CD, Flux) | | 策略执行 | 无——按 manifest 应用模式 | Kyverno 或 OPA Gatekeeper 在集群范围内强制执行加固模式 | | 备份 | 不包含 | 使用 Velero 进行集群 + PVC 备份 | | 日志记录 | 不包含 | Loki、ELK 或类似方案 | | Egress NAT | 单 ingress 节点 | HA egress 或 CNI 原生方案（例如 Cilium） | **总结：** 请将此视为一种能够适应更大集群的 **安全基线 + 参考模式**，而不是大规模生产的蓝图。加固选择是最有价值的可迁移成果；而运维基础架构——HA 控制平面、存储层、可观测性扩展、GitOps、多租户——不在本仓库的讨论范围内，在生产部署中需要单独进行决策。

标签：Homelab, RKE2, 子域名突变, 监控, 系统加固, 自定义请求头, 运维部署