Данные контейнера Mongodb становятся «доступными только для чтения» после перезапуска кубернетов с помощью glusterfs в качестве хранилища?

Question

My mongo работает как контейнер-докер на кубернетах, с glusterfs, обеспечивающим постоянный объем. После того, как я перезапустить kuberntes (отходящие и перезапуск машины питание), все Mongo стручки не могут вернуться, их журналы:

chown: changing ownership of `/data/db/user_management.ns': Read-only file system 
chown: changing ownership of `/data/db/storage.bson': Read-only file system 
chown: changing ownership of `/data/db/local.ns': Read-only file system 
chown: changing ownership of `/data/db/mongod.lock': Read-only file system 

Здесь /data/db/ является установленным объемом Gluster и я могу убедиться, что это rw режим !:

# kubectl get pod mongoxxx -o yaml 
apiVersion: v1 
kind: Pod 
spec: 
    containers: 
    - image: mongo:3.0.5 
    imagePullPolicy: IfNotPresent 
    name: mongo 
    ports: 
    - containerPort: 27017 
     protocol: TCP 
    volumeMounts: 
    - mountPath: /data/db 
     name: mongo-storage 
    volumes: 
    - name: mongo-storage 
    persistentVolumeClaim: 
     claimName: auth-mongo-data 

# kubectl describe pod mongoxxx 
... 
    Volume Mounts: 
     /data/db from mongo-storage (rw) 
     /var/run/secrets/kubernetes.io/serviceaccount from default-token-wdrfp (ro) 
    Environment Variables: <none> 
Conditions: 
    Type  Status 
    Initialized True 
    Ready  False 
    PodScheduled True 
Volumes: 
    mongo-storage: 
    Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace) 
    ClaimName: auth-mongo-data 
    ReadOnly: false 
... 

# kubect get pv xxx 
apiVersion: v1 
kind: PersistentVolume 
metadata: 
    annotations: 
    pv.kubernetes.io/bound-by-controller: "yes" 
    name: auth-mongo-data 
    resourceVersion: "215201" 
    selfLink: /api/v1/persistentvolumes/auth-mongo-data 
    uid: fb74a4b9-e0a3-11e6-b0d1-5254003b48ea 
spec: 
    accessModes: 
    - ReadWriteMany 
    capacity: 
    storage: 4Gi 
    claimRef: 
    apiVersion: v1 
    kind: PersistentVolumeClaim 
    name: auth-mongo-data 
    namespace: default 
    glusterfs: 
    endpoints: glusterfs-cluster 
    path: infra-auth-mongo 
    persistentVolumeReclaimPolicy: Retain 
status: 
    phase: Bound 

И когда я ls на узле kubernetes:

# ls -ls /var/lib/kubelet/pods/fc6c9ef3-e0a3-11e6-b0d1-5254003b48ea/volumes/kubernetes.io~glusterfs/auth-mongo-data/ 
total 163849 
    4 drwxr-xr-x. 2 mongo input  4096 1月 22 21:18 journal 
65536 -rw-------. 1 mongo input 67108864 1月 22 21:16 local.0 
16384 -rw-------. 1 mongo root 16777216 1月 23 17:15 local.ns 
    1 -rwxr-xr-x. 1 mongo root   2 1月 23 17:15 mongod.lock 
    1 -rw-r--r--. 1 mongo root  69 1月 23 17:15 storage.bson 
    4 drwxr-xr-x. 2 mongo input  4096 1月 22 21:18 _tmp 
65536 -rw-------. 1 mongo input 67108864 1月 22 21:18 user_management.0 
16384 -rw-------. 1 mongo root 16777216 1月 23 17:15 user_management.ns 

Я не могу chown хотя объем установлен как rw.

Мой хозяин CentOs 7.3: Linux c4v160 3.10.0-514.el7.x86_64 # 1 SMP Вт 22 ноября 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux.

Answer 1

Я предполагаю, что это потому, что объем тумана, который я предоставил, является нечистым. Объем glusterfs infra-auth-mongo может состоять из грязных каталогов. Одним из решений является удаление этого тома и создание другого.

Еще одно решение - взломать докер-файл mongodb, заставить его изменить владельца /data/db перед запуском процесса mongodb. Пример: https://github.com/harryge00/mongo/commit/143bfc317e431692010f09b5c0d1f28395d2055b