この記事ではDockerとContainerdの違いを説明します。

コンテナランタイム

コンテナ ランタイムは、オペレーティング システム レベルでコンテナを作成および管理するソフトウェア ツールまたはコンポーネントです。これはコンテナ化技術のコアコンポーネントの 1 つであり、コンテナ内でアプリケーションを実行し、分離、リソース管理、セキュリティなどの機能を提供するために使用されます。 Kubernetes では、コンテナ ランタイムはコンテナの管理と実行を担当するコンポーネントです。以前は、Docker が最も一般的に使用されていたコンテナ ランタイムでしたが、時間が経つにつれて、containerd が Kubernetes の別の一般的なコンテナ ランタイムの選択肢になりました。

注: Dockershim は、Kubernetes バージョン 1.24 以降、Kubernetes プロジェクトから削除されました。

コンテナ ランタイムの主なタスクは次のとおりです。

1. コンテナの作成と起動: コンテナ ランタイムは、事前定義されたコンテナ構成情報 (イメージ、コマンド、環境変数など) に基づいてコンテナ インスタンスを作成および起動する役割を担います。
2. コンテナ ファイル システム管理: コンテナ ランタイムは、コンテナのファイル システムを処理し、イメージの内容をコンテナのファイル システムにマウントし、コンテナ間の分離を提供します。
3. リソースの制限と管理: コンテナ ランタイムは、ユーザーまたは管理者が定義したリソース制限に従って、コンテナの CPU、メモリ、ディスクなどのリソースの使用を管理できます。
4. コンテナ ネットワーク: コンテナ ランタイムは、コンテナが他のコンテナまたは外部ネットワークと通信できるように、コンテナのネットワークを構成するのに役立ちます。
5. セキュリティ: コンテナ ランタイムは、コンテナとホスト間の分離を確保し、コンテナ内の悪意のある動作が他のコンテナやホストに影響を及ぼさないようにするためのセキュリティ メカニズムを実装します。

今日のクラウドネイティブ テクノロジーのトレンドでは、コンテナ化テクノロジーが最新のアプリケーション展開の主流の選択肢となっています。 Kubernetes (K8s) は、人気のコンテナ オーケストレーション システムとして、大規模なコンテナ クラスターの管理に広く使用されています。 K8s では、コンテナ ランタイムの選択がパフォーマンス、信頼性、セキュリティにおいて重要な役割を果たします。この記事では、2 つの一般的な K8s コンテナ ランタイムである Containerd と Docker を比較し、それらの類似点と相違点を探ります。

Docker: 元祖リーダー

初期のコンテナ技術である Docker は、従来の仮想化方式を覆し、軽量なコンテナ化によるアプリケーションのパッケージ化、配信、運用を実現しました。 Docker はコンテナ技術の普及に重要な役割を果たしてきました。ユーザーフレンドリーなコマンドライン ツールとグラフィカル インターフェイスにより、コンテナ テクノロジーは開発者にとってより使いやすくなっています。ある時点で、Docker はコンテナ化とほぼ同義になりました。しかし、Kubernetes の台頭により、K8s における Docker の地位は徐々に脅かされるようになりました。一方、完全なコンテナ プラットフォームである Docker には、K8s に必要のない多くの機能が含まれており、リソースの無駄が生じます。一方、K8s 自体はコンテナ オーケストレーションとスケジューリング機能を提供しており、これらは Docker と重複し、ある程度の競合が発生します。 Docker が市場を独占するのを防ぐために、Docker の実装はいくつかの標準化されたモジュールに分割されました。標準化の目的は、モジュールを他の実装に置き換えることができ、特定のメーカーによって制御されないようにすることです。 Dockerは

• dockerクライアント
• ドッカー
• コンテナ
• docker-shim
• ランク

したがって、containerd は docker の基本コンポーネントの 1 つです。 Docker のコンテナの管理と操作は基本的に containerd を通じて完了します。では、containerd とは何でしょうか?

Containerd: K8s エコシステムの標準

Containerd は、Docker チームによって開発されたオープンソースのコンテナ ランタイムです。軽量で高性能なコンテナ ランタイム環境の提供に重点を置いています。 Containerd は純粋なコンテナ ランタイムとして、K8s のアーキテクチャと要件にさらに沿うように設計されています。リソースフットプリントが小さく、起動時間が短く、パフォーマンスが向上します。 K8s コミュニティは Containerd の利点を認識しており、K8s エコシステムの標準コンテナ ランタイムとして使用しています。 Containerd は、コンテナ イメージの転送と保存、コンテナの実行と管理、ストレージとネットワークなど、ホスト内のコンテナのライフサイクル全体を管理できます。より詳細には、Containerd は次のことを行います。

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

