Istio、サイドカーパターンを不要にする「Ambient Service Mesh」機能をメインブランチに統合、正式な機能へ

今回は「Istio、サイドカーパターンを不要にする「Ambient Service Mesh」機能をメインブランチに統合、正式な機能へ」についてご紹介します。

関連ワード （不要、実行、説明等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

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のアーキテクチャとして説明されていたサイドカーパターンは、このようにノードに対するプロキシへと置き換わっていくものと思われます。

関連記事

• Istioが新たな仕組み「Ambient Mesh」を発表。サイドカーなしでサービスメッシュを実現