DockerとK8Sの関係を一文でまとめる

一言でまとめると、Docker は単なるコンテナの一種であり、単一のボディを対象としていますが、K8S は複数のコンテナを管理でき、クラスターを対象としており、Docker はコンテナ ソリューションとして K8S によって管理できます。以下に詳しい紹介をさせていただきます。

1. コンテナの核となる概念

OCI、CR、Runc、Containerd、CRI というコア概念を紹介します。

1.1.コンテナ操作仕様

コンテナ ランタイム仕様 OCI (Open Container Initiative) は、イメージとコンテナ ランタイムの仕様を定義するオープン コンテナ ランタイム仕様です。

コンテナ イメージ仕様: この仕様の目的は、コンテナ イメージを構築、出荷、実行準備するための相互運用可能なツールを作成することです。

コンテナ ランタイム仕様: この仕様は、コンテナの構成、実行環境、およびライフサイクルを定義するために使用されます。

1.2 コンテナランタイム

コンテナ ランタイムは、イメージのプル、ファイル システムへのイメージの抽出、コンテナのマウント ポイントの準備、コンテナが期待どおりに実行されるようにコンテナ イメージからメタデータを設定する、コンテナに分離を割り当てるようにカーネルに通知する、コンテナにリソース制限を割り当てるようにカーネルに通知する、コンテナを起動するためのシステム命令を呼び出すなどのタスクを担当します。

コンテナ ランタイムには、Containerd、CRI-O、Kata、Virtlet などのソリューションが利用可能です。

1.3 ランC

RunC (Run Container) は Docker の libcontainer から移行され、コンテナの起動と停止、リソースの分離などの機能を実装します。 Docker は、OCI コンテナ ランタイム標準のリファレンス実装として、RunC を OCI に寄贈しました。

RunC は、コンテナの作成と実行に使用される、OCI 標準に基づいた軽量のコンテナ実行ツールです。純粋にシステムの観点から見ると、Runc は基盤となるコンテナ ランタイムです。

1.4、コンテナ

Containerd は、RunC によって作成されたコンテナの実行ステータスを維持するために使用されます。つまり、RunC はコンテナの作成と実行に使用され、containerd はコンテナを管理するための常駐プロセスとして使用されます。 Containerd (コンテナ デーモン) は、コンテナの管理と実行に使用されるデーモン プロセスです。イメージをプル/プッシュしたり、コンテナのストレージとネットワークを管理したりするために使用できます。コンテナを作成して実行するには、runc を呼び出します。

Containerd は長い間 Docker Engine に含まれていましたが、現在はよりオープンで安定したコンテナ運用インフラを提供することを目標に、Containerd は独立したオープンソース プロジェクトとして Docker Engine から分離されました。分離された Containerd にはさらに多くの機能があり、コンテナ ランタイム管理全体のすべての要件をカバーし、より強力なサポートを提供します。

Containerd は、シンプルさ、堅牢性、移植性を重視した業界標準のコンテナ ランタイムです。 Containerd は次のタスクを担当します。

• コンテナのライフサイクルを管理する（コンテナの作成から破棄まで）
• コンテナイメージのプル/プッシュ
• ストレージ管理（画像やコンテナデータの保存管理）
• runc を呼び出してコンテナを実行します (runc などのコンテナ ランタイムと対話します)
• コンテナのネットワークインターフェースとネットワークの管理

K8S v1.24 以降、Dockershim は削除され、コンテナ ランタイムとして Containerd が使用されるようになりました。 Containerd を選択する理由は、呼び出しチェーンが短く、コンポーネントが少なく、より安定しており、占有するノード リソースが少ないためです。

1.5. Docker、Containerd、RunC の関係

3 つの関係は以下の図に示されています。

1.6 演色評価数

コンテナ ランタイムは、Kubernetes (K8S) の最も重要なコンポーネントの 1 つであり、イメージとコンテナのライフ サイクルの管理を担当します。 Kubelet は、Container Runtime Interface (CRI) を介してコンテナ ランタイムと対話し、イメージとコンテナを管理します。

CRI (コンテナ ランタイム インターフェイス) は、主に K8S とコンテナ ランタイム間の API 呼び出しを定義するために使用されます。 Kubelet は CRI を通じてコン​​テナ ランタイムを呼び出します。コンテナランタイムが CRI インターフェースを実装している限り、K8S の kubelet コンポーネントに接続できます。

