摸索：Istio 路由規則 Alpha v3

Istio 近期的版本中出現了一個新的 API 組：，應該會替代現有的 API。新的 API 不管是結構上還是功能上、以及命名上，都有很大差異。這裡使用一些簡單例子，體驗一下 Alpha 3 帶來的變化。

注意：正常情況下 istioctl 和 kubectl 都可以用來操作這些對象，但是 kubectl 缺乏驗證功能，因此調試階段使用 istioctl 會更方便一些。

路由分配

過去的路由分配比較簡單，使用標籤即可。新的版本中，提出了 的概念。VirtualService 由一組路由規則構成，用於對服務實體（原文為 Host，個人認為在 K8S 中對應為 Pod）進行定址。一旦有流量符合其中規則的選擇條件，就會發送流量給對應的服務（或者服務的一個版本/子集）。

流量的特徵除了請求數據之外，還包括流量的來源，這樣就能根據一些上下文來進行靈活的定義了。

這裡我們定義來自 sleep 對 php-server 的請求，都轉向 v1：

這裡的匹配策略是具有從上到下的優先順序的，也就是說，最下一條就是預設路由。

可以看到，中不再包含 ，這裡使用標籤來過濾。寫完應用之後，我們在 Sleep Pod 中使用 curl 發起請求，會發現並沒有生效。這是因為，在 v3 中，目標規則不再是小透明了。，路由定義必須以目標策略為基礎。

因此這裡需要定義一個 對象，來滿足上面的目標需求：

上面的文件，創建了名為 的目標規則，並在下級使用標籤創建了三個子集。再次測試，會發現按照我們的要求執行了。

注意：VirtualService 中引用的 Destination.name 似乎對應的是目標規則中的 spec.name，而不是 metadata.name。

斷路器

這部分的 API 變化較大。可以在上面的 DestinationRule 中加入熔斷策略：

接下來就可以使用 Fortio 或其他工具來測試熔斷效果了，具體操作可以參考官方文檔的斷路器一節

總結

新版本 API 加入了相當多的非 K8S 特性，另外突出了 Gateway，VirtualService 等主要對象，使得各個定義的條理性大為增強。但是目前這一組 API 仍然是 Alpha 階段，因此還是存在相當大的變數的，但是個人推測的是，新 API 會得到更大的支持力度，因此可靠性應該更強。總之 Alpha 有風險，使用需謹慎。

參考鏈接

:

：

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