部署模型

在設定 Istio 的生產環境部署時,您需要回答一些問題。網格 (mesh) 將會侷限在單一叢集中,還是會分散在多個叢集中?所有的服務都會位於單一完全連線的網路中,還是需要閘道來連接跨多個網路的服務?是否會有單一控制平面,可能跨叢集共享,還是會部署多個控制平面以確保高可用性 (HA)?所有的叢集都會連接到單一多叢集服務網格中,還是會聯合到一個多網格部署?

以上這些問題,以及其他問題,代表了 Istio 部署的獨立配置維度。

  1. 單一或多個叢集
  2. 單一或多個網路
  3. 單一或多個控制平面
  4. 單一或多個網格

在涉及多個叢集的生產環境中,您可以使用混合的部署模型。例如,建議使用多個控制平面以實現高可用性,但是您可以透過以下方式為 3 個叢集的部署實現此目的:部署 2 個具有單一共享控制平面的叢集,然後在不同的網路中添加具有第二個控制平面的第三個叢集。然後可以將所有三個叢集配置為共享兩個控制平面,以便所有叢集都有 2 個控制源,以確保高可用性。

選擇正確的部署模型取決於您的使用案例的隔離、效能和高可用性需求。本指南描述了設定 Istio 部署時的各種選項和考量。

叢集模型

您的應用程式的工作負載實例在一個或多個叢集中執行。為了隔離、效能和高可用性,您可以將叢集限制在可用性區域和地區中。

生產系統根據其需求,可以跨多個跨越許多區域或地區的叢集執行,並利用雲端負載平衡器來處理諸如位置和區域或地區故障轉移之類的事情。

在大多數情況下,叢集代表配置和端點探索的邊界。例如,每個 Kubernetes 叢集都有一個 API 伺服器,該伺服器管理叢集的配置,並在 Pod 啟動或關閉時提供服務端點資訊。由於 Kubernetes 在每個叢集的基礎上配置此行為,因此此方法有助於限制錯誤配置可能導致的問題。

在 Istio 中,您可以配置單一服務網格以跨越任意數量的叢集。

單一叢集

在最簡單的情況下,您可以將 Istio 網格限制在單一叢集中。叢集通常在單一網路上運作,但因基礎架構提供者而異。單一叢集和單一網路模型包含控制平面,這會產生最簡單的 Istio 部署。

A service mesh with a single cluster
具有單一叢集的服務網格

單一叢集部署提供了簡便性,但缺乏其他功能,例如,容錯隔離和故障轉移。如果您需要更高的可用性,則應使用多個叢集。

多個叢集

您可以將單一網格配置為包含多個叢集。在單一網格中使用多叢集部署,除了單一叢集部署之外,還具有以下功能:

  • 容錯隔離和故障轉移:cluster-1 故障,故障轉移至 cluster-2
  • 位置感知路由和故障轉移:將請求發送到最近的服務。
  • 各種控制平面模型:支援不同的可用性級別。
  • 團隊或專案隔離:每個團隊都執行自己的叢集組。
A service mesh with multiple clusters
具有多個叢集的服務網格

多叢集部署為您提供了更高的隔離度和可用性,但也增加了複雜性。如果您的系統具有高可用性要求,則您可能需要在多個區域和地區中擁有叢集。您可以在單一叢集中進行金絲雀配置更改或新的二進位版本發布,其中配置更改僅影響少量使用者流量。此外,如果叢集出現問題,您可以暫時將流量路由到附近的叢集,直到您解決該問題。

您可以根據網路和雲端提供者支援的選項來配置叢集間通訊。例如,如果兩個叢集位於相同的底層網路上,則可以通過簡單地配置防火牆規則來啟用跨叢集通訊。

在多叢集網格中,根據命名空間一致性的概念,預設情況下會共享所有服務。流量管理規則提供了對多叢集流量行為的細微控制。

具有多個叢集的 DNS

當用戶端應用程式向某個主機發出請求時,它必須先對主機名執行 DNS 查詢,以取得 IP 位址,然後才能繼續請求。在 Kubernetes 中,位於叢集內的 DNS 伺服器通常會根據配置的 Service 定義處理此 DNS 查詢。

