CNCFのCOOに聞いた、CNCFとOCI、Docker、Kubernetes、Cloud Foundryとの関係：Chris Aniszczyk氏インタビュー

コンテナの世界はダイナミックに動いている。Cloud Native Computing Foundation（CNCF）はこれにどのような影響をもたらそうとしているのか。同ファウンデーションCOOのChris Aniszczyk氏に、KubernetesのCRI-OプロジェクトからCloud Foundryとの関係まであらためて聞いた。

[三木泉，＠IT]

　コンテナの世界はダイナミックに動いている。Cloud Native Computing Foundation（CNCF）はこれにどのような影響をもたらそうとしているのか。同ファウンデーションCOOのChris Aniszczyk（クリス・アニズィック）氏に、KubernetesのCRI-Oプロジェクトから、OCIとCNCFの役割分担、コンテナネットワーキングの事実上の標準化、さらにCloud Foundryとの関係まで、あらためて聞いた。

　Aniszczyk氏は、コンテナ形式やコンテナランタイムなどの標準化を進めるOpen Container Initiative（OCI）のエグゼクティブディレクターでもある。

参考記事：コンテナ運用環境を標準化？ CNCFは何をやろうとしているか

――まず、Kubernetesでインキュベーションプロジェクトとして始まったCRI-Oについて聞きたい。これはDockerという企業に対し、Kubernetesを推進するDocker以外の企業がけん制しようとするものだという報道があるが、これをどのように説明するか。

　どんなオープンソースプロジェクトでも、特定の技術への潜在的な依存を、抽象化によって取り除きたいと考えるものだ。CRI-Oはニュースで広く取り上げられたが、Mesosがこれと全く同じことを既にやっている。コンテナ対応を外部化していて、Dockerだろうが、rkt、OCI仕様だろうが、同じように動かせる。

　Kubernetesは現在のところDockerエンジンにひも付いている。彼らにとっては、他のランタイムを（平等に）取り扱えるようなものが必要だった。CRI-Oはコンテナランタイムを抽象化する。これによって、ユーザーはOCI、Docker、rktを自由に活用する選択もできるようになる。

――オーケストレーションツールとのインターフェースの標準化は、OCIの仕事にならないのか？

　潜在的には、OCIがこうした作業を行う場所となり得る。しかしOCIは現在のところ、対象範囲を非常に狭く設定している。CRI-Oの利用するコンテナイメージはrunCであり、OCIを活用している。だが例えばOCIにはレジストリに関する活動が全くない。イメージを手に入れる、あるいはプッシュする方法を提示してはいない。署名やセキュリティについても関与しない。今後、OCIはこれに関する仕様策定に乗り出すかもしれないが、現在は守備範囲外となっている。

――それも質問したかった点だ。OCIとCNCFの役割分担は、正確にはどうなっていくのか。

　OCIのスコープテーブル（活動対象範囲を示す表）でスコープ内なのは、ランタイム、イメージ仕様、ハッシング、テスティングなどだ。署名のアタッチ方法はオプションとしてスコープ内となる。

　一方、スコープ外なのはネーミングや、プッシュ／プルの仕方、つまり配布方法だ。

　将来的に、技術委員会はこれを変える可能性がある。技術委員会は、（OCIのランタイム／イメージ仕様）1.0リリース以降に、配布方法をいつの時点で活動対象とするか、会合を持とうとしている。だが、現在のところ、レジストリには多様な実装の仕方があるため、その標準化は長期的な目標になる。

――とはいえ、OCI内で、政治的な駆け引きがあるのではないか。

　コンテナ形式は退屈な分野だ。オーケストレーションの方が、はるかにビジネス上の活発な競合が繰り広げられている。誰も、コンテナ形式で競争し、エンジニアの時間を浪費したくはない。金になるのは、コンテナを動かし、管理する部分だからだ。Kubernetes、Swarm、Mesos、Nomad、Cloud Foundryなどが、この部分で競合している。だが、誰もがコンテナのイメージ形式については標準化したいと考えている。

　誰かの例えによれば、コンテナ形式は（圧縮の）ZIPのようなものだ。誰もツールに金を払いたいとは思わない。無料のツールを使うだろう。

Cloud FoundryがCNCFで活動する理由

――コンテナオーケストレーションでの競争が激化しているからこそ、なぜ、CNCFにCloud Foundryが参加しているのかがよく分からない。「CNCFは自らがホストしているプロジェクトのプロモーションをする」とあなたも言っているし、イベントとしてCloud Native ConとKubeConを併催していること自体、KubernetesがCNCFの中心であることを象徴しているのではないか。

　KubernetesはCNCFの最初のプロジェクトであり、成功している。MesosphereもCNCFのメンバーで、KubernetesとMesosがうまく共存できることを望んでいる。Cloud FoundryはまだKubernetesを使っていないが、将来、潜在的には連携する可能性がある。Service Broker APIではCloud Foundry Foundationと協力している。

