サービスメッシュのIstio、バージョン1.3がリリース：Mixerを使わないテレメトリなど

Istioプロジェクトは2019年9月12日（米国時間）、Istio 1.3のリリースを発表した。「Istioチームは数リリースごとに、ユーザビリティ、API、全般的なシステムパフォーマンスに関する劇的な改善を提供している。Istio 1.3はこうしたリリースの一つだ」と表現している。

[三木泉，＠IT]

印刷

髫穂ｹ晢ｽ�Post

Shareシェア

はてなブックマーク

SharePocket Button

　Istioプロジェクトは2019年9月12日（米国時間）、Istio 1.3のリリースを発表した。発表のブログポストでは、「Istioチームは数リリースごとに、ユーザビリティ、API、全般的なシステムパフォーマンスに関する劇的な改善を提供している。Istio 1.3はこうしたリリースの一つだ」と表現している。

　Istio 1.3のテーマは、新規ユーザーにとっての使いやすさ、問題解決のしやすさなどに関するユーザーエクスペリエンスの向上だという。主なポイントは次の通り。

Mixerを使わないテレメトリ（試験実装）

　Istioでは、コントロールプレーン側のポリシー／テレメトリ制御コンポーネントMixerが実行してきた機能を、Envoyプロキシに（Envoyフィルタとして）移行する取り組み（「MixerV2」とも呼ばれる）が進められている。その一環として、今回のリリースでは試験実装として、プロキシの機能拡張により、Mixerのistio-telemetryサービスを経由することなく、HTTPメトリックスをPrometeusに直接送信できるようになった。

　「もし、HTTPサービスのテレメトリだけを気にしているのであれば、この機能拡張はぴったりだ」という。

　これによるパフォーマンス上の影響を、同プロジェクトは次のように説明している。

• istio-telemetryを無効化することで、メッシュトラフィック1000rpsごとに0.5vCPUを節約できる。これにより、Istioの標準的メトリックス収集時に消費するCPUリソースを半減できる
• 新しいフィルタがIstio-proxyで消費するCPUリソースは、従来のMixerフィルタと比較し、10％少ない
• この機能を使うと、P90（直前の 10 秒間に応答が返るのが最も遅かったリクエストの 10% の平均レイテンシー）の遅延は1000rps当たり5ms増加する。これを半減することを目標としている

　Istioプロジェクトでは今後、mutual TLSを有効化した際のTCPメトリックスについても、同様に移行する考えだという。

インテリジェントなプロトコル検出（試験実装）

　Istioのルーティング機能を活用するために、サービスポートは同ツール特有の名前付け規則で指定しなければならない。このルールに従わずにポートをメッシュに追加すると、問題が発生する可能性がある。1.3以降では、外向け（アウトバウンド）のトラフィックでIstioのルールに従った名前付けがなされていない場合、自動的にHTTPあるいはTCPとして検出される。今後のリリースでは内向け（インバウンド）トラフィックの自動プロトコル検出にも対応の予定。

containerPort宣言が不要に

　従来は、トランポリントラフィックに対するセキュリティ対策として、ポッドが各コンテナのKubernetes containerPortを明示的に宣言しなければならなかった。 Istio 1.3は、containerPort宣言を必要とせずに、ワークロードインスタンスへのポート上のすべてのインバウンドトラフィックを処理する安全で簡単な方法を提供する。また、ワークロードインスタンスが自身にトラフィックを送信する際、IPテーブルルールで発生し得る無限ループを完全に排除した。

生成されたEnvoy構成のカスタマイズ

　EnvoyFilter APIを拡張した。これにより、ユーザーがIstio Networking APIではカバーされないEnvoyの高度な機能を使用できるようになった。具体的には、次の点を完全にカスタマイズできるという。

• HTTP / TCPリスナーと、LDSによって返されるフィルターチェーン
• RDSによって返されるEnvoy HTTPルート構成
• CDSによって返されるクラスターのセット

　「Kubernetesとの連携で多数のEnvoyプロキシを効率的に処理しながら、Envoy構成をカスタマイズして特定のインフラ要件を満たすことができる」という。