KubeCon Europeでサービスメッシュの標準化を目指すSMIを発表。Istioの動向にも注目

KubeCon Europe初日午後のジェネラルセッションは、コペンハーゲンや上海で開催した際にもMCを努めたGoogleのエンジニアJanet Kuo氏が登壇して始まった。この日は午前中のキーノートで、CNCFのプロジェクトアップデートがあり、Kubernetes以外のさまざまなプロジェクト、CRI-O、Linkerd、Fluentd、Harbor、Rookなどの最新情報が紹介された。そしてKubernetes自体のアップデートは、午後のキーノートセッションでKuo氏が担当するという流れとなった。

MC役を担当したGoogleのJanet Kuo氏

初日午後に最も耳目を集めたService Mesh Interface

しかし、この日の最大のトピックとなったのは、その前に行われたMicrosoftのGabe Monroy氏によるプレゼンテーションであったように思える。

MicrosoftのGabe Monroy氏

Monroy氏が発表したのはService Mesh Interface（SMI）と呼ばれるもので、乱立するサービスメッシュに共通のAPIを定めることで、サービスメッシュ用のツールがどのソフトウェアでも稼働できるように共通化を試みるものだ。それにより、それぞれのツールがIstio向け、Linkerd向け、Consul Connect向け製品を個別に作るようなムダな労力を減らし、エコシステムを拡大しようというプロジェクトである。

最初にここ25年間、「ネットワークはスマートエンドポイントと無能なパイプから構成されてきた」と説明。これはネットワークの構成要素として、認証やルーター、ファイヤーウォールなど多機能なエンドポイントと物理的なケーブルによって構成されてきたのがインターネットであり、それは決して悪くはなかった。だが、現在のマイクロサービスを指向する潮流においては、無能なパイプでは対応できなくなってきたと語り、そのためにスマートパイプが必要であると語る。そして、サービスメッシュこそがスマートパイプに他ならない、というのがMonroy氏の解説だ。これは常に変化するネットワークトラフィックや突然のピークに対応するために、ネットワークそのものが知的に変化する必要があるということを示している。

それぞれのプロダクトにロックインされてしまう

そのためにインテリジェントなパイプとして登場してきたのが、IstioやLinkerd、Consul Connectなどのサービスメッシュであるというのが、ここまでの経緯といえるだろう。しかしそれぞれのプロダクトを使ってサービスメッシュを構築したとして、それぞれのAPIやツールに個々に対応するだけではロックインが起きてしまい、ユーザーにとっては危険な選択となってしまうというのがSMI登場の背景だ。

Service Mesh InterfaceはMicrosoftが中心となって、LinkerdのBuoyant、Consul ConnectのHashiCorp、Glooを開発するSolo.io, incなどが賛同して開発を進めている共通のAPIということになる。

SMIに賛同しているベンダーとツール

BuoyantとHashiCorpがここにいるのは分かりやすいが、すでに独自のオープンソースとして接続するレイヤーを開発するSolo.ioやFlaggerを開発するWeaveworksなども名前を連ねていることは興味深い。また目立たないが、IstioとLinkerdの性能評価を行ったKinvolkなども参加しており、GoogleとIBM、Cisco以外、つまりIstioの開発をリードするベンダー以外がまとまった形になる。これに関しては、コミュニティの中でも評価が分かれるところだろう。今の段階でIstioのコミュニティからの賛同を得ずに発表したことを拙速とするエンジニアがいることは確認しているが、11月のSan DiegoのKubeConまで待たず、5月の時点で発表することで、拡散するサービスメッシュに一定の方向性を与えて、可視化やテレメトリーというコアなプロダクト以外のエコシステムベンダーを募りたいというMicrosoftの意図があるようだ。

