コンテナ技術の発展と基本原理

コンテナ技術の開発背景

近年、コンテナ技術は急速に世界を席巻し、アプリケーションの開発、配信、運用モードを覆し、クラウドコンピューティング、インターネットなどの分野で広く使用されるようになりました。実は、コンテナ技術は約 20 年前に登場しましたが、2013 年に Docker がリリースされるまでは普及しませんでした。これは、偶然の要因と、全体的な環境によって生み出された必然的な要因の両方によるものでした。ここではコンテナの背景と開発プロセスを振り返ります。

電子コンピュータが初めて登場したとき、ハードウェアのコストが高かったため、リソースの利用率を向上させてコストを削減するために、複数のユーザー間でコンピューティング リソースを共有する方法が模索されました。 1960 年代には、ハードウェア技術に基づくホスト仮想化技術が登場しました。物理ホストは複数の小さなマシンに分割できます。各マシンのハードウェアは互いに共有されず、各マシンに独自のオペレーティング システムをインストールして使用できます。 1990 年代後半には、X86 アーキテクチャに基づくハードウェア仮想化テクノロジが徐々に登場しました。同じ物理マシン上で複数のオペレーティング システム インスタンスを分離できるため、多くの利点がもたらされます。現在、ほとんどのデータセンターはハードウェア仮想化テクノロジを使用しています。

ハードウェア仮想化ではリソースを分離する機能が提供されますが、仮想マシンを使用してアプリケーションを分離する効率は低いことがよくあります。結局のところ、各仮想マシンにオペレーティング システム インスタンスをインストールまたはコピーし、そこにアプリケーションを展開する必要があります。そのため、アプリケーション指向の管理をより便利にする、より軽量なソリューションであるオペレーティング システムの仮想化が検討されてきました。いわゆるオペレーティング システムの仮想化とは、オペレーティング システムが仮想システム環境を作成し、アプリケーションが他のアプリケーションの存在を認識せず、あたかもすべてのシステム リソースを単独で占有しているかのようにすることで、アプリケーションの分離の目的を達成することです。この方法では、仮想マシンは必要なく、アプリケーションを相互に分離できます。アプリケーションは同じオペレーティング システム インスタンスを共有するため、仮想マシンよりも多くのリソースを節約し、パフォーマンスが向上します。オペレーティング システムの仮想化は多くのシステムでコンテナーとも呼ばれ、以下ではオペレーティング システムの仮想化を指す場合にもコンテナーが使用されます。

オペレーティング システムの仮想化は、FreeBSD 4.0 で Jail が導入された 2000 年に初めて登場しました。 Jail は、ファイル システムの分離のための chroot 環境を強化および改善します。 2004 年に、Sun はゾーンとリソース管理を組み込んだ Solaris 10 Containers をリリースしました。ゾーンは名前空間の分離とセキュリティ アクセス制御を実装し、リソース管理はリソース割り当て制御を実装します。 2007 年に、コントロール グループ (略して cgroups) が Linux カーネルに導入されました。コントロール グループを使用すると、プロセスのグループによって使用されるリソース (CPU、メモリ、I/O、ネットワークなど) を制限および分離できます。

2013 年に、Docker は Docker オープンソース プロジェクトをリリースし、コンテナーを使用するための一連のシンプルなツール チェーンを提供しました。 Docker がコンテナ技術の火を最初に点火し、クラウドネイティブ アプリケーションの変革の幕を開き、コンテナ エコシステムの急速な発展を促進したと言っても過言ではありません。 2020 年現在、Docker Hub のイメージは 1,300 億回ダウンロードされており、ユーザーは約 600 万個のコンテナ イメージ リポジトリを作成しています。これらのデータから、ユーザーが従来のモデルからコンテナベースのアプリケーションリリースおよび運用モデルに驚くべき速度で切り替えていることがわかります。

