Istioは設定可能なオープンソースのサービスメッシュ層で、 Kubernetesクラスタ内のコンテナを接続、監視、保護する。IstioはKubernetesでのみネイティブに動作しますが、そのオープンソースの性質により、Istioを任意のクラスター・ソフトウェア上で実行できる拡張機能を誰でも作成できます。

Kubernetesはコンテナのオーケストレーションツールで、Kubernetesのコアユニットの1つがノードです。 ノードは、1つ以上のコンテナと他のコンポーネントで構成されます。Kubernete はノードの可用性とリソース消費を管理し、需要の増加に応じてポッド・オートスケーラーを使用してポッドを追加します。Istioは追加のコンテナをポッドに挿入して、セキュリティ、管理、監視を追加します。

Istioはオープンソースであるため、Istioをサポートするパブリック・クラウド・プロバイダーや、意欲的な管理者のいるプライベート・クラウド上で実行できます。

組織がマイクロサービスに移行する場合、数十または数百の特定のアプリケーションをサポートする必要があります。これらのエンドポイントを個別に管理することは、デマンドを含む多数の仮想マシン （VM）をサポートすることを意味します。 Kubernetesのようなクラスター・ソフトウェアはポッドを作成してスケールアップできますが、Kubernetesはルーティング、トラフィック・ルール、強力な監視ツールやデバッグ・ツールを提供しません。

サービス・メッシュに入る

サービスの数が増加するにつれて、潜在的な通信方法の数も飛躍的に増加します。2つのサービスには2つの通信パスしかありません。 3つのサービスには6があり、10のサービスには90があります。サービス・メッシュは、通信のポリシーを作成することで、これらの通信パスを構成する単一の方法を提供します。

サービス・メッシュはサービスを計測し、事前定義された構成に従って通信トラフィックを誘導します。管理者は、実行中のコンテナーを構成したり、そのためのコードを作成したりする代わりに、サービス・メッシュに構成を提供し、その作業を完了させることができます。以前は、これはWebサーバーとサービス間の通信で発生する必要がありました。

クラスター内でこれを行う最も一般的な方法は、サイドカー・パターンを使用することです。サイドカーはポッド内の新しいコンテナであり、サービスとコンテナ間の通信トラフィックをルーティングして監視します。

IstioはKubernetes上に層を形成し、プログラマや管理者には本質的に見えないコンテナを追加します。サイドカー・コンテナと呼ばれるこれらは、「中間者」として機能し、トラフィックを誘導し、コンポーネント間のやり取りを監視します。この2つは、次の3つの方法で組み合わせて機能します。

コンフィギュレーション：Kubernetesで設定を行う主な方法はkubectlコマンド、一般的にはkubectl -f<filename>で、ファイルはYAMLファイルです。 Istioユーザーは、kubectlを使用して新しい異なるタイプのYAMLファイルを実行するか、新しいオプションのioctlコマンドを使用することができます。

監視: Istioを使用すると、Kubernetesで実行されているアプリケーションの健全性を監視できます。Istioインストルメンテーションは、アプリケーションの健全性を管理および視覚化することができ、Kubernetesが提供するクラスターとノードの一般的な監視よりも多くの洞察を提供します。

管理: Istioのインターフェイスは基本的にKubernetesと同じであるため、管理には追加の作業はほとんど必要ありません。Istioでは、Kubernetesクラスタ全体に影響を与え管理するポリシーを作成できるため、各クラスタの管理時間が短縮されるとともに、カスタム管理コードが不要になる。

Istioは、Envoyの大幅に拡張されたバージョンを使用して、監視、管理、ロギングを実行します。すべてのポッドを追跡する必要があり、Istioはすべてのポッドに関する情報を集約して提供する必要があります。Istioを使用する代わりに考えられる1つの方法は、EnvoyをKubernetesクラスターに直接デプロイして管理コードを記述することです。これは基本的に、カスタム開発プロジェクトの関連コストとバグを含めてIstioを再作成することになります。