使用 Admiral 的多叢集 Istio 設定與服務探索

在 Intuit，我們閱讀了部落格文章 用於隔離與邊界保護的多網格部署，並立即意識到其中提到的一些問題。我們了解到，即使我們想設定單一多叢集網格，而不是像部落格文章中描述的多個網格的聯邦，相同的非統一命名問題也適用於我們的環境。這篇部落格文章解釋了我們如何使用 Admiral 解決這些問題，Admiral 是 GitHub 中 istio-ecosystem 下的一個開源專案。

背景

在使用 Istio 時，我們發現多叢集的設定複雜且難以長期維護。因此，我們選擇了 具有複製控制平面的多叢集 Istio 服務網格 中描述的模型，以實現可擴展性和其他操作原因。遵循此模型，我們必須在廣泛採用 Istio 服務網格之前解決以下關鍵要求：

• 建立與命名空間分離的服務 DNS 條目，如 多網格部署的特性 中所述。
• 跨多個叢集的服務探索。
• 支援主動-主動與 HA/DR 部署。我們還必須支援這些關鍵的彈性模式，並且服務部署在跨不同叢集的全球唯一命名空間中。

我們有超過 160 個 Kubernetes 叢集，所有叢集中都有一個全球唯一的命名空間名稱。在此設定中，我們可以讓相同的服務工作負載部署在不同區域，並在不同名稱的命名空間中執行。因此，按照 多叢集版本路由 中提到的路由策略，範例名稱 foo.namespace.global 將無法跨叢集運作。我們需要一個全球唯一且可探索的服務 DNS，該 DNS 可以解析多個叢集中的服務實例，每個實例都使用其獨特的 Kubernetes FQDN 執行/可定址。例如，如果 foo 在兩個具有不同名稱的 Kubernetes 叢集中執行，則 foo.global 應該解析為 foo.uswest2.svc.cluster.local 和 foo.useast2.svc.cluster.local。此外，我們的服務需要具有不同解析和全域路由屬性的其他 DNS 名稱。例如，foo.global 應該先在本機解析，然後使用拓撲路由路由到遠端實例，而 foo-west.global 和 foo-east.global (用於測試的名稱) 應該始終解析到各自的區域。

情境設定

經過進一步調查，很明顯設定需要是情境化的：每個叢集都需要根據其對世界的視圖量身定制的設定。

例如，我們有一個由訂單和報告使用的付款服務。付款服務在 us-east (叢集 3) 和 us-west (叢集 2) 之間進行 HA/DR 部署。付款服務部署在每個區域中具有不同名稱的命名空間中。訂單服務與 us-west (叢集 1) 中的付款服務部署在不同的叢集中。報告服務與 us-west (叢集 2) 中的付款服務部署在相同的叢集中。

以下是叢集 1 和叢集 2 中付款服務的 Istio ServiceEntry yaml，說明其他服務需要使用付款服務的情境設定。

叢集 1 服務條目

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: payments.global-se
spec:
  addresses:
  - 240.0.0.10
  endpoints:
  - address: ef394f...us-east-2.elb.amazonaws.com
    locality: us-east-2
    ports:
      http: 15443
  - address: ad38bc...us-west-2.elb.amazonaws.com
    locality: us-west-2
    ports:
      http: 15443
  hosts:
  - payments.global
  location: MESH_INTERNAL
  ports:
  - name: http
    number: 80
    protocol: http
  resolution: DNS

叢集 2 服務條目

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: payments.global-se
spec:
  addresses:
  - 240.0.0.10
  endpoints:
  - address: ef39xf...us-east-2.elb.amazonaws.com
    locality: us-east-2
    ports:
      http: 15443
  - address: payments.default.svc.cluster.local
    locality: us-west-2
    ports:
      http: 80
  hosts:
  - payments.global
  location: MESH_INTERNAL
  ports:
  - name: http
    number: 80
    protocol: http
  resolution: DNS

從叢集 2 中報告服務的角度來看，付款 ServiceEntry (Istio CRD) 會將位置 us-west 指向本機 Kubernetes FQDN，並將位置 us-east 指向叢集 3 的 istio-ingressgateway (負載平衡器)。從叢集 1 中訂單服務的角度來看，付款 ServiceEntry 會將位置 us-west 指向叢集 2 的 istio-ingressgateway，並將位置 us-east 指向叢集 3 的 istio-ingressgateway。

但是等等，還有更複雜的情況：如果付款服務想要將流量移動到 us-east 區域，以進行 us-west 中的計畫性維護呢？這將需要付款服務變更其所有用戶端叢集中的 Istio 設定。如果沒有自動化，這幾乎是不可能完成的。

Admiral 拯救了我們：Admiral 就是自動化

Admiral 是 Istio 控制平面的控制器。

Admiral 提供自動設定，讓跨越多個叢集的 Istio 網格可以像單一網格一樣運作，方法是基於唯一的服務識別碼，該識別碼將在多個叢集上執行的工作負載與服務相關聯。它還提供自動佈建和跨叢集同步 Istio 設定的功能。這減輕了開發人員和網格營運商的負擔，這有助於擴展到少數幾個叢集之外。

Admiral CRD

全域流量路由

使用 Admiral 的全域流量原則 CRD，付款服務可以更新區域流量權重，而 Admiral 會更新使用付款服務的所有叢集中的 Istio 設定。

apiVersion: admiral.io/v1alpha1
kind: GlobalTrafficPolicy
metadata:
  name: payments-gtp
spec:
  selector:
    identity: payments
  policy:
  - dns: default.payments.global
    lbType: 1
    target:
    - region: us-west-2/*
      weight: 10
    - region: us-east-2/*
      weight: 90

在上面的範例中，90% 的付款服務流量會路由到 us-east 區域。此全域流量設定會自動轉換為 Istio 設定，並情境化地對應到 Kubernetes 叢集，以啟用網格內客戶端的付款服務的多叢集全域路由。

此全域流量路由功能依賴 Istio 1.5 或更高版本中可用的 Istio 每個服務的區域性負載平衡。

相依性

Admiral Dependency CRD 允許我們根據服務識別碼指定服務的相依性。這僅會將 Admiral 產生的設定最佳化地傳遞到執行服務的相依用戶端所在的必要叢集 (而不是將其寫入所有叢集)。Admiral 還會在用戶端的工作負載命名空間中設定和/或更新 Sidecar Istio CRD，以將 Istio 設定限制為僅其相依性。我們使用其他地方記錄的服務對服務授權資訊，以產生供 Admiral 使用的此 dependency 記錄。

orders 服務的 dependency 範例

apiVersion: admiral.io/v1alpha1
kind: Dependency
metadata:
  name: dependency
  namespace: admiral
spec:
  source: orders
  identityLabel: identity
  destinations:
  - payments

Dependency 是可選的，服務遺失相依性將導致該服務的 Istio 設定推送到所有叢集。

摘要

Admiral 提供新的全域流量路由和獨特的服務命名功能，以解決 具有複製控制平面的多叢集部署 中描述的 Istio 模型所帶來的一些挑戰。它消除了叢集之間手動設定同步的需求，並為每個叢集產生情境設定。這使得可以操作由多個 Kubernetes 叢集組成的服務網格。

我們認為 Istio/服務網格社群將受益於這種方法，因此我們開源了 Admiral，並希望收到您的回饋和支援！