Kubernetesサービスメッシュの比較

マイクロサービスのアーキテクチャとコンテナ化について説明するとき、近年、本番環境で実証済みのツールの1つのセットであるサービスメッシュが最も注目を集めています。

実際、マイクロサービスアーキテクチャとKubernetes（多くの場合、定型化された「K8」）はスケーラブルなアプリの標準になり、サービス間の通信管理の問題がホットトピックになり、サービスメッシュは魅力的なソリューションになっています。 私自身、本番環境でサービスメッシュ、具体的にはLinkerd、Istio、および以前の形式のAmbassadorを使用しました。 しかし、サービスメッシュは正確に何をしますか？ どれを使用するのが最適ですか？ 使用する必要があるかどうかをどうやって知るのですか？

これらの質問に答えるには、サービスメッシュが開発された理由を理解するのに役立ちます。 従来のITインフラストラクチャでは、アプリケーションがモノリスとして実行されていました。 1つのサービスが1つのサーバーで実行されました。 より多くの容量が必要な場合、解決策は、より大きなマシンをプロビジョニングすることによって垂直方向に拡張することでした。

このアプローチの限界に達すると、大手テクノロジー企業は急速に3層アーキテクチャを採用し、ロードバランサーをアプリケーションサーバーおよびデータベース層から分離しました。 このアーキテクチャはある程度スケーラブルなままでしたが、アプリケーション層をマイクロサービスに分割することにしました。 これらのサービス間の通信は、アプリケーションを拡張するために監視および保護するために重要になりました。

サービス間通信を可能にするために、これらの企業は社内ライブラリを開発しました。TwitterのFinagle、NetflixのHystrix、GoogleのStubby（2016年にgRPCになりました）。 これらのライブラリは、マイクロサービスアーキテクチャによって発生する問題（サービス間のセキュリティ、遅延、監視、負荷分散）を修正することを目的としています。 しかし、大きなライブラリを依存関係として（複数の言語で）管理することは、複雑で時間がかかります。

結局、そのタイプのライブラリは、使いやすく軽量なプロキシに置き換えられました。 このようなプロキシは、外部からアプリケーションレイヤーから独立しており、アプリケーションに対して透過的である可能性があり、更新、保守、および展開が容易です。 このようにして、サービスメッシュが誕生しました。

サービスメッシュとは何ですか？

サービスメッシュは、サービス間の通信を制御するためのソフトウェアインフラストラクチャレイヤーです。 通常、2つのコンポーネントで構成されています。

1. アプリケーションの近くの通信を処理するデータプレーン。 通常、これは、前に示したように、ネットワークプロキシのセットとしてアプリケーションとともに展開されます。
2. サービスメッシュの「頭脳」であるコントロールプレーン。 コントロールプレーンはプロキシと対話して、構成をプッシュし、サービスディスカバリを確保し、可観測性を一元化します。

サービスメッシュには、サービス間通信に関する3つの主要な目標があります。

1. 接続性
2. 安全
3. 可観測性

接続性

サービスメッシュアーキテクチャのこの側面により、サービス検出と動的ルーティングが可能になります。 また、再試行、タイムアウト、回線切断、レート制限などの通信の復元力についても説明します。

サービスメッシュの主な機能は、負荷分散です。 プロキシによってメッシュ化されるすべてのサービスでは、ラウンドロビン、ランダム、最小リクエストなど、サービス間の負荷分散ポリシーを実装できます。 これらのポリシーは、各サービスの前に小さなロードバランサーがある場合と同様に、サービスメッシュが元のリクエストを受信するレプリカを決定するために使用する戦略です。

最後に、サービスメッシュは、トラフィックシフトとミラーリングの形でルーティング制御を提供します。

安全

従来のマイクロサービスアーキテクチャでは、サービスは暗号化されていないトラフィックと相互に通信します。 暗号化されていない内部トラフィックは、特にパブリッククラウドインフラストラクチャとゼロトラストネットワークのセキュリティの観点から、今日では悪い習慣と見なされています。

ハードウェアを直接制御できないクライアントデータのプライバシーを保護することに加えて、内部トラフィックを暗号化すると、システムが侵害された場合に、さらに複雑なウェルカムレイヤーが追加されます。 したがって、すべてのサービスメッシュは、サービス間通信、つまりすべてのプロキシ間通信に相互TLS（mTLS）暗号化を使用します。

サービスメッシュは、承認ポリシーの複雑なマトリックスを適用することもでき、特定の環境とサービスを対象とするポリシーに基づいてトラフィックを許可または拒否します。

可観測性

サービスメッシュの目標は、サービス間通信に可視性をもたらすことです。 ネットワークを制御することにより、サービスメッシュは可観測性を強化し、レイヤー7メトリックを提供します。これにより、トラフィックがカスタマイズ可能なしきい値に達したときに自動アラートが可能になります。

通常、サードパーティのツールまたはJaegerやZipkinなどのプラグインでサポートされていますが、このような制御では、 HTTPトレースヘッダーを挿入してトレースすることもできます。

