我們將開始發布一系列帖子，展示 Istio 服務網格與紅帽 OpenShift 和 Kubernetes 結合使用時的眾多功能。
第一部分，今天：
- 讓我們解釋一下 Kubernetes sidecar 容器的概念，並闡述本系列文章的主題： “您不需要更改程式碼中的任何內容”.
- 讓我們來介紹一下 Istio 的基本東西——路由規則。 所有其他 Istio 功能都是基於它們構建的，因為它是允許您使用服務代碼外部的 YAML 檔案將流量引導到微服務的規則。 我們也正在考慮Canary Deployment部署方案。 新年獎勵 – 10 堂 Istio 互動課程
即將推出的第二部分將告訴您：
- Istio 如何與 Circuit Breaker 結合實現池彈出，並將演示 Istio 如何允許您從平衡電路中刪除死掉或性能不佳的 pod。
- 我們還將查看第一篇文章中的斷路器主題，以了解如何在此處使用 Istio。 我們將向您展示如何使用 YAML 設定檔和終端命令路由流量並處理網路錯誤，而無需對服務代碼進行絲毫更改。
第三部分：
- 一個關於追蹤和監控的故事，它們已經內建或可以輕鬆添加到 Istio 中。 我們將向您展示如何使用 Prometheus、Jaeger 和 Grafana 等工具結合 OpenShift 擴充功能來輕鬆管理微服務架構。
- 我們從監視和處理錯誤轉向有意將錯誤引入系統。 換句話說，我們學習如何在不更改原始程式碼的情況下進行故障注入，這從測試的角度來看非常重要 - 因為如果為此更改程式碼本身，則存在引入其他錯誤的風險。
最後，在 Istio Service Mesh 的最後一篇文章中：
- 讓我們去黑暗面吧。 更準確地說，我們將學習使用Dark Launch方案，當程式碼直接在生產資料上部署和測試時，但不會以任何方式影響系統的運作。 這就是 Istio 流量拆分能力派上用場的地方。 而在不以任何方式影響作戰系統運作的情況下對即時生產資料進行測試的能力是最有說服力的驗證方法。
- 在 Dark Launch 的基礎上，我們將向您展示如何使用金絲雀部署模型來降低風險並更輕鬆地將新程式碼投入生產。 Canary Deployment 本身並不是什麼新鮮事，但 Istio 允許您僅使用簡單的 YAML 檔案來實現此方案。
- 最後，我們將向您展示如何使用 Istio Egress 為叢集外部的人員提供對服務的存取權限，以便在使用 Internet 時使用 Istio 的功能。
那麼，我們開始吧...
Istio 監控和管理工具 - 在服務網格中編排微服務所需的一切 .
什麼是 Istio 服務網格
服務網格為一組服務實現流量監控、存取控制、發現、安全性、容錯和其他有用的功能。 Istio 允許您完成所有這一切，而無需對服務本身的程式碼進行絲毫更改。 魔法的秘密是什麼？ Istio 以sidecar 容器的形式將自己的代理附加到每個服務上（sidecar 是摩托車邊車），此後該服務的所有流量都經過該代理，該代理在指定策略的指導下決定該流量的方式、時間和是否應該完全達到服務。 Istio 也使得實現先進的 DevOps 技術成為可能，例如金絲雀部署、斷路器、故障注入等。
Istio 如何與容器和 Kubernetes 搭配使用
Istio 服務網格是創建和管理微服務所需的一切的邊車實現：監控、追蹤、斷路器、路由、負載平衡、故障注入、重試、超時、鏡像、存取控制、速率限制等等。 儘管現在有大量的庫可以直接在程式碼中實現這些功能，但使用 Istio，您無需更改程式碼中的任何內容即可獲得所有相同的功能。
根據 sidecar 模型，Istio 運行在一個 Linux 容器中，該容器位於一個 -pod 具有受控服務，並根據給定的配置注入和提取功能和資訊。 我們強調這是您自己的配置，它位於您的程式碼之外。 因此，程式碼變得更加簡單和簡短。
同樣重要的是，微服務的操作元件與程式碼本身沒有任何關係，這意味著它們的操作可以安全地轉移給 IT 專家。 確實，為什麼開發人員要負責斷路器和故障注入？ 反應，是的，但是處理它們並創建它們？ 如果從程式碼中刪除所有這些，程式設計師將能夠完全專注於應用程式功能。 且程式碼本身將變得更短、更簡單。
服務網格
Istio 實現了在程式碼之外管理微服務的功能，這是服務網格的概念。 換句話說，它是一個或多個二進位檔案的協調群組，形成網路功能網格。
Istio 如何與微服務搭配使用
這就是 sidecar 容器的工作原理 и 鳥瞰圖：啟動 Minishift 實例，為 Istio 建立一個專案（我們稱之為「istio-system」），安裝並執行所有 Istio 相關元件。 然後，當您建立專案和 pod 時，您可以將設定資訊新增至您的部署中，並且您的 pod 開始使用 Istio。 簡化圖如下：
現在您可以按順序更改 Istio 設置，例如，組織故障注入、支持 或其他 Istio 功能 - 所有這些都無需觸及應用程式本身的程式碼。 假設您希望將最大客戶（Foo Corporation）的使用者的所有網路流量重新導向到該網站的新版本。 為此，只需建立一個 Istio 路由規則，該規則將在使用者 ID 中尋找 @foocorporation.com 並進行相應的重定向。 對於所有其他用戶來說，什麼都不會改變。 在此期間，您將冷靜地測試網站的新版本。 請注意，您根本不需要讓開發人員參與其中。
你是否需要為此付出高昂的代價？
一點也不。 Istio 速度相當快，並且是用以下語言編寫的 且產生的開銷非常小。 此外，線上生產力可能的損失可以透過開發人員生產力的提高來抵消。 至少在理論上：不要忘記開發人員的時間是寶貴的。 至於軟體成本，Istio 是開源軟體，因此您可以免費取得和使用它。
自己掌握吧
紅帽開發者體驗團隊開發了深入的實踐 由 Istio（英文）編寫。 它可以在 Linux、MacOS 和 Windows 上運行，程式碼可在 Java 和 Node.js 中使用。
10 個關於 Istio 的互動課程
第 1 部分 - 適合初學者
Istio 簡介
30分鐘
讓我們熟悉 Service Mesh，了解如何在 OpenShift Kubernetes 叢集中安裝 Istio。
在 Istio 中部署微服務
30分鐘
我們使用 Istio 透過 Spring Boot 和 Vert.x 部署三個微服務。
第 2 塊 – 中級
Istio 中的監控和追蹤
60分鐘
我們將透過 Prometheus 和 Grafana 探索 Istio 的內建監控工具、自訂指標以及 OpenTracing。
Istio 中的簡單路由
60分鐘
了解如何使用簡單的規則在 Istio 中管理路由。
進階路由規則
60分鐘
讓我們來看看Istio的智慧路由、存取控制、負載平衡和速率限制。
第 3 塊 – 進階用戶
Istio 中的故障注入
60分鐘
我們研究分散式應用程式中的故障處理場景，創建 HTTP 錯誤和網路延遲，並學習使用混沌工程來恢復環境。
Istio 中的斷路器
30分鐘
我們為壓力測試站點安裝 Siege，並學習如何使用重播、斷路器和池彈出來確保後端容錯。
出口和 Istio
10分鐘
我們使用出口路由來建立內部服務與外部 API 和服務互動的規則。
Istio 和 Kiali
15分鐘
學習使用 Kiali 來概述服務網格並探索請求和資料流。
Istio 中的相互 TLS
15分鐘
我們建立 Istio Gateway 和 VirtualService，然後詳細研究雙向 TLS (mTLS) 及其設定。
區塊 3.1 - 深入探討：微服務的 Istio 服務網格
這本書講什麼的：
- 什麼是服務網格？
- Istio 系統及其在微服務架構中的作用。
- 使用Istio可以解決以下問題：
- 容錯；
- 路由;
- 混沌測試；
- 安全;
- 使用追蹤、指標和 Grafana 進行遙測收集。
有關服務網格和 Istio 的系列文章
自己嘗試一下
本系列文章的目的並不是要深入了解 Istio 的世界。 我們只是想向您介紹這個概念，並可能激勵您親自嘗試 Istio。 它完全免費，紅帽提供了您開始使用 OpenShift、Kubernetes、Linux 容器和 Istio 所需的所有工具，包括： , 以及我們的其他資源 。 事不宜遲，從今天開始吧！
Istio 路由規則：將服務請求導向至需要去的地方
и 出色地解決問題 路由到所需的 Pod。 這就是 Kubernetes 存在的原因之一——路由和負載平衡。 但是，如果您需要更微妙和複雜的路由怎麼辦？ 例如，同時使用微服務的兩個版本。 Istio 路由規則在這裡有何幫助？
路由規則是實際決定路由選擇的規則。 無論系統複雜程度如何，這些規則的一般操作原理仍然很簡單：根據某些參數和 HTTP 標頭值路由請求。
讓我們來看看例子：
Kubernetes 預設值：簡單的“50/50”
在我們的範例中，我們將展示如何在 OpenShift 中同時使用微服務的兩個版本，我們將它們稱為 v1 和 v2。 每個版本都在自己的 Kubernetes Pod 中運行，預設它運行均勻平衡的循環路由。 每個 Pod 根據其微服務實例（即副本）的數量接收其請求份額。 Istio 允許您手動更改此平衡。
假設我們在 OpenShift 上部署了兩個版本的建議服務：recommendation-v1 和recommendation-v2。
在圖中。 圖 1 顯示，當每個服務在一個實例中表示時，請求在它們之間均勻交替：1-2-1-2-...這就是 Kubernetes 路由預設的工作方式：
版本之間的加權分佈
在圖中。 圖 2 顯示如果將 v2 服務副本的數量從 2 個增加到 2 個（這是透過 oc scale —replicas=1 deployment/recommendation-v2 指令完成的）會發生什麼情況。 如您所見，v1 和 v2 之間的請求現在以一比三的比例劃分：2-1-2-2-XNUMX-XNUMX-…：
使用 Istio 忽略版本
Istio 可以輕鬆地按照我們需要的方式更改請求的分佈。 例如，使用以下 Istio yaml 檔案僅將所有流量傳送至recommendation-v1：
這裡要注意的是：pod是根據標籤來選擇的。 我們的範例使用標籤 v1。 「weight: 100」參數表示 100% 的流量將路由到所有具有 v1 標籤的服務 Pod。
版本之間的指令分發（金絲雀部署）
接下來，使用權重參數，您可以將流量導向兩個 Pod，忽略每個 Pod 中執行的微服務實例的數量。 例如，這裡我們將 90% 的流量定向到 v1，將 10% 定向到 v2：
為行動用戶提供單獨的路由
總而言之，我們將展示如何強制行動用戶流量路由到服務 v2，並將其他用戶流量路由到 v1。 為此，我們使用正規表示式來分析請求標頭中的用戶代理值：
現在輪到你
用於解析標頭的正規表示式範例應該會激勵您找到自己對 Istio 路由規則的使用。 此外，這裡的可能性非常廣泛，因為標頭值可以在應用程式原始程式碼中形成。
請記住，是運維，而不是開發
我們在上面的範例中展示的所有內容都是在沒有對原始程式碼進行絲毫更改的情況下完成的，除了需要產生特殊請求標頭的情況之外。 Istio 對開發人員很有用，例如，他們將能夠在測試階段使用它，而對 IT 系統操作專家來說，它將在生產中提供極大幫助。
讓我們重複這一系列文章的主題： 您不需要更改程式碼中的任何內容。 無需建置新映像或啟動新容器。 所有這些都是在程式碼之外實現的。
動用你的想像力
想像一下使用正規表示式進行標頭分析的可能性。 想要將您最大的客戶重新導向到您的特殊版本 ？ 容易！ 需要 Chrome 瀏覽器的單獨版本嗎？ 沒問題！ 您可以根據幾乎任何特徵來路由流量。
自己嘗試一下
閱讀 Istio、Kubernetes 和 OpenShift 是一回事，但為什麼不親自接觸所有內容呢？ 團隊 我們準備了詳細的指南（英文），幫助您盡快掌握這些技巧。 該手冊也是 100% 開源的，因此它發佈在公共領域。 該檔案適用於 macOS、Linux 和 Windows，原始程式碼有 Java 和 Node.js 版本（其他語言版本即將推出）。 只需在瀏覽器中開啟對應的git倉庫即可 .
在下一篇文章中：我們完美地解決了問題
今天您了解了 Istio 路由規則的功能。 現在想像同樣的事情，但僅與錯誤處理有關。 這正是我們將在下一篇文章中討論的內容。
來源： www.habr.com