Question

在Kubernetes中，我遇到了目录权限问题。我正在使用Pod进行测试以创建基于ElasticSearch提供的docker映像构建的准Elasticsearch实例。

如果我使用基本的.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。我已经将用户和组的各种其他组合设置了，但无济于事。

这是我的广告连播，持续的批量声明和持续的批量定义。

欢迎提出任何建议。

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:来更改新配置的PersistentVolumes（as in this example）的所有权的原因

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

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

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

1 个答案: