authentik 2025.8.1 worker 报 ENOSPC，histogram 文件持续撑大 /dev/shm

authentik 2025.8.1 通过 Helm 运行，worker 启动一段时间后进入 CrashLoopBackOff，日志出现 OSError: [Errno 28] No space left on device，栈指向 Python 多进程的 SemLock。容器根目录还有空间，但 /dev/shm 的指标文件持续增长。这种情况应检查指标基数问题，不能仅靠放大共享内存来处理。

相关应用修复已进入 authentik 2025.8.2：策略执行指标去掉了高基数的 object_pk 标签，减少不同对象不断产生新的指标组合。这是特定版本和指标路径的修复，不意味着所有 ENOSPC、所有 worker 内存增长都来自同一原因。

先确认耗尽的是哪个挂载

以下只读示例中的命名空间、Pod 和容器名均为占位值；worker 要替换成实际容器名：

kubectl logs authentik-worker-abc12 -n identity -c worker --previous
kubectl get pod authentik-worker-abc12 -n identity -o yaml
kubectl exec authentik-worker-abc12 -n identity -c worker -- df -h /dev/shm
kubectl exec authentik-worker-abc12 -n identity -c worker -- df -i /dev/shm
kubectl exec authentik-worker-abc12 -n identity -c worker -- ls -lh /dev/shm

--previous 读取同一 Pod 中上次已终止容器的日志；没有上次实例时，改看当前日志。容器处于反复退出状态时，exec 可能来不及成功，应先保留日志和已有监控数据，不要为了取一次目录列表不断重启任务。

核对实际镜像版本、退出原因、内存 requests 与 limits，以及 /dev/shm 的挂载来源。比较带时间的文件系统用量和 histogram_*.db 文件变化。ls 中的逻辑文件大小与实际占用不一定相同，判断挂载是否耗尽仍要结合 df 和实际分配量。

根目录空闲不代表 tmpfs 空闲。inode 耗尽、其他挂载或系统资源限制也可能产生相似错误；只有实际指标文件增长、对应挂载用量和故障日志相互吻合，才沿本文路径处理。Docker 中 PostgreSQL 的有限共享内存需求则可参照数据库共享内存容量检查，不能照搬为 authentik 的应用修复。

放大内存卷只能改变何时碰到边界

如果 /dev/shm 使用 emptyDir.medium: Memory，它由 tmpfs 承载，写入会计入写入容器的内存使用。提高卷的上限并不会增加节点内存，也不会停止指标组合增长；原来的 ENOSPC 可能转成 OOMKilled。

同一个 Pod 中容器重启通常保留 emptyDir 内容，删除 Pod 才会移除该临时卷。即使新 Pod 暂时恢复，如果仍运行相同的受影响代码，文件也可能再次增长。重建不能替代修复，更不应删除正在被指标库或业务使用的文件来腾空间。

临时容量调整需要结合节点余量、容器限制、并发和可接受的恢复窗口评估。不要将 tmpfs 上限调得很大后，只凭 worker 能启动就宣布完成。

更新包含修复的正式版本

先保存现有镜像和 Helm 配置，备份数据库、持久化数据和认证部署所需配置，检查版本迁移说明与 chart 兼容要求。选择包含该修复、与现有部署兼容且仍受维护的正式版本；2025.8.2 是修复进入正式版本的边界，不应据此把更高版本降回去。

沿现有部署流程协调 server、worker 和数据库迁移，核对每个正式实例的实际镜像。开发镜像中的恢复反馈可以帮助判断修复方向，却不应成为长期生产版本，也不能替代自己部署的验收。

升级前还要核对监控面板与告警是否依赖被移除的 object_pk 标签。按对象筛选旧指标的查询可能需要调整；应用正常与监控查询仍符合预期，都要检查。

观察业务运行期间的增长趋势

让 worker 在可比较的正常任务负载下运行，持续观察相关挂载、指标文件和容器内存，确认没有继续出现 ENOSPC、OOM 或反复重启，同时核对队列处理、登录和后台任务结果。刚重建时目录很小，只说明初始状态，不能说明增长已经受控。

若新版本仍有增长，保留具体指标文件、运行时长、负载范围和对应日志，继续检查是否有其他高基数指标或独立内存问题。不要把所有 worker 资源异常都套到这一个标签修复上。

需要回退时，先核对数据库迁移和数据格式是否允许回退，再按保留的部署与备份流程恢复。简单切回旧镜像可能重新带回指标增长，也不会撤销已经发生的迁移或业务写入。