elasticsearch - Kubernetes 持久卷声明覆盖现有目录的所有者和权限

Question

在 Kubernetes 中，我遇到目录权限问题。我正在使用 pod 进行测试，以创建一个简单的 elasticsearch 实例，该实例是基于 ElasticSearch 提供的 docker 镜像构建的。

如果我使用基本的 .yaml 文件来定义容器，一切都会启动。当我尝试将从 docker 镜像创建的目录替换为通过安装持久卷创建的目录时，就会出现问题。

原来的目录是

drwxrwxr-x  1 elasticsearch root   4096 Aug 30 19:25 data

如果我安装持久卷，它会将所有者和权限更改为

drwxr-xr-x  2 root          root   4096 Aug 30 19:53 data

现在，随着elasticsearch进程以elasticsearch用户的身份运行，这个目录就可以再被访问了。

我已将 pod 的安全上下文的 fsGroup 设置为 1000，以匹配 elasticsearch 组的组。我已将容器的安全上下文的 runAsUser 设置为 0。我已设置用户和组的各种其他组合，但无济于事。

这是我的 Pod、持久卷声明和持久卷定义。

欢迎任何建议。

apiVersion: v1
kind: Pod
metadata:
  name: elasticfirst
  labels:
    app: elasticsearch

spec:
  securityContext:
    fsGroup: 1000

  containers:
  - name: es01
    image: docker.elastic.co/elasticsearch/elasticsearch:7.3.1
    securityContext:
      runAsUser: 0
    resources:
      limits:
        memory: 2Gi
        cpu: 200m
      requests:
        memory: 1Gi
        cpu: 100m
    env: 
      - name: node.name
        value: es01
      - name: discovery.seed_hosts
        value: es01
      - name: cluster.initial_master_nodes
        value: es01
      - name: cluster.name
        value: elasticsearch-cluster
      - name: bootstrap.memory_lock
        value: "true"
      - name: ES_JAVA_OPTS
        value: "-Xms1g -Xmx2g"
    ports:
    - containerPort: 9200
    volumeMounts:
    - mountPath: "/usr/share/elasticsearch/data"
      name: elastic-storage2
  nodeSelector:
    type: compute

  volumes:
  - name: elastic-storage2
    persistentVolumeClaim:
      claimName: elastic-storage2-pvc 



apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: elastic-storage2-pvc
spec:
  storageClassName: local-storage
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 512Mi


apiVersion: v1
kind: PersistentVolume
metadata:
  name: elastic-storage2-pv
spec:
  storageClassName: local-storage
  capacity:
    storage: 512Mi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /var/tmp/pv

Answer 1

您的问题对于正在发生的事情与您想要发生的事情有点令人困惑，但总的来说，这个问题是一个常见问题；这就是为什么许多设置使用 initContainer: 来更改新配置的 PersistentVolume 的所有权 ( as in this example )

在这样的设置中，initContainer:将以root身份运行，但也可能是一个非常薄的容器，其工作只是chown然后退出，留下您的应用程序容器——示例中的elasticsearch——可以作为非特权用户自由运行

spec:
  initContainers:
  - name: chown
    image: busybox
    command:
    - chown
    - -R
    - "1000:1000"
    - /the/data
    volumeMounts:
    - name: es-data
      mountPoint: /the/data
 containers:
 - name: es
   # etc etc