「KubeCon NA 2022」から、サイドカーレスを実装したサービスメッシュのIstioのセッションを紹介

「KubeCon + CloudNativeCon NA 2022」から、サービスメッシュのIstioのセッションを紹介する。IstioはGoogle、IBM、Lyftが初期の開発を行い、その後CiscoやRed Hat、Solo.ioなども加わって開発を継続しているサービスメッシュのオープンソースソフトウェアだ。2022年9月28日にCNCF配下のインキュベーションプロジェクトとして採用された。実は2020年にGoogleはOpen Usage Commonsというトレードマークの管理を行う非営利団体を立ち上げ、Istioを寄贈した。これは「Istioのガバナンスを中立的な組織に移譲して欲しい」というオープンソースコミュニティからは非難されることとなった。GoogleがOpen Usage Commonsを立ち上げたことに関しては以下の記事を参照されたい。

●参考：GoogleがIstioを新組織に寄贈。トレードマークだけの管理に意味は？

CNCFのCTO、Chris Aniszczyk氏が「どうしてトレードマークだけを管理する団体にIstioを寄贈するのか？」と疑問を投げかけていたことを知れば、2年越しとは言えCNCFという最もIstioにふさわしい団体のプロジェクトとして認められたことは、コミュニティにとっては大きな前進だろう。今回はCNCFの正式プロジェクトとなったIstioに関して、Solo.ioのLin Sun氏とGoogleのMitch Conners氏が行った「Istio Today and Tomorrow:Sidecar and Beyond」というセッションを紹介する。

プレゼンテーションを行うSun氏（左）とConners氏（右）

●動画：Istio Today and Tomorrow: Sidecars and Beyond

このタイトルにあるように、これまでサービスメッシュはKubernetes上のPodで実行されるアプリケーションの脇にProxyを注入して、Podの外のサービスとの通信はProxyが行うサイドカー実装がアーキテクチャーとして採用されていた。それに対してIstioは、新しくサイドカー方式ではない実装を「Istio Ambient Mesh」として2022年9月7日に発表した。その後、CNCFがIstioを採用、そして10月のKubeConでAmbient Meshの開発をリードするSolo.ioとGoogleがテクニカルな部分を解説するこのセッションを行ったという流れだ。

Solo.ioによるAmbient Mesh発表のブログ記事は以下を参照されたい。

●参考：Introducing Ambient Mesh

Ambient MeshについてはSolo.ioのChristian Posta氏がデモを交えて紹介している動画を参照されたい。ここではアーキテクチャーなどは深く説明せずにAmbient Meshの動きをメインに紹介している。

●動画：Istio Ambient Mesh Launch Demo

Sun氏がサイドカー実装の問題点を紹介

Sun氏はこれまでのIstioの活動を振り返った後、CNCFのインキュベーションプロジェクトとなったことを紹介し、その後にサイドカー実装の問題点を解説した。このスライドでは「Transparency」（透明性）と書かれているが、PodにProxyを注入することが必要、アプリとProxyの起動／停止シーケンスが確実に実行できないことなどが挙げられている。

シーケンスについてはSolo.ioが執筆を行った「Istio Ambient Explained」というオライリーが出版した短い書籍に「サイドカーコンテナはKubernetesにとってはファーストクラスシチズンではない（つまりPodのライフサイクルを実行する仕組みや起動停止順序に関する保証がない）」ことを記載している。つまりアプリケーションを実装したコンテナが実行されてもProxyが実行されないことがあることなどを例に、サイドカー実装を悪い例として挙げている。この問題に対してIstioは、レイヤー4とレイヤー7の通信を分離してサイドカーではなく、ノードに単一のProxyを実装して通信を行い、レイヤー7に対してはアプリケーションのカテゴリー別にProxyを実装して通信を行うことがAmbient Meshのアーキテクチャーであると説明している。

レイヤー7のために複数のProxyを用意して通信を分散させる仕組み

このスライドで左側は従来のサイドカー実装、右側のWaypoint Proxyとztunnelと書かれている部分がサイドカーレス実装だ。

ztunnelはノード単位に実行されるデーモンセットとしても実行されるプロセスだが、現状はEnvoyをそのまま利用する実装となっている。このプロセスはそのノードで実行される複数のPodからは共有される。またレイヤー7通信を担当するWaypoint Proxyは、Kubernetesの場合はネームスペースごとに実行されるプロセスとなっており、ここでレイヤー4と7は分離され、ネームスペースごとにも分離されることになる。またztunnelは実装例として使われており、この部分を別のプログラム（例えば、Rustで書いたプログラム）で置き換えることは可能だと説明されている。しかしztunnelはノード内で共有されるため、ノイジーネイバー問題に直面するのでは？ という疑問については、レイヤー4に限定した通信を行うプロセスであり、eBPFのプログラムのような複雑なことは実行されないためにそれほど問題にならないだろうということがオライリーの書籍で解説されている。

L4とL7の通信を分離したアーキテクチャー

次のスライドではztunnelとWaypoint Proxyという2つのProxyを経由して通信が行われる部分を説明した。

Waypointとztunnelを経由して通信が行われるようす

サイドカーレスのサービスメッシュ実装については、Linkerdを開発するBuoyantのCEO、William Morgan氏が6月に公開したブログの中で問題点を指摘している。このブログ記事自体はeBPFを使ったサービスメッシュ、Cilium Service Meshを念頭において書かれており、サイドカーレスサービスメッシュに対する懸念を表したものになっているが、多くの部分でIstio Ambient Meshにも当てはまる内容となっている。

●参考：eBPF, sidecars, and the future of the service mesh

Linkerdと比べて導入と運用が難しいことが欠点として挙げられることが多かったIstioだが、単純にPodにProxyをインジェクションするサイドカーから2つのProxyを実装する形式でサイドカーレスを実装するアーキテクチャーに変わったことになる。サイドカーの実装例と共存できるとは言いつつも、Linkerdに比べれば複雑であることには変わりがない。アプリケーションのデベロッパー目線で利点と言えば、サイドカーの場合に比べて経由するプロセスが2つから1つに減ることだろう。

CNCFに採用されたことで、これまでIstioを支援してきたRed HatやIBM、Ciscoなどのエンタープライズ企業のユーザーを多く抱えるベンダーにとっては追い風と言える。しかし実際にクラウドネイティブなシステムにおいて導入が拡がるのかどうか、注目していきたい。