Il contenitore Docker con utente non root distribuito in Google Container Engine non può scrivere sul disco persistente montato GCE

Question

Sto giocando con kubernetes e google container engine (GKE).

ho schierato un contenitore da questa immagine jupyter/all-spark-notebook

Questo è il mio controller di replica:

{ 
    "apiVersion": "v1", 
    "kind": "ReplicationController", 
    "metadata": { 
    "name": "datalab-notebook" 
    }, 
    "spec": { 
    "replicas": 1, 
    "selector": { 
     "app": "datalab-notebook" 
    }, 
    "template": { 
     "metadata": { 
     "name": "datalab-notebook", 
     "labels": { 
      "environment": "TEST", 
      "app": "datalab-notebook" 
     } 
     }, 
     "spec": { 
     "containers": [{ 
      "name": "datalab-notebook-container", 
      "image": "jupyter/all-spark-notebook", 
      "env": [], 
      "ports": [{ 
      "containerPort": 8888, 
      "name": "datalab-port" 
      }], 
      "volumeMounts": [{ 
      "name": "datalab-notebook-persistent-storage", 
      "mountPath": "/home/jovyan/work" 
      }] 
     }], 
     "volumes": [{ 
      "name": "datalab-notebook-persistent-storage", 
      "gcePersistentDisk": { 
      "pdName": "datalab-notebook-disk", 
      "fsType": "ext4" 
      } 
     }] 
     } 
    } 

    } 
} 

Come potete vedere ho montato un disco persistente Google Compute Engine. Il mio problema è che il contenitore utilizza un utente non root e il disco montato è di proprietà di root. quindi il mio contenitore non può scrivere sul disco.

• Esiste un modo per montare GCE dischi persistenti e farli lettura/scrittura per i contenitori senza utenti non-root?
• Un'altra domanda generale: è sicuro eseguire il contenitore con utente root in Google Container Engine?

Grazie in anticipo per il vostro input

Answer 1

Ho incontrato lo stesso problema. La soluzione che ho usato era di eseguire df -h sul computer host su cui era in esecuzione il contenitore. Da lì sono stato in grado di trovare il punto di collegamento della memoria persistente. Dovrebbe assomigliare a /var/lib/kubelet/plugins/kubernetes.io/gce-pd/mounts/<pd-name>. Sarà anche uno di quelli che ha un file system che inizia con /dev che non è montato su root.

Una volta scoperto che è possibile eseguire sudo chmod -R 0777 /var/lib/kubelet/plugins/kubernetes.io/gce-pd/mounts/<pd-name> dalla casella host, e ora almeno il contenitore può utilizzare la directory, anche se i file saranno ancora di proprietà di root.

Answer 2

È possibile utilizzare il campo FSGroup del contesto di protezione del baccello di rendere scrivibile GCE PD dagli utenti non-root.

In questo esempio, il volume GCE saranno di proprietà del gruppo 1234 e il processo di container avrà 1234 nella sua lista dei gruppi supplementari:

apiVersion: v1 
kind: Pod 
metadata: 
    name: test-pd 
spec: 
    securityContext: 
    fsGroup: 1234 
    containers: 
    - image: gcr.io/google_containers/test-webserver 
    name: test-container 
    volumeMounts: 
    - mountPath: /test-pd 
     name: test-volume 
    volumes: 
    - name: test-volume 
    # This GCE PD must already exist. 
    gcePersistentDisk: 
     pdName: my-data-disk 
     fsType: ext4