APIを確定する際に重要視したのは3つ、まず「ネットワークポリシーを実装できること」、次が「テレメトリーで情報を取れるようにすること」そして、最後は「ルーティング」だ。ルーティングは一番分かりやすいだろう。v1.0のアプリケーションとv1.1のアプリケーションをカナリアリリースして、テストを行う場合、それぞれのトラフィックを振り分ける必要がある。APIゲートウェイやロードバランサーでやる場合もあるだろうが、マイクロサービスのように細分化されている場合、Podがどこに通信を行うのかを、細かいレベルで実装する必要がある。それをSMIのAPI仕様として、どのサービスメッシュであってもポータブルになるように決めようというのがここの意図だ。

SMIが抽象化することで個別の開発が必要なくなる

ここから、より理解を深めるためにデモに移った。最初に行ったデモはトラフィックルーティングの例で、複数のバージョンをカナリアリリースで実装するために、WeaveworksのFlaggerとIstioを使って振り分けている。

次にLinkerdを使ってメトリクスを取るデモを実行した。これはSMIのテレメトリーのAPIを適用することで、実際にLinkerdを経由しているトラフィックのレイテンシーなどの情報を取るものだ。ここでは、Kubecostという元Googleのエンジニアが開発するパブリッククラウド上のKubernetesのコスト情報を取得するツールを紹介した。

またポリシーの部分では、フロントエンドとバックエンドを繋ぐサービスに設定ファイルを適用することで、Consul Connectが簡単に通信を始めるというデモを行った。全体としてIstio、Linkerd、Consul Connectのそれぞれが、すでにこのAPIに従って稼働している様子を見せたデモとなった。

なおGabe Monroy氏の8分に渡るデモは、以下のYouTubeページから見ることができる。これについては、実物を見てもらったほうが理解は早いだろう。

参考：Democratizing Service Mesh on Kubernetes - Gabe Monroy, Microsoft

Microsoftが主導的な役割を担っていることはこのプレゼンテーションでもよく分かるが、この後はGoogle、IBM、Cisco、Red Hatなどの大手ベンダーの賛同を得て、CNCFの仕様として正式に採用されることが必須だろう。Red Hatは、OpenShiftのサービスメッシュはIstioであることをはっきりと宣言しているが、何よりもIstioのコアな開発コミュニティ、そしてユーザーがこれを良き方向として認知することが必要だ。それに関しては、11月のSan Diegoで開かれるKubeConにおけるSMIの扱いがポイントになるだろう。

デモで使われたLinkerdの管理画面

Linkerdのキーパーソン、BuoyantのCTO、Oliver Gould氏（左）とCEO、William Morgan氏（右）

Buoyantの2名は、サービスメッシュのラウンドテーブルやプレスブリーフィング、ワークショップ、ブレークアウトセッションなどでも大いに露出を果たし、Istioの影に隠れがちだったLinkerdを一気に表舞台に立たせたと言える。願わくはあまり混乱なく、SMIに収束して欲しいというのがこれまでのサービスメッシュの動向を追い続けている者からの願いだ。

Kubernetesアップデート

Monroy氏が降壇した後はGoogleのJanet Kuo氏が登壇。ここからKubernetes自体のアップデートを行うことになった。

Kubernetesのアップデートを行うKuo氏

最初は過去の振り返りとして、16年前の2003年にGoogleのコンテナオーストレーターであるBorg、それからBorgの後継であるOmegaから、Dockerの発表、IT業界にコンテナという大きな流れができた後に、2014年にGoogleがKubernetesをDockerConで発表するという流れを紹介した。

DockerConで発表されたKubernetes

そして、オープンソースソフトウェアとしてKubernetesをどうやってガバナンスするのか？　という疑問に答える形でCNCFが創設されて現在に至るという流れだ。

2018年にCNCFを卒業したKubernetes

途中でKuo氏は、Kubernetesはすでに業界のデファクトスタンダードになったと語った。確かにKubernetesが登場した当初は、Docker Swarm、Mesosなどが並び立ち、ユーザーは何を選ぶべきか？　を検討する必要があったと言える。しかし今や、Kubernetes以外のオーケストレーターを選ぶ積極的な理由はないと言っていいだろう。

そしてKubernetesについても、まだやるべきことはあるとして1.14での新機能とそれ以降の改善点などについて解説を行った。