サービスメッシュのメリット

サービスメッシュは、マイクロサービスアーキテクチャによって生じる運用上の負担の一部を相殺するために作成されました。 マイクロサービスアーキテクチャの経験がある人は、日常的に操作するのにかなりの量の作業が必要であることを知っています。 マイクロサービスの可能性を最大限に活用するには、通常、集中ログ、構成管理、スケーラビリティメカニズムなどを処理するための外部ツールが必要です。 サービスメッシュを使用すると、これらの機能、およびそれらのセットアップと統合が標準化されます。

特に、サービスメッシュの可観測性は、非常に用途の広いデバッグおよび最適化手法を提供します。 サービス間の交換に関するきめ細かく完全な可視性のおかげで、エンジニア、特にSREは、起こりうるバグやシステムの設定ミスをより迅速にトラブルシューティングできます。 サービスメッシュトレースを使用すると、システムへのエントリ（ロードバランサーまたは外部プロキシ）からスタック内のプライベートサービスに至るまで、要求を追跡できます。 ロギングを使用してリクエストをマッピングし、各サービスで発生するレイテンシを記録できます。 最終結果：システムパフォーマンスへの詳細な洞察。

トラフィック管理は、サービスの新しいバージョンの完全なリリースに立ち上がる前に、強力な可能性を提供します。

1. リクエストのごく一部を再ルーティングします。
2. さらに良いことに、プロダクションリクエストを新しいバージョンにミラーリングして、リアルタイムトラフィックでの動作をテストします。
3. A / Bは、任意のサービスまたはサービスの組み合わせをテストします。

サービスメッシュは、上記のすべてのシナリオを合理化し、本番環境での予期しない事態を回避および/または軽減することを容易にします。

Kubernetesサービスメッシュの比較

多くの点で、サービスメッシュはマイクロサービスアーキテクチャの究極のツールセットです。 それらの多くは、トップコンテナオーケストレーションツールの1つであるKubernetesで実行されます。 今日Kubernetesで実行されているメインサービスメッシュのうち、Linkerd（v2）、Istio、ConsulConnectの3つを選択しました。 他のサービスメッシュ（Kuma、Traefik Mesh、AWS App Mesh）についても説明します。 現在、使用法とコミュニティの点ではあまり目立ちませんが、ここで確認し、一般的に監視するのに十分な見込みがあります。

サイドカープロキシに関するクイックノート

すべてのKubernetesサービスメッシュが同じアーキテクチャアプローチを採用しているわけではありませんが、一般的なアプローチはサイドカーパターンを活用することです。 これには、プロキシ（サイドカー）をメインアプリケーションに接続して、アプリケーションのインバウンドおよびアウトバウンドネットワークトラフィックを傍受および規制することが含まれます。 実際には、これは、アプリケーションコンテナのライフサイクルに従う各アプリケーションポッドのセカンダリコンテナを介してKubernetesで実行されます。

サービスメッシュへのサイドカーアプローチには、主に2つの利点があります。

• サイドカープロキシは、ランタイムやアプリケーションのプログラミング言語からも独立しています。
  • これは、スタック全体で、使用する場所に関係なく、サービスメッシュのすべての機能を簡単に有効にできることを意味します。
• サイドカーには、アプリケーションと同じレベルの権限とリソースへのアクセス権があります。
  • サイドカーは、監視をメインアプリケーションのコードベースに統合する必要なしに、メインアプリケーションによって使用されるリソースを監視するのに役立ちます。

しかし、サイドカーは、アプリケーションに直接影響を与えるため、さまざまな祝福があります。

• サイドカーの初期化により、アプリケーションの起動メカニズムがデッドロックする可能性があります。
• サイドカープロキシは、アプリケーションに潜在的な遅延を追加します。
• サイドカープロキシは、大規模なコストがかかる可能性のあるリソースフットプリントも追加します。

これらの長所と短所を考えると、サイドカーアプローチはサービスメッシュコミュニティでしばしば議論の対象になります。 とはいえ、ここで比較した6つのサービスメッシュのうち4つは、Envoyサイドカープロキシを使用し、Linkerdは独自のサイドカー実装を使用しています。 Traefik Meshは、その設計にサイドカーを使用していません。

Linkerdレビュー

2017年にデビューしたLinkerdは、市場で最も古いサービスメッシュです。 Linkerd v1は、Buoyant（2人の元Twitterエンジニアによって設立された会社）によって作成され、FinagleとNettyに基づいていました。

Linkerd v1は、完全な本番環境対応のサービスメッシュであったため、時代を先取りしていると説明されていました。 同時に、リソースの使用に関しては少し重いものでした。 また、ドキュメントに大きなギャップがあるため、本番環境でのセットアップと実行が困難でした。