2015 年、OCI (Open Container Initiative) は、異なるメーカーのコンテナ ソリューションが相互運用できるように、コンテナ イメージとランタイム仕様の開発をオープン ソース テクノロジ コミュニティに促進することを目的として、Linux Foundation プロジェクトとして設立されました。クラウドネイティブ分野におけるコンテナ技術の応用を促進し、ユーザーがクラウドネイティブアプリケーションを開発するための敷居を下げることを目的として、CNCFも同年に設立されました。創立メンバーには、Google、Red Hat、Docker、VMware など多くの企業や組織が含まれています。

CNCF が最初に設立されたとき、オープンソース プロジェクトは 1 つしかありませんでしたが、それが後に有名になった Kubernetes になりました。 Kubernetes は、もともと Google チームによって開発されたコンテナ アプリケーション オーケストレーション ツールです。その後、オープンソース化され、シード プロジェクトとして CNCF に寄贈されました。 Kubernetes はベンダー中立のオープンソース プロジェクトであるため、オープンソース化後はコミュニティ ユーザーや開発者から幅広い参加とサポートを受けています。 2018 年までに、Kubernetes はコンテナ オーケストレーションの事実上の標準となり、最初の CNCF 卒業プロジェクトとなりました。 2020年8月には、CNCF傘下のオープンソースプロジェクトの数は、中国発のHarborなどのプロジェクトを含めて63に増加しました。

コンテナの開発の歴史を見ると、コンテナは初期の頃はあまり注目されていなかったことがわかります。その主な理由は、当時はオープンなクラウドコンピューティング環境がまだ登場しておらず、主流になっていなかったためです。 2010 年以降、IaaS、PaaS、SaaS などのクラウド プラットフォームが徐々に成熟するにつれて、ユーザーはクラウド アプリケーションの開発、展開、運用、保守の効率性にますます注目するようになり、コンテナーの価値を再発見し、最終的にコンテナー テクノロジの普及に貢献しました。

コンテナの基礎

このセクションでは、Linux コンテナを例に、主に名前空間とコントロール グループ (cgroup) を含むコンテナの実装原則について説明します。

名前空間

名前空間は、Linux オペレーティング システム カーネルにおけるリソース分離方法であり、異なるプロセスが異なるシステム ビューを持つことを可能にします。システムビューとは、ホスト名、ファイルシステム、ネットワークプロトコルスタック、他のユーザーやプロセスなど、プロセスが認識できるシステム環境のことです。名前空間の使用後は、各プロセスは独立したシステム環境を持ち、プロセスは互いの存在を認識せず、互いに分離されます。現在、Linux にはネスト可能な 6 種類の名前空間があります。

• マウント: ファイル システムのマウント ポイントを分離します。異なる「マウント」名前空間内のプロセスは、異なるファイル システムを参照できます。
• ネットワーク: ネットワーク デバイス、IPv4 および IPv6 プロトコル スタック、ルーティング テーブル、ファイアウォールなど、プロセス ネットワークに関連するシステム リソースを分離します。
• IPC: プロセスが相互に通信するための名前空間。異なる名前空間内のプロセスは通信できません。
• PID: プロセス ID は異なる名前空間で独立して番号付けされ、異なる名前空間のプロセスは同じ ID を持つことができます。もちろん、これらのプロセスは、オペレーティング システムのグローバル ID (名前空間外) 内で一意に番号が付けられます。
• UTS: システム識別子名前空間。各名前空間には異なるホスト名と NIS ドメイン名を設定できます。
• ユーザー: 名前空間内のユーザーは、グローバルとは異なるユーザー ID とグループ ID を持つことができ、異なる権限を持つことができます。

名前空間は、追加のシステム オーバーヘッドをほとんど発生させずに同じオペレーティング システム内のプロセスを分離する方法を実装するため、非常に軽量な分離方法です。プロセスを開始して実行するプロセスは、名前空間内と名前空間外ではほぼ同じです。

対照群

