OpenShift部署Bitnami MongoDB Helm Chart就绪探针脚本执行失败

核心根因 #

该故障和探针参数配置、资源配额无关，本质是OpenShift平台默认安全规则与Bitnami MongoDB镜像运行要求不匹配，触发进程级阻塞：

• OpenShift默认*SCC（安全上下文约束）*未开放IPC_LOCK权能，MongoDB及配套工具mongod/mongosh启动时会尝试锁定内存页执行高效内存映射，无对应权限时进程会进入长时间内核等待状态，无报错直接卡顿
• Bitnami镜像默认仅给UID 1001的内置运行用户开放工作目录、临时目录权限，OpenShift默认会为Pod分配随机UID运行，mongosh启动时需要在临时目录写入JS运行缓存，无写入权限时会卡在IO等待阶段不会抛出显式错误
• 若开启MongoDB TLS认证，证书文件权限不符合随机UID读取要求时，也会触发mongosh连接阻塞

替换探针为cat脚本文件可通过检测，仅能证明exec探针机制本身正常，无法验证MongoDB服务可用性，无实际健康检查意义。

验证步骤 #

• 进入故障Pod执行touch /opt/bitnami/mongodb/tmp/probe_test，如果返回权限报错即可确认目录权限问题
• 执行oc describe pod <pod名称> -n <命名空间>，查看事件栏是否有Permission denied、capability not allowed相关的安全拦截日志
• 手动在Pod内执行mongosh --verbose $TLS_OPTIONS --port $MONGODB_PORT_NUMBER，可观察到进程卡在权限申请或临时文件写入阶段无后续输出

修复方案 #

1. 适配OpenShift安全规则配置Helm参数
   部署时传入以下Values配置，自动适配OpenShift的随机UID运行规则，开放所需最小权能，开启启动时目录权限修正：

   volumePermissions:
     enabled: true
   podSecurityContext:
     enabled: true
     fsGroup: 0
     runAsNonRoot: true
     seccompProfile:
       type: RuntimeDefault
   containerSecurityContext:
     enabled: true
     runAsUser: null
     allowPrivilegeEscalation: false
     capabilities:
       drop:
         - ALL
       add:
         - IPC_LOCK
   

2. 给工作负载绑定对应SCC权限
   为MongoDB使用的ServiceAccount绑定权限，允许使用自定义权能运行：

   oc adm policy add-scc-to-user nonroot-v2 -z <mongo对应serviceaccount名称> -n <部署命名空间>
   

   不需要绑定高权限的anyuid SCC，nonroot-v2配合上述安全上下文配置即可满足运行要求。
3. 可选轻量探针配置
   生产环境如果不需要每次探针校验副本集角色状态，可替换为TCP探针，避免频繁启动mongosh进程带来额外开销：

   readinessProbe:
     tcpSocket:
       port: 27017
     initialDelaySeconds: 10
     periodSeconds: 10
     timeoutSeconds: 2
     failureThreshold: 3
   livenessProbe:
     tcpSocket:
       port: 27017
     initialDelaySeconds: 30
     periodSeconds: 20
     timeoutSeconds: 2
     failureThreshold: 6
   

内容的提问来源于stack exchange，提问作者NMV