なぜ Istio を選ぶのか？
Istio は、2017 年の立ち上げ時にサイドカーベースのサービスメッシュという概念を先駆的に導入しました。このプロジェクトには、ゼロトラストネットワーキングのための標準ベースの相互 TLS、スマートトラフィックルーティング、およびメトリクス、ログ、トレーシングによる可観測性など、サービスメッシュを定義する機能が最初から含まれていました。
それ以来、このプロジェクトは、マルチクラスタおよびマルチネットワークトポロジ、WebAssembly による拡張性、Kubernetes Gateway API の開発、およびアンビエントモードによるアプリケーション開発者からのメッシュインフラストラクチャの移行など、メッシュ分野の進歩を推進してきました。
Istio をサービスメッシュとして使用すべき理由をいくつかご紹介します。
シンプルで強力
Kubernetes には数百の機能と数十の API がありますが、1 つのコマンドだけで使い始めることができます。Istio も同じように構築しました。段階的な開示により、少数の API を使用でき、必要に応じてより強力なノブのみを回すことができます。他の「シンプルな」サービスメッシュは、Istio が初日から備えていた機能セットに追いつくのに数年を費やしました。
機能があって必要ないほうが、必要になったときになかったときよりも良いのです！
Envoy プロキシ
当初から、Istio は、Lyft が最初に構築した高性能サービスプロキシであるEnvoy プロキシを基盤としています。Istio は Envoy を最初に採用したプロジェクトであり、Istio チームが最初の外部コミッターでした。Envoy はその後、Google Cloud を支えるロードバランサーとなり、ほぼすべての他のサービスメッシュプラットフォームのプロキシになりました。
Istio は、Istio チームが Envoy で開発した WebAssembly を使用した世界クラスの拡張性など、Envoy のすべてのパワーと柔軟性を継承しています。
コミュニティ
Istio は真のコミュニティプロジェクトです。2023 年には、10 社の企業が Istio にそれぞれ 1,000 件以上の貢献を行っており、単一企業が 25% を超えることはありませんでした。（数値はこちらをご覧ください）。
他のサービスメッシュプロジェクトには、Istio ほど業界からの幅広いサポートを受けているものはありません。
パッケージ
私たちは、すべてのリリースで、安定したバイナリリリースをすべての人に提供し、継続的に提供することを約束します。最新リリースと以前の複数のリリースに対して、無料で定期的なセキュリティパッチを公開しています。多くのベンダーが古いバージョンをサポートしますが、ベンダーを利用することが、安定したオープンソースプロジェクトで安全を確保するための要件であるべきではないと考えています。
検討された代替案
優れた設計ドキュメントには、検討され、最終的に却下された代替案に関するセクションが含まれています。
なぜ “eBPF を使用しない” のか？
私たちは、適切な場合にはそうしています！Istio は、eBPF を使用して、ポッドからプロキシにトラフィックをルーティングするように構成できます。これにより、iptablesを使用する場合と比較して、わずかなパフォーマンス向上が見られます。
なぜすべてに使用しないのでしょうか？誰もそうしません。なぜなら、実際には誰もできないからです。
eBPF は、Linux カーネル内で実行される仮想マシンです。これは、単純な L3 トラフィックルーティングやアプリケーションの監視などの、カーネルの動作を不安定にしないために、限られた計算量で完了することが保証された機能向けに設計されました。Envoy に見られるような、長時間実行される複雑な機能向けには設計されていません。それが、オペレーティングシステムにユーザー空間がある理由です！eBPF のメンテナーは、最終的には Envoy ほど複雑なプログラムの実行をサポートするように拡張できると理論付けていますが、これは科学プロジェクトであり、現実世界での実用性は低いでしょう。
「eBPF を使用する」と主張する他のメッシュは、実際には機能の多くにノードごとの Envoy プロキシ、またはその他のユーザー空間ツールを使用しています。
なぜノードごとのプロキシを使用しないのか？
Envoy は本質的にマルチテナントではありません。その結果、共有インスタンス内で、複数の制約のないテナントからの L7 トラフィックに関する複雑な処理ルールを混在させることには、大きなセキュリティと安定性の懸念があります。Kubernetes はデフォルトで、任意のノード上の任意の名前空間からポッドをスケジュールできるため、ノードは適切なテナンシー境界ではありません。L7 処理は L4 よりもはるかにコストがかかるため、予算編成とコスト配分も大きな問題です。
アンビエントモードでは、Linux カーネルのように、ztunnel プロキシを L4 処理に厳密に制限します。これにより、脆弱性の表面積が大幅に減少し、共有コンポーネントを安全に運用できます。その後、トラフィックは名前空間ごとに動作する Envoy プロキシに転送されるため、Envoy プロキシがマルチテナントになることはありません。
CNI を持っています。なぜ Istio が必要なのですか？
今日、一部の CNI プラグインは、独自の CNI 実装の上に置かれるアドオンとして、サービスメッシュのような機能を提供し始めています。たとえば、ノード間またはポッド間のトラフィックに独自の暗号化スキームを実装したり、ワークロード ID を実装したり、トラフィックを L7 プロキシにリダイレクトすることにより、ある程度のトランスポートレベルのポリシーをサポートしたりする場合があります。これらのサービスメッシュアドオンは非標準であるため、それらを出荷する CNI の上でのみ機能できます。また、さまざまな機能セットを提供します。たとえば、Wireguard の上に構築されたソリューションは、FIPS に準拠させることができません。
このため、Istio は、実績のある業界標準の暗号化プロトコルを使用して、この機能を透過的かつ効率的に提供するゼロトラストトンネル（ztunnel）コンポーネントを実装しました。ztunnel の詳細はこちら。
Istio は、強力な L7 ポリシー、プラットフォームに依存しないワークロード ID、業界実績のある mTLS プロトコルを使用して、一貫性があり、高度に安全で、効率的で、標準に準拠したサービスメッシュ実装を提供するサービスメッシュとして設計されています。あらゆる環境、あらゆる CNI、または異なる CNI を持つクラスタ間でも。