名前空間はプロセスの分離を実装しますが、各名前空間内のプロセスは CPU、ディスク I/O、メモリなどの同じシステム リソースを共有するため、プロセスが特定のリソースを長時間占有すると、他の名前空間内のプロセスに影響が及びます。これが「うるさい隣人」現象です。したがって、名前空間ではプロセス分離の目的が完全には達成されません。このため、Linux カーネルはこの問題を処理するための制御グループ (cgroups) 機能を提供します。

Linux はプロセスを制御グループに分割し、各グループのプロセスに対してリソース使用ルールと制限を設定します。リソースの競合が発生すると、システムは各グループの定義に応じて制御グループ間でリソースを割り当てます。制御グループがルールを設定できるリソースには、CPU、メモリ、ディスク I/O、ネットワークなどがあります。この方法では、一部のプロセスが他のプロセスのリソースを無期限に占有することがなくなります。

Linux システムは、名前空間を通じてプロセスの可視および利用可能なリソースを設定し、制御グループを通じてプロセスのリソース使用を規定して、分離されたプロセスの仮想環境 (つまり、コンテナー) を確立します。

コンテナランタイム

Linux は、コンテナの基礎となる名前空間と制御グループという 2 つの主要なシステム機能を提供します。ただし、コンテナ内でプロセスを実行するには、コンテナを作成するための Linux システム関数を呼び出す便利な SDK またはコマンドも必要です。コンテナ ランタイムは、コンテナ プロセスを実行および管理するためのツールです。

コンテナ ランタイムは、それぞれ異なる機能の重点を持つ低レベル ランタイムと高レベル ランタイムに分かれています。低レベルランタイムは主にコンテナの実行を担当し、特定のコンテナ ファイル システム上でコンテナ プロセスを実行できます。高レベルランタイムは主にコンテナイメージのダウンロードと解凍、コンテナに必要なファイルシステムへの変換、コンテナのネットワークの作成など、コンテナに必要な動作環境を準備し、その後低レベルランタイムを呼び出してコンテナを起動します。主要なコンテナランタイム間の関係を次の図に示します。

OCI ランタイム仕様

OCI は 2015 年に設立され、Linux Foundation 傘下の共同プロジェクトです。主にコンテナイメージ形式やコンテナランタイムを含む、オープンガバナンス方式でオペレーティングシステム仮想化（特に Linux コンテナ）のオープンな業界標準を開発しています。初期メンバーには、Docker、Amazon、CoreOS、Google、Microsoft、VMware などの企業が含まれています。 OCI が最初に設立されたとき、Docker はコンテナ イメージ形式とランタイムのドラフトと、対応する実装コードを OCI に寄贈しました。もともと Docker に属していた libcontainer プロジェクトは OCI に寄贈され、独立したコンテナ ランタイム プロジェクト runC になりました。

OCI ランタイム仕様は、コンテナの構成、ランタイム、およびライフサイクルの標準を定義します。主流のコンテナ ランタイムは、システムの移植性と相互運用性を向上させるために OCI ランタイム仕様に準拠しています。ユーザーはニーズに応じて選択できます。

まず、コンテナを起動する前に、必要なファイルを特定の形式でファイルシステムに保存する必要があります。 OCI ランタイム仕様は、コンテナ ファイル システム バンドルの標準を定義します。 OCI ランタイムの実装では、通常、高レベルランタイムは OCI イメージをダウンロードし、OCI イメージを OCI ランタイム ファイル システム バンドルに解凍します。次に、OCI ランタイムは構成情報を読み取り、コンテナ内でプロセスを開始します。 OCI ランタイム ファイル システム パッケージは、主に次の 2 つの部分で構成されます。

