Kubernetes展開のDocker

13

兄弟ドッカーコンテナーを作成するサードパーティライブラリを使用しています：

docker run -d /var/run/docker.sock:/var/run/docker.sock ...

上記のコンテナからKubernetesデプロイメントを作成しようとしていますが、現在次のようになっています：

unix：///var/run/docker.sockにあるDockerデーモンに接続できません。Dockerデーモンは実行されていますか？

/var/run/docker.sockデプロイメントyamlでボリュームとして宣言していないため、これは予期されています。

問題は、これを行う方法がわからないことです。/var/run/docker.sock展開yamlのボリュームとしてマウントすることは可能ですか？

そうでない場合、Kubernetes展開/ポッド内からdocker兄弟コンテナを実行するための最良のアプローチは何ですか？

kubernetes docker-in-docker

— rys
ソース

19

k8sの監督の外でコンテナを起動するのは私には脆弱に思えますが/var/run/docker.sock、未検証ですが、hostPathボリュームでマウントできる必要があります。

ドキュメントからのバリエーションの例：

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: gcr.io/google_containers/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /var/run/docker.sock
      name: docker-sock-volume
  volumes:
  - name: docker-sock-volume
    hostPath:
      # location on host
      path: /var/run/docker.sock
      # this field is optional
      type: File

コンテナ内のdockerクライアントからホスト上のdockerデーモンへの通信を許可するには、単純なマウントで十分だと思いますが、書き込み許可エラーが発生した場合、そのようなsecurityContextオブジェクトを使用して特権コンテナとしてコンテナを実行する必要があることを意味します（ちょうど追加を示すための上記の抜粋、ドキュメントから取得した値）：

spec:
  containers:
  - image: gcr.io/google_containers/test-webserver
    securityContext:
      privileged: true
    name: test-container

— 天柴
ソース

これはうまくいきました、ありがとう。ええ、それはサードパーティのツールなので、理想的ではありません。しかし、少なくともKubernetesのメインコンテナの信頼性を高めたいと思っています。コンテナーは、自動UIのテストのためにブラウザーを備えた一時コンテナーを増やし、ブラウザーコンテナーは破棄されます。

— rys

@rys yes、それは私が考えていたケースでしたが、k8sが「ランチャー」コンテナを移動する可能性があるため、ノードの負荷が高くなりすぎると問題が発生する可能性があります。しかし、この場合、テストスイートの失敗は容認できるものだと

— 思います-Tensibai

2

これは実用的な解決策ですが（私は自分で使用しています）、KubernetesポッドでDockerを実行することにより、いくつかの欠点があります。 /var/run/docker.sock

ほとんどの場合、Kubernetesの制御外でDockerコンテナを使用しているという事実です。

私が見つけたもう一つの提案された解決策を使用している側の車のあなたのポッドで容器を。KubernetesのDocker-in-Dockerの事例をご覧ください。提案されたソリューションがパート2にある2つのパートがあります。

これがお役に立てば幸いです。

— エルダッド・アシス
ソース