OpenShift 3 CronJob权限问题：如何从Job/CronJob写入Pod存储？

我帮你梳理下这个问题的解决思路——你遇到的权限拒绝问题，本质是OpenShift的安全上下文约束（SCC）限制了容器的运行用户，再加上持久存储卷的文件系统权限和Job Pod的运行用户不匹配导致的。而且直接写入PodA的文件系统本身就不推荐（Pod的文件系统是临时的，跨Pod直接写也不符合K8s/OpenShift的设计），咱们一步步来解决：

1. 先让Job/CronJob和PodA共享同一个持久存储卷 #

正确的姿势是让Job Pod和PodA共用同一个PersistentVolumeClaim（PVC），这是跨Pod共享存储的标准方式。

操作步骤： #

• 先找到PodA正在使用的PVC名称：

  oc describe pod PodA | grep -A5 "Volumes"
  

  找到输出里的PersistentVolumeClaim条目，记下PVC的名字（比如叫my-app-pvc）。
• 别再用oc run的简单命令创建CronJob了，这种方式没法指定卷挂载。改用YAML配置文件来定义CronJob，这样可以挂载共享PVC。

给你个示例YAML（命名为cronjob-writer.yaml）：

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: crontest
  labels:
    parent: crontest
spec:
  schedule: "* * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: crontest
            image: docker-registry.default.svc:5000/myproject/django:latest
            command: ["/opt/app-root/src/scripts/testScript.sh"]
            volumeMounts:
            - name: app-storage
              mountPath: /path/to/mount  # 这里要和PodA挂载存储的路径保持一致，或者你需要的写入路径
          restartPolicy: OnFailure
          volumes:
          - name: app-storage
            persistentVolumeClaim:
              claimName: my-app-pvc  # 替换成你刚才查到的PodA的PVC名称

然后用这个文件创建CronJob：

oc create -f cronjob-writer.yaml

2. 解决存储卷的权限不匹配问题 #

就算挂载了同一个PVC，还是可能碰到权限拒绝，这时候要处理存储卷的权限和Job Pod运行用户的匹配问题：

方式一：调整存储卷目录的权限 #

如果你的PVC是ReadWriteMany模式（比如NFS、GlusterFS这类支持多Pod读写的存储），可以先进入PodA，修改存储目录的权限，让Job Pod的用户能写入：

oc rsh PodA
# 给目录添加组写入权限，同时把组设置为root组（OpenShift很多容器的用户属于GID 0的root组）
chmod -R 775 /path/to/mount
chgrp -R 0 /path/to/mount
exit

这样Job Pod的运行用户就能正常写入这个目录了。

方式二：让Job Pod以和PodA相同的用户/组运行 #

如果没法修改存储卷权限，可以在CronJob的YAML里指定安全上下文，让Job Pod用和PodA一样的用户身份运行：

• 先查看PodA的运行用户和组：

  oc describe pod PodA | grep "Security Context" -A5
  

  找到RunAsUser和RunAsGroup的数值。
• 修改CronJob YAML，给容器添加securityContext配置：

  # ... 其他内容不变
          containers:
          - name: crontest
            image: docker-registry.default.svc:5000/myproject/django:latest
            command: ["/opt/app-root/src/scripts/testScript.sh"]
            volumeMounts:
            - name: app-storage
              mountPath: /path/to/mount
            securityContext:
              runAsUser: 1000120000  # 替换成PodA的RunAsUser值
              runAsGroup: 1000120000 # 替换成PodA的RunAsGroup值
  # ... 其他内容不变
  

方式三：临时用anyuid SCC（谨慎使用！） #

如果上面两种方法都走不通，你可以给当前项目的默认服务账号添加anyuid安全上下文约束，这样Job Pod可以以任意用户（包括root）运行。但注意这会降低安全性，只建议在测试环境用：

oc adm policy add-scc-to-user anyuid -z default -n myproject

把myproject换成你的实际项目名称。

3. 替代方案：通过PodA的服务接口写入 #

如果直接挂载存储的方式有各种限制，你还可以换个思路：修改testScript.sh，让它通过PodA提供的API接口来写入文件。比如你的PodA是Django应用，可以写个简单的上传接口，让Job Pod用curl之类的工具调用接口，把文件内容传过去，由PodA自己写入存储。这种方式更符合微服务的设计，也绕开了权限问题。

举个脚本里的调用示例：

curl -X POST http://poda-service.myproject.svc.cluster.local/upload \
  -F "file=@/path/to/local/logfile"

（前提是你已经为PodA创建了Service，确保Job Pod能在集群内部访问到这个服务）

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