それで、Buoyantは完全な生産モデルで作業し、それから経験を積み、その知恵を適用する機会がありました。 その結果、Conduitが誕生しました。これは、2018年にリリースされた会社を完全にLinkerdで書き直し、その年の後半にLinkerdv2に名前を変更しました。 Linkerd v2は、いくつかの魅力的な改善をもたらしました。 浮力によるLinkerdv1の積極的な開発はずっと前に中止されたため、この記事の残りの部分での「Linkerd」の言及はv2を指します。

完全にオープンソースのLinkerdは、データプレーンについてはRustで記述された自家製プロキシに依存し、コントロールプレーンについてはGoで記述されたソースコードに依存しています。

接続性

Linkerdプロキシには再試行機能とタイムアウト機能がありますが、この記事の執筆時点では、回路の切断やインジェクションの遅延はありません。 Ingressのサポートは広範囲にわたっています。 Linkerdは、次の入力コントローラーとの統合を誇っています。

• Traefik
• Nginx
• GCE
• 大使
• Gloo
• 輪郭
• コング

Linkerdのサービスプロファイルは、強化されたルーティング機能を提供し、ユーザーメトリック、再試行チューニング、およびタイムアウト設定をすべてルートごとに提供します。 負荷分散に関しては、Linkerdは自動プロキシインジェクション、独自のダッシュボード、およびGrafanaのネイティブサポートを提供します。

安全

LinkerdのmTLSサポートは、毎日の自動キーローテーションと同様に、初期設定が自動であるという点で便利です。

可観測性

箱から出して、Linkerdの統計とルートはCLIを介して監視できます。 GUI側では、オプションには、事前に作成されたGrafanaダッシュボードとネイティブのLinkerdダッシュボードが含まれます。

LinkerdはPrometheusのインスタンスにプラグインできます。

トレースは、OpenTelemetry（以前のOpenCensus）をコレクターとして使用し、Jaegerがトレース自体を実行するアドオンを介して有効にできます。

インストール

Linkerdのインストールは、サイドカープロキシを挿入することで実行されます。これは、Kubernetesのリソースにアノテーションを追加することで実行されます。 これを行うには2つの方法があります。

1. ヘルムチャートを使用する。 （多くの場合、HelmはKubernetesリソースの主要な構成およびテンプレートマネージャーです。）
2. Linkerd CLIをインストールし、それを使用してLinkerdをクラスターにインストールします。

2番目の方法は、インストールスクリプトをダウンロードして実行することから始まります。

 curl -sL https://run.linkerd.io/install | sh

そこから、Linkerd CLIツールlinkerdは、Linkerdの残りの部分をインストールし、アプリクラスターおよびコントロールプレーンと対話するのに役立つ便利なツールキットを提供します。

linkerd check --preは、Linkerdのインストールに必要なすべての予備チェックを実行し、潜在的なLinkerdのインストールがまだ機能しない理由に関する明確で正確なログを提供します。 --preを指定しない場合、このコマンドはインストール後のデバッグに使用できます。

次のステップは、以下を実行してLinkerdをクラスターにインストールすることです。

 linkerd install | kubectl apply -f -

Linkerdは、非常に小さなリソースフットプリントで多くの異なるコンポーネントをインストールします。 したがって、それら自体にマイクロサービスアプローチがあります。

• リンカードコントローラー。CLIとダッシュボードが相互作用するパブリックAPIを提供します。
• リンカードID。mTLSを実装するための認証局を提供します。
• ポッドの構成を変更することでプロキシの注入を処理するlinkerd-proxy-injector
• 展開とポッド、および内部Linkerdコンポーネントの監視を可能にするダッシュボードとして機能するlinkerd-web

Linkerdは、ほとんどの構成をCustomResourceDefinitions （CRD）に基づいています。 これは、Kubernetesアドオンソフトウェアを開発する際のベストプラクティスと見なされます。これは、Kubernetesクラスターにプラグインを永続的にインストールするようなものです。

分散トレースを追加するには（いくつかの一般的な神話のために、Linkerdユーザーが実際に求めているものである場合とそうでない場合があります）、linkerd-collectorとlinkerd-jaegerを使用した別の手順が必要です。 そのためには、最初に構成ファイルを作成します。

 cat >> config.yaml << EOF tracing: enabled: true EOF

トレースを有効にするには、次のコマンドを実行します。

 linkerd upgrade --config config.yaml | kubectl apply -f -

サイドカープロキシに基づく他のサービスメッシュと同様に、トレースを有効にするには、アプリケーションコードを変更する必要があります。 これの大部分は、トレースヘッダーを伝播するためのクライアントライブラリを追加するだけです。 次に、各サービスに含める必要があります。

Linkerdのトラフィック分割機能は、Service Mesh Interface（SMI）準拠のAPIを介して公開されており、すでにカナリアリリースが可能です。 ただし、それらとトラフィック管理を自動化するには、Flaggerなどの外部ツールも必要になります。

Flaggerは、Linkerdが「ゴールデン」メトリックと呼ぶものを評価するプログレッシブ配信ツールです。「リクエスト量、成功率、およびレイテンシーの分布」です。 （元々、Google SREはゴールデンシグナルという用語を使用し、4番目の信号である飽和を含んでいましたが、CPUやメモリの使用量など、直接アクセスできないメトリックが必要になるため、Linkerdはそれをカバーしていません。）フラガーはトラフィックを分割しながらこれらを追跡しますフィードバックループを使用します。 したがって、自動化されたメトリック対応のカナリアリリースを実装できます。

