Workload Entries のご紹介

Workload Entries のご紹介：Kubernetes と VM の橋渡し

これまで、Istio は Kubernetes 上で実行されるワークロードに対して優れたエクスペリエンスを提供してきましたが、仮想マシン（VM）やベアメタルなど、他のタイプのワークロードではスムーズではありませんでした。ギャップとしては、VM上のサイドカーのプロパティを宣言的に指定できないこと、ワークロードのライフサイクル変更（例：起動から準備完了、またはヘルスチェック）に適切に対応できないこと、ワークロードが Kubernetes に移行する際の面倒な DNS 回避策などが挙げられます。

Istio 1.6 では、コンテナ以外のユースケース（Kubernetes以外のプラットフォームで従来のデータベースを実行したり、既存のアプリケーションを書き直さずに Istio の機能を採用するなど）で Istio の利点をより簡単に活用できるように、非 Kubernetes ワークロードの管理方法にいくつかの変更が加えられました。

背景

Istio 1.6 より前は、非コンテナ化されたワークロードは、単に ServiceEntry 内の IP アドレスとして構成可能でした。つまり、サービスの一部としてのみ存在していました。Istio には、これらの非コンテナ化されたワークロードに対するファーストクラスの抽象化が欠けていました。Kubernetes が Pod をコンピューティングの基本単位として扱う方法（名前、ラベル、セキュリティプロパティ、ライフサイクルステータスイベントなど、ワークロードに関連するすべてのものの収集ポイントとして機能する名前付きオブジェクト）と似たものです。そこで WorkloadEntry の登場です。

IP アドレスを持つ数十個の VM によって実装されるサービスを記述した、次の ServiceEntry を考えてみましょう。

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: svc1
spec:
  hosts:
  - svc1.internal.com
  ports:
  - number: 80
    name: http
    protocol: HTTP
  resolution: STATIC
  endpoints:
  - address: 1.1.1.1
  - address: 2.2.2.2
  ....

このサービスをアクティブ/アクティブな方法で Kubernetes に移行したい場合（つまり、多数の Pod を起動し、トラフィックの一部を Istio 相互 TLS (mTLS) 経由で Pod に送信し、残りをサイドカーなしで VM に送信する場合）、どのようにすればよいでしょうか？この動作を実現するには、Kubernetes サービス、仮想サービス、および宛先ルールの組み合わせを使用する必要がありました。次に、これらの VM にサイドカーを 1 つずつ追加し、サイドカーを持つ VM へのトラフィックのみが Istio mTLS を使用するようにしたいとします。他のサービスエントリが同じ VM をアドレスに含めている場合、事態は非常に複雑になり、エラーが発生しやすくなります。

これらの複雑さの主な原因は、Istio に、それが属するサービスとは独立してプロパティを記述できる非コンテナ化されたワークロードのファーストクラスの定義が欠けていたことです。

Workload Entry：非 Kubernetes エンドポイント

WorkloadEntry は、この問題を解決するために特別に作成されました。WorkloadEntry を使用すると、メッシュの一部である必要がある非 Pod エンドポイントを記述し、Pod と同じように扱うことができます。ここから、ワークロードがコンテナ化されているかどうかにかかわらず、ワークロード間の MUTUAL_TLS を有効にするなど、すべてが簡単になります。

WorkloadEntry を作成して ServiceEntry に添付するには、次のようにします。

---
apiVersion: networking.istio.io/v1alpha3
kind: WorkloadEntry
metadata:
  name: vm1
  namespace: ns1
spec:
  address: 1.1.1.1
  labels:
    app: foo
    instance-id: vm-78ad2
    class: vm
---
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: svc1
  namespace: ns1
spec:
  hosts:
  - svc1.internal.com
  ports:
  - number: 80
    name: http
    protocol: HTTP
  resolution: STATIC
  workloadSelector:
    labels:
      app: foo

これにより、一連のラベルとアドレスを持つ新しい WorkloadEntry と、WorkloadSelector を使用して、目的のラベルを持つすべてのエンドポイント（この場合は VM 用に作成された WorkloadEntry を含む）を選択する ServiceEntry が作成されます。

ServiceEntry は、同じセレクターを使用して、Pod と WorkloadEntries の両方を参照できることに注意してください。VM と Pod は、分離された状態ではなく、Istio によって同一に扱われるようになりました。

一部のワークロードを Kubernetes に移行することを選択し、かなりの数の VM を維持することを選択した場合、WorkloadSelector は Pod と VM の両方を選択でき、Istio はそれらの間で自動的にロードバランスを行います。1.6 の変更は、WorkloadSelector が Pod と VM の間で構成を同期し、mTLS や認可のような重複するポリシーで両方のインフラストラクチャをターゲットにする手動の要件を削除することも意味します。Istio 1.6 リリースは、Istio の将来に向けて可能になることの素晴らしい出発点を提供します。メッシュの外部に存在するものを Pod と同じように記述できる機能は、ブートストラップエクスペリエンスの向上などの付加的なメリットにつながります。ただし、これらのメリットは単なる副作用にすぎません。コアのメリットは、VM と Pod が、両者をつなぎ合わせるための構成を必要とせずに共存できるようになったことです。