Istio 使用 DNS 查詢傳回的虛擬 IP,以在請求服務的活動端點清單之間進行負載平衡,並考慮任何 Istio 配置的路由規則。Istio 使用 Kubernetes Service/Endpoint 或 Istio ServiceEntry 來配置其內部主機名到工作負載 IP 位址的對應。

當您有多個叢集時,此雙層命名系統會變得更加複雜。Istio 本質上是多叢集感知的,但 Kubernetes 不是(目前)。因此,用戶端叢集必須具有服務的 DNS 項目,以便 DNS 查詢成功,並且請求可以成功發送。即使在用戶端叢集中沒有執行該服務的 Pod 實例,也是如此。

為了確保 DNS 查詢成功,您必須將 Kubernetes Service 部署到每個使用該服務的叢集。這可確保無論請求從何處發起,它都會通過 DNS 查詢並被傳遞給 Istio 進行適當的路由。也可以使用 Istio ServiceEntry 而非 Kubernetes Service 來實現此目的。但是,ServiceEntry 不會配置 Kubernetes DNS 伺服器。這表示 DNS 將需要手動配置,或使用自動化工具配置,例如 Istio DNS Proxying位址自動分配功能。

網路模型

Istio 使用簡化的網路定義來指稱具有直接可達性的工作負載實例。例如,預設情況下,單一叢集中的所有工作負載實例都位於同一網路上。

許多生產系統需要多個網路或子網路來進行隔離和高可用性。Istio 支援在各種網路拓撲上擴展服務網格。這種方法允許您選擇符合現有網路拓撲的網路模型。

單一網路

在最簡單的情況下,服務網格在單一完全連線的網路上運作。在單一網路模型中,所有工作負載實例可以彼此直接連線,而無需 Istio 閘道。

單一網路允許 Istio 以統一的方式在網格中配置服務使用者,並能夠直接定址工作負載實例。但請注意,對於跨多個叢集的單一網路,服務和端點不能有重疊的 IP 位址。

A service mesh with a single network
具有單一網路的服務網格

多個網路

您可以跨多個網路擴展單一服務網格;這種配置稱為多網路

多個網路提供以下超越單一網路的功能

  • 服務端點的重疊 IP 或 VIP 範圍
  • 跨越管理邊界
  • 容錯能力
  • 網路位址的擴展
  • 符合需要網路分段的標準

在此模型中,不同網路中的工作負載實例只能透過一個或多個Istio 閘道彼此連線。Istio 使用分割的服務探索,為使用者提供服務端點的不同視圖。視圖取決於使用者的網路。

A service mesh with multiple networks
具有多個網路的服務網格

此解決方案需要透過閘道暴露所有服務(或一部分)。雲端供應商可能會提供不需要在公共網路上暴露服務的選項。如果存在這種選項且符合您的要求,這很可能是最佳選擇。

控制平面模型

Istio 網格使用控制平面來配置網格內工作負載實例之間的所有通訊。工作負載實例連線到控制平面實例以取得其配置。

在最簡單的情況下,您可以在單一叢集上使用控制平面執行網格。

A single cluster with a control plane
具有控制平面的單一叢集

像這樣具有其自己本地控制平面的叢集稱為主叢集

多叢集部署也可以共享控制平面實例。在這種情況下,控制平面實例可以駐留在一個或多個主叢集中。沒有自己控制平面的叢集稱為遠端叢集

A service mesh with a primary and a remote cluster
具有一個主叢集和一個遠端叢集的服務網格

為了在多叢集網格中支援遠端叢集,主叢集中的控制平面必須透過穩定的 IP(例如叢集 IP)存取。對於跨越網路的叢集,可以透過 Istio 閘道公開控制平面來實現此目的。雲端供應商可能會提供一些選項,例如內部負載平衡器,以便在不將控制平面暴露在公共網路上也能提供此功能。如果存在這種選項且符合您的要求,這很可能是最佳選擇。

在具有多個主叢集的多叢集部署中,每個主叢集都會從駐留在同一叢集中的 Kubernetes API 伺服器接收其配置(即 ServiceServiceEntryDestinationRule 等)。因此,每個主叢集都有獨立的配置來源。在推出變更時,跨主叢集的這種配置重複需要額外的步驟。大型生產系統可以使用工具(例如 CI/CD 系統)來自動化此流程,以便管理配置推出。

