Istio、サイドカーパターンを不要にする「Ambient Service Mesh」機能をメインブランチに統合、正式な機能へ
Istioは、サービスメッシュを実現する新たな仕組みとして試験的に開発していた「Ambient Service Mesh」をメインブランチに統合し、正式な機能として組み込んで行く方針であることを発表しました。
現在のIstioは、各サービス(≒KubenetesのPod)ごとにプロキシを配置し、サービス間のネットワークをプロキシ経由で構成することによってサービスメッシュを構築しています。これによりサービス間の通信のトラフィックコントロール、暗号化、可観測性(オブザーバビリティ)などの機能が実現されるわけです。
この仕組みは、サービスの隣にプロキシを配置することから、「サイドカー」パターンなどと呼ばれています。
しかしPodごとにサイドカーをデプロイする必要があるため、これにかかる手間やリソースの消費が課題でした。
eBPFを用いたサイドカーフリーなCiliumへ注目が集まる
そうした中で最近、Linuxカーネルの内部をフックして機能を拡張できる「eBPF」と呼ばれる注目の技術を用いてサービスメッシュを実現する「Cilium」が注目されるようになってきました。
Ciliumではカーネル内部をフックして通信を処理する仕組みであるため、サイドカーパターンを用いることなく、シンプルかつ負荷の小さなサービスメッシュの構築が可能です。
おそらくはこのCiliumの躍進が背景にあり、Istioもサイドカーパターンを用いない、よりシンプルな方法を開発する必要に迫られたのだと推察されます。そして登場したのが、今回メインブランチにマージされた「Ambient Service Mesh」機能です。
ポッドではなくノードにプロキシを配置
Ambient Service Meshの説明図が下記です。左が従来のサイドカーパターンで、各サービス(水色の四角)の左に「P」で示されたプロキシが配置され、サービス間の通信はプロキシ経由で行われます。
右がAmbient Service Meshによるサイドカーレスのパターンです。
Ambient Service Meshではポッドごとではなく、複数のポッドを実行しているノード(灰色の長方形)ごとにプロキシが配置されます。
そしてすべてのポッド間(=サービス間)の通信は、ノード上のプロキシ経由で行われるため、このプロキシにサービスメッシュの機能を実装します。これによってポッドのサイドカーを不要にしているのです。
現在、Istioはバージョン1.17が最新版であり、1.18からこのAmbient Service Meshが取り込まれる予定です。これまでIstioのアーキテクチャとして説明されていたサイドカーパターンは、このようにノードに対するプロキシへと置き換わっていくものと思われます。
関連記事
あわせて読みたい
オラクル、次期Oracleデータベースの開発者向け無償版「Oracle Database 23c Free - Developer Release」提供開始。JavaScriptストアドプロシージャなど
≪前の記事
マイクロソフト、.NET中間言語をWebAssemblyにコンパイルする「Jiterpreter」をBlazor WebAssemblyに搭載へ、.NET 8で