IBM Watson＆Cloud PlatformのコンテナおよびLinuxアーキテクチャのテクニカルディレクターであるPhil Estesによる最近の記事は、イベントのスレッドを失った（またはキャッチしたことがない）人物をナビゲートし、より広い理解を得る方法に関する優れた回顧展を提供します。 Mobyおよびコンテナプロジェクトのメンテナーの1人であり、Open Container Initiative（OCI）およびMobyの技術委員会のメンバーであり、Dockerキャプテンのステータスも持っている著者は、コンテナランタイムの新しい素晴らしい世界の過去、現在、未来について書いています。 そして、最も怠forな人にとっては、素材はコンパクトなTLで始まり、主題に関するDR ...
主な調査結果
- 時間が経つにつれて、コンテナーランタイムの選択肢が増え、一般的なDockerエンジンよりも多くのオプションが提供されます。
- Open Container Initiative（OCI）は、ランタイム環境間の相互運用性（「相互運用性」-約Transl。）を保証するために、コンテナおよびコンテナイメージの概念を正常に標準化しました。
- KubernetesはContainer Runtime Interface（CRI）を追加しました。これにより、コンテナはK8の基礎となるオーケストレーションレイヤーを使用してランタイム環境に接続できます。
- この分野の革新により、コンテナは軽量の仮想化やその他の独自の分離技術を活用して、セキュリティ要件を拡大することができます。
- OCIおよびCRIを使用すると、ランタイムコンテナおよびオーケストレーション環境のエコシステムで相互運用性と選択が現実のものになりました。
コンテナ化技術は、Linuxオペレーティングシステムの世界ではかなり前から存在していました。ファイルシステムとプロセスの個別の名前空間に関する最初のアイデアは、10年以上前に登場しました。 また、比較的最近では、LXCが登場し、LinuxユーザーがLinuxカーネルに隠された強力な分離技術と対話するための標準的な方法になりました。
しかし、今日私たちが通常コンテナと呼ぶもののさまざまな技術的な「内部」を組み合わせる複雑さを隠そうとするLXCの試みにもかかわらず、コンテナは一種の魔法であり、特に知識のある世界でのみ強くなり、大衆の間で広く普及しませんでした。
2014年にDockerですべてが変更され、LXCが装備されたのと同じLinuxカーネルテクノロジーの開発者向けの新しいラッパーがありました。実際、Dockerの初期バージョンは「舞台裏」でLXCを使用し、コンテナは-Dockerコンテナイメージとそれらを操作するためのシンプルなコマンドを再利用するシンプルさと可能性に開発者が染み込んでいたため、真の大衆現象。
もちろん、コンテナ市場でシェアを獲得したいと思ったのは、Dockerだけではありませんでした。2014年の最初の爆発的な関心の後、それに付随する誇大広告が沈静化することを考えなかったからです。 長年にわたって、 CoreOS（rkt） 、 Intel Clear Containers 、 hyper.sh （軽量コンテナーベースの仮想化）、およびハイパフォーマンスコンピューティング（HPC）研究の世界のSingularityとシフターから、実行可能なコンテナー環境に対してさまざまな代替案が生まれました。
市場は成長と成熟を続けており、 Open Container Initiative（OCI）により、Dockerが推進する最初のアイデアを標準化する取り組みが始まりました。 現在、多くのコンテナ実行可能環境はすでにOCIと互換性があるか、またはこれに近づいており、特定のアプリケーションに焦点を当てた機能を促進するための条件をメーカーに提供しています。
Kubernetesの人気
コンテナの進化の次の段階は、マイクロコンピューティング並の分散コンピューティングコンテナとコンテナを組み合わせることでした。これは、急速な開発と展開の反復の新しい世界（DevOpsと言うことができます）であり、Dockerの人気とともに活発になっています。
Kubernetesが支配する前に、 Apache Mesosと他のソフトウェアオーケストレーションプラットフォームの両方が存在していましたが、 K8は小さなGoogle Open SourceプロジェクトからCloud Native Computing Foundation（CNCF）メインプロジェクトに迅速に移行しました。
ご注意 perev。 ：Kubernetes 1.0のリリース時に2015年にCNCF が登場したことをご存知ですか？ 同時に、プロジェクトはGoogleによって、Linux Foundationの一部となった新しい独立組織に移されました。
Mesosphere、CoreOS、Mirantis、OpenStack、Bitnamiなどが後援するK8s 1.0リリースイベント
ZDNetでのKubernetes 1.0のリリースに関するニュースから
DockerがDockerに組み込まれ、Dockerのシンプルさとデフォルトの安全なクラスター構成に焦点を合わせたライバルオーケストレーションプラットフォームSwarmをリリースした後でも、これはKubernetesへの関心の高まりを食い止めるのに十分ではありませんでした。
ただし、急速に成長しているクラウドネイティブコミュニティ以外の多くの利害関係者は混乱していた。 平均的なオブザーバーは、何が起こっているのか理解できませんでした。KubernetesはDockerまたは彼らの協力と戦いますか Kubernetesは単なるオーケストレーションプラットフォームであるため、Kubernetesで調整されたコンテナを直接起動する実行可能なコンテナ環境が必要でした。 当初から、KubernetesはDockerエンジンを使用していましたが、SwarmとKubernetesの間の競争の緊張にもかかわらず、Dockerは依然としてデフォルトのランタイムであり、Kubernetesクラスターが機能するために必要でした。
Docker以外の少数のコンテナーランタイムでは、ランタイムとKubernetesのペアリングには、ランタイムごとに特別に記述されたインターフェイス（shim）が必要であることは明らかです。 コンテナランタイムを実装するための明確なインターフェイスがないため、Kubernetesで新しいランタイムのサポートを追加することは非常に困難でした。
コンテナランタイムインターフェイス（CRI）
Kubernetesでのランタイムの実装の複雑さの増大を解決するために、コミュニティは、コンテナランタイムがKubernetes内に実装する特定の機能- コンテナランタイムインターフェース（CRI） （Kubernetes 1.5-約Transl。 。 このイベントは、コンテナランタイムの使用に影響を与えるKubernetesコードベースのフラグメント数の増加の問題を解決するだけでなく、潜在的なランタイムがCRIに準拠したい場合にサポートされる機能を正確に理解するのにも役立ちました。
ご想像のとおり、CRIはランタイムから非常に単純なものを期待しています。 このような環境では、ポッドの開始と停止、ポッドのコンテキストでのコンテナーのすべての操作（開始、停止、一時停止、強制終了、削除）が可能で、レジストリを使用したコンテナーイメージの管理もサポートする必要があります。 ログ、メトリックなどを収集するための補助機能もあります。
Kubernetesに新しい機能が表示され、コンテナランタイムのレイヤーに依存している場合、そのような変更はバージョン付きCRI APIに対して行われます。 これにより、Kubernetesへの新しい機能的な依存関係が作成され、新しい機能をサポートするランタイムの通常バージョンのリリースが必要になります（最近の例の1つはユーザー名前空間です）。
現在のCRIの状況
2018年の時点では、Kubernetesのコンテナーランタイムとして使用するためのいくつかのオプションがあります。 以下の図に示すように、実際のオプションの1つは、まだCRI APIを実装するdockershimを備えたDockerです。 実際、今日のKubernetesインストールのほとんどでは、Dockerがデフォルトのランタイムのままです。
Swarmを使用したDockerオーケストレーション戦略とKubernetesコミュニティの間の緊張の興味深い結果の1つは、Dockerからのランタイムに基づいて、共同開発された新しいオープンソースプロジェクト-containerdを集めた共同プロジェクトでした。 時間が経つにつれて、containedはKubernetesプロジェクトを管理および所有する同じ組織であるCNCFに移管されました。 （ translに注意してください 。 別の記事でcontainerdの外観について詳しく説明しました。）
Dockerブログでの containerdの発表から
Containerdは、DockerとKubernetes（CRI経由）の両方のランタイムのシンプルで基本的で企業に依存しない（意見のない）実装であり、多くのKubernetesインストールでDockerの潜在的な代替品として人気を集め始めました。 これまで、IBM CloudとGoogle Cloudの両方には、アーリーアクセス/ベータモードのコンテナベースのクラスターがあります。 また、Microsoft Azureは将来containerdに切り替えることを約束しました。Amazonは、Dockerの使用を継続しながら、コンテナーソリューション（ECSおよびEKS）のランタイムのさまざまなオプションを検討しています。
Red Hatは、OCIリファレンス実装runcに基づいてcri-oと呼ばれる単純なCRI実装を作成することにより、コンテナランタイム空間に参入しました。 Dockerとcontainerdもruncベースですが、cri-oの作成者は、ランタイムはKubernetesにとって「十分」であり、それ以上必要ないことを主張しています。基本的なruncバイナリにKubernetes CRIを実装するために最も必要な機能を追加しただけです。 （ translに注意してください。CRI -Oプロジェクトについてはこの記事で詳しく説明し 、ここではポッドマンの形でのさらなる開発について説明しました。）
軽量仮想化プロジェクト：Intel Clear Containersおよびhyper.sh-OpenStack Foundationの荒野であるKata containerに登場し、 fraktiと呼ばれるCRI実装を使用した追加の分離のための仮想化コンテナーのビジョンを提供します。 cri-oとcontainerdはどちらもKataコンテナでも機能するため、OCI互換のランタイムをプラグ可能なオプションとして選択できます。
未来を予測する
通常、未来を知っていると言うのはあまり賢明ではありませんが、コンテナのエコシステムが熱意と誇大広告から私たちの存在のより成熟した段階に移行するにつれて、少なくともいくつかの新しいトレンドを修正できます。
コンテナのエコシステムが断片化された環境を形成するという初期の懸念があり、その参加者はコンテナが何であるかについて異なる互換性のないアイデアを思い付くでしょう。 OCIの作業と主要ベンダーおよび参加者の責任ある行動のおかげで、OCI互換性を好むソフトウェア製品の中で、業界で健全な環境が見られました。
既存の制限によりDockerの使用基準が抵抗を受けにくい新しい環境（HPCなど）でさえ、非Dockerベースのコンテナーコンテナー環境を作成しようとするすべての試みもOCIに注目を集めました。 OCIが科学者や研究者のコミュニティの特定のニーズに対して実行可能なソリューションになり得るかどうかについて議論が進行中です。
これに加えて、CRIを使用したKubernetesのプラグインコンテナーランタイムの標準化により、開発者と管理者がタスクに適したツールとソフトウェアスタックを選択し、コンテナーエコシステム全体の相互運用性を待機および監視できる世界を想像できます。
この世界をよりよく理解するために特定の例を考えてみましょう。
- MacBookを使用する開発者は、Docker for Macを使用してアプリケーションを開発し、組み込みのKubernetesサポート（ここではDockerはCRIランタイムのように機能します）を使用して、K8sポッドに新しいアプリケーションをデプロイしようとします。
- アプリケーションはベンダーのソフトウェアのCI / CDを通過し、runcおよび特別な（ベンダーが作成した）コードを使用してOCIイメージをパッケージ化し、テストのためにコンテナーの企業レジストリにロードします。
- containerdをCRIランタイムとして使用するオンプレミスのKubernetesクラスターインストールは、アプリケーションのテストスイートを起動します。
- この会社は、何らかの理由で、実稼働環境の特定のワークロードにKataコンテナーを選択したため、アプリケーションをデプロイするときに、runcではなくKataコンテナーをランタイムとして使用するcontainerdが設定されたポッドで起動します。
説明されているシナリオ全体は、ランタイム環境およびイメージのOCI仕様との互換性、およびCRIがランタイムを選択する柔軟性を提供するという事実のおかげで、素晴らしい機能を発揮します。
この可能な柔軟性と正しい選択は、コンテナエコシステムを本当に驚くべきものにし、2014年以来急速に成長している業界の成熟にとって非常に重要な条件でもあります。 2019年以降のしきい値では、コンテナに基づいたプラットフォームを使用および作成する人々にとって、継続的な革新と柔軟性を備えた明るい未来が見えます。
このトピックの詳細については、QCon NYでの最近のPhil Estesの講演をご覧ください 。「 CRI Runtimes Deep Dive：だれがKubernetes Podを実行していますか？」 」
翻訳者からのPS
ブログもご覧ください。