4

minikube で 2 つの k8s 環境をセットアップしました。旗のある--container-runtime=dockerものと--container-runtime=containerd旗のあるもの。ここに私が見る違いがあります。

を設定するcontainer-runtime=dockerと、これらのことが起こります

  1. 実行中のdockerdサービスがあります
  2. dockerdサービスはcontainerd独自の子として生成されます
  3. /usr/bin/containerd-shim-runc-v2実際のコンテナーを実行するプロセスがあり、これらのそれぞれの親はcontainerd-shim-runc-v2システム上の PID 1 です。

を設定するcontainer-runtime=containerdと、これらのことが起こります

  1. そこにはdockerdサービスも曖昧さもありません。
  2. PID 1が所有するcontainerdプロセスがあります。ここでも、当然のことです。
  3. containerd-shim実際のコンテナを実行するプロセスがあり、これらの各プロセスの親はcontainerd-shimcontainerd

だからここに私の質問があります

  1. containerd-shimとはどう違いcontainerd-shim-runc-v2ますか？彼らはほとんど似たようなフラグなどを取っているようです.
  2. シナリオ 1 ではシムが PID 1 の子であるのに、シナリオ 2 ではシムが containerd の子であるのはなぜですか?

編集：編集を考えただけです。ubuntu 20 ボックスに docker をインストールすると、dockerd は親が PID 1 の別のプロセスになり、containerd は親が PID 1 の別のプロセスになり、すべてのコンテナーは PID が 1 の container-shim-runc-v2 の子になります。 ?!?! containerdの子ではないのはなぜdockerdですか? これはどこで構成されていますか?

4

1 に答える 1

7

私はこのトピックを掘り下げ、次の結論と情報源にたどり着きました。

1. containerd-shim と containerd-shim-runc-v2 の違いは何ですか? 彼らはほとんど似たようなフラグなどを取っているようです.

これらはバージョンが異なるだけcontainerd-shim-runc-v2で、最新バージョンのcontainerd-shim. ソースコードはこちらをご覧ください。

その docker はまだcontainerd-shimの代わりに使用しているようですcontainerd-shim-runc-v2。基本機能は、シムが runc コンテナーを監視して、runc がランタイムを終了したときに containerd に通知するため、シムと同じ機能です。

API の違いが気になる場合は、ソースコードを参照してください。しかし、機能的には、それらは shim API の異なるバージョンにすぎません。

2. シナリオ 1 では shim が PID 1 の子であるのに、シナリオ 2 では shim が containerd の子であるのはなぜですか?

最終的に、それらは両方とも PID 1 の子であり、シムは PID 1 の子である containerd の子です。

このブログ投稿では、k8s とワーカー ノードでのランタイムの概要を説明しています。特に、Docker、containerd、および shims に関するセクションでは、質問に対するより多くの視点が得られます。

shim は、コンテナー マネージャーとランタイムの間に配置され、通信を容易にし、発生する可能性のある統合の問題を防ぎます。これにより、デーモンのないコンテナーが可能になります。基本的に、コンテナのプロセスの親として位置し、通信を容易にし、コンテナの実行時間の長いプロセスを排除します。シムとコンテナのプロセスはしっかりと結合されています。ただし、コンテナー マネージャーのプロセスからは完全に分離されています。

これは、containerd、 shim、およびそれらが Linux とどのように相互作用するかについてのより詳細なリソースです。

このリソースでは、Linux でのrunc 、containerd、およびそれらの PID について詳しく説明しています。

于 2021-05-25T09:21:51.173 に答える