没有办法使用Pod的定义来设置UID，但您可以使用与主容器相同的volumeMount的initContainer来设置所需权限。
在像您这样需要将用户所有权设置为非根值的情况下，它很方便。
下面是一个示例配置（根据您的需要更改）：

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - name: sec-ctx-demo
    image: busybox
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: false
  initContainers:
  - name: volume-mount-hack
    image: busybox
    command: ["sh", "-c", "chown -R 999:999 /data/demo"]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo

不，没有这样的选择。要检查securityContext中可用的每个选项，可以使用

kubectl explain deployment.spec.template.spec.securityContext

根据文件

fsGroup      <integer>
     A special supplemental group that applies to all containers in a pod. Some
     volume types allow the Kubelet to change the ownership of that volume to be
     owned by the pod: 1. The owning GID will be the FSGroup 2. The setgid bit
     is set (new files created in the volume will be owned by FSGroup) 3. The
     permission bits are OR'd with rw-rw---- If unset, the Kubelet will not
     modify the ownership and permissions of any volume.

通过组所有权来处理对文件的访问通常是一个好主意，因为在受限的kubernetes配置中，您实际上无法控制用户ID或组ID，例如在RedHat Openshift中。
如果您的kubernetes提供商允许，您可以使用runAsUser

runAsUser    <integer>
     The UID to run the entrypoint of the container process. Defaults to user
     specified in image metadata if unspecified. May also be set in
     SecurityContext. If set in both SecurityContext and PodSecurityContext, the
     value specified in SecurityContext takes precedence for that container.

您的应用程序将与您想要的uid一起工作，并且自然地将创建和访问您想要的文件。如前所述，这样做通常不是最好的主意，因为它使应用程序在不同平台上的分发变得更加困难。

另一种设置用户/组或权限的方法是使用preStart钩子。根据文档，preStart将在pod创建后执行。

lifecycle:
  postStart:
    exec:
        command: ["/bin/sh", "-c", "WHATEVER BASH COMMAND YOU NEED TO ON YOUR POD"]