istiodのご紹介：コントロールプレーンの簡素化
Istiodは、Istioコントロールプレーンのコンポーネントを単一のバイナリに統合します。
マイクロサービスは、サービスを異なるチームにマッピングする場合、または独立したロールアウトとスケーリングの価値がオーケストレーションのコストを上回る場合に最適なパターンです。私たちはIstioを現実世界で運用している顧客やチームと定期的に話し合っていますが、Istioコントロールプレーンではこれらのいずれも当てはまらないことがわかりました。そのため、Istio 1.5ではIstioのパッケージング方法を変更し、コントロールプレーンの機能をistiodという単一のバイナリに統合しました。
Istioコントロールプレーンの歴史
Istioは、GoogleとIBMの両方で長年使用されてきたパターンを実装しており、後に「サービスメッシュ」として知られるようになりました。クライアントプロセスとサーバープロセスをプロキシサーバーとペアリングすることにより、単にホスト間のパケットを移動したり、ワイヤ上のパルスを送信するだけでなく、アプリケーションを認識するデータプレーンとして機能します。
このパターンは、マイクロサービス（粒度の細かい、疎結合のサービスで、軽量プロトコルを介して接続）を理解するのに役立ちます。独自のトランスポートに代わるHTTPやgRPCのような共通のクロスプラットフォームおよびクロス言語標準、および必要なライブラリの広範な存在により、異なるチームが全体アーキテクチャの異なる部分を、最も意味のある言語で記述できます。さらに、各サービスは必要に応じて個別にスケーリングできます。このようなネットワークに対するセキュリティ、可観測性、トラフィック制御を実装したいという願望が、Istioの人気を高めています。
Istioのコントロールプレーンは、それ自体が最新のクラウドネイティブアプリケーションです。そのため、最初からマイクロサービスのセットとして構築されました。サービスディスカバリ（Pilot）、コンフィグレーション（Galley）、証明書生成（Citadel）、拡張性（Mixer）などの個々のIstioコンポーネントはすべて、個別のマイクロサービスとして記述およびデプロイされました。これらのコンポーネントが安全に通信し、可観測性を持つ必要があるため、Istioは自らの成果を活用する機会（比喩的に言えば、「自分のシャンパンを飲む」）を得ました。
複雑さのコスト
優秀なチームは、自身の選択を振り返り、事後的にそれを見直します。一般的に、チームがマイクロサービスとその固有の複雑さを採用すると、トレードオフを正当化するために他の領域の改善を探します。そのレンズを通してIstioコントロールプレーンを見てみましょう。
マイクロサービスは、異なる言語で記述することを可能にします。データプレーン（Envoyプロキシ）はC++で記述されており、この境界はxDS APIに関して明確な分離から恩恵を受けています。しかし、IstioコントロールプレーンのすべてのコンポーネントはGoで記述されています。適切な仕事に適切な言語を選択することができました。プロキシには高性能なC++、その他すべてにはアクセスしやすく、開発のスピードが速い言語です。
マイクロサービスは、異なるチームが個別にサービスを管理することを可能にします。Istioのインストールの大部分では、すべてのコンポーネントは単一のチームまたは個人によってインストールおよび運用されています。Istio内で実行されるコンポーネント化は、それを構築する開発チームの境界に沿って調整されています。これは、Istioコンポーネントが作成者によってマネージドサービスとして提供される場合に理にかなっていますが、実際にはそうではありません！開発チームにとっての生活の簡素化は、桁違いに多いユーザーの使いやすさに大きな影響を与えました。
マイクロサービスは、バージョンを分離し、異なるコンポーネントを異なる時期にリリースすることを可能にします。コントロールプレーンのすべてのコンポーネントは、常に同じバージョンで同時にリリースされてきました。（たとえば）CitadelとPilotの異なるバージョンを実行することは、これまでテストもサポートもされていませんでした。
マイクロサービスは、コンポーネントを個別にスケーリングすることを可能にします。Istio 1.5では、コントロールプレーンのコストは、データプレーンをプログラムするEnvoy xDS APIを提供するという単一の機能によって支配されています。その他のすべての機能は限界費用であり、それらの機能を個別にスケーラブルなマイクロサービスにする価値はほとんどありません。
マイクロサービスは、セキュリティ境界を維持することを可能にします。アプリケーションを異なるマイクロサービスに分割するもう1つの良い理由は、異なるセキュリティロールを持つ場合です。サイドカーインジェクター、Envoyブートストラップ、Citadel、Pilotなど、複数のIstioマイクロサービスは、プロキシ構成を変更するためのほぼ同等の権限を持っています。したがって、これらのサービスのいずれかを悪用すると、ほぼ同等の損害が発生します。Istioをデプロイすると、すべてのコンポーネントはデフォルトで同じKubernetes名前空間にインストールされるため、セキュリティの分離は限定的です。
統合のメリット：istiodのご紹介
マイクロサービスの一般的なメリットの多くがIstioコントロールプレーンに適用されないことを確立したので、それらを単一のバイナリ：istiod（'d'はデーモンを表します）に統合することにしました。
新しいパッケージングのメリットを見てみましょう
インストールが容易になります。必要なKubernetesデプロイメントと関連する構成が少なくなり、Istioの構成オプションとフラグのセットが大幅に削減されます。最も簡単なケースでは、すべての機能が有効になっているIstioコントロールプレーンを、単一のPodを起動するだけで開始できます。
構成が容易になります。今日のIstioには、コントロールプレーンのコンポーネントをオーケストレートするための多くの構成オプションがありますが、これらはもはや必要ありません。また、Istioをデプロイするために、クラスタ全体の
PodSecurityPolicyを変更する必要もなくなります。VMの使用が容易になります。ワークロードをメッシュに追加するには、1つのエージェントと生成された証明書をインストールするだけで済みます。そのエージェントは、単一のサービスのみに接続します。
メンテナンスが容易になります。Istioのインストール、アップグレード、削除に、複雑なバージョンの依存関係と起動順序の処理は不要になりました。たとえば、アップグレードするには、既存のコントロールプレーンと並行して新しいistiodバージョンを起動し、カナリアリリースを行い、その後すべてのトラフィックを新しいバージョンに移行するだけです。
スケーラビリティが容易になります。スケーリングするコンポーネントは1つだけになりました。
デバッグが容易になります。コンポーネントが少なくなると、コンポーネント間の環境デバッグが少なくなります。
起動時間が短縮されます。コンポーネントは、定義された順序で互いの起動を待つ必要がなくなりました。
リソース使用量が減少し、応答性が向上します。コンポーネント間の通信は保証され、gRPCのサイズ制限の影響を受けなくなります。キャッシュを安全に共有できるため、その結果としてリソースフットプリントが減少します。
istiodは、Pilot、Galley、Citadel、およびサイドカーインジェクターが以前実行していた機能を単一のバイナリに統合します。
個別のコンポーネントであるistio-agentは、構成とシークレットをEnvoyプロキシに安全に渡すことで、各サイドカーがメッシュに接続するのに役立ちます。厳密に言えばエージェントはコントロールプレーンの一部ですが、Podごとに実行されます。DaemonSetとして実行されていたノードごとの機能を、そのPodごとのエージェントに統合することで、さらに簡素化しました。
上級者向け情報
Istioコンポーネントを個別に実行したり、特定のコンポーネントを置き換えたい場合もあります。
メッシュ外部の認証局（CA）を使用したいユーザーもいるため、その方法に関するドキュメントを用意しています。別のツールを使用して証明書の調達を行う場合、組み込みのCAの代わりにそれを使用できます。
今後の展望
本質的に、istiodはパッケージングと最適化の変更に過ぎません。これは、個別のコンポーネントと同じコードとAPI契約に基づいて構築されており、包括的なテストスイートによってカバーされています。これにより、Istio 1.5でデフォルトにすることに自信を持っています。サービスは現在istiodと呼ばれています。アップグレードプロセスが完了すると、既存のプロキシにはistio-pilotが表示されます。
istiodへの移行は大きな変更のように見えるかもしれませんが、メッシュを管理および維持する人々にとって大きな改善であり、Istioを使用する際の日常生活には影響を与えません。istiodは、メッシュを構成するために使用されるAPIを一切変更していないため、既存のプロセスはすべてそのままです。
この変更は、すべてのワークロードとアーキテクチャにおいてマイクロサービスが間違いであることを意味するのでしょうか？もちろん違います。マイクロサービスはツールベルト内のツールであり、組織の現実を反映している場合に最も効果を発揮します。代わりに、この変更は、ユーザーからのフィードバックに基づいて変更する意思を示しており、すべてのユーザーにとっての簡素化に継続的に焦点を当てています。マイクロサービスは適切なサイズでなければならず、Istioにとって適切なサイズを見つけたと考えています。
