Kubernetesをサービスメッシュ化するIstioとは？

2017年12月にオースチンで開かれたKubeCon＋CloudNativeConは非常な盛り上がりで、いよいよKubernetesがコンテナオーケストレーションの本流として認知されたイベントであった言える。しかしクラウドネイティブなシステムを指向するエンジニアは「複数のコンテナを同時に管理できるのは良いけど、どうやって全体を管理するのか？」に注目している。その解決策のひとつがサービスメッシュだ。

今回は、KubeConでのセッションを紹介しつつ、Istioの基本的な概要を紹介したい。

今回紹介する動画は、KubeConでのセッションで「Setting Sail with Istio [B]」と題されたもので、スピーカーはMicrosoftのLachlan Evenson氏だ。

マイクロサービス化は難しい

Evenson氏は「マイクロサービスといっても、実際にそれを実現するのは難しい」と言う話からスタートした。またマイクロサービス化、つまりKubernetesを使ってアプリケーションを実行することは究極の目的ではない、つまり「End Game」ではないというGoogleのKelsey Hightower氏のコメントを紹介した。デベロッパーにとってマイクロサービス化はスタート地点であり、その先に進むべきだというのがメッセージだ。

GoogleのKelsey Hightower氏のコメント

そしてモノリシックなシステムをマイクロサービスにする際に重要なのは、ツールの選択ではなく、それに関わる人間とプロセスを変えるほうがずっと困難であると語る。マイクロサービス化はすなわちCI/CDに繋がるDevOpsの延長であるというのが背景にあるだろうし、DevOpsが出来ないのにマイクロサービス化をしてもあまり意味がない。マイクロサービスの目的がスケールできて、障害に強いシステムを目指すのであれば、何か不具合があった時にすぐさま修正できて、それを本番環境に反映できるプロセスを作っておく必要がある。つまりマイクロサービスとDevOpsは、表裏一体とでも言えるだろう。

マイクロサービスに伴う困難は人とプロセスを変えること

また最初の段階ではマイクロサービスは簡単であるが、ツール（これはIstioや、それに含まれるEnvoyやgRPCなどを差しているものと思われる）はまだ出来上がってから日が浅く未熟であり、デベロッパーも自分で調べながら進んでいくしかないと説明した。

最初は簡単だがツールはまだ未熟である

次にIstioの機能を紹介するために、マイクロサービスのプラットフォームとして必要な機能は何か？　を紹介した。ここではモニタリングとトレーシング、それにトラフィックコントロールなどが説明された。またセキュリティに関しては後半で説明されるように、mTLS（Mutual TLS）が実装される。これはKubeConの別の記事でも紹介しているので参照されたい。

新しいセキュリティアプローチ、CalicoとIstio、Kubernetesによるゼロトラストネットワークとは

マイクロサービスプラットフォームに必要な要件

そしてここからはデベロッパー向けではなくオペレーター向けの説明と断って進めたのは、Istioの構造の話である。つまりIstioを構成するソフトウェアは、サイドカーとしてPodに挿入されるEnvoyプロキシーとそれをコントロールするPilot、ポリシーを管理するMixer、そして上位のプラットフォーム（この場合はKubernetes）と接続をするためのMixerのアダプターというシンプルな構成だ。

Istioの構成

上位にあるPilot、Mixer、Istio-Auth（後述するCAに相当）と、各Podに配置されるEnvoyが通信を行う。ここで注目するべきなのは、IstioはKubernetesのサービスメッシュプラットフォームとして注目されているが、プラグインによってMESOSやCloud Foundryといった様々なプラットフォームにも応用できる予定があるという点だろう。これはプラットフォームだけではなく、モニタリングのPrometheusなどもプラグイン経由で情報のやり取りができることを示している。

ProxyとしてEnvoyが全ての通信を行う

Podへの通信は全てEnvoyが中継することになるという図表だが、サイドカーとしてPodに注入されたEnvoyが全ての通信を中継しなければモニタリングもトレーシングも不可能であるわけで、ここは、そのために軽量のProxyを開発したLyftに感謝するべきだろう。

mTLSの概要

この恩恵のひとつがmTLSだ。全てのエンドポイント間を暗号化することで、よりセキュアなネットワークを構成できる。そのためにIstioには、CA（Certified Authority）が一緒に実装される。また興味深いのは、Istioが使うキーバリューなどのリソースとしてKubernetes 1.8から導入されたCRD（Custom Resource Definition）を使うことだろう。つまりIstioのための特別なデータストアを用意せずに、上位のプラットフォームであるKubernetesのデータストア（つまりはetcd）を間借りしている。そのために個別のデータストアを用意することなく、コンパクトに実装できる点だろう。

Mixerの説明

このCRDを使うことで、別の利点もある。それはValidationが行われることで、よりエラーの少ないコードを書くことができる点だ。またEnvoy同士の通信もgRPCを使うところも、最新のクラウドネイティブなツールというところだろう。

