仮想マシンをIstioサービスメッシュに追加する簡単な方法

仮想マシンの参加に伴う複雑さの一部は、サービスメッシュが提供する機能の sheer な数に起因しています。 しかし、これらの機能のサブセットのみが必要な場合はどうでしょうか？ たとえば、仮想マシンからサービスメッシュ内で実行されているサービスへの安全な通信です。 いくつかのトレードオフだけで、仮想マシンにすべてのオーバーヘッドなしでサービスメッシュ機能を提供できます。

ローカル開発はどうでしょうか？ ますます多くのマイクロサービスがKubernetesにデプロイされ、依存関係グラフがクモの巣に似てくるにつれて、ローカル開発を行うのがますます困難になっています。 ローカルマシンが単にサービスメッシュに参加してメッシュアプリケーションを呼び出すことができたらどうでしょうか。 このソリューションは、開発者がコードのデプロイを待つ必要がないため、時間と費用を節約できる可能性があります。

複雑さの軽減

現在、Istioサービスメッシュに仮想マシンを追加するには、多くの可動部分が伴います。 Kubernetesサービスアカウント、Istioワークロードエントリを作成し、単一の仮想マシンをオンボーディングする前に、すべて設定を生成する必要があります。 これらを自動化することにも複雑さがあり、特にVMの自動スケーリングの場合に当てはまります。 最後に、Istiodをクラスターの外部に公開する必要があります。

仮想マシンの追加の複雑さは、VMがサービスメッシュ内で100％参加するという期待から来ています。 多くの人にとってこれは必須ではなく、システムの実際の要件を調べることで、仮想マシンのオンボーディングを簡素化し、それでも必要な機能を取得できる場合があります。

では、満たすことができるが、それでも仮想マシンをサービスメッシュで扱いやすくできるユースケースにはどのようなものがあるでしょうか？

単方向トラフィックフロー

場合によっては、仮想マシンはサービスメッシュ内のアプリケーションと安全に通信する必要があるだけです。 これは、他のVMがこれらのアプリケーションに依存している可能性のあるVMベースのアプリケーションをKubernetesに移行する場合によくあります。 以下で説明するアプローチでは、上記のようにすべての運用オーバーヘッドなしで、これを引き続き実現できます。

開発者のサービスメッシュへのアクセス

エンジニアは、多くの場合、環境に必要なすべてのマイクロサービスを実行するためのリソースを持っていません。 以下のアプローチでは、仮想マシンがメッシュアプリケーションと安全に通信するのと同じ方法でこれを実現する方法について説明します。

EnvoyとIstioの分離

仮想マシンに関連する最大の複雑さは、EnvoyをIstiodに接続して設定を取得することです。 より簡単なアプローチは、それらをもう接続しないことです。 Istioはメッシュ内で通信している仮想マシンを認識しなくなりますが、その通信は引き続き安全で認証されます。 秘訣は、メッシュワークロードと同じ信頼チェーンにルート化された独自のワークロード証明書を仮想マシンに発行することです。 これは、エンドユーザーが仮想マシンでEnvoyを手動で設定する責任があることも意味します。 ほとんどの場合、これはそれほど頻繁に変更されることは想定されていないため、問題にはなりません。

より簡単なオンボーディング体験

組み込みのIstio機能を利用することで、よりシンプルなセットアップを実現できます。 まず、メッシュ外のアプリケーションがメッシュ内のアプリケーションと通信するための安全なトンネルを公開する必要があります。

これを行うには、IstioのEast-Westゲートウェイを作成し、`AUTO_PASSTHROUGH`を有効にするだけです。 これにより、East-Westゲートウェイは、mTLSを介して正しいサービスにトラフィックを通過させるように自動的に構成されます。 これにより、仮想マシンは到達しようとしているアプリケーションとのエンドツーエンドの認証された暗号化を実現できます。

EnvoyをIstiodと通信するように構成するのは複雑なため、仮想マシンEnvoyを直接構成する方が実用的です。 最初は非常に困難に聞こえますが、複雑さが軽減されたため、これを機能させるにはいくつかの機能を有効にするだけで済みます。 Envoyは、仮想マシンが通信する必要がある各サービスメッシュアプリケーションを認識するように構成する必要があります。 次に、これらをEnvoy内で`クラスター`として構成し、サービスメッシュのEast-Westゲートウェイを通過するmTLS通信を使用するように設定します。 次に、仮想マシンアプリケーションからの着信トラフィックを処理するためにリスナーを公開する必要があります。 最後に、サービスメッシュアプリケーションと同じ信頼のルートを共有する各仮想マシンに証明書を発行する必要があります。 これにより、エンドツーエンドの暗号化と、仮想マシンが通信できるアプリケーションを承認する機能が可能になります。

自動化の容易化

仮想マシンをオンボーディングする際にサービスメッシュクラスターで初期化を行う必要がないため、自動化がはるかに容易になります。 仮想マシンEnvoyに必要な構成は、パイプラインに追加できます。 Envoyコンテナは、Docker経由でプルするか、イメージ構築インフラストラクチャに追加できます。 mTLS証明書は、HashicorpのVaultなどのサードパーティによってプロビジョニングおよび保守することもできます。

より多くのランタイムサポート

このインストール方法では、基盤となるOSネットワーキングにアクセスする必要がないため。 WindowsやDockerなど、より多くのタイプの環境でこのアプローチを実行できます。 唯一の要件は、EnvoyにこちらにあるIstio拡張機能が含まれていることです。 Dockerを使用すると、ローカルマシンでEnvoyプロキシを実行し、サービスメッシュと直接通信できるようになりました。

高度なユースケース

gRPCからJSONへ

この手法は、gRPCエンドポイントを実装することなく、仮想マシンアプリケーションがgRPCアプリケーションと通信できるようにするためにも活用できます。 EnvoyのgRPC / JSON変換を使用すると、仮想マシンアプリケーションはRESTを介してローカルEnvoyと通信でき、EnvoyはそれをgRPCに変換します。

多方向

サービスメッシュはそれと通信している仮想マシンを認識していない場合でも、サービスエントリを使用して外部エンドポイントとして追加できます。 そのサービスエントリは、複数の仮想マシンへのトラフィックを管理するHTTPSロードバランサーエンドポイントにすることができます。 このセットアップは、仮想マシンを仮想メッシュに完全にオンボーディングするよりも、多くの場合、依然として実現可能です。

フォワーディングプロキシ

すべての仮想マシンにEnvoyをインストールするのはまだ複雑すぎるかもしれません。 代替手段として、Envoy（または自動スケーリンググループ）を独自の仮想マシンで実行し、メッシュへのフォワーディングプロキシとして機能させることができます。 これは、アプリケーションを実行する仮想マシンに手を加えないため、メッシュサービスにアクセスするためのよりシンプルなソリューションです。

パート2…

パート2では、メッシュ内で通信するようにIstioと仮想マシンを構成する方法について説明します。 プレビューをご希望の場合は、nick.nellis@solo.ioまでお気軽にお問い合わせください。

謝辞

この仮想マシンのアイデアについてDave Ortizに特に感謝し、Constant Contactに新しい登録Istioユーザーとしてお祝い申し上げます！