コンテナ ランタイム インターフェース (CRI)

コンテナ ランタイム インターフェース (CRI)。 CRI は、クラスター コンポーネントを再コンパイルせずに kubelet がさまざまなコンテナ ランタイムを使用できるようにするプラグイン インターフェイスです。 kubelet が Pod とそのコンテナを起動できるように、クラスター内のすべてのノードで機能するコンテナ ランタイムが必要です。コンテナ ランタイム インターフェース (CRI) は、kubelet とコンテナ ランタイム間の通信に使用される主要なプロトコルです。

Kubernetes と dockershim

Kubernetes アーキテクチャ図から、Kubelet の下に、OS との実際のやり取りである Contianer ランタイム (コンテナ ランタイム) のレイヤーがあることがわかります。このコンテナ ランタイムは、コンテナのライフ サイクル全体を管理し、イメージのプルなどの操作を実行する役割を担います。

現在サポートされているCRIバックエンド

Kubernetes を初めて使用する場合、通常はデフォルトで Docker をコンテナ ランタイムとして使用します。実際、Kubernetes 1.5 は CRI をサポートしています。 CRI インターフェースを通じて、Pod のバックエンドとして他のコンテナ ランタイムを指定できます。現在、CRI をサポートしているバックエンドは次のとおりです。

• cri-o: cri-o は Kubernetes 用の CRI 標準の実装であり、Kubernetes が OCI 互換のコンテナ ランタイムを間接的に使用できるようにします。 cri-o は、Kubernetes が OCI 互換のコンテナ ランタイムを使用するための中間層として考えることができます。
• cri-containerd: Containerd に基づく Kubernetes CRI 実装。 Containerd は、CRI-Containerd のプロセスおよび実装です。
• rkt: CoreOS が Docker に対抗するために推進しているコンテナ ランタイム
• frakti: ハイパーバイザベースの CRI
• Docker: Kubernetes が元々サポートしていたコンテナ ランタイム。まだ kubelet から完全に分離されていません。 Docker は OCI 標準も推進しました。

ドッカーシム

Kubernetes が CRI 動作仕様を提案したとき、Docker は containerd を分離したばかりで、CRI 標準をサポートしていませんでした。当時、Docker は最も主流かつ権威のあるコンテナ技術であったため、Kuberentes は CRI インターフェース仕様を提案したものの、CRI と Docker 間の接続を適応させる必要があり、Kubelet と Docker のコンテナ ランタイムを接続するための中間層またはシムが必要でした。そこで、Dockershim が kubelet に追加されました (shim は一時的かつ互換性があることを意味します)。 docker をランタイムとして使用する場合、コンテナを起動する実際のプロセスは次のようになります。この段階では、dockershim コンポーネントは Kubelet コード内にあります。つまり、Dockershim は K8S 組織によって開発および保守されています。 K8S 組織は Docker のバージョンリリースを制御および管理できないため、Docker が新しいリリースをリリースするたびに、K8S 組織は Dockershim を迅速に更新および保守することに重点を置く必要があります。 Kubernetes バージョン 1.24 では、dockershim が正式に削除され、非推奨になりました。この問題の本質は、組み込みの dockershim 機能を放棄し、Containerd に直接接続することです (CRI は後でサポートされます)。この方法はより標準的であり、呼び出しリンクもシンプルです。

通話関係の比較

ランタイムが docker の場合の呼び出しチェーン: 呼び出し関係は次のとおりです: kubelet --> dockershim (kubelet プロセス内) --> dockerd --> containerd ランタイムが containerd の場合の呼び出しチェーン: 呼び出し関係は次のとおりです: kubelet --> cri plugin (containerd プロセス内) --> containerd 概要: k8s の観点からは、Containerd をランタイム コンポーネントとして選択する方が適切です。これは、Containerd の方が呼び出しチェーンが短く、コンポーネントが少なく、より安定しており、占有するノード リソースが少ないためです。

一般的なコマンド

ctr は containerd のクライアント ツールです。 crictl は、k8s ノード上のコンテナ ランタイムとアプリケーションを検査およびデバッグするために使用できる、CRI 準拠のコンテナ ランタイム コマンド ライン インターフェイスです。 ctr -v は containerd のバージョンを出力し、crictl -v は k8s の現在のバージョンを出力します。結果から、明らかに crictl が k8s に使用されていることがわかります。