「FaaS、PaaS、CaaSの間の垣根を取っ払う」Knativeの可能性と課題とは：IBMのダグ・デイヴィス氏に聞いた（2/2 ページ）

[三木泉，＠IT]

　プライベートクラウドでの活用を考えると分かりやすいが、基盤統合により、ユーザーはFaaSやPaaSを活用したいからといってそれぞれに専用のプラットフォームを導入することなく、Kubernetes（＋Knative）という共通基盤をまず導入し、さらに必要に応じて、開発者の望む使い勝手を実現するコンポーネントを導入すればいいということになる。

　デイヴィス氏が講演で、「あなたはCaaS、PaaS、FaaSのどれをどう選ぶかについての悩みから解放されるべきだ」と話したのは、このことを意味している。

　「そして私たちは、（Kubernetes、Knative、Cloud Foundry、OpenWhiskという）4種類のデベロッパーエクスペリエンスのうち、Kubernetesをそのまま直接使うようなやり方は減っていくのが望ましいと考えている。Knativeを介したほうが、単純にいって使いやすいからだ。とはいえ、もちろんこの2つのどちらを使うかは自由だ。加えて、特別なユーザーエクスペリエンスを提供したい場合は、Cloud FoundryやOpenWhiskを使うことができる。将来は、それぞれの開発者が自らの使いたいインタフェースを選びながら、Kubernetesを共通に活用できるようになる」

　「Knativeは、2通りのやり方で提供していく。1つはKubernetesクラスタ上にユーザーがインストールする方法。もう1つは、『IBM Cloud Functions』でファンクション単位の課金をしているのと同様、（Knativeの）利用量に応じて課金するマルチテナントのクラウドサービスとしての提供だ」

今後のKnativeを左右する課題とは

　では、IBMがKnative上に、Cloud FoundryやOpenWhiskとは異なるインタフェースを構築して提供する可能性はあるのだろうか。

　「それについては今後判断することになるだろう」とデイヴィス氏は答えた。

　「最終的にIBMとしては、自社の顧客が望む機能をサポートしなければならない。もし、IBMが必要と考える機能の全てを、Knativeが提供できないなら、IBMはこの上に何らかのコンポーネントを構築することになる。今後の成り行き次第だ」

　IBMは、Knativeができるだけ多様なKubernetesワークロードに対応できるようになって欲しいと考えていると、デイヴィス氏は説明する。そしてこれが、Knativeの直面する課題につながってくるという。

　「私の示した図では、Knativeに関して全項目にチェックが入っているか、『取り組み中』としていて、この技術が世界中のあらゆる問題を解決するような印象を与える。だが、これは正しくない。あえて説明しなかったが、さまざまな制限が存在する。IBMとしては、Knativeを過度に複雑化したり、使いにくくしたりすることなく、現在見られる制限を、できるだけ取り払いたいと考えている。一方、Knativeコミュニティは、より保守的な考え方を持っているようだ。複雑化につながらなくとも、機能追加は十分な理由がある場合のみに限定しようとしている。

IBM Knative担当オファリングマネージャー／CNCFサーバレスワーキンググループメンバーのダグ・デイヴィス氏

　具体的な例を挙げよう。現在のところ、Knativeサービスには永続ボリュームをマウントできない。Kubernetesでは永続ボリュームをマウントしつつ、アプリケーションをスケールできる。このためにはCloud Providerがボリュームの複数箇所でのマウントをサポートしなければならない。だが、一部のボリュームではRead/Write Onceしかサポートしていない。このため、Knativeコミュニティーは永続ボリュームのサポートをためらっている。永続ボリュームのサポートがコードを複雑化するわけではなく、これが理由ではない。Cloud Providerによるサポートの違いが、ユーザーエクスペリエンスを複雑化するかもしれないという懸念から、サポートしたがらない。

　今後Knativeに関しては、これと同様な議論がさまざまな観点から続けられることになるだろう。（ユーザーエクスペリエンスにおける）シンプルさと、ユーザーが必要とするあらゆる機能をサポートできる柔軟性とのバランスを、どう取っていくかが問題だ。私はKnativeとKubernetesが提供する機能の違いは、できるだけ小さくなって欲しい。だが、2つの違いはコミュニティーが決めることだ。

　従って、IBMとしてのロードマップ、そしてKubernetesとKnativeの間の境界線についても、決められない部分がある。私はこの点で、ユーザーの果たす役割は大きいと考えている。もし、多数のユーザーが『Knativeが与えてくれるユーザーエクスペリエンスは素晴らしい、だが○○の機能は必須だ』と言うなら、コミュニティーはそうした機能を提供する方向に進むだろう」

Buildが抜けたKnative、成熟度ではどの位置にあるか

　2019年7月のインタビュー時点で、Knativeはバージョン0.7だった。ではどのような要件を満たせば、「バージョン1.0」と呼ぶことになるのか。デイヴィス氏は、Knative発足当時の構成要素、「Serving」「Eventing」「Build」に分けて説明した。

　「Knative Servingについてはコミュニティー内の多くの人々が、機能的にほぼ1.0だと考えている。Servingは検証段階に入りつつあるところだ。IBMとしては、バージョン1.0に入れたい機能やKubernetes拡張が5項目ほどある。コミュニティはこれらへの対応を含め、今後数カ月の間にServingを1.0に到達させたいようだ」

　「一方、Knative Eventingは少し遅れている。まだ、どういう形がいいのか煮詰まってはいない段階だ」

　Knative Buildは、Knativeプロジェクトから離脱した。これがKnativeプロジェクトにとって新たな課題にもなっていると、デイヴィス氏は指摘する。

　「Buildは最近、Knativeを離れ、『Tekton』の基になった。Buildはソースコードからイメージを構築し、Knative Servingに提供するツールとして始まった。Tektonを始めた人たちは、Buildが備えるインフラを気に入り、Knativeに限定されない汎用なツールに育てたいと考え（てKnativeから分離し）た。Tektonでは、基本的にどんなCI/CDパイプラインも作れる。Jenkinsとほぼ同様だ。

　そこでKnativeコミュニティーにとっては、BuildがKnativeを離れてTektonになった今、この2つをどう結び付けるかという課題が生まれている。今でもKnative側では、Build（現Tekton）を使いたいという気持ちが強い。だがTektonでイメージをビルドし、Knative Servingにプッシュできるようにするための統合作業は複雑化している。そこで、両者を統合的に使う際のユーザーエクスペリエンスを向上させるための方法を検討しているところだ」