Istioとは?

この記事の執筆時点で、IstioはKubernetesでのみネイティブに動作しますが、そのオープンソースの性質により、Istioを任意のクラスター・ソフトウェア上で実行できる拡張機能を誰でも作成できます。今日は、Istioの最も一般的なユースケースであるKubernetesでの使用に焦点を当てて説明します。

Kubernetesはコンテナのオーケストレーション・ツールで、Kubernetesのコア・ユニットの1つがノードです。ノードは、1つ以上のコンテナと、ファイル・システムまたはその他のコンポーネントで構成されます。マイクロサービス・アーキテクチャーには、それぞれ異なるマイクロサービスを表す12個の異なるノードが含まれる場合があります。Kuberneteはノードの可用性とリソース消費を管理し、需要の増加に応じてポッド・オートスケーラーを使用してポッドを追加します。Istioは追加のコンテナをポッドに挿入して、セキュリティー、管理、監視を追加します。

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

次の動画では、Istioの基本について詳しく説明しています。

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

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

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

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

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

前述のように、IstioはKubernetesの上にレイヤー化され、プログラマーや管理者には見えないコンテナを追加します。サイドカー・コンテナーと呼ばれるこれらは中間者のような役割を果たし、トラフィックを誘導し、コンポーネント間のやり取りを監視します。これら2つは、構成、監視、管理の3つの方法で連携して機能します。

Kubernetesで構成を設定する主な方法はkubectlコマンドで、通常は「kubectl -f 」で、ファイルはYAMLファイルです。Istioユーザーは、kubectlを使用して新しい異なるタイプのYAMLファイルを実行するか、新しいオプションのioctlコマンドを使用することができます。

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

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

サービス・メッシュの主なメリットには、デバッグ、監視、ルーティング、セキュリティー、使用性の向上の機能が含まれます。つまり、Istioを使用すると、より広範なサービス・グループをより簡単に管理することができます。

例えば、サービスに複数の依存関係があるとします。保険会社のpay_claimサービスはdeductible_amtサービスを呼び出し、deductible_amtサービスはis_member_coveredサービスを呼び出し…、というように続きます。複雑な依存関係チェーンには、10個ないし12個のサービス呼び出しが含まれる場合があります。これら12個のうちの1つが失敗すると、連鎖的な失敗が発生し、500エラー、400エラー、またはまったく応答しない状態になることがあります。

その一連の呼び出しをデバッグするには、スタック・トレースのようなものを使用できます。フロントエンドでは、クライアント側の開発者は、Webサーバーからどの要素がどのような順序で返されるかを確認し、調査することができます。フロントエンドのプログラマーは、ウォーターフォール図を入手して、デバッグを支援できます。

この例では、データセンター内で何が起こっているか、つまり、callback=parselLotamaAudiencesが他の4つのWebサービスをどのように呼び出し、どのサービスがより遅い応答をするかは示されていません。後ほど、Istioがこの図のような関数呼び出しをトレースするためのツールをどのように提供しているかについて説明します。

DevOpsチームやIT管理者は、トラフィックを観察して、レイテンシー、サービス時間、トラフィックの割合としてのエラーなどを確認する必要がある場合があります。多くの場合、ダッシュボードを使用しますが、ダッシュボードでは、合計、平均、または一定期間にわたるメトリクスを確認できます。また、特定のノード、サービス、またはポッドにドリルダウンすることも可能です。Kubernetesはこれらの機能をネイティブには提供しません。

デフォルトでは、Kubernetesはすべてのポッドが他のすべてのポッドにトラフィックを送信することを許可します。Istioを使用すると、管理者は相互に連携できるサービスを制限するポリシーを作成できます。したがって、例えば、サービスは、真の依存関係にある他のサービスのみを呼び出すことができます。サービスを維持するためのもう1つのポリシーはレート制限です。これにより、過剰なトラフィックによるサービスの停滞が防止され、サービス拒否攻撃を防ぐことができます。

デフォルトでは、Kubernetesはラウンドロビンによる負荷分散を提供します。マイクロサービスを提供するポッドが6つある場合、Kubernetesはロード・バランサー、つまり各ポッドにリクエストを昇順で送信し、再度やり直すサービスを提供します。ただし、企業によっては、同じサービスの異なるバージョンを本番環境に導入する場合があります。

最も単純な例としては、ブルー・デプロイメントまたはグリーン・デプロイメントが挙げられます。その場合、ソフトウェアは、実稼働ユーザーを送信せずに、本番環境でアプリケーションのまったく新しいバージョンを構築する可能性があります。新しいバージョンを宣伝した後、会社は古いサーバーを保持しておき、障害が発生した場合に迅速に切り替えられるようにすることができます。

Istioでは、これは構成ファイルでタグ付けを使用するのと同じくらい簡単です。管理者はラベルを使用して、接続するサービスの種類を指定し、ヘッダーに基づいてルールを構築することもできます。例えば、ベータ・ユーザーは最新かつ最高のビルドを備えたカナリア・ポッドにルーティングでき、通常のユーザーは安定した本番環境ビルドにアクセスできます。

サービスが過負荷になり、またはダウンすると、システムの過負荷が続くと同時に、さらに多くのリクエストが失敗します。Istioはエラーと遅延を追跡しているため、ポリシーで設定された特定の数のリクエストの後に一時停止を強制し、サービスを回復させることができます。小さなテキスト・ファイルを作成し、それを新しいポリシーとして使用するようにIstio に指示することで、このポリシーをクラスター全体に適用できます。

ISTIOは、認証、承認、監査（AAA）に加えて、デフォルトでID認証やポリシーを提供し、暗号化を行います。他のポッドと通信する管理下にあるすべてのポッドは、暗号化されたトラフィックを使用するため、観測が防止されます。ID認証と暗号化を組み合わせることで、権限のないユーザーがサービス呼び出しを偽造したり「なりすまし」たりすることがないようにすることができます。AAAは、セキュリティーおよびオペレーションの専門家に、オーバーヘッドを抑えながら監視に必要なツールを提供します。

従来のアプリケーションには、ISTIOが提供するID認証、ポリシー、セキュリティー機能が依然として必要です。これにより、プログラマーと管理者が不適切なレベルの抽象化で作業し、すべてのサービスに対して同じセキュリティー・ルールを何度も再実装することになります。ISTIOを使用すると、適切なレベルで作業し、単一のコントロールパネルを介してクラスターのポリシーを設定できます。