DockerとKubernetesを超えて: コンテナエコシステムは進化し続けている

コンテナはここ数年で大きく進歩し、ニッチなテクノロジーから、最新のクラウドネイティブ アプリケーションとサービスを展開するための重要なプラットフォームへと進化しました。展開が拡大するにつれて、エコシステムも拡大しています。

コンテナという概念は、実は長年存在してきました。これらは常にコンピュータ リソースを割り当てる方法であり、これは仮想マシンの機能でもあります。

両者の違いは、仮想化はベアメタル レベルで実行されるのに対し、コンテナーはオペレーティング システム カーネルから配信され、基本的に個々のアプリケーションまたはコード モジュールごとに個別の実行環境を提供することです。

企業はこれまで主に仮想マシンを使用していましたが、Docker がコンテナ テクノロジーとツールを組み合わせてアジャイル開発に最適なツールにすることで、コンテナに新たな命を吹き込みました。

コンテナは仮想マシンよりも軽量で高速であるため、企業はコンテナを使用してマイクロサービス ベースのアーキテクチャを展開し、DevOps イニシアチブを展開することも好んでいます。

5年前にDockerプラットフォームがリリースされて以来、コンテナエコシステムは急速に拡大してきました。これは良いことでした。なぜなら、当初この技術には多くのサポートツールや機能（オーケストレーションや負荷分散など）が欠けていたからです。これらのツールは仮想マシンを中心に構築されていたため、開発者はすぐにそのギャップを埋めることができました。

エコシステムの構築

オーケストレーションに関しては、Kubernetes がほぼ勝利を収めていることがわかります。ますます多くのオンプレミス コンテナ プラットフォームで使用されているだけでなく、すべての主要なクラウド サービス プロバイダーが、Kubernetes をオーケストレーション レイヤーとして使用したコンテナ サービスを提供しています。

同時に、コンテナ ランタイム (コンテナを実際に実行するエンジン) やコンテナ イメージの保存と配布に使用されるファイル形式など、コンテナをサポートする基盤テクノロジの標準化がさらに進みました。

ランタイム側では、Linux Foundation の後援の下で設立された Open Container Initiative (OCI) がコンテナを監視し、Docker は基本的な機能を提供する独自のテクノロジーに基づくリファレンス デプロイメントである runc を提供しています。

その後、Docker は runc を、独自に使用するために containerd と呼ばれるより機能豊富なランタイムに組み込み、Kubernetes を監督する団体である Cloud Native Computing Foundation (CNCF) に提出しました。

Docker は独自の製品でも containerd を使用します。 runc が含まれているため、containerd は OCI 仕様との互換性を維持します。

その後しばらくして、OCI は標準のコンテナ イメージ形式の仕様を作成するための新しいワーキング グループを結成しました。 Docker も仕様の作成に参加し、結果として得られた OCI 形式を Docker V2 イメージとして独自のプラットフォームに統合しました。

その結果、コンテナ ランタイムとコンテナ イメージの両方に独自の標準が確立されるようになりました。すべてのコンテナ ランタイムは最終的に OCI 標準に準拠する必要があります。つまり、インフラストラクチャの残りの部分も OCI に準拠していれば、コンテナのデプロイメントの一部としてさまざまなソースからのソフトウェア コンポーネントを組み合わせて使用​​することが比較的容易になります。

コンテナセキュリティの課題を解決する

コンテナの使用を希望する企業は、仮想マシンの展開でハイパーバイザーによって実装されるインスタンス間の分離レベルと同じレベルをコンテナが提供しないため、コンテナのセキュリティについて非常に懸念しています。

これは、ホスト上で実行されているすべてのコンテナが同じ共有カーネルを呼び出してリソースにアクセスするため、潜在的な脆弱性がすべてのコンテナに影響を及ぼす可能性が高くなるためです。

コンテナ業界は現在、さまざまな方法でこの問題を解決しようとしています。たとえば、OpenStack が支援する Kata コンテナ プロジェクトは最近、コンテナに似た軽量の仮想マシンを作成する戦略を盛り込んだバージョン 1.0 をリリースしました。

これは、OCI 仕様に準拠し、外部の世界をコンテナ ランタイムとして認識するハイパーバイザーを使用することで実現されます。ハイパーバイザーは、最小限のオペレーティング システム カーネルと実際のコンテナーをカプセル化する軽量の仮想マシンを作成します。

これは、既存のプラットフォームの一部がコンテナ サポートを統合する方法と似ています。 Pivotal Container Service (PKS) は、VMware の vSphere または Google Cloud Platform 上の仮想マシン内でコンテナを実行しますが、Amazon の AWS は複数のコンテナ サービスを実行し、そのすべてが EC2 インスタンス内にコンテナを配置します。

これらはすべて標準の VM をコンテナ ホストとして使用しますが、Kata Containers はコンテナ ランタイムを装った軽量の VM を使用しているようです。

一方、Google は gVisor オープンソース プロジェクトを通じてコン​​テナのセキュリティを向上させる別のソリューションを開発しました。ここではハイパーバイザーは使用されず、ホストカーネルとコンテナアプリケーション間の追加カーネルとして機能します。

gVisor カーネルは通常のユーザー レベルの権限を持ち、アプリケーションからのシステム コールをインターセプトし、操作を実行してサービスを行うことができます。つまり、gVisor は、アプリケーションがホスト カーネルやその他のリソースに直接アクセスするのを防ぐプロキシまたはバッファリング レイヤーのように機能します。

ただし、gVisor と Kata Containers はどちらも、追加のパフォーマンス オーバーヘッドと潜在的なアプリケーション互換性の問題をもたらします。これは特に gVisor に当てはまり、Google はすべての Linux システム コールをサポートするわけではないと警告しています。

さらに、コンテナ エコシステムは拡大し続けており、コンテナ インフラストラクチャの構築に必要な不足部分を補うサードパーティのツールやプラットフォームが登場しています。

StorageOS や PortWorx など、特定のワークロードに永続的なストレージを提供するための新しいツールが利用可能になりました。その他のツールは監視機能や高度なネットワーク機能を提供しますが、コンテナ イメージ リポジトリの構築に重点を置いているツールもあります。

さらに、他のベンダーやプロジェクトは、コンテナを中心としたプラットフォームの構築に注力し、最新のクラウドネイティブ アプリケーション (CircleCl や GoCD など) のビルド、テスト、展開全体をサポートするターンキー配信パイプラインを作成しています。

おそらく、Amazon などの多くのクラウド サービス プロバイダーがすでにこの機能を提供しており、従来のプラットフォーム サービス (Red Hat の OpenShift など) はコンテナーを中心とした開発者プラットフォームになっています。

ただし、コンテナは現時点では、特に管理とオーケストレーションの分野では仮想マシンほど成熟していないかもしれませんが、この市場は急速に発展しており、コンテナはクラウド コンピューティング時代のアプリケーション開発に最適なツールになりつつあります。