インストールプロセスを詳しく調べた後、Linkerdサービスメッシュを操作可能にし、一般的に必要な機能を活用するには、少なくとも12のサービスを実行するのは簡単であることが明らかになりました。 とは言うものの、それらの多くは、他のサービスメッシュよりもインストール時にLinkerdによって提供されます。

Linkerdサービスメッシュの概要

利点：

Linkerdは、内部ツールであるFinagleに取り組み、後にLinkerd v1から学んだ2人の元Twitterエンジニアである、その作成者の経験から恩恵を受けています。 最初のサービスメッシュの1つとして、Linkerdには活発なコミュニティ（Slackには5,000人以上のユーザーがいて、アクティブなメーリングリストとDiscordサーバーがあります）と豊富なドキュメントとチュートリアルがあります。 Linkerdは、ノードストローム、eBay、Strava、Expedia、Subspaceなどの大企業に採用されていることからもわかるように、バージョン2.9のリリースで成熟しています。 Linkerdは、Buoyantによる有料のエンタープライズグレードのサポートを利用できます。

欠点：

Linkerdサービスメッシュを最大限に活用するには、かなり強力な学習曲線があります。 Linkerdは、Kubernetesコンテナ内でのみサポートされます（つまり、VMベースの「ユニバーサル」モードはありません）。 LinkerdサイドカープロキシはEnvoyではありません。 これにより、Buoyantは適切と思われるように調整できますが、Envoyが提供する固有の拡張性は失われます。 また、Linkerdが回路遮断、遅延注入、およびレート制限のサポートを欠いていることも意味します。 Linkerdコントロールプレーンを簡単に制御するための特定のAPIは公開されていません。 （ただし、gRPC APIバインディングを見つけることができます。）

Linkerdは、v1以降、使いやすさとインストールのしやすさにおいて大きな進歩を遂げました。 公式に公開されているAPIがないことは、注目に値する省略です。 しかし、他の点ではよく考えられたドキュメントのおかげで、Linkerdのすぐに使える機能を簡単にテストできます。

領事コネクトレビュー

次のサービスメッシュ候補であるConsulConnectは、ユニークなハイブリッドです。 HashiCorpの領事は、分散アーキテクチャ用のKey-Valueストレージでよく知られており、長年にわたって使用されてきました。 Consulがサービスツールの完全なスイートに進化した後、HashiCorpはその上にサービスメッシュを構築することを決定しました：ConsulConnect。

そのハイブリッドの性質について正確に言うと：

Consul Connectデータプレーンは、C++で記述されたEnvoyに基づいています。 ConsulConnectのコントロールプレーンはGoで記述されています。 これは、Key-ValueストアであるConsulKVが支援する部分です。

他のほとんどのサービスメッシュと同様に、Consul Connectは、アプリケーションポッド内にサイドカープロキシを挿入することで機能します。 アーキテクチャに関しては、ConsulConnectはエージェントとサーバーに基づいています。 箱から出して、Consul Connectは、ポッドの非親和性を指定するStatefulSetとして3つまたは5つのサーバーを使用する高可用性（HA）を持つことを目的としています。 ポッドの非アフィニティとは、分散ソフトウェアシステムのポッドが同じノード（サーバー）に配置されないようにすることで、単一のノードに障害が発生した場合の可用性を保証することです。

接続性

ConsulConnectをこの分野で際立たせるものはあまりありません。 これは、サービスメッシュが行うこと（かなりの量）に加えて、パスベースのルーティング、トラフィックシフト、およびロードバランシングのためのレイヤー7機能を提供します。

安全

他のサービスメッシュと同様に、ConsulConnectは基本的なmTLS機能を提供します。 また、ConsulとVault（これもHashiCorpによる）間のネイティブ統合を特徴としており、クラスター内の証明書を管理および署名するためのCAプロバイダーとして使用できます。

可観測性

Consul Connectは、Envoyをサイドカープロキシとして組み込んでレイヤー7機能を提供することにより、最も一般的な可観測性アプローチを採用しています。 Consul ConnectのUIを構成してメトリックをフェッチするには、組み込みの構成ファイルを変更し、Prometheusなどのメトリックプロバイダーを有効にする必要があります。 一部のGrafanaダッシュボードを構成して、関連するサービス固有のメトリックを表示することもできます。

インストール

Consul Connectは、Helmチャートを使用してKubernetesクラスターにインストールされます。

 helm repo add hashicorp https://helm.releases.hashicorp.com

UIを有効にする場合、またはConsul Connectモジュールにサイドカープロキシを挿入させる場合は、デフォルトのvalues.yamlを変更する必要があります。

 helm install -f consul-values.yml hashicorp hashicorp/consul

