必须用statefulset而非deployment，因其提供稳定网络标识（固定域名）、有序启停及独占persistentvolume，确保storage节点ip变更不导致注册失败、数据丢失或同步异常。
Kubernetes Skills
下载
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
StatefulSet 是部署 FastDFS 的必要选择，用 Deployment 启动 Storage 节点必然失败——Storage 依赖稳定网络标识和本地数据路径，而 Deployment 重建 Pod 后 IP、主机名、挂载路径全变，fdfs_storaged 会拒绝启动或同步异常。
为什么必须用 StatefulSet 而不是 Deployment
FastDFS 的 Storage 节点在启动时会向 Tracker 注册自身 IP 和端口，并将该信息持久化到 storage.conf 对应的 base_path 下（如 /var/fdfs/data/storage_stat.dat）。若用 Deployment，Pod 重启后：
- IP 地址变化 → Tracker 认为节点下线，新 Pod 注册为“新节点”，旧数据无法识别
- 无固定 DNS 名称 → Tracker 无法通过
storage0-0.fastdfs-svc.fastdfs.svc.cluster.local这类域名反向定位 Storage 实例 - 默认 emptyDir 或非绑定 PVC → 数据随 Pod 删除彻底丢失，
store_path0目录清空即等于文件元数据+实际文件全丢
只有 StatefulSet 能提供：
- 稳定的网络身份（
pod-name-0+ Headless Service 域名） - 有序启停与固定序号（保障多 Storage 节点间组名/编号不冲突）
- 与
PersistentVolume绑定的独占式存储卷（每个 Pod 拥有专属 PV） - Tracker 的
bind_addr应设为0.0.0.0，端口暴露给 Headless Service - Storage 的
tracker_server必须填 Tracker 的 Headless Service FQDN：fastdfs-tracker-svc.fastdfs.svc.cluster.local:22122 - 所有配置项（如
group_name、http.server_port）都应从 ConfigMap 挂载，避免镜像打包固化 - 注意：ConfigMap 挂载后权限默认为只读，
fdfs_storaged启动时需能写入base_path下的日志子目录，因此volumeMounts必须单独挂载可写 PV 到/var/fdfs，而非覆盖整个/etc/fdfs - 多个实例写同一
store_path0目录 → 文件索引错乱、sync状态冲突、fdfs_monitor显示 inconsistent - 若用 NFS 并设为
ReadWriteMany，虽能挂载成功，但 FastDFS 自身未做分布式锁，会导致trunk.bin和storage_stat.dat被并发修改而损坏 - 推荐方案：每个 Storage Pod 绑定一个独占 PV（
accessModes: [ReadWriteOnce]），后端可用 Local PV（高性能）、Ceph RBD（生产级）、或云厂商块存储（EBS/EVS） - 特别注意：PV 的
capacity.storage必须 ≥ 实际需要的文件容量；storageClassName必须与集群中真实存在的 StorageClass 名称一致（如ceph-rbd-sc），否则 PVC 会长期 Pending - 在 Storage Pod 的
command中漏掉参数，例如写成["/usr/bin/start.sh"]而非["/usr/bin/start.sh", "storage"]→ 容器启动后静默退出 - 误把 Tracker 的启动命令用于 Storage Pod：
/usr/bin/fdfs_trackerd /etc/fdfs/tracker.conf在 Storage 容器里执行会报错can't load conf file（因 tracker.conf 缺少 tracker 专属字段） - 未等待 Tracker Ready 就启动 Storage：应在 Storage 的
livenessProbe或 initContainer 中加检查，例如nc -z fastdfs-tracker-svc 22122，否则 Storage 启动失败后反复 CrashLoopBackOff - nginx 未随 Storage 启动：FastDFS 的 HTTP 下载依赖
nginx+fastdfs-nginx-module，Storage Pod 的启动命令应为fdfs_storaged && nginx两进程共存，推荐用supervisord或自写循环守护，避免 nginx 挂了整个服务不可用
真正卡住人的地方不在 YAML 写法，而在于 Storage 节点首次注册后生成的
tracker.conf 和 storage.conf 必须通过 ConfigMap 注入，且不能硬编码 IP
直接在容器里写死 bind_addr=10.244.1.5 或 tracker_server=192.168.10.100:22122 是反模式。Kubernetes 中 Pod IP 动态分配，Service ClusterIP 又不可被 Storage 主动连接（Tracker 需监听，Storage 需主动连）。
Storage 节点的 PersistentVolume 必须支持 ReadWriteOnce 或 ReadWriteMany，但不能混用
Storage 节点之间**不共享同一块存储卷**——每个 Storage Pod 必须拥有独立 PV，否则：
start.sh 启动脚本必须区分角色并传参，不能靠环境变量自动判断
很多公开镜像的 start.sh 写成 if [ "$1" = "tracker" ]; then ... fi，这没问题；但常见错误是：
storage_ids 和 ip_addr 会被写死进本地文件。一旦你删掉 StatefulSet 又重建，哪怕用同一个 PVC，只要 statefulset.spec.revision 变了，Kubernetes 就可能分配新主机名——此时 Storage 会拿旧记录去连新域名，导致 Tracker 日志刷屏 recv from client xx.xx.xx.xx:xxxxxx fail, errno: Connection refused。这种问题不会报错，只会让上传成功但下载 404，排查时得直连 Storage 容器查 /var/fdfs/data 下的 storage_ids 和 ip_addr 是否匹配当前 DNS 解析结果。