2. DockerとK8Sの関係

Docker と K8S は基本的にコンテナを作成するためのツールです。 Docker は単一のマシンに使用され、K8S はクラスターに使用されます。

スタンドアロン コンテナ ソリューションでは、Docker が第一の選択肢となります。時代の発展とともに、システムパフォーマンスに対する要件はますます高まっています。高可用性と高同時実行性が基本的な要件です。要求が高くなるにつれて、単一のマシンのパフォーマンスでは明らかに追いつかなくなり、サーバー クラスター管理が開発トレンドになっているため、Kubernetes に代表されるクラウド ネイティブ技術が力強く発展しています。

2.1、コンテナ作成呼び出しリンク

Docker、Kubernetes、OCI、CRI-O、containerd、runc はどのように連携するのでしょうか?下の図を参照してください。

上の図はコンテナの呼び出しチェーンを示しています。図からわかるように、CRI を実装するコンテナ ランタイムはすべて K8S に採用できます。 Containerd は CRI プラグインを通じて CRI に適合しますが、CRI-O は CRI の大量生産向けに構築されています。

また、Docker と K8S を含む 2 つの主要なラインがあることもわかります。 Docker は主に単一のアプリケーションを対象としていますが、K8S はクラスターに使用されます。

2.2 関係

上記のコンテナ呼び出しリンクから、Containerd と CRI-O が何をするのかをよく理解していることがわかりますが、Docker と K8S 間の接続を整理する必要があります。

この図は、K8S と Docker (K8S バージョン 1.23 以前を含む) 間の接続を示しています。 K8S-1.24 以降では、docker-shim モジュールが削除されます。彼らの間の小さな物語を引き続き見てみましょう。

3. Dockershimについての短い物語

3.1.ドッカーシムの起源

K8S - v1.24 以降、Dockershim は削除されました。これは K8S プロジェクトにとって前向きな動きです。

K8S の初期の頃は、サポートされていたコンテナ ランタイムは 1 つだけで、そのコンテナ ランタイムは Docker Engine でした。当時は他に選択肢がなかったのです。

時間が経ち、rkt や hypernetes などのコンテナ ランタイムが追加され始めると、K8S ユーザーは自分にとって最適なランタイムを選択したいと考えていることが明らかになりました。したがって、K8S では、K8S クラスターが任意のコンテナ ランタイムを柔軟に使用できるようにする方法が必要です。

そこで、Container Runtime Interface (CRI) がリリースされました。 CRI の導入は K8S プロジェクトと K8S ユーザーにとって素晴らしいことでしたが、問題が発生しました。コンテナ ランタイムとしての Docker Engine の使用は CRI より前から行われていたため、Docker Engine は CRI と互換性がありません。

この問題を解決するために、kubelet コンポーネントに小さなソフトウェア シム (dockershim) が導入されました。これは、特に Docker Engine と CRI 間のギャップを埋め、クラスターが引き続き Docker Engine をコンテナー ランタイムとして使用できるようにするためのものです。

3.2、ドッカーシムの運命

ただし、この小さなソフトウェア シムは、永続的な解決策となることを意図したものではありません。長年にわたり、その存在により、kubelet 自体に多くの不必要な複雑さが生じてきました。このシムにより、一部の Docker 統合が一貫性なく実装され、メンテナーの負担が増加しました。

つまり、このアプローチは複雑さが増すだけでなく、コンポーネントの増加による不安定性も増し、メンテナンスの負担も増えるため、dockershim が放棄されるのは時間の問題です。

概要: dockershim は、Docker をサポート対象のコンテナ ランタイムにするために、K8S コミュニティによって維持されてきた互換性プログラムです。いわゆる放棄は、K8S が現在のコード リポジトリ内の dockershim のメンテナンス サポートを放棄することを意味するだけです。 K8S が当初の計画どおりに CRI の維持のみを担当できるように、CRI 互換のコンテナ ランタイムを K8S ランタイムとして使用できます。

3.3、フローチャート:

概要: この記事では、コンテナのコアコンセプト、Docker と K8S の関係、Dockershim のストーリーについて説明します。お役に立てれば幸いです！