昨日発表した Dockerの製品によるKubernetesの公式サポートは、Kubernetesでコンテナを起動するための代替アプローチとして、 CRI-Oに関する最新の出版物の1つを続ける理想的な機会です。 すでにcri-containerdのトピックに触れました。これは、コンテナのテクノロジーの唯一のプロバイダーから逃げようとするオープンソースコミュニティの試みに対する一種の「Docker応答」です。 何がDockerの人生に新たな転換をもたらしたのか、そしてそのパターンはMobyプロジェクトの最近の歴史でどのように確認されていますか？
選択の自由：KubernetesとDockerの両方から
コンテナを操作するためのPaaSとしてのKubernetesは、元々、特定のプラットフォーム機能の実装をユーザーが自由に選択できるようにするというアイデアで作成されました。 （これについて詳しく説明し、KubernetesがPaaSよりも優れている理由については別の記事で説明しました 。）コンテナーの起動に使用されるテクノロジーは、そのような実装の一例です。 コンテナのオープンソースの世界はDockerに限定されないため 、 Kubernetesは長い間、コンテナの実行可能環境としてrktを使用できました 。 はい、概して、そのような機会は特定の会社-CoreOS-の努力（および利益）のために現れましたが、今年以来、RKTは非営利組織CNCF および Dockerからの競争相手であるコンテナ化された （およびそれ自体Kubernetesは同じ基金で開発しています） 。
ただし、デフォルトでは、Kubernetesはまだrktを使用していませんが、業界の事実上の標準であるDockerを使用しています。 ユーザーに柔軟性を提供したいという同じ欲求、一部の企業の利益と「チーム化」により、プロジェクトは、 コンテナランタイムインターフェース（CRI）の作成を通じて利用可能な実行可能環境をさらに拡張しました-Kubernetes 1.5のリリースで登場しました。
CRIの助けを借りて、新しいコンテナテクノロジーの「接続」が統一され、シンプルになりました。これは、先週詳しく説明したCRI-Oプロジェクトのフレームワークで初めて実証されました。 正式には、 CRI-Oを使用すると、OCI仕様（ runtime-spec ）と互換性のあるコンテナの実行可能環境を使用できますが、実際には、よく知られているrunC （2015年にDockerから分離され、OCI標準の参照実装となったプロジェクト）とClear Containersをサポートしています（Intelから） 。
DockerはKubernetesのサポートを発表する一方で、「Dockerアーキテクチャの哲学は常に選択肢と柔軟性を提供することである」と強調しました。 そこで、彼らは公式にプラットフォームでのKubernetesブロックの外観について説明しました。
プラットフォーム層自体は次のように説明されます（下から上）。
- 業界標準のコンテナランタイムとしてコンテナ化されています。
- Swarm orchestration 。ノードのグループを分散システムに変換します。
- コンテナー内のアプリケーションを作成および配信するためのシンプルなワークフローを開発者に提供するDocker Community Edition 。
- Docker Enterprise Editionは、安全なソフトウェア配信の全サイクルを管理し、実稼働環境でコンテナーを起動します。
そして今、「Swarm orchestration」というポイントは「Swarm or Kubernetes orchestration」として定式化されており、将来（誰が知っていますか）他のソリューションにも拡張できます。
同社の公式発表は、KubernetesのサポートをDockerプラットフォームに統合するもう1つの理由- 顧客の希望を発表しました 。 Dockerユーザーは、「Kubernetes用のサービスを設計したか、必要な特定の機能のためにKubernetesが必要です。」 状況をより客観的に見ると、当時のDockerのようなKubernetesが「業界標準」になりつつあることは明らかです。 また、エンドユーザーは特定の基盤となるコンテナーテクノロジーよりもオーケストレーションツールを選択する可能性が高いため、Docker がオーディエンスを維持（および拡大）する唯一のオプションは、その業界自体のニーズを満たすことです。 Docker-Swarm-で開発されているKubernetesの直接的な競合他社の市場の見通しは何ですか？これは未解決のままであり、すぐに会社のポリシーで明らかにされるべき問題です。
MobyとKubernetes
Dockerプラットフォームのすべてのレイヤーは、特別なMobyオープンソースプロジェクトを使用して組み立てられます。
要するに、Dockerは、その助けを借りて、コミュニティで「コンテナベースのシステムを構築する」ための標準として推進することにより、コンテナエコシステムにおけるリーダーシップを維持しようとしています。 正式には、 MobyはDockerプラットフォームの構築に使用されるすべてのアップストリームプロジェクトも表します。 （合計で、それらは年間平均8800のプルリクエストを占めています。）
発表されたKubernetesのDockerサポートへのMobyの参加について話すと、著者は、この作業は昨日から始まったのではなく、約1年続いていると述べています。 主なイベントは次のとおりです。
MobyとKubernetesの「密接な関係」の詳細は、Dockerプラットフォームなどを構成するプロジェクトの例として示されています。
コンテナ
過去のcontainerdは、 コンテナを起動するためのランタイムを実装するDockerコンポーネントです。
runCの場合と同様に、独立したオープンソースプロジェクトでのDockerからの分離の運命でした（今年初めにCNCFファンドに移管され、受け入れられました）。 現在のバージョンは1.0.0-beta.2であり、最終リリース1.0.0は間もなくリリースされる予定です。 Dockerの基本コンポーネントの1つであるこのプロジェクトは、より広く認知されることを目指しており、 cri-containerd （今年4月に開始されました）は、その配布を目的とした主要なイニシアチブの1つになりました。
前述のKubernetes CRIインターフェイスの最初の実装の1つとして、cri-containerdは、「重い」DockerがK8sユーザーのデフォルトオプションではない時代にKubernetesでコンテナを起動するための一般的なソリューションであると主張しています。 現在のステータスはアルファ版で、完全な機能セットを備えており、「最終的な安定化プロセス」が進行中です。 GoogleのLiu Lantao は 、9月14日にロサンゼルスで開催されたMoby Summitでcri-containerdのステータスについて話し 、プロジェクトはCRIとKubernetesに「非常によく」準拠しており、年内にベータ版をリリースすることも約束しました。
cri-containerdによってcontainerdのKubernetesへの参加がどのように変化するかを以下に示します。
図の注： dockershimは、 K8の Dockerコンテナーの現在のランタイム実装です。
より詳細なcri-containerd作業スキーム：
さまざまな指示を使用して、実際にcri-containerdを試すことができます。
- Ansibleのクイックスタート 。
- kubeadmによるインストール 。
- LinuxKitからローカル仮想マシンへのインストール （詳細については以下を参照） 。
LinuxKit
LinuxKitは、コンパクトなLinuxコンテナシステムを構築するためにMobyと同時に発表されたユーティリティです。 プロジェクトの説明で指定されているように、LinuxKitは「DockerやKubernetesなどのコンテナオーケストレーションツールを使用してクラスターアプリケーションを構築および実行するように設計されています」。
プロジェクトのドキュメントには、 Kubernetesを使用して最小限のOSイメージを作成する方法を説明する「 Kubernetes and LinuxKit 」という記事が含まれています。 デフォルトでは、これらのイメージにインストールされたK8はDocker Engineを使用し、cri-containerdに切り替えるには、ビルドプロセス中に1つのコマンドを追加するだけです。
インフラキット
InfraKitは、「自己管理および自己修復」を行うように設計されたインフラストラクチャを調整するためのユーティリティセットです。 技術的には、プロジェクトは、さまざまなインターフェイス（サービスプロバイダーインターフェイス、SPI-詳細についてはドキュメントを参照）を実装するプラグインと呼ばれる一連の小さなコントローラーで構成されています。 これらのインターフェースの1つであるFlavor SPIは、アプリケーション固有の構成とステータスチェックを担当します。 Flavorなどのプラグインの例としては、クラスター内のノードの存在の確認、スケジューラーからのノードによるタスクの受信の一時停止などを行うSwarmやKubernetesがあります。
InfraKitのKubernetesプラグインのドキュメントは、最近このREADMEにまとめられています 。 主任プロジェクト開発者（David Chung）から、InfraKitとAWS CloudFormationを使用してAWSでKubernetesを起動する方法を示す17分のビデオも利用できます。 ブートストラップノードは、Docker Engineの最新バージョンのインストールからボリュームのマウントとフォーマット用のラベルの更新まで、一連のアクションを実行します。 プラグインとInfraKitテンプレートによって生成されたスクリプトをダウンロードします。
libnetwork
libnetworkは、Dockerが使用するコンテナのコンテナネットワークモデル（CNM）ネットワークインターフェイスの実装です。 CNMは、本質的に、 この記事で説明したContainer Networking Interface（CNI）の直接の競争相手です。 KubernetesはCNIの初期のユーザーの1人になり、すでにKubernetesに接続しているCNIのプラグインでネットワークインターフェイスを開発したい人を招待しています。
Red HatのScott McCartyは先月コンテナ標準について話し 、「多くのネットワークベンダーがCNIとCNMの両方に適したユーティリティを作成するため」CNMを「事実上の標準」と呼びました。
DockerはCNIではなくCNMにとどまるつもりなので、Kubernetesと統合するためのオプションは何ですか？ そうです、libnetworkサポートを実装する CNI プラグインを作成します 。 プロセスはすでに実行されていますが、masterブランチにはまだ到達していません。
Kubernetesのアップストリームバージョンのすべてのユーザーにとって有益な Dockerの「リバースムーブメント」の例をご覧ください。
公証人
Notaryは、 Update Framework（TUF）の作業に基づき、Goで記述された（TUF のPythonではなく ）コンテナーの署名と検証を行うDockerプロジェクトです。 今月初め、CNCFプロジェクトインキュベーターに公証人とTUFを含めるための投票が開始されました。 基金の委員会の多くの代表者はすでにそれを支持していますが、最終的な決定はまだなされていません。 公証人はまだK8に正式な拘束力はありませんが、Dockerはその採用後にCNCFが「Kubernetesなどの他のCNCFプロジェクトと直接統合する」ことを期待しています。
自由権
libentitlementライブラリは 、コンテナでの高度な権利管理用に設計されています。 いわゆるエンタイトルメントは、構成プロファイルのさまざまなセキュリティ機能を有効/無効にし、ライブラリはコンテナのこれらのプロファイルを管理するように設計されています。 ここで実装のために提案された資格のリストを見つけることができます 。
プロジェクトはまだ若く、そのリポジトリでの最初のコミットは5月に行われました。 Dockerによると、LibentitlementはKubernetesコミュニティの参加により開発されています。 プロジェクトのドキュメントにはKubernetesのデフォルトの資格のリストが含まれていますが、現時点では有望な「TBD」のみがリストされています。
まとめると
コンテナの世界は、オープンソースプロジェクトとその背後にある企業との競争と同時コラボレーションの興味深い場所になっています。
Dockerプラットフォームに統合されたオーケストレーションツールにKubernetesが含まれていない場合でも、この会社のエンジニアはしばらくの間、K8に特に焦点を当てたプロジェクトまたはそのエコシステムと密接に関連するプロジェクトに取り組んできました。
Kubernetesによるサポートの正式な発表は、コミュニティにとって重要で楽しいイベントであり、選択の自由に関する会社の言葉を裏付けています。 Docker自体にとって、これは主にMesosphereの最近の同様のケースに似た強制的な手段です。
悪名高いKubernetesによるDockerエンドユーザー製品のサポートの詳細については、関連する企業ブログエントリ（ Docker CE for Mac and Windows 、 Docker EE）で確認できます。
PS
ブログもご覧ください。