Files
Deploy-Laboratory/docs/00-03-未来规划与待补功能.md
jack be97836e0d chore: 清理调试脚本并收敛到 Ansible 流程
移除已废弃的调试/验证脚本与空目录,统一文档与脚本说明到 ansible-playbook 的部署方式,避免失效引用和误用路径。

Made-with: Cursor
2026-03-23 19:18:55 +08:00

5.1 KiB
Raw Blame History

00-03-未来规划与待补功能

给未来的自己:这里不是“必须现在就做完”的清单,而是把你已经想到、但还没系统实现的能力先写下来,等有时间再一项项补。

1. 日志与审计体系

  • 现状
    • 主要依赖 kubectl logs + 节点本地日志 + Prometheus/Grafana 指标。
    • 没有集中日志查询入口,也没有明确的“关键操作审计”路径。
  • 规划方向
    • 引入轻量日志聚合(例如 Loki 或 ELK 中的一个最小栈),统一收集:
      • K3s 控制面与核心组件日志;
      • 关键应用GitLab、openlist、OpenClaw 等)的访问/错误日志。
    • 为“集群操作日志”(如 kubectl apply/delete)预留出口,后续可结合 GitOps 做审计。
  • 建议文档
    • 05-09-k3s-集中日志与查询-loki.md(示例名称)

2. 统一身份与权限管理SSO

  • 现状
    • GitLab、Grafana、Homer、openlist 等各自维护账号。
    • Cloudflare Zero Trust 只覆盖到部分 Web 入口,没有形成统一的“家庭账号体系”。
  • 规划方向
    • 引入一个轻量 IdP如 Keycloak / Authentik集中管理家庭成员账号与 OAuth/OIDC 客户端。
    • 按优先级为关键组件接入 SSO
      • GitLab、Grafana、Homer 优先;
      • 其余应用按需要接入。
  • 建议文档
    • 05-10-homelab-sso-keycloak-部署与接入.md

3. 运维自动化与 GitOps

  • 现状
    • 节点初始化、K3s 配置和应用部署以“手工 + scripts/”为主。
    • 没有一套“从裸机/虚机到完整环境”的幂等自动化流程。
  • 规划方向
    • 节点侧 已完成 01-06-节点初始化-ansible-实践.mdAnsible 一键完成初始化 + k3s 安装 + firewalld 基线 + Traefik 标签(含 8472/udp、6443/tcp 端口开放)。
    • 集群侧:引入 GitOpsArgo CD / Flux 二选一)管理:
      • K3s 核心配置与 CRD
      • Ingress/IngressRoute、Traefik 配置;
      • 常用应用Homer、openlist、监控、GitLab 等)的清单。
  • 建议文档
    • 03-09-k3s-gitops-集群配置管理.md

4. 网络边界与安全基线

  • 现状
    • 已有 NetworkPolicy 排障文档 06-01-k3s-networkpolicy-故障排查.md
    • 家庭网络与实验网段的边界、安全分区IoT 设备、访客网络等)主要依赖网关/OpenWrt尚未在本仓库中系统描述。
  • 规划方向
    • 定义一份“最小可接受安全基线”:
      • 命名空间隔离与默认拒绝策略;
      • 仅对入口、监控、GitLab 等核心组件放行必须的东西;
      • 节点对外暴露端口白名单。
    • 梳理家庭网络拓扑与 K3s 网络在其中的位置:
      • 内/外网、IoT 网段、Admin 网段;
      • 哪些通过 Cloudflare、哪些只允许 VPN。
  • 建议文档
    • 06-04-homelab-网络分区与安全基线.md

5. 备份与灾难恢复(超越单应用)

  • 现状
    • 06-03-k3s-自动备份与恢复-openlist-webdav.md 已覆盖 openlist 的备份/恢复实践。
    • 尚未有一份“集群级 + 存储级 + 应用级”的整体 DR 方案。
  • 规划方向
    • 明确几类不同的“灾难级别”与对应恢复路径:
      1. 单个 Pod/Deployment 配置误操作;
      2. 某一节点worker/server硬件/系统损坏;
      3. 存储节点NFS/硬盘阵列)损坏;
      4. 整个 K3s 集群需要在新环境中重建。
    • 对应规划:
      • K3s datastore/外部数据库定期备份;
      • NFS/重要 hostPath 目录的文件级备份或异地同步;
      • 关键应用GitLab、openlist、openclaw workspace 等)的专项恢复演练。
  • 建议文档
    • 06-05-k3s-集群级备份与灾难恢复设计.md

6. 远程访问形态Tunnel + VPN 双轨

  • 现状
    • 通过 Cloudflare Tunnel 提供部分 Web 入口访问。
    • 管理/运维时仍主要依赖局域网直接访问。
  • 规划方向
    • 保持Cloudflare Tunnel 作为零信任 Web 入口方案;
    • 额外增加一条 WireGuard/OpenVPN 运维 VPN 路径:
      • 只向极少数管理设备开放;
      • 主要用途为 SSH、kubeconfig、底层网络排障。
  • 建议文档
    • 01-07-wireguard-运维vpn-接入与实践.md

7. 其他可选实验方向

这些不是“缺失”,而是你以后如果有时间,可以尝试的升级路线。

  • 多集群/多环境管理
    • 在本地再起一个极简 K3s/Kind用作“预生产/实验”环境,通过 GitOps 控制与主集群的差异。
  • 存储升级
    • 从基础 NFS 逐步尝试 Longhorn、Rook-Ceph 或轻量分布式存储,评估在家庭环境下的性价比与复杂度。
  • 可观测性增强
    • 在现有 Prometheus/Grafana 基础上补充 Alertmanager 与简单告警策略(如节点离线、磁盘空间、关键 Pod 异常)。

8. 使用方式建议

  • 不必一次全部实现,可按“对你当前使用最有帮助的”优先级来选;
  • 每当某个方向完成初版实践时,在 00-02-验证矩阵.md 中补充状态与备注;
  • 新增文档时记得回到 00-00-构建总览.md,把入口挂上。