• config.json: これは必須の構成ファイルであり、ファイル システム パッケージのルート ディレクトリに保存されます。 OCI ランタイム仕様は、Linux、Windows、Solaris、仮想マシンの 4 つのプラットフォームのランタイムに対応する構成仕様を提供します。
• コンテナ ルート ファイル システム: コンテナの起動後にプロセスによって使用されるルート ファイル システム。ファイル システムのパスは、config.json の root.path プロパティによって決定され、通常は "rootfs/" になります。

次に、ファイル システム パッケージの定義に基づいて、OCI ランタイム仕様はランタイムおよびライフサイクル管理の仕様を確立します。ライフサイクルは、コンテナの作成から削除までのプロセス全体を定義し、次の 3 つのコマンドで記述できます。

• 「create」コマンド: このコマンドは、ファイル システム パッケージのディレクトリの場所とコンテナーの一意の識別子を使用して呼び出されます。動作環境を作成するときは、config.json の設定を使用する必要があります。作成プロセス中に、ユーザーは特定のイベント フックを追加して、カスタマイズされた処理をトリガーできます。これらのイベント フックには、prestart、createRuntime、createContainer が含まれます。
• 「start」コマンド: このコマンドを呼び出すときは、実行中のコンテナの一意の識別子が必要です。ユーザーは、config.json の process プロパティで実行中のプログラムの詳細を指定できます。 「start」コマンドには、startContainer と poststart という 2 つのイベント フックが含まれています。
• 「delete」コマンド: このコマンドを呼び出すときは、実行中のコンテナの一意の ID が必要です。ユーザーのプログラムが終了すると (正常終了と異常終了を含む)、コンテナ ランタイムは "delete" コマンドを実行してコンテナの動作環境をクリアします。 「delete」コマンドには、poststop という 1 つのイベント フックがあります。

上記のライフサイクル コマンドに加えて、OCI ランタイムは 2 つの追加コマンドをサポートする必要があります。

「state」コマンド: このコマンドを呼び出すときは、実行中のコンテナの一意の識別子が必要です。このコマンドはコンテナのステータスを照会します。必須のステータス属性は、ociVersion、id、status、pid、および bundle です。オプションの属性は注釈です。ランタイム実装が異なると、多少の違いが生じる場合があります。コンテナのステータスの例を次に示します。

 {
 "ociバージョン" : "1.0.1" 、
 「id」 : 「oci-container001」 、
 「ステータス」 : 「実行中」 、
 「pid」 : 8080,
 「バンドル」 : 「/containers/nginx」 、
 「注釈」 : {
 "キー1" : "値1"  
    }
 }

「kill」コマンド: このコマンドを呼び出すときは、実行中のコンテナの一意の識別子とシグナル番号が必要です。このコマンドはコンテナ プロセスにシグナルを送信します。たとえば、Linux オペレーティング システムのシグナル 9 は、プロセスを直ちに終了することを意味します。

ランC

runC は、OCI ランタイム仕様のリファレンス実装であり、containerd や CRI-O などの他の複数のプロジェクトで使用されている、最も一般的に使用されているコンテナ ランタイムです。 runC も低レベルのコンテナ ランタイムです。開発者は runC を使用してコンテナのライフサイクル管理を実装し、面倒なオペレーティング システム呼び出しを回避できます。 OCI ランタイム仕様によれば、runC にはコンテナ イメージ管理機能は含まれていません。コンテナのファイル パッケージがイメージから解凍され、ファイル システムに保存されていることを前提としています。 runC によって作成されたコンテナは、他のコンテナまたはネットワーク ノードと接続するためにネットワークを手動で構成する必要があります。これを行うには、コンテナを起動する前に、OCI によって定義されたイベント フックを通じてネットワークを設定できます。

runC によって提供される機能は比較的単純であり、複雑な環境ではより高レベルのコンテナ ランタイムを生成する必要があるため、runC は他の高レベル コンテナ ランタイムの基盤となる実装基盤となることがよくあります。

コンテナ

