介紹 Workload Entries

介紹 Workload Entries：橋接 Kubernetes 和 VM

過去，Istio 為在 Kubernetes 上運行的工作負載提供了很好的體驗，但對於其他類型的工作負載，例如虛擬機器（VM）和裸機，則不太順利。這些差距包括無法宣告式地指定 VM 上 sidecar 的屬性、無法正確響應工作負載的生命週期變化（例如，從啟動到未就緒到就緒，或健康檢查），以及在工作負載遷移到 Kubernetes 時繁瑣的 DNS 變通方法等等。

Istio 1.6 針對如何管理非 Kubernetes 工作負載引入了一些變更，其驅動力是希望讓使用者更容易地獲得 Istio 的優勢，以便在容器以外的使用案例中使用，例如在 Kubernetes 之外的平台上運行傳統資料庫，或在不重寫現有應用程式的情況下採用 Istio 的功能。

背景

在 Istio 1.6 之前，非容器化工作負載僅能以 ServiceEntry 中的 IP 地址來配置，這表示它們僅作為服務的一部分存在。Istio 缺乏這些非容器化工作負載的一級抽象，類似於 Kubernetes 將 Pod 作為計算的基本單位 - 一個命名的對象，作為與工作負載相關的所有事物（名稱、標籤、安全屬性、生命週期狀態事件等）的收集點。這就是 WorkloadEntry 的由來。

考慮以下 ServiceEntry，它描述了一個由幾個數十個具有 IP 地址的 VM 實現的服務

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，並將其餘流量發送到沒有 sidecar 的 VM - 你會如何做？你將需要結合使用 Kubernetes 服務、虛擬服務和目標規則才能實現此行為。現在，假設你決定逐步為這些 VM 添加 sidecar，這樣你希望只有發送到具有 sidecar 的 VM 的流量才使用 Istio mTLS。如果任何其他 Service Entry 碰巧將同一 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 來選擇所有具有所需標籤的端點的 ServiceEntry，在此範例中包括為 VM 建立的 WorkloadEntry。

請注意，ServiceEntry 可以使用相同的選擇器來引用 Pod 和 WorkloadEntries。現在，Istio 可以將 VM 和 Pod 同等對待，而不是將它們分開。

如果你要將一些工作負載遷移到 Kubernetes，並且你選擇保留大量的 VM，則 WorkloadSelector 可以選擇 Pod 和 VM，並且 Istio 會自動在它們之間進行負載平衡。1.6 的變更也表示 WorkloadSelector 會在 Pod 和 VM 之間同步配置，並消除了使用重複策略（如 mTLS 和授權）針對這兩種基礎架構的手動要求。Istio 1.6 版本為 Istio 的未來可能性提供了很好的起點。以與 Pod 相同的方式描述網格外部存在的事物的能力會帶來額外的好處，例如改善引導體驗。但是，這些好處僅僅是副作用。核心好處是你現在可以讓 VM 和 Pod 共存，而無需任何配置來將兩者橋接在一起。