CISO Assistant项目中Helm Chart持久化存储配置问题解析

背景介绍

在Kubernetes环境中部署CISO Assistant项目时，使用Helm Chart进行管理是一种常见做法。近期社区发现了一个关于持久化存储配置的重要问题：当用户选择PostgreSQL作为数据库而非SQLite时，附件存储目录/code/db/attachments/的持久卷声明(PVC)未被正确创建，导致Pod重启后上传的文件丢失。

问题本质

该问题的核心在于Helm Chart中持久化存储的配置逻辑存在缺陷。当前实现中，/code/db/attachments/目录的PVC仅在启用SQLite数据库时才会创建。这种设计存在两个主要问题：

1. 功能缺失：使用PostgreSQL时，附件存储缺乏持久化机制
2. 路径混淆：代码中同时存在对/code/db和/code/db/attachments/的引用，路径设计不够清晰

解决方案演进

社区经过讨论后明确了以下改进方向：

1. 统一存储管理：计划将多个PVC（数据库、附件和Huey任务队列）合并为单一PVC，简化存储管理
2. 外部PVC支持：增加对已有PVC的引用支持，允许用户使用自定义存储方案（如AWS EFS）
3. 配置灵活性：使PVC创建成为可选功能，满足不同部署场景需求

技术实现建议

对于需要在生产环境部署CISO Assistant的用户，建议采取以下临时解决方案：

1. 启用localStorage：设置backend.persistence.localStorage.enabled=true确保附件持久化
2. 自定义PVC：修改Helm Chart模板，将默认PVC替换为预先创建的高可用存储方案
3. 数据备份：在Chart升级前确保重要数据备份，避免未来版本变更导致数据丢失

未来版本注意事项

开发团队已确认将在后续版本中进行存储架构调整，这属于破坏性变更(breaking change)。用户需要注意：

1. 新版Chart将采用单一PVC设计
2. 升级时需遵循数据迁移指南
3. 外部PVC引用功能将作为标准配置提供

最佳实践建议

对于企业级部署，建议：

1. 使用网络附加存储(NAS)方案而非本地存储
2. 实现定期备份策略
3. 监控存储使用情况
4. 在测试环境验证存储配置变更

通过以上措施，可以确保CISO Assistant在Kubernetes环境中的稳定运行和数据安全。