Istio v1aplha3 routing API介紹

目錄

設計原則

v1alpha3中的配置資源

Gateway

VirtualService

DestinationRule

ServiceEntry

創建和刪除v1alpha3路由規則

總結

致謝

到目前為止，Istio提供了一個簡單的API來進行流量管理，該API包括了四種資源：RouteRule，DestinationPolicy，EgressRule和Ingress（直接使用了Kubernets的Ingress資源）。藉助此API，用戶可以輕鬆管理Istio服務網格中的流量。該API允許用戶將請求路由到特定版本的服務，為彈性測試注入延遲和失敗，添加超時和斷路器等等，所有這些功能都不必更改應用程序本身的代碼。

雖然目前API的功能已被證明是Istio非常引人注目的一部分，但用戶的反饋也表明，這個API確實有一些缺點，尤其是在使用它來管理包含數千個服務的非常大的應用程序，以及使用HTTP以外的協議時。 此外，使用Kubernetes Ingress資源來配置外部流量的方式已被證明不能滿足需求。

為了解決上述缺陷和其他的一些問題，Istio引入了新的流量管理API v1alpha3，新版本的API將完全取代之前的API。 儘管v1alpha3和之前的模型在本質上是基本相同的，但它並不向後兼容的，基於舊API的模型需要進行手動轉換。 Istio接下來的幾個版本中會提供一個新舊模型的轉換工具。

為了證明該非兼容升級的必要性，v1alpha3 API經歷了漫長而艱苦的社區評估過程，以希望新的API能夠大幅改進，並經得起時間考驗。 在本文中，我們將介紹新的配置模型，並試圖解釋其後面的一些動機和設計原則。

設計原則

路由模型的重構過程中遵循了一些關鍵的設計原則：

除支持聲明式（意圖）配置外，也支持顯式指定模型依賴的基礎設施。例如，除了配置入口網關（的功能特性）之外，負責實現 入口網關功能的組件（Controller）也可以在模型指定。

編寫模型時應該「生產者導向」和「以Host為中心」，而不是通過組合多個規則來編寫模型。 例如，所有與特定Host關聯的規則被配置在一起，而不是單獨配置。

將路由與路由後行為清晰分開。

v1alpha3中的配置資源

在一個典型的網格中，通常有一個或多個用於終結外部TLS鏈接，將流量引入網格的負載均衡器（我們稱之為gateway）。 然後流量通過邊車網關（sidecar gateway）流經內部服務。 應用程序使用外部服務的情況也很常見（例如訪問Google Maps API），一些情況下，這些外部服務可能被直接調用；但在某些部署中，網格中所有訪問外部服務的流量可能被要求強制通過專用的出口網關（Egress gateway）。 下圖描繪了網關在網格中的使用情況。

考慮到上述因素，引入了以下這些新的配置資源來控制進入網格，網格內部和離開網格的流量路由。

，和分別替換了原API中的，和。 是一個獨立於平台的抽象，用於對流入專用中間設備的流量進行建模。

下圖描述了跨多個配置資源的控制流程。

Gateway

Gateway用於為HTTP / TCP流量配置負載均衡器，並不管該負載均衡器將在哪裡運行。 網格中可以存在任意數量的Gateway，並且多個不同的Gateway實現可以共存。 實際上，通過在配置中指定一組工作負載（Pod）標籤，可以將Gateway配置綁定到特定的工作負載，從而允許用戶通過編寫簡單的Gateway Controller來重用現成的網路設備。

對於入口流量管理，您可能會問： 為什麼不直接使用Kubernetes Ingress API ？ 原因是Ingress API無法表達Istio的路由需求。 Ingress試圖在不同的HTTP代理之間取一個公共的交集，因此只能支持最基本的HTTP路由，最終導致需要將代理的其他高級功能放入到註解（annotation）中，而註解的方式在多個代理之間是不兼容的，無法移植。

Istio 通過將L4-L6配置與L7配置分離的方式克服了的這些缺點。 只用於配置L4-L6功能（例如，對外公開的埠，TLS配置），所有主流的L7代理均以統一的方式實現了這些功能。 然後，通過在上綁定的方式，可以使用標準的Istio規則來控制進入的HTTP和TCP流量。

例如，下面這個簡單的配置了一個Load Balancer，以允許訪問hostbookinfo.com的https外部流量入mesh中：

要為進入上面的Gateway的流量配置相應的路由，必須為同一個host定義一個（在下一節中描述），並使用配置中的欄位綁定到前面定義的 上：

Gateway可以用於建模邊緣代理或純粹的內部代理，如第一張圖所示。 無論在哪個位置，所有網關都可以用相同的方式進行配置和控制。

VirtualService

用一種叫做「Virtual services」的東西代替路由規則可能看起來有點奇怪，但對於它配置的內容而言，這事實上是一個更好的名稱，特別是在重新設計API以解決先前模型的可擴展性問題之後。

實際上，發生的變化是：在之前的模型中，需要用一組相互獨立的配置規則來為特定的目的服務設置路由規則，並通過precedence欄位來控制這些規則的順序；在新的API中，則直接對（虛擬）服務進行配置，該虛擬服務的所有規則以一個有序列表的方式配置在對應的VirtualService 資源中。

例如，之前在Bookinfo 應用程序的reviews服務中有兩個RouteRule資源，如下所示：

在，可以在單個資源中提供相同的配置：