メンバーに相談してさまざまなノードを確認するには、Consulは、コンテナーの1つconsul exec使用することをお勧めします。

Consulが提供するすぐに使用できるWebUIを提供するには、 kubectl port-forward service/hashicorp-consul-ui 18500:80を実行します。

ConsulConnectサービスメッシュの概要

利点：

• 領事はHashiCorpの支援を受けています。 フリーミアム製品として、エンタープライズレベルのサポートを提供する機能が追加されたエンタープライズバージョンもあります。 開発チームの経験という点では、領事は市場で最も古いツールの1つです。
• Consulには強固なエンタープライズコミュニティがあり、50,000ノードのインフラストラクチャで実行されることが知られています。 また、2014年から発売されており、市場に比べて成熟した製品となっています。
• Consul Connectは、ネイティブサポートのおかげで、VM内で適切に実行されます。
• Consul Connectを使用すると、一流のテクノロジー企業でのサービスメッシュ前の実装と同じくらい深いアプリ統合を実現できます。 これは、完全に文書化されたライブラリレベルのAPIの公開のおかげです。

欠点：

• Consul Connectは、他のサービスメッシュよりも学習曲線が急であり、視覚的なダッシュボードとメトリックを実行するには、より多くの調整が必要になります。
• HashiCorpのドキュメントは単純ではなく、ユーザーはそれを正しく構成するために掘り下げて実験する必要があります。
• トラフィック管理のドキュメントは見つけるのが難しく、ほとんどがEnvoyのドキュメントへのリンクで構成されています。このドキュメントには、特にConsulConnectのトラフィック管理に関する詳細は記載されていません。
• ConsulConnectのSMIインターフェースはまだ実験段階です。

Consul Connectは、エンタープライズグレードの製品をお探しの方に最適です。 HashiCorpはその製品の品質で知られており、ConsulConnectも例外ではありません。 ここでは、他のサービスメッシュと比較して、2つの強力な利点を確認できます。エンタープライズバージョンを使用した会社からの強力なサポートと、あらゆる種類のアーキテクチャ（Kubernetesだけでなく）に対応したツールです。

Istioレビュー

2017年5月、Google、IBM、LyftはIstioを発表しました。 Istioがサービスメッシュツールの競争に参入したとき、それは技術分野で非常に良い露出を得ました。 その作者は、バージョン1.9までずっとユーザーのフィードバックに基づいて機能を追加しました。

Istioは、自動負荷分散、フォールトインジェクションなど、当時の競合他社に比べて重要な新機能を約束しました。 これはコミュニティから多大な注目を集めましたが、以下で詳しく説明するように、Istioの使用は簡単ではありません。Istioは、本番環境に移行するのが特に複雑であると認識されています。

歴史的に、Istioプロジェクトは、ソースコードの変更に関して頻繁にバウンスしてきました。 コントロールプレーンにマイクロサービスアーキテクチャを採用すると、Istioは（バージョン1.5以降）モノリシックアーキテクチャに戻りました。 集中化に戻るためのIstioの論理的根拠は、マイクロサービスはオペレーターが監視するのが難しく、コードベースが冗長すぎ、プロジェクトが組織的に成熟したため、多くの小さなチームがサイロで作業する必要がなくなったためです。

ただし、その過程で、IstioはGitHubの未解決の問題の数が最も多いことで有名になりました。 この記事を書いている時点で、数は約800の問題が開いており、約12,000の問題が閉じています。 問題の数は誤解を招く可能性がありますが、この場合、以前に壊れていた機能や制御不能なリソースの使用に関して、意味のある改善を示しています。

接続性

Istioは、Consul ConnectやLinkerdと比較して、トラフィック管理に非常に優れています。 これは、リクエストルーティング、フォールトインジェクション、トラフィックシフト、リクエストタイムアウト、回線遮断、サービスメッシュへの入出力トラフィックの制御などのサブ機能の広範な提供のおかげです。 仮想サービスと宛先ルールの概念により、トラフィック管理の観点から非常に完全になります。

ただし、これらすべての可能性には、学習曲線に加えて、Kubernetesクラスター上のこれらの新しいリソースの管理が伴います。

安全

Istioは、認証と承認という2つの主要な軸を備えた、セキュリティ関連の包括的なツールセットを誇っています。 Istioは、ワークロード固有、名前空間全体、またはメッシュ全体など、さまざまなスコープにさまざまなレベルのポリシーを適用できます。 このようなセキュリティリソースはすべて、 AuthorizationPolicyやPeerAuthenticationなどのIstioCRDを介して管理されます。

標準のmTLSサポートに加えて、Istioは、暗号化されていないトラフィックを受け入れるか拒否するように構成することもできます。

可観測性

ここで、Istioは箱から出してかなり高度であり、サービスメッシュへの確かな洞察を提供するいくつかのタイプのテレメトリを備えています。 メトリックは、4つのゴールデンシグナル（遅延、トラフィック、エラー、およびある程度の飽和）に基づいています。

