Istio 1.5リリースは、運用エクスペリエンスの向上を目的として、サービスメッシュのインストールを簡素化するモノリシックな「Istiod」コントロールプレーンバイナリが導入された。このバージョンは、Wasmを使用するプロキシサーバの新しい拡張モデルも導入されており、使いやすさ、セキュリティ、テレメトリ、トラフィック制御が改善されている。
単一のIstiodバイナリへの移行は、デバッグと理解を容易にすることを目的として、可動部分が少なくなることを意味する。Istiodを使用しても、メッシュユーザエクスペリエンスは変わらない。すべてのAPIとランタイム特性は、前のコンポーネントと一致している。Istiodは、事実上、マイクロサービスアーキテクチャモデルの逆転である。
Istio 1.4の構造には、拡張性のための5つのサービスとプラグインで構成されたコントロールプレーンがあった。サイドカープロキシの読み込みは、サイドカーインジェクタサービスによって提供された。Mixerサービスおよびアダプタプラグインによって提供される拡張性および拡張性プラグイン。Pilotサービスによって提供されたサイドカープロキシ構成の生成と提供。Citadelサービスによって提供されたセキュリティ。Galleyサービスによって提供された検証。Istio 1.5は、コントロールプレーンを1つのサービスに再編成し、拡張性を再実装した。Istiodは、プロキシサイドカーの読み込み、メッシュ操作、セキュリティ、検証を提供し、データプレーンは、Envoy WebAssembly (Wasm) プラグインとしてメッシュ内にMixerアダプタを実装するようになった。
Istioは、拡張可能なサービスメッシュとして設計されており、カスタムポリシーとテレメトリのサポートを可能にするMixerプラグインと、データプレーンのカスタマイズを可能にするEnvoy拡張機能を備えている。Istio 1.5では、新しいモデルがWasmを使用して、Istioの拡張性モデルをEnvoyの拡張性モデルと統合する。Wasmを使用すると、開発者はEnvoyプロキシでコードを配布および実行して、テレメトリシステム、ポリシーシステム、制御ルーティング、さらにはメッセージの本文を変換することができる。Istioは、個別のMixerコンポーネントを実行する必要がなくなり、デプロイを簡素化することができるようになる。
Steven Dake氏は、ブログ投稿で、Istioが最初マイクロサービスアーキテクチャを使用して、Istio内のチームの作業方法をサポートしたと説明している。当時、チームはさまざまなスケジュールでサービスの更新とリリースを提供していた。チームはチーム間でAPI契約を使用しており、独立した水平スケーリングが必要だった。Istioのチームとテクノロジーが成熟するにつれて、マイクロサービスアーキテクチャの利点は衰えていった。Istio 1.4の開発が終了すると、Istio環境ワーキンググループは、既存のコンポーネントのモノリスを構成する提案を受け取った。環境ワーキンググループが技術的な議論を主導し、Istiodのコンセプトが生まれた。その後のIstio技術監視委員会の会議中に、環境ワーキンググループはIstiodバイナリの使用を提案した。
もう1つの新しい拡張機能は、istioctlを使用したIstioのコマンドラインインストールである。これは現在、インストールのベータ版である。Kubernetes Operatorを介したインストールの管理はまだアルファ版だが、Istioは新しいIstioOperator APIを使用してインストールを改善し続けている。istioctlには多くの改善点がある。分析できる新しい項目、改善された検証ルール、CIシステムと統合する機能である。istioctl analyseは実験段階を卒業した。
Istioセキュリティも強化された。Auto mTLSのベータリリースにより、mTLSの構成が簡素化および自動化され、Istio 1.4でのAuthorisationポリシーのベータリリースに基づいて、間接参照を削除して単一のCRDに統合することにより、アクセス制御が簡素化された。1.5では、Auto mTLS、AuthenticationPolicy (PeerAuthenticationおよびRequestAuthentication) 、Authorisationを含むすべてのセキュリティポリシーがベータ版になり、SDSが安定した。Authorisationは、オーバーライドできない必須の制御を実施するための拒否セマンティクスをサポートするようになった。
NodeエージェントとIstioエージェントが1つのバイナリに結合された。つまり、PodSecurityPolicyの構成は不要になったということである。証明書をすべてのPodにマウントする必要がなくなり、証明書が変更されたときにEnvoyを再起動する必要がなくなった。証明書はIstiodからすべてのPodに直接配信され、各Podは一意の証明書を受け取る。
Telemetry v2は、(HTTPに加えて) 生のTCP接続のメトリックを報告するようになり、gRPCワークロードのサポートは、テレメトリとログにレスポンスステータスコードを追加することで強化された。Telemetry v2がデフォルトで使用されるようになった。新しいテレメトリシステムは、待ち時間を半分に短縮すると報告されている。90パーセンタイルの待ち時間が7ミリ秒から3.3ミリ秒に短縮された。Mixerの廃止により、CPUの総消費量が50％減少し、1秒あたりの1,000リクエストあたり0.55 vCPUになったと報告されている。
Solo.ioとGoogleはどちらも、Istioからの発表に応えており、Googleの共同作業者のLyftとIBMで構築されたWebAssembly (Wasm) 拡張機能をGoogleはEnvoyに導入している。Solo.ioは、EnvoyとIstioのサポートを含むように、WebAssembly Hubを拡張および改善した。