サービスメッシュの比較Istio vs. Linkerd vs. Envoy （前半）

今回は、３つのサービスメッシュの比較をしていきたいと思います。長い記事なので２回に分けてお送りします。今回はトラフィック管理、セキュリティ、ロギング面での比較をします。

簡単に言えば、サービスメッシュは、プラットフォームで実行されているアプリケーションのネットワーク機能を処理するものです。 Kubernetesがテクノロジーとして成熟するにつれて、サービスメッシュが話題になり、トラフィック管理、セキュリティ、観測性などの分野に関連する課題を解決するためにさまざまな製品が開発されています。こういった内容をしっかりと理解するには、徹底的なサービスメッシュ比較をしてみると分かりやすいです。

この記事では、3つのサービスメッシュを比較してみたいと思います。まず、サービスメッシュスペースの最大手、Istioです。2017年5月にGoogle、IBM、Lyftによってオープンソース化され、その後多くのマインドシェアを獲得しています。2つ目のLinkerdは、Istioより前に誕生しています。バージョン1.0でネットワークプロキシとしてスタートしています。2018年9月に既存のサービスメッシュ（Conduit）と合併してLinkerd 2.0となり、ネットワークプロキシにサービスメッシュ機能が追加されました。本記事では、Linkerd 2.0を中心に解説していきます。最後に、Hashicorp（Vault、Terraform、Vagrantの生みの親）が参入したConsul Connectを検証します。

Service Mesh Architecture

これらの3つの製品はすべて同じようなアーキテクチャを使用しています。これらの製品は、クラスタ・レベルでデータが取るパスを管理する「コントロール・プレーン」と、メッシュ内のあるインターフェースから別のインターフェースへデータを転送する機能やプロセスを指す「データ・プレーン」を分離しています。

より詳しくは：

• Sqlite vs. MySQL vs. PostgreSQL: 関連するデータベースの比較
• 5つのホストされたKubernetes プラットフォーム
• Jaeger と ELKスタックを使った分散したトレーシング

Consul Connectはデーモンセット内の各ノードで動作するエージェントをコントロールプレーンとして使用する一方で、IstioやLinkerd’s Conduitは集中型サービスを使用しています。

データプレーンについては、3つのメッシュ製品すべてが、各ポッド内の別のコンテナにプロキシを配置する「サイドカー」パターンを使用しています。このサイドカーコンテナは、アプリケーションからデータを受け取り、アプリケーションにデータを送ります。また、データを他のポッドやクラスター外のスペースに移動したり、変換したりなどのような大変な作業も行います。Istio はこの機能を実行するために Envoy プロキシを使用しています。 Linkerd 2.0はプロキシとしてConduit製品を採用しています。対照的にConsul…