　CNCFは、多様なテクノロジーコンポーネントを提供しようとしている。Prometheus、fluentd、Open Tracingなど、さまざまなツールを用意する。これらをつなぎ合わせて、Cloud Foundryの競合となるような製品を作り出せるようになるかもしれない。例えばCoreOSはKubernetesを活用してTectonicを生み出している。これが同社にとっての「opinionatedな」（自社の考えや提供価値を体現した）アプローチだ。

　CNCFはopinionatedなスタックを生み出すつもりはない。コンポーネントの提供に徹し、メンバーがopinionatedなアプローチを構築することを助ける。メンバーがコンポーネントを自らのやりたいように活用して製品を作り、市場に届けられるように支援する。例えばCloud Foundryは、間もなくCNCFプロジェクトになるetcdを利用している。

　CNCFでは、クラウドネイティブ分野で正当性のある複数のプロジェクトに対し、独立した、中立的な「家」を提供する。そして財務的にサポートするとともに、イベントを開催し、コミュニティの拡大を助ける。

　私たちは特定の技術に自分たちを結び付けようとはしていない。（Kubernetesとは）別のオーケストレーションプラットフォームが、CNCFに（「ホストしてほしい」といって）きたとしたら、Technical Oversight Committee（TOC）が承認する限り、受け入れることになるだろう。

　TOCには、MesosphereのBen Hindman（ベン・ヒンドマン）氏や、DockerのSolomon Hykes（ソロモン・ハイクス）氏などがいる。この人たちは会社としては競争しているが、全体的には正しいことをし、適切なプロジェクトを選択し、エコシステムを築き上げたいと考えている。より多くの人たちがコンテナを使うようになるのは、皆が望むことだ。

――では、例えばMesosがCNCFに来る可能性はあるのか。

　実は4年前、私がTwitterにいたころに、MesosがApache Foundationに行くのを助けたことがある。一度入ったら、出るのは非常に難しい。だから、CNCFにMesosが来る可能性は非常に低い。だが、他のMesos関連プロジェクトについては、喜んで可能性を検討する。CNCFがスタートしたとき、MesosphereはKubernetesとMesosの統合作業に力を注ぎ、Mesos Framework上でKubernetesアプリケーションが確実に動作するようにした。

　（CNCFエグゼクティブディレクターの）Dan Kohn氏も私も、技術的にいろいろな可能性を考えることができる。だが、決めるのはTOCだ。独立して選ばれた人々が賢い選択をする。これらの人々はさまざまなコミュニティを代表しており、企業としては時に競合する。だが、全員が技術者で、「正しいことをやる」ということに興味を持っている。これは良いことだと私は考えている。TOCは最高裁判所のようなもので、任期は3年と長い。

――CNCFでは、例えば複数のコンテナオーケストレーションプラットフォーム間でのインターフェースとなるようなものを積極的に整備していくつもりはあるのか。

　ある。コンテナネットワーキングはいい例だ。この世界は非常に混沌としている。Dockerは自らのlibnetworkを推進しているが、CNI（Container Network Interface）に人気が出てきている。他にもWeave Net、Canalなど、たくさんある。私たちの当初の考えは、これらのプロジェクトを集め、その80％を標準化し、残りの20％でそれぞれが差別化を図れるようにすることだった。現時点でも、CNI、flannel、Calico、Weave Netなどによる話し合いが持たれている。

　ファウンデーションは、コンテナネットワーキングの標準化についてTOCに話し、TOCもいい考えだと認めているが、関係するプロジェクトの同意が必要だ。CNIは一定の成果をもたらしているが、さまざまな関連プロジェクトがより密接に協力し合う必要がある。ファウンデーションとしては、関連プロジェクトが同席できる場を増やすなどの取り組みを進めていきたい。

――私にはまだ、Cloud FoundryがなぜCNCFに参加する意味があるのかがよく分からない。

　CNCFは1つ1つのテクノロジー要素を提供している。これに対し、Cloud Foundryは1つの巨大なブロックのようなものに見える。プラガブルなものになっておらず、「これが唯一のやり方だ」と自らを提示している。Cloud FoundryはTectonicと同様、opinionatedなソリューションだ。だが、内部でCNCFがホストする技術を使うことができる。

　他にも（理由は）ある。Cloud Foundryは上位レイヤの問題を解決しようとしてきており、アプリケーションやサービス定義を得意としている。Service Broker APIでは、CNCFの複数のメンバーがCloud Foundryと一緒にやっている。だが、その基礎部分は、過去の経緯もあって、コンテナに最適化されているとは言えない。

　私は、Cloud FoundryがKubenetesを活用すればどんなに素晴らしいだろうかと考えている。オーケストレーションでは長期的にKubernetesが明確な勝者となるだろう。Cloud Foundry内部でも、Kubernetesを採用するという選択肢について、活発な検討がなされているということも私は知っている。オーケストレーションは非常に根本的な部分であるため、この部分を入れ替えることは困難だ。だが、彼らは賢い人たちで、Kubernetesの勢いが増していることを知っているし、これを活用することが彼らのためになるということも理解している。

　Cloud Foundryは（CNCFと同様）Linux Foundation傘下のプロジェクトであり、頻繁にコミュニケーションを取り合っている。