特に、Istioはコントロールプレーン自体のメトリックを提供します。 また、分散トレースとアクセスログを提供し、Jaeger、Lightstep、およびZipkinとの明示的な互換性を誇り、トレースを可能にします。

ネイティブダッシュボードはありませんが、Kiali管理コンソールは公式にサポートされています。

インストール

インストールは、公式の手順に従うのと同じくらい簡単です。 Istioもベータ機能としてGKEにネイティブに統合されていますが、GKEは最新のモノリスバージョンではなく、古いマイクロサービスバージョンであるIstio1.4.Xを使用しています。

ネイティブインストールは、最新リリースのダウンロードから始まります。

 curl -L https://istio.io/downloadIstio | sh -

新しく作成されたistio-*フォルダーにcdした後、それをパスに追加して、 istioctlユーティリティツールを使用できるようにします。

 export PATH=$PWD/bin:$PATH

そこから、istioctlを介してistioctlをKubernetesクラスターにインストールできます。

 istioctl install

これにより、 defaultのプロファイルでIstioがインストールされます。 istioctlプロファイルを使用すると、さまざまなインストール構成を作成し、必要に応じてそれらを切り替えることができます。 ただし、単一プロファイルのシナリオでも、一部のCRDを変更することで、Istioのインストールを大幅にカスタマイズできます。

トラフィック管理を確実に実施するには、少なくともVirtualService 、 DestinationRule 、 Gatewayなどのいくつかの種類のCRDを管理する必要があるため、Istioリソースの管理は困難になります。

• VirtualServiceリソースは、サービスと、要求に適用されるさまざまなルーティングルールを宣言する構成です。
• DestinationRuleリソースは、ターゲット固有のトラフィックポリシーをグループ化して適用するために使用されます。
• Gatewayリソースは、インバウンドおよびアウトバウンドのサービスメッシュトラフィックを管理するために作成されます（つまり、追加のEnvoyプロキシですが、サイドカーとしてではなくエッジで実行されます）。

セマンティックの詳細はこのレビューの範囲を超えていますが、これらのそれぞれが連携して機能することを示す簡単な例を見てみましょう。 productsと呼ばれるサービスを備えたeコマースWebサイトがあるとします。 VirtualServiceは次のようになります。

 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: products-route namespace: ecommerce spec: hosts: - products # interpreted as products.ecommerce.svc.cluster.local http: - match: - uri: prefix: "/listv1" - uri: prefix: "/catalog" rewrite: uri: "/listproducts" route: - destination: host: products # interpreted as products.ecommerce.svc.cluster.local subset: v2 - route: - destination: host: products # interpreted asproducts.ecommerce.svc.cluster.local subset: v1

対応するDestinationRuleは次のようになります。

 apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: products spec: host: products trafficPolicy: loadBalancer: simple: RANDOM # or LEAST_CONN or ROUND_ROBIN subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 - name: v3 labels: version: v3

最後に、私たちのGateway ：

 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: cert-manager-gateway namespace: istio-system spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*"

これらの3つのファイルを配置すると、Istioインストールで基本的なトラフィックを処理できるようになります。

Istioサービスメッシュの概要

利点：

• さまざまなサービスメッシュの中で、Istioはこの記事の執筆時点で最大のオンラインコミュニティを持つものです。 スタックオーバーフローの結果は、主要な競合他社の10倍を超えており、Web上で最も話題になっているサービスメッシュです。 そのGitHubの貢献者も同様に、Linkerdの貢献者を1桁超えています。
• IstioはKubernetesモードとVMモードの両方をサポートしています。 後者はバージョン1.9の時点でベータ版です。

欠点：

• Istioは、2つの意味で無料ではありません。
  • ドキュメントを読み、セットアップし、適切に機能させ、保守するために必要な時間の点で、その要件は高くなっています。 インフラストラクチャのサイズとサービスの数に応じて、Istioが完全に機能し、本番環境に統合されるまでには、数週間から数か月のフルタイムの作業が必要になります。
  • また、かなりの量のリソースオーバーヘッドが追加されます。Envoyコンテナの場合、1,000リクエスト/秒（RPS）あたり350ミリコア（mCPU）かかります。 コントロールプレーン自体でさえ、リソースを消費する可能性があります。 （以前は、リソースの使用量を予測するのは困難でしたが、ある程度の努力の結果、 istiodは1つのvCPUと1.5 GBのメモリを使用することで安定しました。）
• Linkerdとは異なり、ネイティブの管理ダッシュボードはありません。
• Istioでは、独自の入力ゲートウェイを使用する必要があります。
• IstioコントロールプレーンはKubernetesコンテナ内でのみサポートされます（つまり、Istioのデータプレーンとは異なり、VMモードはありません）。

Istioは、彼らが直面している課題に対処するためのオープンソースプロジェクトを作成するために集まったハイテク巨人の素晴らしい例です。 Istioプロジェクト全体がそれ自体を構築し（マイクロサービスからモノリスへのアーキテクチャの移行を思い出して）、その多くの初期の問題を解決するのに少し時間がかかりました。 今日、Istioは、サービスメッシュに期待されるすべてのことを完全に実行しており、大幅に拡張できます。 しかし、これらすべての可能性には、実稼働環境での使用をサポートするための知識、作業時間、およびコンピューティングリソースに関する厳しい要件が伴います。

