2016-02-04 3 views
5

私はkubernetesとGoogleコンテナエンジン(GKE)で遊んでいます。Google Container Engineに非ルートユーザーを配備したDockerコンテナは、マウントされたGCEに書き込むことができません。永続ディスク

私はこれは私の複製コントローラである。このイメージからjupyter/all-spark-notebook

をコンテナを展開:あなたは、私はGoogleのCompute Engineの永続ディスクをマウント見ることができるように

{ 
    "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" 
      } 
     }] 
     } 
    } 

    } 
} 

。私の問題は、コンテナが非rootユーザーを使用し、マウントされたディスクがrootによって所有されていることです。私のコンテナはディスクに書き込むことができません。

  • GCE永続ディスクをマウントし、root以外のユーザーのいないコンテナに対して読み書きできる方法はありますか?
  • もう1つの一般的な質問:Google Container Engineでルートユーザーでコンテナを実行するのは安全ですか?

は、root以外のユーザーでGCEのPD書き込み可能にするために、ポッドのセキュリティコンテキストのFSGroupフィールドを使用することができ、あなたの入力のために事前に

+1

あなたは何を安全と定義しますか? GKはあなたにkubernetesクラスタの一部として実行される各VMを提供するので、少なくともそれは慣れていましたが、それがまだ当てはまるかどうかはわかりませんが、私はそう信じています。だから、rootのユーザコンテナはあなたのホスト上でrootを走らせるのと同じだから、もしあなたのアプリケーションが正常にルートを走らせていれば、あなたは大丈夫であるはずです –

答えて

2

私は同じ問題に遭遇しました。私が使用した回避策は、コンテナが実行されていたホストマシン上でdf -hを実行することでした。そこから永続ストレージのバインドポイントを見つけることができました。それは/var/lib/kubelet/plugins/kubernetes.io/gce-pd/mounts/<pd-name>のように見えるはずです。また、ルートにマウントされていない/devで始まるファイルシステムを持つものの1つになります。

ホストボックスからsudo chmod -R 0777 /var/lib/kubelet/plugins/kubernetes.io/gce-pd/mounts/<pd-name>を実行しても、今度はコンテナがそのディレクトリを使用できるようになりましたが、ファイルは引き続きrootによって所有されます。

+0

私のための仕事は私のために働いた。ありがとう@funkymonkeymonkしかし、私はkubernetes設定ファイルのこの種のアクセス許可の変更を構成する必要があると思います – med

+1

私は同じボートにいます。私はもっ​​と良い解決策が必要だと思いますが、それが起こるまで、この作業はプロビジョニングに自動化するのはかなり簡単です。 – funkymonkeymonk

+0

この作品を追跡できるPRはありますか?私はこれを職場のウォッチリストに載せたいと思っています。 – funkymonkeymonk

11

、ありがとうございました。この例では

、GCEのボリュームは、グループ1234によって所有され、コンテナプロセスは、補足グループのリストに1234を持っています:

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 
+1

あなたの入力をありがとう、私はこの解決策を試みました。 GKEではまだサポートされていません。それはドキュメントにはありませんが、私はそれをここで見つけました。https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/volumes.md – med

+0

@medこれについていくつか掘り下げます。 –

+0

ありがとう@PaulMorie – med

関連する問題