正如你所看到的， 和reviews服務相關的兩個規則集中寫在了一個地方。這個改變乍一看可能覺得並沒有什麼特別的優勢， 然而，如果仔細觀察這個新模型，會發現它和之前的API之間存在著根本的差異，這使得v1alpha3功能更加強大。

首先，請注意的目標服務是使用欄位（實際上是重複欄位）指定的，然後再在每個路由的欄位中指定。 這是與以前模型的重要區別。

描述了一個或多個用戶可定址目標到網格內實際工作負載之間的映射。在上面的示例中，這兩個地址是相同的，但實際上用戶可定址目標可以是任何用於定位服務的，具有可選通配符前綴或CIDR前綴的DNS名稱。 這對於應用從單體架構到微服務架構的遷移過程特別有用，單體應用被拆分為多個獨立的微服務後，採用VirtaulService可以繼續把多個微服務對外暴露為同一個目標地址，而不需要服務消費者進行修改以適應該變化。

例如，以下規則允許服務消費者訪問Bookinfo應用程序的reviews和ratings服務，就好像它們是（虛擬）服務的一部分：

實際上在｀VirtualService｀中hosts部分設置只是虛擬的目的地,因此不一定是已在網格中註冊的服務。這允許用戶為在網格內沒有可路由條目的虛擬主機的流量進行建模。 通過將綁定到同一Host的配置（如前一節所述 ），可向網格外部暴露這些Host。

除了這個重大的重構之外， 還包括其他一些重要的改變：

DestinationRule

DestinationRule配置將流量轉發到服務時應用的策略集。 這些策略應由由服務提供者撰寫，用於描述斷路器，負載均衡設置，TLS設置等。 除了下述改變外，與其前身大致相同。

DestinationRule的可以包含通配符前綴，以允許單個規則應用於多個服務。

定義了目的host的子集 （例如：命名版本）。 這些subset用於｀VirtualService｀的路由規則設置中，可以將流量導向服務的某些特定版本。 通過這種方式為版本命名後，可以在不同的virtual service中明確地引用這些命名版本的ubset，簡化Istio代理髮出的統計數據，並可以將subsets編碼到SNI頭中。 為reviews服務配置策略和subsets的可能如下所示：

注意，與不同的是，可在單個中指定多個策略（例如上面實例中的預設策略和v2版本特定的策略）。

ServiceEntry

ServiceEntry用於將附加條目添加到Istio內部維護的服務註冊表中。 它最常用於對訪問網格外部依賴的流量進行建模，例如訪問Web上的API或遺留基礎設施中的服務。

所有以前使用進行配置的內容都可以通過輕鬆完成。 例如，可以使用類似這樣的配置來允許從網格內部訪問一個簡單的外部服務：

也就是說，比它的前身具有更多的功能。首先，不限於外部服務配置，它可以有兩種類型：網格內部或網格外部。網格內部條目只是用於向網格顯式添加服務，添加的服務與其他內部服務一樣。採用網格內部條目，可以把原本未被網格管理的基礎設施也納入到網格中（例如，把虛機中的服務添加到基於Kubernetes的服務網格中）。網格外部條目則代表了網格外部的服務。對於這些外部服務來說，mTLS身份驗證是禁用的，並且策略是在客戶端執行的，而不是在像內部服務請求一樣在伺服器端執行策略。

由於配置只是將服務添加到網格內部的服務註冊表中，因此它可以像註冊表中的任何其他服務一樣,與和/或一起使用。例如，以下可用於啟動外部服務的mTLS連接：

除了擴展通用性以外，還提供了其他一些有關改進，其中包括：

一個可以配置多個服務端點，這在之前需要採用多個來實現。

現在可以配置服務端點的解析模式（，或）。

此外，我們正在努力解決另一個難題：目前需要通過純文本埠訪問安全的外部服務（例如）。該問題將會在未來幾周內得到解決，屆時將允許從應用程序直接訪問。請繼續關註解決此限制的Istio補丁版本（0.8.x）。

創建和刪除v1alpha3路由規則

由於一個特定目的地的所有路由規則現在都存儲在單個資源的一個有序列表中，因此為該目的地添加新的規則不需要再創建新的，而是通過更新該目的地的資源來實現。

舊的路由規則：

路由規則：

刪除路由規則也使用istioctl replace完成，當然刪除最後一個路由規則除外（刪除最後一個路由規則需要刪除）。

在添加或刪除引用服務版本的路由時，需要在該服務相應的更新subsets 。 正如你可能猜到的，這也是使用完成的。

總結

Istio 路由API具有比其前身更多的功能，但不幸的是新的API並不向後兼容，舊的模型升級需要一次手動轉換。 Istio 0.9以後將不再支持，和這些以前的配置資源 。Kubernetes用戶可以繼續使用配置邊緣負載均衡器來實現基本的路由。 但是，高級路由功能（例如，跨兩個版本的流量分割）則需要使 ，這是一種功能更強大，Istio推薦的替代品。

致謝

感謝以下人員為新版本的路由模型重構和實現工作做出的貢獻（按字母順序）

Frank Budinsky (IBM)

Zack Butcher (Google)

Greg Hanson (IBM)

Costin Manolache (Google)

Martin Ostrowski (Google)

Shriram Rajagopalan (VMware)

Louis Ryan (Google)

Isaiah Snell-Feikema (IBM)

Kuat Yessenov (Google)

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！