熊クイックレビュー

Kongによって作成され、その後オープンソース化されたKumaは、2020年後半に1.0に達しました。ある程度、最初のサービスメッシュがかなり重く、操作が難しいことに対応して作成されました。

その機能リストは、それが非常にモジュール化されていることを示唆しています。 Kumaの背後にある考え方は、Kubernetesまたは他のインフラストラクチャですでに実行されているアプリケーションとの統合に向けることです。

• 交通管理の分野では、Kumaはフォールトインジェクションや回路遮断などの一般的なサービスメッシュ機能を提供しています。
• サービス間mTLS暗号化を超えて、データプレーンとコントロールプレーン間の交換は、データプレーンプロキシトークンを介してKumaで保護されます。
• 可観測性は、メトリック、トレース、およびロギングに関するさまざまなトラフィックポリシーを介してKumaで定義されます。
• コントロールプレーンのポート5653で実行される独自のDNSリゾルバーのおかげで、Kumaを介してサービス検出を利用できます。
• Kumaはマルチメッシュ機能に重点を置いています。複数のKubernetesクラスターまたはVM環境を、マルチゾーンデプロイメントタイプの共通のKumaクラスターに簡単に組み合わせることができます。
• Kumaは、既存のKongユーザー向けにKongGatewayと簡単に統合できます。

Kumaのユニバーサル（非Kubernetes）バージョンでは、依存関係としてPostgreSQLが必要であり、KongのCTOは特にSMIのサポートに反対しています。 しかし、Kumaは最初からマルチクラウドとマルチクラスターの展開というアイデアで開発されており、そのダッシュボードにはこれが反映されています。

Kumaはサービスメッシュの分野ではまだ若く、これまでのところ本番環境での使用例はほとんどありませんが、興味深い有望な候補です。

Traefikメッシュクイックレビュー

もともとMaeshと名付けられたTraefikMesh（Traefik Labsによる）は、サービスメッシュツーリングレースのもう1つの新参者です。 プロジェクトの使命は、使いやすく構成しやすいようにすることで、サービスメッシュを民主化することです。 よく考えられたTraefikProxyでの開発者の経験により、開発者はそれを達成するための最高の位置に置かれました。

• Traefik Meshのトラフィック管理機能には、回線遮断とレート制限が含まれます。
• 可観測性の観点から、Traefik Meshは、ネイティブのOpenTracingサポートとすぐに使用できるメトリック（標準のインストールには自動的にPrometheusとGrafanaが含まれます）を備えているため、セットアップ時間を節約できます。
• セキュリティのために（mTLSを除く）、仕様はSMIに準拠しており、Traefik Meshを使用すると、アクセス制御を通じてトラフィックのアクセス許可を微調整できます。

Traefik Meshでは、CoreDNSをクラスターにインストールする必要があります。 （Azureは1.12以降デフォルトでCoreDNSを使用していますが、この記事の執筆時点では、GKEはデフォルトでkube-dnsになっています。つまり、この場合、かなりの追加手順が必要になります。）マルチクラスター機能もありません。

とは言うものの、Traefik Meshは、サイドカーインジェクションを使用しないという点で、サービスメッシュの比較においてユニークです。 代わりに、すべてのノードにDaemonSetとしてデプロイされ、サービス間のプロキシとして機能するため、非侵襲的です。 全体として、TraefikMeshはインストールと使用が簡単です。

AWSアプリメッシュクイックレビュー

クラウドプロバイダーの世界では、AWSはKubernetes（または特にEKS）だけでなく他のサービスにもプラグイン可能なネイティブサービスメッシュを実装した最初のプロバイダーです。 AWS App Meshは2018年11月にリリースされ、それ以来AWSはそれを繰り返しています。 AWS App Meshの主な利点は、既存のAWSエコシステムと市場での地位です。 AWS全体の背後にある大きなコミュニティは、引き続きその使用法と使いやすさを推進します。

• AWS App Meshのトラフィック管理には、一般的な機能に加えて回路遮断が含まれています。
• AWS App MeshはAWSによってホストされているため、フルマネージドサービスです。つまり、リソースの使用状況やコントロールプレーンの可用性について心配する必要はありません。
• Observability in AWS App Mesh can be done through Prometheus or AWS X-Ray.

The project is not open source, doesn't support SMI, and there's not much info online about HA standards for the control plane. AWS App Mesh is more complex to set up than other Kubernetes-native service meshes and has very little community online (24 answers on Stack Overflow, 400 stars on GitHub) but that's because users are meant to benefit from AWS support.

AWS App Mesh has native integration with AWS, starting with EKS and extending to other AWS services like ECS (Fargate) and EC2. Unlike Traefik Mesh, it has multicluster support. Plus, like most service meshes, it's based on injecting Envoy, the battle-tested sidecar proxy.

