Open Infrastructure Summitで注目を集めるKata ContainersとStarlingX

Open Infrastructure SummitではOpenStackの各プロジェクトの最新情報だけでなく、新たにOpenStack Foundationがホストを始めたプロジェクトに関するセッションも目立っていた。特にコンテナハイパーバイザーのKata Containersと、エッジ向けのプラットフォームのStarlingXは、それぞれIntel、AT＆Tという強力な企業のバックアップを背景にして、露出を高めているという印象だ。

Intelと中国Hyper.shの協力で誕生したKata Containers

Kata Containersは、Intelと中国のHyper.shの両社が互いのコードをマージして始まった仮想マシンの特徴を備えたコンテナハイパーバイザーだ。現在もIntelとHyper.shが共同で開発を行っているものだが、CNCFではなくOpenStack Foundationにホストされ、今回のサミットで正式にプロジェクトとして認定されたということになる。

メディア向けブリーフィングで紹介されたKata Containers

この写真は、サミット初日のランチタイムに開催されたメディア・アナリスト向けブリーフィングでJonathan Bryce氏が使ったスライドだ。OpenStackを中心に、Kata Containers、StarlingX、そしてOpenStackが利用するCI/CDのZuul、そしてAirShip（こちらもAT＆Tが自社の通信網の支局用のプラットフォームの管理のために開発したもの）が並び、Zuulに次いでKata Containersがいわば昇格したことを示している。

機能の説明についてはすでに何度も行われているということもあるためか、キーノートではAWSが開発を行っているオープンソースの軽量の仮想化基盤であるFirecrackerとの連携が発表された。Kata ContainersもFirecrackerもカーネルを共有するコンテナランタイムではなく、ネームスペースや特権などを共有しない仮想マシン型のランタイムだが、実装的にはKata ContainersはShimとしてベースとなるOSとFirecrackerの間に挟まるように配置されるようだ。

Kata Containersの概要

コンテナランタイムについては、すでにCNCFのグラデュエーションフェーズになったContainerdとインキュベーションフェーズのRkt、それに2019年4月に新たにCNCFのインキュベーションに加わったcri-oなどがそれぞれ開発を進めている。その上GoogleがgVisorを、AWSがFirecrackerを開発するという状態で、ユーザーにとってはなにを選ぶべきか？　大いに悩む事態と言える。

そこにOpenStack FoundationがKata Containersを加えたことで、さらに混乱が深まったように見える。CNCFもOpenStack Foundationも大いに期待をかける中国市場を背景にした中国の企業Hyper.shと、Intelという巨大なスポンサーが推すKata Containersが、今後どのようにコミュニティやユーザーから支援を集めるのか要注目だ。

StarlingX

カンファレンスの会場でKata Containersに並んでプレゼンスを誇っていたのが、StarlingXだ。先ほど紹介したプレス向けブリーフィングでも、StarlingXの担当者が説明を行うなど、まだプロジェクト自体の歴史は短いものの、多くの期待を掛けられていることが分かる扱いであった。

エッジコンピューティング向けのプラットフォームStarlingX

StarlingXはプラットフォームとしてOpenStackを使ったエッジ、つまりデータセンターではなく拠点向けのコンピュータリソースとして定義されている。しかし旧称のOpenStack Summitの時代から参加しているエンジニアには既知だろうが、「エッジ」の定義だけで数時間の議論が必要なぐらいにユーザーやデベロッパーにおいて「エッジとは何か？」が異なってしまうというのが実情である。

完全に統合されたエッジ向けプラットフォームがStarlingX

プレゼンテーションを行ったエンジニアによれば「誰に聞いてもエッジの定義がバラバラで決まらなかった。でもひとつだけ誰もが納得したエッジの定義は『U2のギタリスト』というものだった」。こんなジョークが出るほどのカオスぶりである。

StarlingX開発の経緯

このスライドで注意してみて欲しいのは、プロジェクトが2018年5月に始まり、同年10月に最初の商用に耐えるリリースを行っていること、そして2019年8月に2回めのメジャーリリースを予定していることではない。小さい文字で書かれた「OpenStack Pike with many patches」と「Kubernetes 1.13」「OpenStack Stein with no out of tree patches」という短い文章だろう。これらの文章が意味するところは、OpenStackのPikeリリースを流用してパッケージングしたが、エッジ向けにするために多くの独自の修正を行ったということ、そしてリリース2ではSteinをベースにするが、独自の修正はやらない、という宣言だ。OpenStackのPikeは2017年8月にリリースされたもので、そこからQueenとRockyと呼ばれる2つのOpenStackのリリースを飛ばしてSteinを使う、ということを意味している。

カンファレンスに参加した何人かのコントリビュータのコメントによれば、「StarlingXはエッジ向けに動かすために『魔改造』だらけ」というのが下馬評のようだ。IntelにしてみればTitanium CloudとしてWind Riverが持っていたコードを、プロプライエタリソフトウェアではなくオープンソースとして公開するために、OpenStackをベースにして無理をしてでもエッジ向けのプラットフォームとして先行したかったということだろう。その無理の部分が独自の修正、いわゆる魔改造だろう。この技術的負債を、プロジェクトがどのように返済していくのか要注目だ。

また先行するKata Containersはプロジェクトの進め方についても参考にしているようで、組織の構造やガバナンスを受け継いでいるという。

Kata Containersと同様のガバナンスを目指す

技術的な内容に関するコミッティー（Technical Steering Committee）も結成し、2019年6月に新たなコミッティーメンバーを選出するということが表明され、ここでも新しいメンバーの参加を期待していることを語った形になった。

しかし実質、IntelとWind River Systemsのエンジニアでなければ修正の背景もユースケースも見えてこないのではないかと思える。多分に先行スタートすることが最優先で始まった感があるStarlingXだが、前途多難に見えてしまうのは気のせいだろうか。

これからのToDoには技術的負債の返済は書かれていない