仮想マシンを Istio サービス メッシュに統合するにはどうすればよいですか?

[[350264]]

[51CTO.com クイック翻訳] Istio は、サービスを接続、保護、制御、監視するために使用される人気のサービス メッシュです。 Kubernetes は 2017 年にオープンソース システムとしてデビューして以来、コンテナ オーケストレーション戦争に勝利してきましたが、Istio はマイクロサービスに移行する組織のニーズを満たしています。 Istio は Nomad、Consul、Eureka、Cloud Foundry、Mesos などの異機種環境をサポートすると主張していますが、実際には Kubernetes と連携すると最もスムーズに実行されます。結局のところ、Istio のサービス検出は Kubernetes に基づいています。

Istio は開発の初期段階で、コンポーネントの数が多い、インストールとメンテナンスが複雑、デバッグが難しい、新しい概念やオブジェクト (最大 50 CRD) の導入が多すぎるため開始が難しいなど、多くの問題で批判されていました。 Mixer コンポーネントがパフォーマンスに影響を与えました。しかし、Istio チームはこれらの問題を徐々に解決しています。 2020 年初頭にリリースされたロードマップからわかるように、Istio は大きな進歩を遂げています。

今年の Istio チームの主な焦点は、VM ベースのワークロードをメッシュに適切に統合することでした。この記事では、Istio を仮想マシンと統合する必要がある理由と、それを実現する方法について説明します。

Istio が VM をサポートする必要があるのはなぜですか?

コンテナと Kubernetes は現在広く使用されていますが、Kubernetes クラスターの外部の仮想マシンや API にデプロイされ、Istio メッシュで管理する必要があるサービスはまだ数多くあります。古い環境の管理を新しい環境と統合することは大きな課題です。

グリッドに仮想マシンを追加するには何が必要ですか?

仮想マシンを追加する方法を説明する前に、まず仮想マシンをグリッドに追加するために必要なものを説明しましょう。 VM トラフィックをサポートする場合、Istio は次のことを理解する必要があります。メッシュの一部となるべきサービスを持つ VM はどれですか? VM にアクセスするにはどうすればいいですか?各 VM には、メッシュの残りの部分と安全に通信できるように ID も必要です。これらの要件は、Kubernetes CRD および Consul などのフル機能のサービス レジストリと互換性があります。サービス アカウント ベースの ID ブートストラップは、プラットフォーム ID を持たない仮想マシンにワークロード ID を割り当てるメカニズムとして機能します。プラットフォーム ID を持つ VM (EC2、GCP、Azure など) の場合、Istio は mTLS 通信を確立するために Kubernetes ID とプラットフォーム ID を交換する作業を行っています。

Istio は仮想マシンをどのようにサポートしますか?

Istio の仮想マシンのサポートは、サービス登録メカニズムから始まります。 Istio メッシュ内のサービスとインスタンスに関する情報は、これまでポッドの表示または追跡のみを行っていた Istio のサービス レジストリから取得されます。新しいバージョンでは、Istio に仮想マシンを追跡および監視するためのリソース タイプが追加されました。メッシュ内のサイドカーは、メッシュ外のサービスに関する情報を持っていないため、メッシュ外のサービスに送信されるトラフィックを監視および制御することはできません。

Istio コミュニティは、Istio での仮想マシンのサポートに多大な労力を費やしてきました。バージョン 1.6 では WorkloadEntry が追加され、Kubernetes で実行されているホストを記述するのと同じ方法で仮想マシンを記述できるようになりました。バージョン 1.7 のリリースでは、トークンを介してメッシュに VM をブートストラップするための基盤が自動的に追加され、Istio が面倒な処理を処理するようになりました。 Istio 1.8 では、Kubernetes Deployment オブジェクトに似ていますが、仮想マシン向けの WorkloadGroup と呼ばれる別の抽象化が初めて導入されます。

次の図は、Istio がメッシュ内でサービスをモデル化する方法を示しています。情報の主なソースは、プラットフォーム サービス レジストリ (Kubernetes など) またはシステム (Consul など) から取得されます。さらに、ServiceEntry は、仮想マシン上のサービスや組織外の外部サービスをモデル化できるユーザー定義のサービス レジストリとして機能します。

Istio のサービス登録モデル

ServiceEntry を使用して VM にサービスを導入できるのに、なぜ VM に Istio をインストールするのでしょうか?

ServiceEntry を使用すると、メッシュ内のサービスが外部サービスを検出してアクセスし、それらの外部サービスへのトラフィックを管理できるようになります。 VirtualService と組み合わせて使用​​すると、対応する外部サービス (要求タイムアウトやフォールト挿入など) のアクセス ルールを構成して、指定した外部サービスへのアクセスを制御できます。

それでも、クライアント側のトラフィックしか制御できず、他のサービスに導入された外部サービスへのアクセスを制御することはできません。つまり、通話の発信元であるサービスの動作を制御することはできません。仮想マシンにサイドカーをデプロイし、ワークロード セレクターを通じて仮想マシンのワークロードを導入することで、Kubernetes のポッドと同様に仮想マシンを自由に管理できるようになります。

将来に向けて

bookinfo デモ (https://istio.io/latest/docs/examples/virtual-machines/bookinfo/) からわかるように、このプロセスには手作業が多すぎて、エラーが発生しやすくなります。今後、Istio では VM テストの忠実度が向上し、プラットフォーム ID に基づく自動ブートストラップが可能になり、DNS サポートと istioctl デバッグが改善される予定です。VM サポートの詳細については、Istio 環境ワーキング グループ (https://github.com/istio/community/blob/master/WORKING-GROUPS.md) をフォローしてください。

元のタイトル: 仮想マシンを Istio サービス メッシュに統合する方法、著者: Jimmy Song

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。