112 lines
5.1 KiB
Markdown
112 lines
5.1 KiB
Markdown
# 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-07-节点初始化-ansible-实践.md`，Ansible 一键完成初始化 + k3s 安装 + firewalld 基线 + Traefik 标签（含 8472/udp、6443/tcp 端口开放）。
|
||
- **集群侧**：引入 GitOps（Argo 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-08-wireguard-运维vpn-接入与实践.md`
|
||
|
||
## 7. 其他可选实验方向
|
||
|
||
> 这些不是“缺失”，而是你以后如果有时间，可以尝试的升级路线。
|
||
|
||
- **多集群/多环境管理**：
|
||
- 在本地再起一个极简 K3s/Kind，用作“预生产/实验”环境，通过 GitOps 控制与主集群的差异。
|
||
- **存储升级**：
|
||
- 从基础 NFS 逐步尝试 Longhorn、Rook-Ceph 或轻量分布式存储，评估在家庭环境下的性价比与复杂度。
|
||
- **可观测性增强**：
|
||
- 在现有 Prometheus/Grafana 基础上补充 Alertmanager 与简单告警策略（如节点离线、磁盘空间、关键 Pod 异常）。
|
||
|
||
---
|
||
|
||
## 8. 使用方式建议
|
||
|
||
- 不必一次全部实现，可按“对你当前使用最有帮助的”优先级来选；
|
||
- 每当某个方向完成初版实践时，在 `00-02-验证矩阵.md` 中补充状态与备注；
|
||
- 新增文档时记得回到 `00-00-构建总览.md`，把入口挂上。
|
||
|
||
|