Windows NodeがGAになった1.14

今後の改善点については、さらに拡張性を向上させることの他に、CRD（Custom Resource Definition）がまだベータであることを説明した。CRDはKubernetesをカスタマイズする際に構成情報などをetcdに格納するための仕組みだが、これがまだベータであることは、エコシステムを支えるベンダーにとっては大きな意味がある。つまりCRDを使って連携するソリューションを開発しようとしても、ベータということで安定していない、もしくは仕様が変更される可能性があるためだ。そのために、CRDを早急にStableな状態にしたいというのは、コミュニティのみならずソリューションを開発するベンダーにとっても最大の願いであろう。

CRDはまだベータ

そして信頼性についても、全体を通じて考えなければいけないこと、KubernetesのSIGを跨ぐ形での開発を行う必要があることを解説した。

信頼性はSIGを跨いだ努力が必要

Cluster API

ここでKubernetesのアップデートは終わり、次にVMwareに買収されたHeptioの元CEO、Joe Beda氏が登壇し、Cluster APIに関する簡単な紹介を行った。これはKubernetesが仮想マシンからコンテナへの流れを強化する方向で導入されていることに伴い、Kubernetesを使ってクラスター自体を管理したいという、言わば仮想マシン→コンテナとは逆方向の仮想マシン→ベアメタルを管理したいというニーズに応えるものだ。

Cluster APIを紹介するJoe Beda氏

Kubernetesのユースケース

その後は、CERNのエンジニアが登壇し、ここからはKubernetesを使ったユースケースのセッションとなった。CERNは世界最大の素粒子に関する研究機関で、IT業界ではOpenStackのユースケースとしても、何度もOpenStack Summitで紹介されていたユーザーだ。

今回はヒッグス粒子を発見するワークロードをデモ

OpenStackをインフラストラクチャーとして使いながらも、新しいアプリケーションについてはKubernetesも積極的に利用するというのがCERNの方針のようだ。規模はさておき、仮想マシンベースのワークロードとコンテナベースのワークロードが混在するというユースケースは、これからのエンタープライズにおいても参考となるのではないだろうか。

使われているのはCeph、OpenStack Magnum、Redis、Jupyter notebook

Red HatはOperator Frameworkを推す

初日午後のキーノートの最後に登壇したのは、Red HatのRob Szumski氏だ。Operator FrameworkはCoreOSが開発をリードしていたもので、Kubernetesの上の様々なアプリケーションの実装、管理を容易にする仕組みだが、一番分かりやすいのはSzumski氏が使ったこのスライドだろう。

PostgreSQLを使う際の選択肢

これは「PostgreSQLを使う際にどのような選択肢があるのか？」というもので、左はDockerの上でPostgreSQLを使う、中央はパブリッククラウドのPostgreSQL互換のサービスを使う、そして右はOperator Frameworkを使って公開されているOperatorから選択するというものだ。リストアップされている機能を見れば、左は原始的な選択だし、パブリッククラウドはオンプレミスができないという課題があるが、その点Operatorを使えばオープンソースの透明性とクラウド／オンプレミスの双方で実装できる、という結論を導きたいことが分かるだろう。

特にパブリッククラウドとの違いということで、パブリッククラウドベンダーがサービスとして提供されているものはソースを確認することができずにアプリケーションのバグとサービス側のバグを切り分けるのが難しいというエピソードをこの後に紹介していた。その点Operatorであれば、100％オープンソースであり、またオンプレミスでも使えるという部分を強調した形になった。

そしてOperatorHubの説明も簡単に行い、Red Hatが認定する信頼できるコードが共有されていること、ベンダーニュートラルであることを再度強調した。

Operatorに認定されたサードパーティ製品

写真：DSC09712.jpg

初日午後のキーノートは、SMIが最大の注目ポイントとなった。しかしSMIがサービスメッシュのデファクトスタンダードとなるには、まだやるべきことは多い。Microsoft、Buoyant、HashiCorp連合が、IBM、Google、Ciscoなどの大手ベンダーの賛同を得られるのか注目したい。