服務網格可以完全由外部外部控制平面控制,而不是在網格內的主叢集中執行控制平面。這可以實現隔離的管理,並將控制平面部署與組成網格的資料平面服務完全分離。

A single cluster with an external control plane
具有外部控制平面的單一叢集

雲端供應商的受管理的控制平面是外部控制平面的典型範例。

為了實現高可用性,您應該在叢集、區域或地區之間部署多個控制平面。

A service mesh with control plane instances for each region
每個地區都有控制平面實例的服務網格

此模型具有以下優點

  • 提高可用性:如果控制平面變得不可用,則中斷範圍僅限於該控制平面管理之叢集中的工作負載。

  • 配置隔離:您可以在一個叢集、區域或地區中進行配置變更,而不會影響其他叢集、區域或地區。

  • 受控推出:您可以更精細地控制配置推出(例如,一次一個叢集)。您也可以在給定主叢集控制的網格子部分中測試配置變更。

  • 選擇性服務可見性:您可以將服務可見性限制在網格的一部分,這有助於建立服務層級隔離。例如,管理員可能會選擇將 HelloWorld 服務部署到叢集 A,而不是叢集 B。任何嘗試從叢集 B 呼叫 HelloWorld 的操作都會使 DNS 查詢失敗。

以下清單依可用性排名控制平面部署範例

  • 每個地區一個叢集(最低可用性
  • 每個地區多個叢集
  • 每個區域一個叢集
  • 每個區域多個叢集
  • 每個叢集(最高可用性

具有多個控制平面的端點探索

Istio 控制平面透過為每個代理提供服務端點清單來管理網格內的流量。為了使此功能在多叢集情境中正常運作,每個控制平面都必須觀察每個叢集中 API 伺服器的端點。

為了為叢集啟用端點探索,管理員會產生一個 remote secret 並將其部署到網格中的每個主叢集。remote secret 包含憑證,允許存取叢集中的 API 伺服器。然後,控制平面將會連線並探索叢集的服務端點,為這些服務啟用跨叢集負載平衡。

Primary clusters with endpoint discovery
具有端點探索的主叢集

預設情況下,Istio 會在每個叢集中的端點之間均勻地負載平衡請求。在跨越地理區域的大型系統中,可能需要使用區域性負載平衡,以優先讓流量留在同一個區域或地區。

在某些進階情境中,可能不需要跨叢集負載平衡。例如,在藍/綠部署中,您可能會將不同版本的系統部署到不同的叢集。在這種情況下,每個叢集都實際上作為一個獨立的網格運作。可以透過幾種方式實現此行為

  • 請勿在叢集之間交換遠端密碼。這可以在叢集之間提供最強的隔離。

  • 使用 VirtualServiceDestinationRule 來禁止在兩個版本的服務之間進行路由。

無論是哪種情況,都會阻止跨叢集負載平衡。可以使用外部負載平衡器將外部流量路由到一個或另一個叢集。

身份和信任模型

當工作負載實例在服務網格中建立時,Istio 會為該工作負載指派一個身分

憑證授權機構 (CA) 會建立並簽署用於驗證網格內身分的憑證。您可以使用建立並簽署該身分憑證的 CA 公開金鑰,來驗證訊息傳送者的身分。信任組合是 Istio 網格使用的所有 CA 公開金鑰的集合。有了網格的信任組合,任何人都可以驗證來自該網格的任何訊息的傳送者。

網格內的信任

在單一 Istio 網格內,Istio 會確保每個工作負載實例都有一個適當的憑證來代表其自身的身分,以及識別網格內和任何聯邦網格的所有身分所需的信任組合。CA 會建立並簽署這些身分的憑證。此模型允許網格中的工作負載實例在通訊時相互驗證。

A service mesh with a common certificate authority
具有通用憑證授權機構的服務網格

網格之間的信任

若要啟用兩個具有不同 CA 的網格之間的通訊,您必須交換網格的信任組合。Istio 不提供任何工具來跨網格交換信任組合。您可以手動或使用諸如 SPIFFE 信任網域聯邦之類的協定自動交換信任組合。將信任組合匯入網格後,您可以為這些身分設定本機原則。

Multiple service meshes with different certificate authorities
具有不同憑證授權機構的多個服務網格

網格模型

Istio 支援將您所有的服務放在一個網格中,或將多個網格聯合在一起,這也稱為多網格

單一網格

最簡單的 Istio 部署是單一網格。在網格內,服務名稱是唯一的。例如,在 foo 命名空間中,只能有一個服務的名稱為 mysvc。此外,工作負載實例共用一個通用身分,因為服務帳戶名稱在命名空間內是唯一的,就像服務名稱一樣。

單一網格可以跨越一個或多個叢集一個或多個網路。在網格內,命名空間用於租戶

多個網格

多網格部署是由於網格聯合造成的。

多個網格提供了超越單一網格的以下功能

  • 組織邊界:業務線
  • 服務名稱或命名空間重用:default 命名空間的多個不同用途
  • 更強的隔離:將測試工作負載與生產工作負載隔離

您可以使用網格聯合來啟用網格間的通訊。聯合時,每個網格都可以公開一組服務和身分,所有參與的網格都可以識別這些服務和身分。

Multiple service meshes
多個服務網格

為了避免服務名稱衝突,您可以為每個網格提供一個全域唯一的 網格 ID,以確保每個服務的完整網域名稱 (FQDN) 是不同的。

當聯合兩個不共用相同信任網域的網格時,您必須在它們之間聯合身分信任組合。有關更多詳細資訊,請參閱關於網格之間的信任章節。

租戶模型

在 Istio 中,租戶是一組使用者,他們針對一組已部署的工作負載共用通用存取權限。租戶可以用於在不同團隊之間提供一定程度的隔離。

您可以設定租戶模型,以滿足以下組織隔離要求

  • 安全性
  • 原則
  • 容量
  • 成本
  • 效能

Istio 支援三種租戶模型

命名空間租戶

可以在多個團隊之間共用一個叢集,每個團隊使用不同的命名空間。您可以授予團隊權限,使其僅將其工作負載部署到給定的命名空間或一組命名空間。

預設情況下,來自多個命名空間的服務可以相互通訊,但是您可以通過選擇性地選擇要公開給其他命名空間的服務來增加隔離。您可以為公開的服務設定授權原則,以限制僅對適當的呼叫者進行存取。

A service mesh with two namespaces and an exposed service
具有兩個命名空間和一個公開服務的服務網格

命名空間租戶可以擴展到單一叢集之外。當使用多個叢集時,預設情況下,每個叢集中共用相同名稱的命名空間被視為相同的命名空間。例如,叢集 WestTeam-1 命名空間中的 Service B 和叢集 EastTeam-1 命名空間中的 Service B 指的是同一服務,並且 Istio 會合併它們的端點以進行服務探索和負載平衡。

A service mesh with two clusters with the same namespace
具有相同命名空間的叢集的服務網格

叢集租戶

Istio 支援將叢集用作租戶的單位。在這種情況下,您可以為每個團隊提供一個專用的叢集或一組叢集來部署其工作負載。叢集的權限通常僅限於擁有該叢集的團隊成員。您可以為更精細的控制設定各種角色,例如

  • 叢集管理員
  • 開發人員

若要搭配 Istio 使用叢集租戶,您可以為每個團隊的叢集配置各自的控制平面,讓每個團隊可以管理自己的配置。或者,您可以使用 Istio 將一組叢集作為單一租戶實現,方法是使用遠端叢集或多個同步的主叢集。詳細資訊請參考控制平面模型

網格租戶

在具有網格聯盟的多網格部署中,每個網格可以用作隔離的單位。

Two isolated service meshes with two clusters and two namespaces
兩個隔離的服務網格,具有兩個叢集和兩個命名空間

由於不同的團隊或組織操作每個網格,因此服務命名很少是不同的。例如,叢集 Team-1foo 命名空間中的 Service C 和叢集 Team-2foo 命名空間中的 Service C 服務將不會指向相同的服務。最常見的例子是在 Kubernetes 中,許多團隊將他們的工作負載部署到 default 命名空間中。

當每個團隊都有自己的網格時,跨網格的通信遵循多網格模型中描述的概念。

此資訊是否有用?
您是否有任何改進建議?

感謝您的回饋!