OCI が設立されたとき、Docker は Docker プロジェクトを runC の低レベル ランタイムと高レベル ランタイム関数に分割しました。 2017 年、Docker はこの高レベル コンテナ ランタイムの機能を containerd プロジェクトに集約し、Cloud Native Computing Foundation に寄贈しました。

Containerd は、複数のプロジェクトで使用される高レベルのコンテナ ランタイムになりました。コンテナイメージのダウンロードや解凍などのイメージ管理機能を提供します。コンテナを実行すると、containerd はまずイメージを OCI ファイル システム パッケージに解凍し、次に runC を呼び出してコンテナを実行します。 Containerd は、他のアプリケーションが containerd と対話できる API を提供します。 「ctr」は、containerd のコマンドライン ツールであり、「docker」コマンドと非常によく似ています。ただし、コンテナランタイムとしてのcontainerdはコンテナの操作などの側面にのみ焦点を当てているため、開発者が使用するイメージの構築やイメージリポジトリへのイメージのアップロードなどの機能は含まれていません。

ドッカー

Docker Engine は、最も古くから普及し、最も広く使用されているコンテナ ランタイムの 1 つです。次の図に示すアーキテクチャを持つコンテナ管理ツールです。 Docker クライアント (コマンドライン CLI ツール) は、API を介してコンテナー エンジン Docker Daemon (dockerd) の機能を呼び出し、さまざまなコンテナー管理タスクを実行します。

Docker エンジンがリリースされたとき、それはすべての機能が 1 つの実行可能ファイルに集中したモノリシック アプリケーションでした。その後、機能に応じて runC と containerd という 2 つの異なるレベルのランタイムに分割され、それぞれ OCI と CNCF に寄贈されました。上記の 2 つのセクションでは、それぞれ runC と containerd の主な機能について紹介しました。残りの dockerd は、Docker によって管理されるコンテナ ランタイムです。

Docker は開発者とオペレーターの両方に機能を提供します。このうち、開発者向けコマンドは主にイメージ管理機能を提供します。コンテナ イメージは通常、Dockerfile から構築できます。 Dockerfile は、一連のコマンド キーワードを通じて、コンテナー イメージに含まれるベース イメージ、必要なソフトウェア パッケージ、および関連アプリケーションを定義するテキスト ファイルです。 Dockerfile が書き込まれたら、「docker build」コマンドを使用してイメージをビルドできます。以下は Dockerfile の簡単な例です。

 ubuntu:18.04より
エクスポーズ8080
 CMD [ "nginx" 、 "-g" 、 "デーモンオフ;" ]

コンテナ イメージがビルドされると、ローカル イメージ ライブラリに保存されます。イメージを他のノードと共有する必要がある場合は、イメージ リポジトリ (レジストリ) にアップロードして、他のノードがダウンロードできるようにすることができます。

Docker は、コンテナ ストレージとネットワークをホスト マシンにマッピングする機能も提供しており、そのほとんどは containerd によって実装されています。アプリケーション データはコンテナのプライベート ファイル システムに保存され、このデータはコンテナとともに削除されます。データの永続性を必要とするステートフル アプリケーションの場合、データ ボリュームを使用して、ホスト上のファイル ディレクトリをコンテナーにインポートできます。ディレクトリへのすべての書き込み操作は、ホストのファイル システムに保存されます。 Docker はコンテナ内のネットワークをホストのネットワークにマッピングし、外部ネットワークに接続できます。

CRI と CRI-O

Kubernetes は現在主流のコンテナ オーケストレーション プラットフォームです。さまざまなシナリオのニーズに適応するために、Kubernetes はさまざまなコンテナ ランタイムを使用できる必要があります。このため、Kubernetes はバージョン 1.5 以降、コンテナ ランタイム インターフェイス CRI (Container Runtime Interface) を kubelet に追加しました。 Kubernetes に接続する必要があるコンテナ ランタイムは、CRI インターフェースを実装する必要があります。 kubelet のタスクはこのノードのワークロードを管理することなので、イメージを管理し、コンテナを実行する機能が必要です。したがって、CRI へのアクセスには、高レベルのコンテナ ランタイムのみが適しています。 CRI とコンテナ ランタイムの関係を次の図に示します。

