仮想マシンアーキテクチャ

約4分

このドキュメントを読む前に、Istioのアーキテクチャとデプロイモデルを確認してください。このページでは、これらのドキュメントに基づいて、Istioを拡張して仮想マシンをメッシュに接続する方法について説明します。

Istioの仮想マシンサポートにより、Kubernetesクラスタの外部にあるワークロードをメッシュに接続できます。これにより、レガシーアプリケーションやコンテナ化された環境で実行するには適さないアプリケーションでも、IstioがKubernetes内で実行されるアプリケーションに提供するすべてのメリットを得ることができます。

Kubernetes上で実行されるワークロードの場合、Kubernetesプラットフォーム自体は、サービスディスカバリ、DNS解決、ヘルスチェックなどの機能を提供しますが、これらの機能は仮想マシン環境ではしばしば欠けています。Istioは仮想マシン上で実行されるワークロードに対してこれらの機能を有効にし、さらに、これらのワークロードが相互TLS (mTLS)、豊富なテレメトリ、高度なトラフィック管理機能などのIstio機能を利用できるようにします。

次の図は、仮想マシンを含むメッシュのアーキテクチャを示しています。

このメッシュでは、ポッドと仮想マシンがお互いに直接通信できる単一のネットワークがあります。

XDS構成や証明書の署名など、コントロールプレーントラフィックはクラスタ内のゲートウェイを経由して送信されます。これにより、仮想マシンはブートストラップ時に接続するための安定したアドレスを持つことができます。ポッドと仮想マシンは、中間ゲートウェイを必要とせずに、お互いに直接通信できます。

A service mesh with a single network and virtual machines — 単一ネットワークと仮想マシンを持つサービスメッシュ

サービスアソシエーション

Istioは、仮想マシンのワークロードを表す2つのメカニズムを提供します。

WorkloadGroup は、共通のプロパティを共有する仮想マシンのワークロードの論理的なグループを表します。これはKubernetesのDeploymentに似ています。
WorkloadEntry は、仮想マシンのワークロードの単一インスタンスを表します。これはKubernetesのPodに似ています。

これらのリソース（WorkloadGroupとWorkloadEntry）を作成しても、リソースのプロビジョニングや仮想マシンのワークロードの実行は行われません。これらのリソースは、これらのワークロードを参照し、Istioにメッシュを適切に構成する方法を知らせるだけです。

仮想マシンのワークロードをメッシュに追加する場合、各WorkloadEntryインスタンスのテンプレートとして機能するWorkloadGroupを作成する必要があります。

apiVersion: networking.istio.io/v1
kind: WorkloadGroup
metadata:
  name: product-vm
spec:
  metadata:
    labels:
      app: product
  template:
    serviceAccount: default
  probe:
    httpGet:
      port: 8080

仮想マシンが構成され、メッシュに追加されると、対応するWorkloadEntryはIstioコントロールプレーンによって自動的に作成されます。例：

apiVersion: networking.istio.io/v1
kind: WorkloadEntry
metadata:
  annotations:
    istio.io/autoRegistrationGroup: product-vm
  labels:
    app: product
  name: product-vm-1.2.3.4
spec:
  address: 1.2.3.4
  labels:
    app: product
  serviceAccount: default

このWorkloadEntryリソースは、KubernetesのPodと同様に、ワークロードの単一インスタンスを記述します。ワークロードがメッシュから削除されると、WorkloadEntryリソースも自動的に削除されます。さらに、WorkloadGroupリソースにプローブが構成されている場合、Istioコントロールプレーンは関連付けられたWorkloadEntryインスタンスのヘルスステータスを自動的に更新します。

コンシューマーがワークロードを確実に呼び出すためには、Serviceの関連付けを宣言することをお勧めします。これにより、クライアントは、一時的なIPアドレスではなく、product.default.svc.cluster.localのような安定したホスト名にアクセスできます。これにより、DestinationRuleとVirtualService APIを使用してIstioの高度なルーティング機能を使用することもできます。

任意のKubernetesサービスは、PodとWorkloadEntryのラベルにそれぞれ一致するセレクターフィールドを介して、Podと仮想マシンの両方のワークロードを透過的に選択できます。

たとえば、productという名前のServiceは、PodとWorkloadEntryで構成されています。

この構成では、productへのリクエストは、Podと仮想マシンのワークロードインスタンスの両方でロードバランスされます。

DNS

Kubernetesは、Pod内でService名のDNS解決を提供するため、Podは安定したホスト名を使用して互いに簡単に通信できます。

仮想マシンの拡張のために、IstioはDNSプロキシを介して同様の機能を提供します。この機能は、仮想マシンのワークロードからのすべてのDNSクエリをIstioプロキシにリダイレクトし、ホスト名とIPアドレスのマッピングを維持します。

その結果、仮想マシン上で実行されているワークロードは、追加の構成を必要とせずに、（Podと同様に）Serviceを透過的に呼び出すことができます。