前置きが非常に長くなったが、ここからが「オペレーター向けのデモ」と言う部分に入る。実はこのセッションの中ではIstioをインストールする際にHelmというパッケージマネージャーを使っている。そのためまずはHelmについて基本的な理解をしていないと、デモの操作についていけない可能性があるだろう。

HelmはKubernetesのSIG-Appsで開発が進んでいるプロジェクトで、HelmというクライアントとTillerというサーバーがgRPCを通じて協調してKubernetesのPodをパッケージとして運用するためのシステムだ。パッケージはChartと呼ばれ、Bitnamiがホストするリポジトリーで公開されている。

KubeApps Hub

Istio自身も、Incubatorという状態で公開がされている。つまり、まだStableではないが、実験的に利用が可能であるというフラグだと思えば良いだろう。Helmはyamlファイルに書かれた設定情報を元にKubernetesのクラスターをインストールしたり、Upgradeしたりできるツールとして今、注目が集まっている。

https://hub.kubeapps.com/charts/incubator/istio

Evenson氏はまず、Istioが利用するCRDをHelmのコマンドで用意した上でIstio本体をインストールした。このスクリーンショットからも分かるようにistio-systemというネームスペースに、CA（Certified Authority）やmixer、pilotなどのpodが立ち上がっていることがわかる。またGrafanaやPrometheus、Zipkinなどのモジュールも確認できる。

作成されたIstio用の複数のPod

より詳細にPodのサービスを見てみると、「istio-ingress」というPodがIstioの中のLoad Balancerとして動作していることがわかる。

Istioのサービスの概要。ingressがin-coming通信の受け口になっている

ここまでがIstioを準備するまでのデモであり、「ここまではIstio for Operatorのデモ。ここからデベロッパー向けのデモをやる」として始まったのが、KubernetesのCLI、kubectlを使った操作だ。ここでは会場からボランティアを募ってBookinfoというデモアプリをDeployする操作をさせるのだが、ポイントはIstioがあるということを全く意識する必要がないという部分だろう。

BookinfoというデモについてはIstioのDocumentationの以下を参照して欲しい。

Bookinfo

これは本のレビューを表示するサイトを例にとったもので、Pythonで書かれたフロントエンド（/productpage）から3つのレビューを表示するJavaで書かれたモジュール、その後ろにNode.jsで書かれたRatingのモジュール、さらにRubyで書かれた詳細のモジュールがPodとして構成されている。

Bookinfoの構成

このように複数の言語で書かれたマイクロサービスを、kubectlコマンドを1回叩くだけでProxyであるEnvoyをInjectionして、稼働させることができる。つまりデベロッパーにとって、Istioは意識する必要がないものであるという点を強調した。

次にデモを行なったのは、Dotvizというプラグインを使ったモジュールの依存関係の可視化だ。これはBookinfoがどのように通信を行っているのかをビジュアライズするものである。

Dotvizによる依存関係の可視化

さらにGrafanaを使って、各Podのテレメトリーを行うようすをデモンストレーションした。

Grafanaによる可視化の例

またZipkinを用いたトレーシングも可能である。

Zipkinによるトレーシング

これらは、全てMixerがプラグイン可能な構造を持っているからであるという。当然のようにCAが用意されていることから、全てのPodに対して秘密鍵を生成して通信を暗号化するmTLSが可能だ。

より詳細な解説は、Istioの公式ページを参照していただきたい。Bookinfoのデモも、準備から最後にクリーンアップする操作までが丁寧に解説されている。

Istio

Bookinfoのデモについては、以下のURLから参照して欲しい。

https://github.com/istio/istio/tree/master/samples/bookinfo

なお、Istioと同じくサービスメッシュを実現するために、Buoyantが開発をリードするConduitについて、mTLSとPluginが現状ではサポートされていないが、BuoyantのWilliam Morgan氏によればすでに計画中であるという。

mTLS and plugins are on the roadmap. Stay tuned!

— William Morgan (@wm) 2018年2月9日

Istioは、サービスメッシュのプラットフォームとして今後も確実に広がっていくだろうということを感じさせるセッションであった。そしてKubeConは、Kubernetesのエコシステムが単なるコンテナのオーケストレーションから、より現実的なマイクロサービスのためのプラットフォームとして動き出していることを感じることのできるイベントだ。3月後半にLos Angelesで行われるOpen Networking Summit North AmericaではPivotalのエンジニアがIstioとEnvoyに関するセッションを行うことが決定しているという。これをみてもPaaSのレイヤーにおいてもマイクロサービスの波が及んでいることを感じる。

Open Networking Summit North America Program Now Available, Featuring Topics for the Enterprise, Cloud and Service Providers

引き続きクラウドネイティブなプラットフォームに注目していきたい。