対応するコンテナ ランタイムと一致させるために、CRI とコンテナ ランタイムの間に、通常はシムと呼ばれるインターフェイス レイヤーが必要です。 CRI インターフェースは shim によって実装され、次のように定義され、RuntimeService と ImageServiceManager に分かれています (コードについては、GitHub の kubernetes/cri-api にあるプロジェクト ファイル「pkg/apis/services.go」を参照してください)。

 // RuntimeServiceインターフェースはコンテナランタイムによって実装される必要がある
// 以下のメソッドはスレッドセーフでなければならない
RuntimeServiceインターフェース型{
ランタイムバージョナー
コンテナマネージャー
ポッドサンドボックスマネージャー
コンテナ統計マネージャ
 
 // UpdateRuntimeConfig はランタイム構成を更新します
UpdateRuntimeConfig(runtimeConfig *runtimeapi.RuntimeConfig) エラー
 
 // ステータスは実行時のステータスを返します
Status() (*runtimeapi.RuntimeStatus、エラー)
 } 
 
 // ImageManagerServiceインターフェースはコンテナマネージャーによって実装される必要があります
// 以下のメソッドはスレッドセーフでなければならない
ImageManagerServiceインターフェース型{
 // ListImages は既存の画像をリストします
ListImages(フィルター *runtimeapi.ImageFilter) ([]*runtimeapi.Image, エラー) 
 
 // ImageStatusは画像ステータスを返します
ImageStatus(イメージ *runtimeapi.ImageSpec) (*runtimeapi.Image, エラー) 
 
 // PullImage は認証設定を使用してイメージをプルします
PullImage(image *runtimeapi.ImageSpec、auth *runtimeapi.AuthConfig、podSandboxConfig *runtimeapi.PodSandboxConfig) (文字列、エラー) 
 
 // RemoveImage は画像を削除します
RemoveImage(image *runtimeapi.ImageSpec) エラー
 
 // ImageFsInfo はストレージイメージのファイルシステム情報を返します
ImageFsInfo() ([]*runtimeapi.FilesystemUsage、エラー)
 }

Docker ランタイムは広く使用されており、その CRI シムは dockershim と呼ばれ、Kubernetes の kubelet に組み込まれ、Kubernetes プロジェクト チームによって開発および保守されています。他のランタイムでは外部シムを提供する必要があります。バージョン 1.1 以降、containerd には CRI プラグインが組み込まれており、リクエストを転送するために外部シムが不要になり、効率が向上します。最新バージョンの Docker をインストールすると、containerd が自動的にインストールされます。そのため、一部のシステムでは、Docker と Kubernetes は containerd を使用してコンテナを同時に実行できます。ただし、2 つのイメージは名前空間によって分離されており、互いに独立しているため、イメージを共有することはできません。 Docker と containerd は同時に存在することが多いため、Docker を使用する必要のないシステムにのみ containerd をインストールする必要があります。

Containerd はもともと Docker 用に設計されており、ユーザー関連の機能がいくつか含まれています。対照的に、CRI-O は Docker や containerd に代わる、効率的で軽量なコンテナ ランタイム ソリューションです。これは CRI の実装であり、OCI 仕様に準拠したコンテナを実行できるため、CRI-O と呼ばれます。 CRI-O は、本番システムでコンテナを実行するように設計されています。テスト用のシンプルなコマンドラインツールがありますが、コンテナを管理することはできません。 CRI-O は OCI コンテナ イメージ形式をサポートしており、コンテナ イメージ リポジトリからイメージをダウンロードできます。 CRI-O は、runC と Kata Containers という 2 つの低レベル コンテナー ランタイムをサポートしています。