Kubernetes Service Mesh Comparison Tables

The six Kubernetes service mesh options presented here have a few things in common:

• Protocol support : They all work with HTTP, HTTP/2, gRPC, TCP, and WebSockets.
• They all have basic security in the form of mTLS between proxies by default.
• Service meshes, by design, provide some form of load balancing .
• These six, at least, also include a request retrying option among their traffic management features.
• Lastly, service discovery is a core feature of any service mesh.

But there are certainly differences worth highlighting when it comes to service mesh infrastructure, traffic management, observability, deployment, and other aspects.

インフラストラクチャー

交通管理

可観測性

* OpenCensus and OpenTracing merged into OpenTelemetry in 2019, but you might find Linkerd articles referring to OpenCensus, as well as Istio and Traefik Mesh articles referring to OpenTracing.

展開

Other Service Mesh Considerations

Should We Use a Kubernetes Service Mesh?

Now that we have seen what service meshes are, how they work, and the multitude of differences between them, we can ask: Do we need a service mesh?

That's the big question for SREs and cloud engineers these past few years. Indeed, microservices bring operational challenges in network communication that a service mesh can solve. But service meshes, for the most part, bring their own challenges when it comes to installation and operation.

One problem we can see emerging in many projects is that with service meshes, there is a gap between the proof-of-concept stage and the production stage. That is, it's unfortunately rare for companies to achieve staging environments that are identical to production in every aspect; with service meshes involving crucial infrastructure, scale- and edge-related effects can bring deployment surprises.

Service meshes are still under heavy development and improvement. This could actually be attractive for teams with high deployment velocities—those who have mastered “the art of staying state-of-the-art” and can closely follow the development cycle of cloud-native tools.

For others, though, the pace of service mesh evolution could be more of a pitfall. It would be easy enough to set up a service mesh but then forget about the need to maintain it. Security patches may go unapplied or, even if remembered, may carry with them unplanned issues in the form of deprecated features or a modified set of dependencies.

There's also a notable cost in terms of manpower to set up a service mesh in production. It would be a sensible goal for any team to evaluate this and understand if the benefits from a service mesh would outweigh the initial setup time. Service meshes are hard, no matter what the “easy” demo installations show.

In short, service meshes can solve some of the problems typical to projects deployed at scale but may introduce others, so be prepared to invest time and energy. In a hypothetical infrastructure involving 25 microservices and load of five queries per second, I would recommend having at least one person (preferably two) dedicated for at least a month to preparing a proof of concept and validating key aspects before thinking about running it in production. Once it's set up, anticipate the need for frequent upgrades—they will impact a core component of your infrastructure, namely network communications.

Kubernetes Service Meshes: A (Complex) Evolution in Scalable App Architecture

We've seen what service meshes are: a suite of tooling to answer new challenges introduced by microservices architecture. Through traffic management, observability, service discovery, and enhanced security, service meshes can reveal deep insights into app infrastructure.

There are multiple actors on the market, sometimes promoted by GAFAM et al., that have in some cases open-sourced or promoted their own internal tooling. Despite two different implementation types, service meshes will always have a control plane—the brain of the system—and a data plane, made of proxies that will intercept the requests of your application.

Reviewing the three biggest service meshes (Linkerd, Consul Connect, and Istio) we have seen the different strategies they've chosen to implement and the advantages they bring. Linkerd, being the oldest service mesh on the market, benefits from its creators' experience at Twitter. HashiCorp, for its part, offers the enterprise-ready Consul Connect, backed by a high level of expertise and support. Istio, which initially garnered ample attention online, has evolved into a mature project, delivering a feature-complete platform in the end.

But these actors are far from being the only ones, and some less-talked-about service meshes have emerged: Kuma, Traefik Mesh, and AWS App Mesh, among others. Kuma, from Kong, was created with the idea of making the service mesh idea “simple” and pluggable into any system, not just Kubernetes. Traefik Mesh benefited from experience with the preexisting Traefik Proxy and made the rare decision to eschew sidecar proxies. Last but not least, AWS decided to develop its own version of the service mesh, but one that relies on the dependable Envoy sidecar proxy.

In practice, service meshes are still hard to implement. Although service mesh benefits are compelling, their impact, critically, cuts both ways: Failure of a service mesh could render your microservices unable to communicate with each other, possibly bringing down your entire stack. A notorious example of this: Incompatibility between a Linkerd version and a Kubernetes version created a complete production outage at Monzo, an online bank.

Nonetheless, the whole industry is structuring itself around Kubernetes and initiatives like the Microsoft-spearheaded SMI, a standard interface for service meshes on Kubernetes. Among numerous other projects, the Cloud Native Computing Foundation (CNCF) has the Envoy-based Open Service Mesh (OSM) initiative, which was also originally introduced by Microsoft. The service mesh ecosystem remains abuzz, and I predict a champion emerging in the coming years, the same way Kubernetes became the de facto container orchestration tool.