yldmdocs

存储 (storage)

storage 类聚集了集群里负责数据落盘与对象存储的基础组件：MinIO 对象存储、nfs-provisioner 动态供给器、以及自托管的镜像 registry。它们的 manifest 位于 applications/storage/<service>/，由 ArgoCD 自动同步。

本页只陈述能从 manifest、README、CLAUDE.md 验证的事实（镜像、namespace、副本数、端口、ingress host、依赖的 secret、ServiceMonitor 等）。集群的整体数据层视角见 集群架构 · 数据层，节点与调度约定见 节点与调度。

存储方案

集群有两套并存的存储方案，按工作负载特性分流：

  • Name
    NFS（共享 RWX）
    Description
    由 nfs-provisioner 动态供给，后端是 PVE3（worker3，MS-01 i9-12900H）上的 1TB NVMe，作为 NFS 服务器（192.168.88.68:/srv/nfs，定时备份到 NAS）。适合需要多 Pod 共享读写（RWX）的卷，例如游戏服的 RWX 数据目录。PROVISIONER_NAME 为 nfs-storage。
  • Name
    local-path（节点本地）
    Description
    K3s 内置的 local-path provisioner，PV 钉在本节点磁盘上。数据库等有状态服务用它，以 StatefulSet 钉在 node-role=database 的 worker3 本地盘——README 数据库段列出 PostgreSQL 主从、Redis、MongoDB、RabbitMQ、Meilisearch ×2、MinIO（800GB）、NATS、Consul、Tempo 等都跑在 local-path 上。

组件清单

  • Name
    minio
    Description
    S3 兼容对象存储。单副本 StatefulSet，镜像 quay.io/minio/minio:RELEASE.2025-09-07T16-13-09Z，namespace minio。数据卷用 volumeClaimTemplates，storageClassName: local-path，请求 800Gi，并以 nodeSelector: node-role=database 钉在 worker3。容器暴露 9000（S3 API）与 9001（Console）两个端口，ClusterIP Service 同时转发两者。Ingress 把 minio.yldm.tech 路由到 Console（9001）、minio-api.yldm.tech 路由到 API（9000），证书走 letsencrypt-prod、经 Cloudflare tunnel 代理。登录集成 Dex OIDC（https://dex.yldm.tech），ExternalSecret minio-secret 从 Vault 拉 minio/root 的 root 密码与 dex/clients/minio 的 OIDC client secret。有 ServiceMonitor（抓 /minio/v2/metrics/cluster）。pve-infra 的 Terraform state 等就存在这里。
  • Name
    nfs-provisioner
    Description
    NFS 动态供给器，nfs-subdir-external-provisioner:v4.0.2，单副本 Deployment（strategy: Recreate），namespace nfs-provisioner，调度到 workload: infra 节点。后端 NFS 服务器 192.168.88.68、路径 /srv/nfs，对外提供 nfs-storage 这个 provisioner。
  • Name
    registry
    Description
    自托管镜像仓库，registry:3.1.1，单副本 Deployment，namespace registry，以非 root（uid/gid 1000）运行。容器端口 5000（HTTP）与 5001（metrics）。存储后端是 S3——直接指向集群内的 MinIO（http://minio.minio.svc.cluster.local:9000，bucket registry，forcepathstyle），凭据由 ExternalSecret registry-s3 从 Vault registry/minio 注入（access-key / secret-key / http-secret）。另带一个 registry-ui（joxit/docker-registry-ui:2.6.0，端口 8080）做只读浏览。有 ServiceMonitor（抓 5001 的 /metrics）。
README 的"存储组件（2个）"指的是 bootstrap 里登记的 storage 类 Application（minio、nfs-provisioner）；registry 同样位于 applications/storage/ 目录下。

MinIO 的桶

MinIO 通过一组 sync-wave 的 Job（quay.io/minio/mc，mc mb --ignore-existing）幂等创建初始 bucket，连接 https://minio-api.yldm.tech：

Bucket用途（按 Job 命名）
registry镜像仓库的 S3 后端
velero-backupsVelero 备份目标
k3s-etcd-snapshotsK3s etcd 快照
dnfDNF 相关数据
yldm-static静态资源

MinIO 同时是集群三层备份（源 → MinIO → NAS）中的中间层，相关流程见仓库 docs/backup-and-restore-runbook.md。

镜像仓库

registry 把镜像 blob 实际存到 MinIO 的 registry bucket，但关掉了 S3 重定向（redirect.disable: true）：MinIO 只在集群内可达（NetworkPolicy + 内部 DNS），若让客户端被 307 重定向到 minio.minio.svc:9000 会拉取失败，因此由 registry 自身代理 blob 内容。

对外有两套域名，分别挂在不同的 Cloudflare account tunnel 上：

  • Name
    yldm.tech（新 account tunnel）
    Description
    registry.yldm.tech（推拉）与 registry-ui.yldm.tech（UI），由 cert-manager 经 DNS-01 签发 origin 证书（registry-tls / registry-ui-tls）。镜像层可能很大，ingress 放开了 body 上限并拉长了读写超时。
  • Name
    dunaifen.games（旧 account tunnel）
    Description
    registry.dunaifen.games 与 registry-ui.dunaifen.games 仍在旧 account 的 tunnel 上，走 Cloudflare 边缘 TLS 回源，因此没有 origin 证书（无 tls 块）。
回到集群架构 · 数据层

评论